Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

2 participants
2906 discussions

[PATCH v9 0/3] Secure Memory Allocation Framework

by Benjamin Gaignard

version 9 changes: - rebased on 4.8-rc5 - struct dma_attrs doesn't exist anymore so update CMA allocator to compile with new dma_*_attr functions - add example SMAF use case in cover letter version 8 changes: - rework of the structures used within ioctl by adding a version field and padding to be futur proof - rename fake secure moduel to test secure module - fix the various remarks done on the previous patcheset version 7 changes: - rebased on kernel 4.6-rc7 - simplify secure module API - add vma ops to be able to detect mmap/munmap calls - add ioctl to get number and allocator names - update libsmaf with adding tests https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - add debug log in fake secure module version 6 changes: - rebased on kernel 4.5-rc4 - fix mmapping bug while requested allocation size isn't a a multiple of PAGE_SIZE (add a test for this in libsmaf) version 5 changes: - rebased on kernel 4.3-rc6 - rework locking schema and make handle status use an atomic_t - add a fake secure module to allow performing tests without trusted environment version 4 changes: - rebased on kernel 4.3-rc3 - fix missing EXPORT_SYMBOL for smaf_create_handle() version 3 changes: - Remove ioctl for allocator selection instead provide the name of the targeted allocator with allocation request. Selecting allocator from userland isn't the prefered way of working but is needed when the first user of the buffer is a software component. - Fix issues in case of error while creating smaf handle. - Fix module license. - Update libsmaf and tests to care of the SMAF API evolution https://git.linaro.org/people/benjamin.gaignard/libsmaf.git version 2 changes: - Add one ioctl to allow allocator selection from userspace. This is required for the uses case where the first user of the buffer is a software IP which can't perform dma_buf attachement. - Add name and ranking to allocator structure to be able to sort them. - Create a tiny library to test SMAF: https://git.linaro.org/people/benjamin.gaignard/libsmaf.git - Fix one issue when try to secure buffer without secure module registered SMAF aim to solve two problems: allocating memory that fit with hardware IPs constraints and secure those data from bus point of view. One example of SMAF usage is camera preview: on SoC you may use either an USB webcam or the built-in camera interface and the frames could be send directly to the dipslay Ip or handle by GPU. Most of USB interfaces and GPU have mmu but almost all built-in camera interace and display Ips don't have mmu so when selecting how allocate buffer you need to be aware of each devices constraints (contiguous memroy, stride, boundary, alignment ...). ION has solve this problem by let userland decide which allocator (heap) to use but this require to adapt userland for each platform and sometime for each use case. To be sure to select the best allocation method for devices SMAF implement deferred allocation mechanism: memory allocation is only done when the first device effectively required it. Allocator modules have to implement a match() to let SMAF know if they are compatibles with devices needs. This patch set provide an example of allocator module which use dma_{alloc/free/mmap}_attrs() and check if at least one device have coherent_dma_mask set to DMA_BIT_MASK(32) in match function. In the same camera preview use case, SMAF allow to protect the data from being read by unauthorized IPs (i.e. a malware to dump camera stream). Until now I have only see access rights protection at process/thread level (PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus firewalls. SMAF propose an interface to control and implement those firewalls. Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty devices that are attempting DMA attacks. Secure modules are responsibles of granting and revoking devices access rights on the memory. Secure module is also called to check if CPU map memory into kernel and user address spaces. An example of secure module implementation can be found here: http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git This code isn't yet part of the patch set because it depends on generic TEE which is still under discussion (https://lwn.net/Articles/644646/) For allocation part of SMAF code I get inspirated by Sumit Semwal work about constraint aware allocator. Benjamin Gaignard (3): create SMAF module SMAF: add CMA allocator SMAF: add test secure module drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/smaf/Kconfig | 17 + drivers/smaf/Makefile | 3 + drivers/smaf/smaf-cma.c | 186 ++++++++++ drivers/smaf/smaf-core.c | 818 +++++++++++++++++++++++++++++++++++++++++ drivers/smaf/smaf-testsecure.c | 90 +++++ include/linux/smaf-allocator.h | 45 +++ include/linux/smaf-secure.h | 65 ++++ include/uapi/linux/smaf.h | 85 +++++ 10 files changed, 1312 insertions(+) create mode 100644 drivers/smaf/Kconfig create mode 100644 drivers/smaf/Makefile create mode 100644 drivers/smaf/smaf-cma.c create mode 100644 drivers/smaf/smaf-core.c create mode 100644 drivers/smaf/smaf-testsecure.c create mode 100644 include/linux/smaf-allocator.h create mode 100644 include/linux/smaf-secure.h create mode 100644 include/uapi/linux/smaf.h -- 1.9.1

8 years, 9 months

Re: [Linaro-mm-sig] [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

by Rob Clark

Tom, hmm, I wonder if it was a bug/oversight for the YUV capabilities of this extension to not depend on OES_EGL_image_external (which unfortunately, doesn't seem to have a GL counterpart)? I think this currently implies that you could sample from an imported YUV eglimg using (for example) sampler2D in GL or GLES, which I think was not the intention. BR, -R On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey <tom.cooksey(a)arm.com> wrote: > Hi All, > > The final spec has had enum values assigned and been published on Khronos: > > http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_im… > > Thanks to all who've provided input. > > > Cheers, > > Tom > > > >> -----Original Message----- >> From: mesa-dev-bounces+tom.cooksey=arm.com(a)lists.freedesktop.org [mailto:mesa-dev- >> bounces+tom.cooksey=arm.com(a)lists.freedesktop.org] On Behalf Of Tom Cooksey >> Sent: 04 October 2012 13:10 >> To: mesa-dev(a)lists.freedesktop.org; linaro-mm-sig(a)lists.linaro.org; dri- >> devel(a)lists.freedesktop.org; linux-media(a)vger.kernel.org >> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft! >> >> Hi All, >> >> After receiving a fair bit of feedback (thanks!), I've updated the >> EGL_EXT_image_dma_buf_import spec >> and expanded it to resolve a number of the issues. Please find the latest draft below and let >> me >> know any additional feedback you might have, either on the lists or by private e-mail - I >> don't mind >> which. >> >> I think the only remaining issue now is if we need a mechanism whereby an application can >> query >> which drm_fourcc.h formats EGL supports or if just failing with EGL_BAD_MATCH when the >> application >> has use one EGL doesn't support is sufficient. Any thoughts? >> >> >> Cheers, >> >> Tom >> >> >> --------------------8<-------------------- >> >> >> Name >> >> EXT_image_dma_buf_import >> >> Name Strings >> >> EGL_EXT_image_dma_buf_import >> >> Contributors >> >> Jesse Barker >> Rob Clark >> Tom Cooksey >> >> Contacts >> >> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) >> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com) >> >> Status >> >> DRAFT >> >> Version >> >> Version 4, October 04, 2012 >> >> Number >> >> EGL Extension ??? >> >> Dependencies >> >> EGL 1.2 is required. >> >> EGL_KHR_image_base is required. >> >> The EGL implementation must be running on a Linux kernel supporting the >> dma_buf buffer sharing mechanism. >> >> This extension is written against the wording of the EGL 1.2 Specification. >> >> Overview >> >> This extension allows creating an EGLImage from a Linux dma_buf file >> descriptor or multiple file descriptors in the case of multi-plane YUV >> images. >> >> New Types >> >> None >> >> New Procedures and Functions >> >> None >> >> New Tokens >> >> Accepted by the <target> parameter of eglCreateImageKHR: >> >> EGL_LINUX_DMA_BUF_EXT >> >> Accepted as an attribute in the <attrib_list> parameter of >> eglCreateImageKHR: >> >> EGL_LINUX_DRM_FOURCC_EXT >> EGL_DMA_BUF_PLANE0_FD_EXT >> EGL_DMA_BUF_PLANE0_OFFSET_EXT >> EGL_DMA_BUF_PLANE0_PITCH_EXT >> EGL_DMA_BUF_PLANE1_FD_EXT >> EGL_DMA_BUF_PLANE1_OFFSET_EXT >> EGL_DMA_BUF_PLANE1_PITCH_EXT >> EGL_DMA_BUF_PLANE2_FD_EXT >> EGL_DMA_BUF_PLANE2_OFFSET_EXT >> EGL_DMA_BUF_PLANE2_PITCH_EXT >> EGL_YUV_COLOR_SPACE_HINT_EXT >> EGL_SAMPLE_RANGE_HINT_EXT >> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT >> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT >> >> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute: >> >> EGL_ITU_REC601_EXT >> EGL_ITU_REC709_EXT >> EGL_ITU_REC2020_EXT >> >> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute: >> >> EGL_YUV_FULL_RANGE_EXT >> EGL_YUV_NARROW_RANGE_EXT >> >> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & >> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes: >> >> EGL_YUV_CHROMA_SITING_0_EXT >> EGL_YUV_CHROMA_SITING_0_5_EXT >> >> >> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation) >> >> Add to section 2.5.1 "EGLImage Specification" (as defined by the >> EGL_KHR_image_base specification), in the description of >> eglCreateImageKHR: >> >> "Values accepted for <target> are listed in Table aaa, below. >> >> +-------------------------+--------------------------------------------+ >> | <target> | Notes | >> +-------------------------+--------------------------------------------+ >> | EGL_LINUX_DMA_BUF_EXT | Used for EGLImages imported from Linux | >> | | dma_buf file descriptors | >> +-------------------------+--------------------------------------------+ >> Table aaa. Legal values for eglCreateImageKHR <target> parameter >> >> ... >> >> If <target> is EGL_LINUX_DMA_BUF_EXT, <dpy> must be a valid display, <ctx> >> must be EGL_NO_CONTEXT, and <buffer> must be NULL, cast into the type >> EGLClientBuffer. The details of the image is specified by the attributes >> passed into eglCreateImageKHR. Required attributes and their values are as >> follows: >> >> * EGL_WIDTH & EGL_HEIGHT: The logical dimensions of the buffer in pixels >> >> * EGL_LINUX_DRM_FOURCC_EXT: The pixel format of the buffer, as specified >> by drm_fourcc.h and used as the pixel_format parameter of the >> drm_mode_fb_cmd2 ioctl. >> >> * EGL_DMA_BUF_PLANE0_FD_EXT: The dma_buf file descriptor of plane 0 of >> the image. >> >> * EGL_DMA_BUF_PLANE0_OFFSET_EXT: The offset from the start of the >> dma_buf of the first sample in plane 0, in bytes. >> >> * EGL_DMA_BUF_PLANE0_PITCH_EXT: The number of bytes between the start of >> subsequent rows of samples in plane 0. May have special meaning for >> non-linear formats. >> >> For images in an RGB color-space or those using a single-plane YUV format, >> only the first plane's file descriptor, offset & pitch should be specified. >> For semi-planar YUV formats, the chroma samples are stored in plane 1 and >> for fully planar formats, U-samples are stored in plane 1 and V-samples are >> stored in plane 2. Planes 1 & 2 are specified by the following attributes, >> which have the same meanings as defined above for plane 0: >> >> * EGL_DMA_BUF_PLANE1_FD_EXT >> * EGL_DMA_BUF_PLANE1_OFFSET_EXT >> * EGL_DMA_BUF_PLANE1_PITCH_EXT >> * EGL_DMA_BUF_PLANE2_FD_EXT >> * EGL_DMA_BUF_PLANE2_OFFSET_EXT >> * EGL_DMA_BUF_PLANE2_PITCH_EXT >> >> In addition to the above required attributes, the application may also >> provide hints as to how the data should be interpreted by the GL. If any of >> these hints are not specified, the GL will guess based on the pixel format >> passed as the EGL_LINUX_DRM_FOURCC_EXT attribute or may fall-back to some >> default value. Not all GLs will be able to support all combinations of >> these hints and are free to use whatever settings they choose to achieve >> the closest possible match. >> >> * EGL_YUV_COLOR_SPACE_HINT_EXT: The color-space the data is in. Only >> relevant for images in a YUV format, ignored when specified for an >> image in an RGB format. Accepted values are: >> EGL_ITU_REC601_EXT, EGL_ITU_REC709_EXT & EGL_ITU_REC2020_EXT. >> >> * EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & >> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT: Where chroma samples are >> sited relative to luma samples when the image is in a sub-sampled >> format. When the image is not using chroma sub-sampling, the luma and >> chroma samples are assumed to be co-sited. Siting is split into the >> vertical and horizontal and is in a fixed range. A siting of zero >> means the first luma sample is taken from the same position in that >> dimension as the chroma sample. This is best illustrated in the >> diagram below: >> >> (0.5, 0.5) (0.0, 0.5) (0.0, 0.0) >> + + + + + + + + * + * + >> x x x x >> + + + + + + + + + + + + >> >> + + + + + + + + * + * + >> x x x x >> + + + + + + + + + + + + >> >> Luma samples (+), Chroma samples (x) Chrome & Luma samples (*) >> >> Note this attribute is ignored for RGB images and non sub-sampled >> YUV images. Accepted values are: EGL_YUV_CHROMA_SITING_0_EXT (0.0) >> & EGL_YUV_CHROMA_SITING_0_5_EXT (0.5) >> >> * EGL_SAMPLE_RANGE_HINT_EXT: The numerical range of samples. Only >> relevant for images in a YUV format, ignored when specified for >> images in an RGB format. Accepted values are: EGL_YUV_FULL_RANGE_EXT >> (0-256) & EGL_YUV_NARROW_RANGE_EXT (16-235). >> >> >> If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target, the >> EGL takes ownership of the file descriptor and is responsible for closing >> it, which it may do at any time while the EGLDisplay is initialized." >> >> >> Add to the list of error conditions for eglCreateImageKHR: >> >> "* If <target> is EGL_LINUX_DMA_BUF_EXT and <buffer> is not NULL, the >> error EGL_BAD_PARAMETER is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT, and the list of attributes is >> incomplete, EGL_BAD_PARAMETER is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT >> attribute is set to a format not supported by the EGL, EGL_BAD_MATCH >> is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT, and the EGL_LINUX_DRM_FOURCC_EXT >> attribute indicates a single-plane format, EGL_BAD_ATTRIBUTE is >> generated if any of the EGL_DMA_BUF_PLANE1_* or EGL_DMA_BUF_PLANE2_* >> attributes are specified. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for >> EGL_YUV_COLOR_SPACE_HINT_EXT is not EGL_ITU_REC601_EXT, >> EGL_ITU_REC709_EXT or EGL_ITU_REC2020_EXT, EGL_BAD_ATTRIBUTE is >> generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for >> EGL_SAMPLE_RANGE_HINT_EXT is not EGL_YUV_FULL_RANGE_EXT or >> EGL_YUV_NARROW_RANGE_EXT, EGL_BAD_ATTRIBUTE is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT and the value specified for >> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT or >> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT is not >> EGL_YUV_CHROMA_SITING_0_EXT or EGL_YUV_CHROMA_SITING_0_5_EXT, >> EGL_BAD_ATTRIBUTE is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT and one or more of the values >> specified for a plane's pitch or offset isn't supported by EGL, >> EGL_BAD_ACCESS is generated. >> >> * If <target> is EGL_LINUX_DMA_BUF_EXT and eglCreateImageKHR fails, >> EGL does not retain ownership of the file descriptor and it is the >> responsibility of the application to close it." >> >> >> Issues >> >> 1. Should this be a KHR or EXT extension? >> >> ANSWER: EXT. Khronos EGL working group not keen on this extension as it is >> seen as contradicting the EGLStream direction the specification is going in. >> The working group recommends creating additional specs to allow an EGLStream >> producer/consumer connected to v4l2/DRM or any other Linux interface. >> >> 2. Should this be a generic any platform extension, or a Linux-only >> extension which explicitly states the handles are dma_buf fds? >> >> ANSWER: There's currently no intention to port this extension to any OS not >> based on the Linux kernel. Consequently, this spec can be explicitly written >> against Linux and the dma_buf API. >> >> 3. Does ownership of the file descriptor pass to the EGL library? >> >> ANSWER: If eglCreateImageKHR is successful, EGL assumes ownership of the >> file descriptors and is responsible for closing them. >> >> 4. How are the different YUV color spaces handled (BT.709/BT.601)? >> >> ANSWER: The pixel formats defined in drm_fourcc.h only specify how the data >> is laid out in memory. It does not define how that data should be >> interpreted. Added a new EGL_YUV_COLOR_SPACE_HINT_EXT attribute to allow the >> application to specify which color space the data is in to allow the GL to >> choose an appropriate set of co-efficients if it needs to convert that data >> to RGB for example. >> >> 5. What chroma-siting is used for sub-sampled YUV formats? >> >> ANSWER: The chroma siting is not specified by either the v4l2 or DRM APIs. >> This is similar to the color-space issue (4) in that the chroma siting >> doesn't affect how the data is stored in memory. However, the GL will need >> to know the siting in order to filter the image correctly. While the visual >> impact of getting the siting wrong is minor, provision should be made to >> allow an application to specify the siting if desired. Added additional >> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT & >> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes to allow the siting to >> be specified using a set of pre-defined values (0 or 0.5). >> >> 6. How can an application query which formats the EGL implementation >> supports? >> >> PROPOSAL: Don't provide a query mechanism but instead add an error condition >> that EGL_BAD_MATCH is raised if the EGL implementation doesn't support that >> particular format. >> >> 7. Which image formats should be supported and how is format specified? >> >> Seem to be two options 1) specify a new enum in this specification and >> enumerate all possible formats. 2) Use an existing enum already in Linux, >> either v4l2_mbus_pixelcode and/or those formats listed in drm_fourcc.h? >> >> ANSWER: Go for option 2) and just use values defined in drm_fourcc.h. >> >> 8. How can AYUV images be handled? >> >> ANSWER: At least on fourcc.org and in drm_fourcc.h, there only seems to be >> a single AYUV format and that is a packed format, so everything, including >> the alpha component would be in the first plane. >> >> 9. How can you import interlaced images? >> >> ANSWER: Interlaced frames are usually stored with the top & bottom fields >> interleaved in a single buffer. As the fields would need to be displayed as >> at different times, the application would create two EGLImages from the same >> buffer, one for the top field and another for the bottom. Both EGLImages >> would set the pitch to 2x the buffer width and the second EGLImage would use >> a suitable offset to indicate it started on the second line of the buffer. >> This should work regardless of whether the data is packed in a single plane, >> semi-planar or multi-planar. >> >> If each interlaced field is stored in a separate buffer then it should be >> trivial to create two EGLImages, one for each field's buffer. >> >> 10. How are semi-planar/planar formats handled that have a different >> width/height for Y' and CbCr such as YUV420? >> >> ANSWER: The spec says EGL_WIDTH & EGL_HEIGHT specify the *logical* width and >> height of the buffer in pixels. For pixel formats with sub-sampled Chroma >> values, it should be trivial for the EGL implementation to calculate the >> width/height of the Chroma sample buffers using the logical width & height >> and by inspecting the pixel format passed as the EGL_LINUX_DRM_FOURCC_EXT >> attribute. I.e. If the pixel format says it's YUV420, the Chroma buffer's >> width = EGL_WIDTH/2 & height =EGL_HEIGHT/2. >> >> 11. How are Bayer formats handled? >> >> ANSWER: As of Linux 2.6.34, drm_fourcc.h does not include any Bayer formats. >> However, future kernel versions may add such formats in which case they >> would be handled in the same way as any other format. >> >> 12. Should the spec support buffers which have samples in a "narrow range"? >> >> Content sampled from older analogue sources typically don't use the full >> (0-256) range of the data type storing the sample and instead use a narrow >> (16-235) range to allow some headroom & toeroom in the signals to avoid >> clipping signals which overshoot slightly during processing. This is >> sometimes known as signals using "studio swing". >> >> ANSWER: Add a new attribute to define if the samples use a narrow 16-235 >> range or the full 0-256 range. >> >> 13. Specifying the color space and range seems cumbersome, why not just >> allow the application to specify the full YUV->RGB color conversion matrix? >> >> ANSWER: Some hardware may not be able to use an arbitrary conversion matrix >> and needs to select an appropriate pre-defined matrix based on the color >> space and the sample range. >> >> 14. How do you handle EGL implementations which have restrictions on pitch >> and/or offset? >> >> ANSWER: Buffers being imported using dma_buf pretty much have to be >> allocated by a kernel-space driver. As such, it is expected that a system >> integrator would make sure all devices which allocate buffers suitable for >> exporting make sure they use a pitch supported by all possible importers. >> However, it is still possible eglCreateImageKHR can fail due to an >> unsupported pitch. Added a new error to the list indicating this. >> >> 15. Should this specification also describe how to export an existing >> EGLImage as a dma_buf file descriptor? >> >> ANSWER: No. Importing and exporting buffers are two separate operations and >> importing an existing dma_buf fd into an EGLImage is useful functionality in >> itself. Agree that exporting an EGLImage as a dma_buf fd is useful, E.g. it >> could be used by an OpenMAX IL implementation's OMX_UseEGLImage function to >> give access to the buffer backing an EGLImage to video hardware. However, >> exporting can be split into a separate extension specification. >> >> >> Revision History >> >> #4 (Tom Cooksey, October 04, 2012) >> - Fixed issue numbering! >> - Added issues 8 - 15. >> - Promoted proposal for Issue 3 to be the answer. >> - Added an additional attribute to allow an application to specify the color >> space as a hint which should address issue 4. >> - Added an additional attribute to allow an application to specify the chroma >> siting as a hint which should address issue 5. >> - Added an additional attribute to allow an application to specify the sample >> range as a hint which should address the new issue 12. >> - Added language to end of error section clarifying who owns the fd passed >> to eglCreateImageKHR if an error is generated. >> >> #3 (Tom Cooksey, August 16, 2012) >> - Changed name from EGL_EXT_image_external and re-written language to >> explicitly state this for use with Linux & dma_buf. >> - Added a list of issues, including some still open ones. >> >> #2 (Jesse Barker, May 30, 2012) >> - Revision to split eglCreateImageKHR functionality from export >> Functionality. >> - Update definition of EGLNativeBufferType to be a struct containing a list >> of handles to support multi-buffer/multi-planar formats. >> >> #1 (Jesse Barker, March 20, 2012) >> - Initial draft. >> >> >> >> >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev(a)lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > _______________________________________________ > mesa-dev mailing list > mesa-dev(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev

8 years, 10 months

[PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

by Chris Wilson

Currently we install a callback for performing poll on a dma-buf, irrespective of the timeout. This involves taking a spinlock, as well as unnecessary work, and greatly reduces scaling of poll(.timeout=0) across multiple threads. We can query whether the poll will block prior to installing the callback to make the busy-query fast. Single thread: 60% faster 8 threads on 4 (+4 HT) cores: 600% faster Still not quite the perfect scaling we get with a native busy ioctl, but poll(dmabuf) is faster due to the quicker lookup of the object and avoiding drm_ioctl(). Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-buf.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index cf04d249a6a4..c7a7bc579941 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -156,6 +156,18 @@ static unsigned int dma_buf_poll(struct file *file, poll_table *poll) if (!events) return 0; + if (poll_does_not_wait(poll)) { + if (events & POLLOUT && + !reservation_object_test_signaled_rcu(resv, true)) + events &= ~(POLLOUT | POLLIN); + + if (events & POLLIN && + !reservation_object_test_signaled_rcu(resv, false)) + events &= ~POLLIN; + + return events; + } + retry: seq = read_seqcount_begin(&resv->seq); rcu_read_lock(); -- 2.9.3

8 years, 10 months

[PATCH v2 0/2] doc: dma-buf: sphinx conversion

by Sumit Semwal

Convert dma-buf documentation over to sphinx. While at that, convert dma-buf-sharing.txt as well, and make it the dma-buf API guide. There is no content change yet; only format conversion and creation of some hyperlinks. v2: Address review comments from Jonathan Corbet and Markus Heiser. Sumit Semwal (2): Documentation: move dma-buf documentation to rst Documentation/sphinx: link dma-buf rsts Documentation/DocBook/device-drivers.tmpl | 41 --- Documentation/dma-buf-sharing.txt | 482 ---------------------------- Documentation/dma-buf/guide.rst | 507 ++++++++++++++++++++++++++++++ Documentation/dma-buf/intro.rst | 82 +++++ Documentation/index.rst | 2 + MAINTAINERS | 2 +- 6 files changed, 592 insertions(+), 524 deletions(-) delete mode 100644 Documentation/dma-buf-sharing.txt create mode 100644 Documentation/dma-buf/guide.rst create mode 100644 Documentation/dma-buf/intro.rst -- 2.7.4

8 years, 10 months

[PATCH] dma-buf: fix kernel-doc warning and typos

by Randy Dunlap

From: Randy Dunlap <rdunlap(a)infradead.org> Fix dma-buf kernel-doc warning and 2 minor typos in fence_array_create(). Fixes this warning: ..//drivers/dma-buf/fence-array.c:124: warning: No description found for parameter 'signal_on_any' Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/fence-array.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- lnx-48-rc2.orig/drivers/dma-buf/fence-array.c +++ lnx-48-rc2/drivers/dma-buf/fence-array.c @@ -106,14 +106,14 @@ const struct fence_ops fence_array_ops = * @fences: [in] array containing the fences * @context: [in] fence context to use * @seqno: [in] sequence number to use - * @signal_on_any [in] signal on any fence in the array + * @signal_on_any: [in] signal on any fence in the array * * Allocate a fence_array object and initialize the base fence with fence_init(). * In case of error it returns NULL. * - * The caller should allocte the fences array with num_fences size + * The caller should allocate the fences array with num_fences size * and fill it with the fences it wants to add to the object. Ownership of this - * array is take and fence_put() is used on each fence on release. + * array is taken and fence_put() is used on each fence on release. * * If @signal_on_any is true the fence array signals if any fence in the array * signals, otherwise it signals when all fences in the array signal.

8 years, 10 months

[RFCv2][PATCH 0/5] Cleanup Ion mapping/caching

by Laura Abbott

Hi, This is v2 on the attempt to remove misuse of the cache APIs from Ion. The previous version[1] attempted to pull the cache APIs into Ion. This was indicated as the wrong approach and real APIs should be created instead. The APIs created are kernel_force_cache_clean and kernel_force_cache_invalidate. They force a clean and invalidate of the cache, respectively. The aim was to take the semantics of dma_sync and turn them into something that isn't dma_sync. This series includes a nominal implementation for arm/arm64, mostly for demonstration purposes. I did review before writing this of whether Ion could just use the DMA mapping APIs to acheive the necessary coherency. The conclusion I came to was that trying to force the Ion code into the DMA model would create more problem than it solved since there wasn't anything like DMA going on. Similarly, none of the existing cache APIs did exactly what was needed either. The closest matches were designed for file cache pages and not drivers. The series includes conversion of Ion to the new APIs. There are a few other drivers which are calling either arch specific APIs or flush_dcache_page that could be converted as well. The i915 driver could potentially be converted with the addition of an x86 implementation. Feedback appreciated as always. Thanks, Laura [1] https://lkml.kernel.org/g/<1464205684-5587-1-git-send-email-labbott(a)redhat.com> Laura Abbott (5): Documentation: Introduce kernel_force_cache_* APIs arm: Implement ARCH_HAS_FORCE_CACHE arm64: Implement ARCH_HAS_FORCE_CACHE staging: android: ion: Convert to the kernel_force_cache APIs staging: ion: Add support for syncing with DMA_BUF_IOCTL_SYNC Documentation/cachetlb.txt | 18 +++- arch/arm/include/asm/cacheflush.h | 4 + arch/arm/mm/dma-mapping.c | 119 ------------------------ arch/arm/mm/flush.c | 115 +++++++++++++++++++++++ arch/arm/mm/mm.h | 8 ++ arch/arm64/include/asm/cacheflush.h | 5 + arch/arm64/mm/flush.c | 11 +++ drivers/staging/android/ion/ion.c | 53 +++++++---- drivers/staging/android/ion/ion_carveout_heap.c | 8 +- drivers/staging/android/ion/ion_chunk_heap.c | 12 ++- drivers/staging/android/ion/ion_page_pool.c | 6 +- drivers/staging/android/ion/ion_priv.h | 11 --- drivers/staging/android/ion/ion_system_heap.c | 6 +- include/linux/cacheflush.h | 11 +++ 14 files changed, 225 insertions(+), 162 deletions(-) create mode 100644 include/linux/cacheflush.h -- 2.7.4

8 years, 10 months

[RESEND][PATCH 0/5] Ion cleanup

by Laura Abbott

I never saw any feedback or action on these patches so this is a resend. Probably hit the window when everyone was busy/traveling. --- Hi, This is some clean up of old Ion interfaces and APIs. These are interfaces that mostly existed before dma_buf was well integrated into the kernel along with reservations for board files. If there are objections to deletion I expect it to turn into a discussion about what other APIs need to be extended. Thanks, Laura Laura Abbott (5): staging: android: ion: Get rid of ion_sg_table staging: android: ion: Drop ion_phys interface staging: android: ion: Get rid of map_dma/unmap_dma staging: android: ion: Drop ion_carveout_allocate definitions staging: android: ion: Get rid of ion_reserve drivers/staging/android/ion/ion.c | 103 ++---------------------- drivers/staging/android/ion/ion.h | 41 ---------- drivers/staging/android/ion/ion_carveout_heap.c | 33 +------- drivers/staging/android/ion/ion_chunk_heap.c | 17 +--- drivers/staging/android/ion/ion_cma_heap.c | 34 +------- drivers/staging/android/ion/ion_priv.h | 30 +------ drivers/staging/android/ion/ion_system_heap.c | 44 +--------- 7 files changed, 19 insertions(+), 283 deletions(-) -- 2.5.5

8 years, 10 months

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

by Sumit Semwal

Convert dma-buf documentation over to sphinx; also cleanup to address sphinx warnings. While at that, convert dma-buf-sharing.txt as well, and make it the dma-buf API guide. There is no content change yet; only format conversion and creation of some hyperlinks. Sumit Semwal (4): dma-buf/fence: kerneldoc: remove unused struct members dma-buf/fence: kerneldoc: remove spurious section header Documentation: move dma-buf documentation to rst Documentation/sphinx: link dma-buf rsts Documentation/DocBook/device-drivers.tmpl | 37 --- Documentation/dma-buf/guide.rst | 503 ++++++++++++++++++++++++++++++ Documentation/dma-buf/intro.rst | 76 +++++ Documentation/index.rst | 2 + MAINTAINERS | 2 +- include/linux/fence.h | 4 +- 6 files changed, 583 insertions(+), 41 deletions(-) create mode 100644 Documentation/dma-buf/guide.rst create mode 100644 Documentation/dma-buf/intro.rst -- 2.7.4

8 years, 10 months

[RFC 0/4] doc: dma-buf: sphinx conversion and cleanup

by Sumit Semwal

8 years, 10 months

Re: [Linaro-mm-sig] [RFCv2][PATCH 2/5] arm: Implement ARCH_HAS_FORCE_CACHE

by Laura Abbott

On 08/09/2016 02:56 PM, Florian Fainelli wrote: > On 08/08/2016 10:49 AM, Laura Abbott wrote: >> arm may need the kernel_force_cache APIs to guarantee data consistency. >> Implement versions of these APIs based on the DMA APIs. >> >> Signed-off-by: Laura Abbott <labbott(a)redhat.com> >> --- >> arch/arm/include/asm/cacheflush.h | 4 ++ >> arch/arm/mm/dma-mapping.c | 119 -------------------------------------- >> arch/arm/mm/flush.c | 115 ++++++++++++++++++++++++++++++++++++ > > Why is the code moved between dma-mapping.c and flush.c? It was not > obvious while looking at these patches why this is needed. > I wanted to use the cache flushing routines from dma-mapping.c and it seemed better to pull them out vs. trying to put more generic cache flushing code in dma-mapping.c. flush.c seemed like an appropriate place although I forgot about the dependency on CONFIG_MMU. It can certainly remain in dma-mapping.c if deemed appropriate. Thanks, Laura

8 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig