Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
3320 discussions

Re: [Linaro-mm-sig] [PATCH v2] dma-buf: use vma_pages().

by Eric Engestrom

On Mon, May 23, 2016 at 05:08:42PM +0530, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages(). > Also, include <linux/mm.h> All good! Reviewed-by: Eric Engestrom <eric.engestrom(a)imgtec.com>

9 years, 8 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: use vma_pages().

by Eric Engestrom

On Sat, May 21, 2016 at 06:53:32PM +0530, Muhammad Falak R Wani wrote: > Replace explicit computation of vma page count by a call to > vma_pages() > > Signed-off-by: Muhammad Falak R Wani <falakreyaz(a)gmail.com> > --- Good change, but this function is defined in mm.h Please add: #include <linux/mm.h> With that fixed: Reviewed-by: Eric Engestrom <eric.engestrom(a)imgtec.com>

9 years, 8 months

[PATCH v8 0/3] Secure Memory Allocation Framework

by Benjamin Gaignard

version 8 chanegs: - 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 The outcome of the previous RFC about how do secure data path was the need of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) SMAF goal is to provide a framework that allow allocating and securing memory by using dma_buf. Each platform have it own way to perform those two features so SMAF design allow to register helper modules to perform them. 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. I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if a better name could be found for this file. 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 | 188 ++++++++++ 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, 1314 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

9 years, 8 months

[PATCH v8 00/11] Add DRM for stih4xx platforms

by Benjamin Gaignard

This series of patches add the support of DRM/KMS drivers for STMicroelectronics chipsets stih416 and stih407. version 8: - Allow driver to be build as kernel module. - Use Universal Plane instead of legacy code. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v8 version 7: - rebased on top of drm-next (2014-07-24) patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v7 version 6: - rebased on top of new component framework API. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v6 version 5: - Rework sti_drm_drv probes functions to support deferred probe. This allow hdmi to delayed framebuffer creation until I2C is available. - Add ops functions in sti_layer structure to simpify GDP and VID code. - Add NOTES file to describe how the DRM concepts are mapped on hardware. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v5 version 4: - Remove depency between TVout it subdevices HDMI and HDA - Rework and simplify VTG and VTAC code - Fix numbers of typo and indentation - Remove debug (will be push in separate patches) - Fix remarks done in previous patcheset patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v4 version 3: - Correctly split code between probe and bind funtions - Squash some commits - remove HQ-VDP device code to have a smaller patcheset, we will introduce it later. patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v3 version 2: - Use componentized device instead of register sub-devices in master driver probe function - Fix Makefile and Kconfig to only allow built-in compilation patches could be found here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on branch: drm_kms_for_next-v2 version 1: - First path submission Hardware is split in two main blocks: Compositor and TVout. Each of them includes specific hardware IPs and the display timing are controlled by a specific Video Timing Generator hardware IP (VTG). Compositor is made of the follow hardware IPs: - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB) buffers - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers - HQVDP (High Quality Video Display Processor) that supports scaling, deinterlacing and some miscellaneous image quality improvements. It fetches the Video decoded buffers from memory, processes them and pushes them to the Compositor through a HW dedicated bus. - Mixer is responsible of mixing all the entries depending of their respective z-order and layout TVout is divided in 3 parts: - HDMI to generate HDMI signals, depending of chipset version HDMI phy can change. - HDA to generate signals for HD analog TV - VIP to control/switch data path coming from Compositor On stih416 compositor and Tvout are on different dies so a Video Trafic Advance inter-die Communication mechanism (VTAC) is needed. +---------------------------------------------+ +----------------------------------------+ | +-------------------------------+ +----+ | | +----+ +--------------------------+ | | | | | | | | | | | +---------+ +----+ | | | | +----+ +------+ | | | | | | | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | | | | | | | +----+ | | | | +----+ |Mixer |--|-->| | | | | |---|->| switcher| | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | | | |---->|HDA | | | | | +------+ | |VTAC|========>|VTAC| | +---------+ +----+ | | | | | | | | | | | | | | | | Compositor | | | | | | | | TVout | | | +-------------------------------+ | | | | | | +--------------------------+ | | ^ | | | | | | ^ | | | | | | | | | | | | +--------------+ | | | | | | +-------------+ | | | VTG (master) |----->| | | | | |----->| VTG (slave) | | | +--------------+ +----+ | | +----+ +-------------+ | |Digital die | | Analog Die| +---------------------------------------------+ +----------------------------------------+ On stih407 Compositor and Tvout are on the same die +-----------------------------------------------------------------+ | +-------------------------------+ +--------------------------+ | | | | | +---------+ +----+ | | | | +----+ +------+ | | | VIP |---->|HDMI| | | | | |GPD +------------->| | | | | | +----+ | | | | +----+ |Mixer |--|--|->| switcher| | | | | +----+ +-----+ | | | | | | +----+ | | | | |VDP +-->+HQVDP+--->| | | | | |---->|HDA | | | | | +----+ +-----+ +------+ | | +---------+ +----+ | | | | | | | | | | Compositor | | TVout | | | +-------------------------------+ +--------------------------+ | | ^ ^ | | | | | | +--------------+ | | | VTG | | | +--------------+ | |Digital die | +-----------------------------------------------------------------+ In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used by HDMI driver to retrieve EDID for monitor. To unify interfaces of GDP and VDP we create a "layer" interface called by compositor to control both GPD and VDP. Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions to allocate frame buffer. File naming convention is: - sti_* for IPs drivers - sti_drm_* for drm functions implementation. Benjamin Gaignard (11): drm: sti: add bindings for DRM driver drm: sti: add VTG driver drm: sti: add VTAC drivers drm: sti: add HDMI driver drm: sti: add HDA driver drm: sti: add TVOut driver drm: sti: add GDP layer drm: sti: add VID layer drm: sti: add Mixer drm: sti: add Compositor drm: sti: Add DRM driver itself .../devicetree/bindings/gpu/st,stih4xx.txt | 189 +++++ drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/sti/Kconfig | 14 + drivers/gpu/drm/sti/Makefile | 21 + drivers/gpu/drm/sti/NOTES | 58 ++ drivers/gpu/drm/sti/sti_compositor.c | 279 +++++++ drivers/gpu/drm/sti/sti_compositor.h | 90 +++ drivers/gpu/drm/sti/sti_drm_crtc.c | 423 +++++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 22 + drivers/gpu/drm/sti/sti_drm_drv.c | 241 ++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 29 + drivers/gpu/drm/sti/sti_drm_plane.c | 195 +++++ drivers/gpu/drm/sti/sti_drm_plane.h | 18 + drivers/gpu/drm/sti/sti_gdp.c | 549 ++++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 16 + drivers/gpu/drm/sti/sti_hda.c | 794 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.c | 810 +++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.h | 88 +++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 +++++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 + drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 211 ++++++ drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h | 14 + drivers/gpu/drm/sti/sti_layer.c | 197 +++++ drivers/gpu/drm/sti/sti_layer.h | 123 ++++ drivers/gpu/drm/sti/sti_mixer.c | 249 +++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 ++ drivers/gpu/drm/sti/sti_tvout.c | 648 +++++++++++++++++ drivers/gpu/drm/sti/sti_vid.c | 138 ++++ drivers/gpu/drm/sti/sti_vid.h | 12 + drivers/gpu/drm/sti/sti_vtac.c | 215 ++++++ drivers/gpu/drm/sti/sti_vtg.c | 366 ++++++++++ drivers/gpu/drm/sti/sti_vtg.h | 28 + 33 files changed, 6444 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt create mode 100644 drivers/gpu/drm/sti/Kconfig create mode 100644 drivers/gpu/drm/sti/Makefile create mode 100644 drivers/gpu/drm/sti/NOTES create mode 100644 drivers/gpu/drm/sti/sti_compositor.c create mode 100644 drivers/gpu/drm/sti/sti_compositor.h create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h create mode 100644 drivers/gpu/drm/sti/sti_gdp.c create mode 100644 drivers/gpu/drm/sti/sti_gdp.h create mode 100644 drivers/gpu/drm/sti/sti_hda.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h create mode 100644 drivers/gpu/drm/sti/sti_layer.c create mode 100644 drivers/gpu/drm/sti/sti_layer.h create mode 100644 drivers/gpu/drm/sti/sti_mixer.c create mode 100644 drivers/gpu/drm/sti/sti_mixer.h create mode 100644 drivers/gpu/drm/sti/sti_tvout.c create mode 100644 drivers/gpu/drm/sti/sti_vid.c create mode 100644 drivers/gpu/drm/sti/sti_vid.h create mode 100644 drivers/gpu/drm/sti/sti_vtac.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.c create mode 100644 drivers/gpu/drm/sti/sti_vtg.h -- 1.9.1

9 years, 9 months

[RFC 0/3] Unify IOMMU-based DMA-mapping code for ARM and ARM64

by Marek Szyprowski

Dear All, This is an initial RFC on the unification of IOMMU-based DMA-mapping code for ARM and ARM64 architectures. Right now ARM architecture still use my old code for IOMMU-based DMA-mapping glue, initially merged in commit 4ce63fcd919c32d22528e54dcd89506962933719 ("ARM: dma-mapping: add support for IOMMU mapper"). In meantime ARM64 got a new, slightly improved implementation provided by Robin Murphy in commit 13b8629f651164d71f4d38b821925f93ba4236c8 ("arm64: Add IOMMU dma_ops"). Both implementations are very similar thus their unification is desired to avoid duplicating future works and simplify code, which uses this layer on both architectures. In this patchset I've selected the new implementation (from ARM64 architecture) as a base. This means that ARM-specific, old interface (arm_iommu_* functions) for configuring IOMMU domains will be no longer available and its users have to be converted to new API. Besides lack of old interface, the second difference is additional requirements for IOMMU drivers. New code relies on the support for IOMMU_DOMAIN_DMA and default IOMMU domain, which is automatically attached by the IOMMU core. The new code also assumes that the IOMMU-based DMA-mapping ops are mainly configured from arch_setup_dma_ops() function, which means that the IOMMU driver should provide needed of_xlate callbacks and initialize IOMMU ops for device nodes. However it should be also possible to initialize IOMMU-based DMA-mapping ops for client devices directly from IOMMU drivers by calling common_iommu_setup_dma_ops() (some drivers used such approach). IOMMU drivers should be also aware of the fact that the default domain is attached via device_attach and then device_attach callback can be called once again with different domain without previous detach from default domain. For more information on this issue, see the following thread: https://lists.linaro.org/pipermail/linaro-mm-sig/2016-February/004625.html Currently there are 4 users of the old arm_iommu_* interface: 1. Exynos DRM driver 2. Rockchip DRM driver 3. OMAP3 ISP camera driver 4. Renesas VMSA-compatible IPMMU driver In this patchset I've converted Exynos DRM driver for the new API (patch 1). This required some changes in the memory management model inside the driver and removal of some hacks, which were used to setup IOMMU-based DMA-mapping ops on the 'exynos-drm' virtual device and common IOMMU domain for all Exynos DRM sub-devices, those changes have been posted separately here: http://www.spinics.net/lists/dri-devel/msg100861.html Rockchip DRM driver requires similar conversion. Converting OMAP3 ISP camera driver to new API requires adding support for IOMMU groups to OMAP IOMMU driver, because the new DMA/IOMMU code used IOMMU_DOMAIN_DMA type domains and default groups. Renesas IPMMU driver needs also to be extended with IOMMU_DOMAIN_DMA domain type support. It can also be prepared for IOMMU_OF_DECLARE and of_xlate callback-based initialization to let core to automatically setup of IOMMU-based DMA mapping implementation. Patch 2 moves existing code from arch/arm64 to drivers/iommu and introduces some minor changes in function names - mainly adding arch_ prefix to some dma-mapping internal functions, which stay in arch/arm64/ (functions of similar names are present in arch/arm). Patch 3 adapts ARM architecture for the common code. I would like to get your comments on the proposed approach. There is still some work that need to be done to convert remaining users of the old API and updating IOMMU drivers to the new API requirements. This change need to be tested on the all affected ARM sub-architectures. Right now patches were tested on only Exynos based boards: ARM 32bit: Exynos4412 and Exynos5422 boards and ARM 64 bit Exnyos 5433 (with some out-of-tree DTS). To ease testing I've prepared a branch with all the patches needed (there are all needed patches for Exynos subarch, which have been posted as separate patchsets): https://git.linaro.org/people/marek.szyprowski/linux-srpol.git v4.5-dma-iommu-unification Patches are based on Linux v4.5-rc4 vanilla tree. Best regards Marek Szyprowski Samsung R&D Institute Poland Patch summary: Marek Szyprowski (3): drm/exynos: rewrite IOMMU support code iommu: dma-iommu: move IOMMU/DMA-mapping code from ARM64 arch to drivers iommu: dma-iommu: use common implementation also on ARM architecture arch/arm/Kconfig | 22 +- arch/arm/include/asm/device.h | 9 - arch/arm/include/asm/dma-iommu.h | 37 - arch/arm/include/asm/dma-mapping.h | 59 +- arch/arm/mm/dma-mapping.c | 1158 +---------------------------- arch/arm64/include/asm/dma-mapping.h | 39 +- arch/arm64/mm/dma-mapping.c | 491 +----------- drivers/gpu/drm/exynos/Kconfig | 2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 91 ++- drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +- drivers/gpu/drm/rockchip/Kconfig | 1 + drivers/iommu/Kconfig | 1 + drivers/iommu/Makefile | 2 +- drivers/iommu/dma-iommu-ops.c | 471 ++++++++++++ drivers/media/platform/Kconfig | 1 + include/linux/dma-iommu.h | 14 + 18 files changed, 679 insertions(+), 1730 deletions(-) delete mode 100644 arch/arm/include/asm/dma-iommu.h create mode 100644 drivers/iommu/dma-iommu-ops.c -- 1.9.2

9 years, 9 months

Re: [Linaro-mm-sig] [RESEND] fence: add missing descriptions for fence

by Sumit Semwal

Hi Luis, On 12 April 2016 at 04:03, Luis de Bethencourt <luisbg(a)osg.samsung.com> wrote: > On 11/04/16 21:09, Gustavo Padovan wrote: >> Hi Luis, >> >> 2016-04-11 Luis de Bethencourt <luisbg(a)osg.samsung.com>: >> >>> The members child_list and active_list were added to the fence struct >>> without descriptions for the Documentation. Adding these. >>> Thanks for the patch; will get it queued for for-next. >>> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") >>> Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com> >>> Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> >>> --- >>> Hi, >>> >>> Just resending this patch since it hasn't had any reviews in since >>> March 21st. >>> >>> Thanks, >>> Luis >>> >>> include/linux/fence.h | 2 ++ >>> 1 file changed, 2 insertions(+) >> >> Reviewed-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> >> >> Gustavo >> > > Thank you Gustavo. > > Nice seeing you around here :) > > Luis BR, Sumit.

9 years, 9 months

Re: [Linaro-mm-sig] [RESEND] fence: add missing descriptions for fence

by Gustavo Padovan

Hi Luis, 2016-04-11 Luis de Bethencourt <luisbg(a)osg.samsung.com>: > The members child_list and active_list were added to the fence struct > without descriptions for the Documentation. Adding these. > > Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt") > Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com> > Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com> > --- > Hi, > > Just resending this patch since it hasn't had any reviews in since > March 21st. > > Thanks, > Luis > > include/linux/fence.h | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> Gustavo

9 years, 10 months

[PATCH 0/2] drm: add generic zpos property

by Benjamin Gaignard

The original patches have been done by Marek: https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html I have just adapt them to make zpos depend on plane and no more on drm core. Since zpos range can be define per plane normalize function takes care of the min and max before compute normalized zpos value. Benjamin Gaignard (2): drm: add generic zpos property drm: sti: use generic zpos for plane Documentation/DocBook/gpu.tmpl | 10 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 6 + drivers/gpu/drm/drm_blend.c | 242 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/sti/sti_mixer.c | 2 +- drivers/gpu/drm/sti/sti_plane.c | 82 +++++------- drivers/gpu/drm/sti/sti_plane.h | 2 - include/drm/drm_crtc.h | 17 +++ 10 files changed, 314 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c -- 1.9.1

9 years, 10 months

[PATCH] dma-buf: Release module reference on creation failure

by Chris Wilson

If we fail to create the anon file, we need to remember to release the module reference on the owner. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> 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 | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 4a2c07ee6677..6f0f0b10a241 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) struct reservation_object *resv = exp_info->resv; struct file *file; size_t alloc_size = sizeof(struct dma_buf); + int ret; if (!exp_info->resv) alloc_size += sizeof(struct reservation_object); @@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf = kzalloc(alloc_size, GFP_KERNEL); if (!dmabuf) { - module_put(exp_info->owner); - return ERR_PTR(-ENOMEM); + ret = -ENOMEM; + goto free_module; } dmabuf->priv = exp_info->priv; @@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, exp_info->flags); if (IS_ERR(file)) { - kfree(dmabuf); - return ERR_CAST(file); + ret = PTR_ERR(file); + goto free_dmabuf; } file->f_mode |= FMODE_LSEEK; @@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) mutex_unlock(&db_list.lock); return dmabuf; + +free_dmabuf: + kfree(dmabuf); +free_module: + module_put(exp_info->owner); + return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(dma_buf_export); -- 2.8.0.rc3

9 years, 10 months

Re: [Linaro-mm-sig] [PATCH] dma-buf: Update docs for SYNC ioctl

by David Herrmann

Hi On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti <tiago.vignatti(a)intel.com> wrote: > Do we have an agreement here after all? David? I need to know whether this > fixup is okay to go cause I'll need to submit to Chrome OS then. Sure it is fine. The code is already there, we cannot change it. Thanks David

9 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig