dri-devel June 2012

dri-devel@lists.freedesktop.org

125 participants
696 discussions

[ANNOUNCE] libdrm 2.4.35
by Alex Deucher 07 Jun '12

07 Jun '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Deucher (3): radeon: add new pci ids radeon: fall back to 1D tiling only with broken kernels configure: bump version for release Ben Widawsky (2): intel: sanitize i915_drm.h intel: wait render header updates Inki Dae (1): libdrm: add exynos drm support Michel Dänzer (1): radeon: Add Southern Islands PCI IDs. git tag: libdrm-2.4.35 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.35.tar.bz2 MD5: a40f5293dc0a7b49d2a1e959d7d60194 libdrm-2.4.35.tar.bz2 SHA1: a1d8d4945f782371d7855dbd693db885bd7e3d83 libdrm-2.4.35.tar.bz2 SHA256: c390aee132f05910edb09398b70e108c6b53f9b69b21914a9ea3165eed6f1b21 libdrm-2.4.35.tar.bz2 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.35.tar.gz MD5: 77992a226118a55e214f315bf23d4273 libdrm-2.4.35.tar.gz SHA1: e59f1607a33488e0c7d0ec7bb230777d09bbd788 libdrm-2.4.35.tar.gz SHA256: b5fa1e1a1abe263e1e62af4f3a5515c53c6aca35a713bfbaa173402b32f637be libdrm-2.4.35.tar.gz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk/QxFQACgkQm07k+YR03kBjZgCgpJGQ0GnPYUgdIgksRTBCm7yL TxcAn3utXITwGobX6qWd0/RbpsNNTTyz =QXk0 -----END PGP SIGNATURE-----

1 0

[PATCH 1/2] drm: drmIoctl return -errno on failure conditions
by Ben Widawsky 07 Jun '12

07 Jun '12

Anyone aware of what this will break? It seems to be a much nicer thing to do for callers. If people do not like it, I will probably just create a #define drmIoctl2 or some such thing. Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Keith Packard <keithp(a)keithp.com> Signed-off-by: Ben Widawsky <ben(a)bwidawsk.net> --- xf86drm.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xf86drm.c b/xf86drm.c index 6ea068f..015203d 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -166,6 +166,10 @@ drmIoctl(int fd, unsigned long request, void *arg) do { ret = ioctl(fd, request, arg); } while (ret == -1 && (errno == EINTR || errno == EAGAIN)); + + if (ret) + return -errno; + return ret; } -- 1.7.10.3

3 4

[PATCH libdrm 0/8] Latest properties patches
by Rob Clark 07 Jun '12

07 Jun '12

From: Rob Clark <rob(a)ti.com> The first 6 patches are a re-send of what has already been sent by Paulo and myself, and the last two add bitmask and plane properties support to proptest as suggested by Paulo. I can push these to libdrm git tree if ok. Paulo Zanoni (3): Add support for generic object properties IOCTLs modetest: print CRTC properties tests: add proptest Rob Clark (5): Add support for bitmask properties modetest: support bitmask properties modetest: support plane properties proptest: support bitmask properties proptest: support plane properties configure.ac | 1 + include/drm/drm.h | 2 + include/drm/drm_mode.h | 25 ++++ tests/Makefile.am | 2 +- tests/modetest/modetest.c | 37 +++++ tests/proptest/Makefile.am | 11 ++ tests/proptest/proptest.c | 357 ++++++++++++++++++++++++++++++++++++++++++++ xf86drmMode.c | 87 ++++++++++- xf86drmMode.h | 14 ++ 9 files changed, 533 insertions(+), 3 deletions(-) create mode 100644 tests/proptest/Makefile.am create mode 100644 tests/proptest/proptest.c -- 1.7.9.5

2 11

RE: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices
by Tom Cooksey 07 Jun '12

07 Jun '12

> >>> The bigger issue is the previous point about how to deal > >>> with cases where the CPU doesn't really need to get involved as an > >>> intermediary. > >>> > >>> CPU fallback access to the buffer is the only legit case where we > >>> need a standardized API to userspace (since CPU access isn't already > >>> associated w/ some other kernel device file where some extra ioctl > >>> can be added) > >> > >> The CPU case will still need to wait on an arbitrarily backed sync > >> primitive. It shouldn't need to know if it's backed by the gpu, > >> camera, or dsp. > > > > Right, this is the one place we definitely need something.. some > > userspace code would just get passed a dmabuf file descriptor and > > want to mmap it and do something, without really knowing where it > > came from. I *guess* we'll have to add some ioctl's to the dmabuf > > fd. > > I personally favor having sync primitives have their own anon inode > vs. strictly coupling them with dma_buf. I think this is really the crux of the matter - do we associate sync objects with buffers or not. The approach ARM are suggesting _is_ to associate the sync objects with the buffer and do this by adding kds_resource* as a member of struct dma_buf. The main reason I want to do this is because it doesn't require changes to existing interfaces. Specifically, DRM/KMS & v4l2. These user/kernel interfaces already allow userspace to specify the handle of a buffer the driver should perform an operation on. What dma_buf has done is allowed those driver-specific buffer handles to be exported from one driver and imported into another. While new ioctls have been added to the v4l2 & DRM interfaces for dma_buf, they have only been to allow the import & export of driver-specific buffer objects. Once imported as a driver specific buffer object, existing ioctls are re-used to perform operations on those buffers (at least this is what PRIME does for DRM, I'm not so sure about v4l2?). But my point is that no new "page flip to this dma_buf fd" ioctl has been added to KMS, you use the existing drm_mode_crtc_page_flip and specify an fb_id which has been imported from a dma_buf. If we associate sync objects with buffers, none of those device specific ioctls which perform operations on buffer objects need to be modified. It's just that internally, those drivers use kds or something similar to make sure they don't tread on each other's toes. The alternate is to not associate sync objects with buffers and have them be distinct entities, exposed to userspace. This gives userpsace more power and flexibility and might allow for use-cases which an implicit synchronization mechanism can't satisfy - I'd be curious to know any specifics here. However, every driver which needs to participate in the synchronization mechanism will need to have its interface with userspace modified to allow the sync objects to be passed to the drivers. This seemed like a lot of work to me, which is why I prefer the implicit approach. However I don't actually know what work is needed and think it should be explored. I.e. How much work is it to add explicit sync object support to the DRM & v4l2 interfaces? E.g. I believe DRM/GEM's job dispatch API is "in-order" in which case it might be easy to just add "wait for this fence" and "signal this fence" ioctls. Seems like vmwgfx already has something similar to this already? Could this work over having to specify a list of sync objects to wait on and another list of sync objects to signal for every operation (exec buf/page flip)? What about for v4l2? I guess my other thought is that implicit vs explicit is not mutually exclusive, though I'd guess there'd be interesting deadlocks to have to debug if both were in use _at the same time_. :-) Cheers, Tom

1 0

[Bug 13364] BUG: unable to handle kernel paging request at 429a4c40
by bugzilla-daemon＠bugzilla.kernel.org 07 Jun '12

07 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=13364 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

[Bug 13364] BUG: unable to handle kernel paging request at 429a4c40
by bugzilla-daemon＠bugzilla.kernel.org 07 Jun '12

07 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=13364 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |alan(a)lxorguk.ukuu.org.uk Resolution| |OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 0

[Bug 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs
by bugzilla-daemon＠bugzilla.kernel.org 07 Jun '12

07 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=13249 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 13249] Intel 945GM: Boot option`vga=0x31a' breaks display of TTYs
by bugzilla-daemon＠bugzilla.kernel.org 07 Jun '12

07 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=13249 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED CC| |alan(a)lxorguk.ukuu.org.uk Resolution| |OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[PATCHv6 00/13] Integration of videobuf2 with dmabuf
by Tomasz Stanislawski 07 Jun '12

07 Jun '12

Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use 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 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-dma-contig: add support for dma_buf importing Tomasz Stanislawski (5): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: Remove unneeded allocation context structure v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation/DocBook/media/v4l/compat.xml | 4 + Documentation/DocBook/media/v4l/io.xml | 179 +++++++ .../DocBook/media/v4l/vidioc-create-bufs.xml | 1 + Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 45 +- drivers/media/video/s5p-fimc/Kconfig | 1 + drivers/media/video/s5p-fimc/fimc-capture.c | 2 +- drivers/media/video/s5p-tv/Kconfig | 1 + drivers/media/video/s5p-tv/mixer_video.c | 2 +- drivers/media/video/v4l2-ioctl.c | 1 + drivers/media/video/videobuf-core.c | 4 + drivers/media/video/videobuf2-core.c | 207 +++++++- drivers/media/video/videobuf2-dma-contig.c | 520 +++++++++++++++++--- include/linux/videodev2.h | 7 + include/media/videobuf2-core.h | 34 ++ 15 files changed, 924 insertions(+), 99 deletions(-) -- 1.7.9.5

8 30

Re: Synchronization framework
by Maarten Lankhorst 07 Jun '12

07 Jun '12

Hey, For intel/nouveau hybrid graphics I'm interested in this since it would allow me to synchronize between intel and nvidia cards without waiting for rendering to complete. I'm worried about the api though, nouveau and intel already have existing infrastructure to deal with fencing so exposing additional ioctl's will complicate the implementation. Would it be possible to never expose this interface to userspace but keep it inside the kernel only? nouveau_gem_ioctl_pushbuf is what's used for nouveau. If any dmabuf synch framework could hook into that then userspace would never have to act differently on shared bo's. I haven't looked at intel and amd, but from a quick glance it seems like they already implement fencing too, so just some way to synch up the fences on shared buffers seems like it could benefit all graphics drivers and the whole userspace synching could be done away with entirely. Cheers, Maarten

1 0

← Newer
1
...
62
63
64
65
66
67
68
69
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2012