Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

15 participants
7027 discussions

[linaro-mm-sig] Backward compatibility of 3.4 android kernel to ICS

by Nishanth Peethambaran

Hi, I see that the lowmemkiller.c is changed to use oom_score_adj instead of oom_adj. Does this mean I cannot use an ICS system image with 3.4 kernel? Or is there a workaround? - Nishanth Peethambaran

13 years, 11 months

Re: [Linaro-mm-sig] CMA allocation issue : some pages can't be migrated

by Aubertin, Guillaume

looping-in the linaro-mm-sig ML. On Thu, Aug 30, 2012 at 4:47 PM, Aubertin, Guillaume <g-aubertin(a)ti.com>wrote: > hi guys, > > I've been working for a few days on getting a proper rmmod with the > remoteproc/rpmsg modules, and I stumbled upon an interesting issue. > > when doing sucessive memory allocation and release in the CMA > reservation (by loading/unloading the firmware several times), the > following message shows up : > > [ 119.908477] cma: dma_alloc_from_contiguous(cma ed10ad00, count 256, > align 8) > [ 119.908843] cma: dma_alloc_from_contiguous(): memory range at c0dfb000 > is busy, retrying > [ 119.909698] cma: dma_alloc_from_contiguous(): returned c0dfd000 > > dma_alloc_from_contiguous() tries to allocate the following range, > 0xc0dfd000, succesfully this time. > > In some cases, the allocation fails after trying several ranges : > > [ 119.912231] cma: dma_alloc_from_contiguous(cma ed10ad00, count 768, > align 8) > [ 119.912719] cma: dma_alloc_from_contiguous(): memory range at c0dff000 > is busy, retrying > [ 119.913055] cma: dma_alloc_from_contiguous(): memory range at c0e01000 > is busy, retrying > [ 119.913055] rproc remoteproc0: dma_alloc_coherent failed: 3145728 > > Here is my understanding so far : > > First, even if we made a CMA reservation, the kernel can still allocate > pages in this area, but these pages must be movable (user process page by > example). > > When dma_alloc_from_contiguous() is called to allocate X pages, it looks > for the next X contiguous free pages in it's CMA bitmap (with respect to > the memory alignment). Then, alloc_contig_range() is called to allocate the > given range of pages. Alloc_contig_range() analyses the pages we want to > allocate, and if a page is already used, it is migrated to a new page > outside the page array we want to reserve. this is done using > isolate_migratepages_range() to list the pages to migrate, and > migrate_pages() to try to migrate the pages, and that's where it fails. > Below is a list of next function calls : > > fallback_migrate_page() --> migrate_page() --> try_to_release_page() > --> try_to_free_buffer() --> drop_buffers() --> buffer_busy() > > I understand here that the page contains used buffers that can't be > dropped, and so the page can't be migrated. Well, I must admit that once > here, I'm feeling a little lost in this ocean of memory management code ;). > After a few researches, I found the following thread on the > linux-arm-kernel ML talking about the same issue : > > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/102844.html with > the following patch : > > * mm/page_alloc.c | 3 ++-* > * 1 files changed, 2 insertions(+), 1 deletions(-)* > * > * > *diff --git a/mm/page_alloc.c b/mm/page_alloc.c* > *index 0e1c6f5..c9a6483 100644* > *--- a/mm/page_alloc.c* > *+++ b/mm/page_alloc.c* > *@@ -1310,7 +1310,8 @@ void free_hot_cold_page(struct page *page, int > cold)* > * * excessively into the page allocator* > * */* > * if (migratetype >= MIGRATE_PCPTYPES) {* > *- if (unlikely(migratetype == MIGRATE_ISOLATE)) {* > *+ if (unlikely(migratetype == MIGRATE_ISOLATE)* > *+ || is_migrate_cma(migratetype)) {* > * free_one_page(zone, page, 0, migratetype);* > * goto out;* > * }* > > I tried the patch, and it seems to work (I didn't have any "memory range > busy" in 5000+ tests), but I'm affraid that this could have some nasty side > effects. > > Any idea ? > > Thanks in advance, > Guillaume > > > -- > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve > Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 > -- Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

13 years, 11 months

[RFC] New dma_buf -> EGLImage EGL extension

by Tom Cooksey

Hi All, Over the last few months I've been working on & off with a few people from Linaro on a new EGL extension. The extension allows constructing an EGLImage from a (set of) dma_buf file descriptors, including support for multi-plane YUV. I envisage the primary use-case of this extension to be importing video frames from v4l2 into the EGL/GLES graphics driver to texture from. Originally the intent was to develop this as a Khronos-ratified extension. However, this is a little too platform-specific to be an officially sanctioned Khronos extension. It also goes against the general "EGLStream" direction the EGL working group is going in. As such, the general feeling was to make this an EXT "multi-vendor" extension with no official stamp of approval from Khronos. As this is no-longer intended to be a Khronos extension, I've re-written it to be a lot more Linux & dma_buf specific. It also allows me to circulate the extension more widely (I.e. To those outside Khronos membership). ARM are implementing this extension for at least our Mali-T6xx driver and likely earlier drivers too. I am sending this e-mail to solicit feedback, both from other vendors who might implement this extension (Mesa3D?) and from potential users of the extension. However, any feedback is welcome. Please find the extension text as it currently stands below. There several open issues which I've proposed solutions for, but I'm not really happy with those proposals and hoped others could chip-in with better ideas. There are likely other issues I've not thought about which also need to be added and addressed. Once there's a general consensus or if no-one's interested, I'll update the spec, move it out of Draft status and get it added to the Khronos registry, which includes assigning values for the new symbols. 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 3, August 16, 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 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 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. 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? PROPOSAL: 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)? Open issue, still TBD. Doesn't seem to be specified by either the v4l2 or DRM APIs. PROPOSAL: Undefined and implementation/format dependent. 5. What chroma-siting is used for sub-sampled YUV formats? Open issue, still TBD. Doesn't seem to be specified by either the v4l2 or DRM APIs. PROPOSAL: Undefined and implementation/format dependent. 5. 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. 5. Which image formats should be supported and how is format specified? Open issue, still TBD. 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? PROPOSAL: Go for option 2) and just use values defined in drm_fourcc.h. Revision History #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.

13 years, 11 months

[PATCH 1/4] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

by Maarten Lankhorst

Documentation says that code requiring dma-buf should add it to select, so inline fallbacks are not going to be used. A link error will make it obvious what went wrong, instead of silently doing nothing at runtime. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- include/linux/dma-buf.h | 99 ----------------------------------------------- 1 file changed, 99 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index eb48f38..bd2e52c 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -156,7 +156,6 @@ static inline void get_dma_buf(struct dma_buf *dmabuf) get_file(dmabuf->file); } -#ifdef CONFIG_DMA_SHARED_BUFFER struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); void dma_buf_detach(struct dma_buf *dmabuf, @@ -184,103 +183,5 @@ int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); void *dma_buf_vmap(struct dma_buf *); void dma_buf_vunmap(struct dma_buf *, void *vaddr); -#else - -static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach) -{ - return; -} - -static inline struct dma_buf *dma_buf_export(void *priv, - const struct dma_buf_ops *ops, - size_t size, int flags) -{ - return ERR_PTR(-ENODEV); -} - -static inline int dma_buf_fd(struct dma_buf *dmabuf, int flags) -{ - return -ENODEV; -} - -static inline struct dma_buf *dma_buf_get(int fd) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_put(struct dma_buf *dmabuf) -{ - return; -} - -static inline struct sg_table *dma_buf_map_attachment( - struct dma_buf_attachment *attach, enum dma_data_direction write) -{ - return ERR_PTR(-ENODEV); -} - -static inline void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, - struct sg_table *sg, enum dma_data_direction dir) -{ - return; -} - -static inline int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, - size_t start, size_t len, - enum dma_data_direction dir) -{ - return -ENODEV; -} - -static inline void dma_buf_end_cpu_access(struct dma_buf *dmabuf, - size_t start, size_t len, - enum dma_data_direction dir) -{ -} - -static inline void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, - unsigned long pnum) -{ - return NULL; -} - -static inline void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, - unsigned long pnum, void *vaddr) -{ -} - -static inline void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long pnum) -{ - return NULL; -} - -static inline void dma_buf_kunmap(struct dma_buf *dmabuf, - unsigned long pnum, void *vaddr) -{ -} - -static inline int dma_buf_mmap(struct dma_buf *dmabuf, - struct vm_area_struct *vma, - unsigned long pgoff) -{ - return -ENODEV; -} - -static inline void *dma_buf_vmap(struct dma_buf *dmabuf) -{ - return NULL; -} - -static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) -{ -} -#endif /* CONFIG_DMA_SHARED_BUFFER */ #endif /* __DMA_BUF_H__ */

13 years, 11 months

[PATCH 1/4] ARM: dma-mapping: Small logical clean up

by Hiroshi Doyu

Skip unnecessary operations if order == 0. A little bit easier to read. Signed-off-by: Hiroshi Doyu <hdoyu(a)nvidia.com> --- arch/arm/mm/dma-mapping.c | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 70a6275..aaea5e4 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1032,11 +1032,12 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, gfp_t if (!pages[i]) goto error; - if (order) + if (order) { split_page(pages[i], order); - j = 1 << order; - while (--j) - pages[i + j] = pages[i] + j; + j = 1 << order; + while (--j) + pages[i + j] = pages[i] + j; + } __dma_clear_buffer(pages[i], PAGE_SIZE << order); i += 1 << order; -- 1.7.5.4

13 years, 11 months

[PATCH 0/3] Add code for setting coherent pool size

by Marek Szyprowski

Hi! Aaro Koskinen and Josh Coombs reported that commit e9da6e9905e639 ("ARM: dma-mapping: remove custom consistent dma region") introduced a regresion. It turned out that the default 256KiB for atomic coherent pool might not be enough. After that patch, some Kirkwood systems run out of atomic coherent memory and fail without any meanfull message. This patch series is an attempt to fix those issues by adding function for setting coherent pool size from platform initialization code and increasing the size of the pool for Kirkwood systems. Best regards Marek Szyprowski Samsung Poland R&D Center Patch summary: Marek Szyprowski (3): ARM: DMA-Mapping: add function for setting coherent pool size from platform code ARM: DMA-Mapping: print warning when atomic coherent allocation fails ARM: Kirkwood: increase atomic coherent pool size arch/arm/include/asm/dma-mapping.h | 7 +++++++ arch/arm/mach-kirkwood/common.c | 7 +++++++ arch/arm/mm/dma-mapping.c | 22 +++++++++++++++++++++- 3 files changed, 35 insertions(+), 1 deletions(-) -- 1.7.1.569.g6f426

13 years, 11 months

[v4 0/4] ARM: dma-mapping: IOMMU atomic allocation

by Hiroshi Doyu

Hi, The commit e9da6e9 "ARM: dma-mapping: remove custom consistent dma region" breaks the compatibility with existing drivers. This causes the following kernel oops(*1). That driver has called dma_pool_alloc() to allocate memory from the interrupt context, and it hits BUG_ON(in_interrpt()) in "get_vm_area_caller()". This patch seris fixes this problem with making use of the pre-allocate atomic memory pool which DMA is using in the same way as DMA does now. Any comment would be really appreciated. v4: Fix plain memory allocation. (Konrad,Marek) Print nicer error message at __in_atomic_pool() (Konrad) v3: Provide a different path for IOMMU for more clean code. (Marek) atomic_pool is backed with struct page *pages[]. http://lists.linaro.org/pipermail/linaro-mm-sig/2012-August/002446.html v2: Don't modify attrs(DMA_ATTR_NO_KERNEL_MAPPING) for atomic allocation. (Marek) Modify vzalloc (KyongHo,Minchan) http://lists.linaro.org/pipermail/linaro-mm-sig/2012-August/002430.html v1: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-August/002398.html *1: [ 8.321343] ------------[ cut here ]------------ [ 8.325971] kernel BUG at kernel/mm/vmalloc.c:1322! [ 8.333615] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 8.339436] Modules linked in: [ 8.342496] CPU: 0 Tainted: G W (3.4.6-00067-g5d485f7 #67) [ 8.349192] PC is at __get_vm_area_node.isra.29+0x164/0x16c [ 8.354758] LR is at get_vm_area_caller+0x4c/0x54 [ 8.359454] pc : [<c011297c>] lr : [<c011318c>] psr: 20000193 [ 8.359458] sp : c09edca0 ip : c09ec000 fp : ae278000 [ 8.370922] r10: f0000000 r9 : c011aa54 r8 : c0a26cb8 [ 8.376136] r7 : 00000001 r6 : 000000d0 r5 : 20000008 r4 : c09edca0 [ 8.382651] r3 : 00010000 r2 : 20000008 r1 : 00000001 r0 : 00001000 [ 8.389166] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 8.396549] Control: 10c5387d Table: ad98c04a DAC: 00000015 .... [ 9.169162] dfa0: 412fc099 c09ec000 00000000 c000fdd8 c06df1e4 c0a1b080 00000000 00000000 [ 9.177329] dfc0: c0a235cc 8000406a 00000000 c0986818 ffffffff ffffffff c0986404 00000000 [ 9.185497] dfe0: 00000000 c09bb070 10c5387d c0a19c58 c09bb064 80008044 00000000 00000000 [ 9.193673] [<c011297c>] (__get_vm_area_node.isra.29+0x164/0x16c) from [<c011318c>] (get_vm_area_caller+0x4c/0x54) [ 9.204022] [<c011318c>] (get_vm_area_caller+0x4c/0x54) from [<c001aed8>] (__iommu_alloc_remap.isra.14+0x2c/0xfc) [ 9.214276] [<c001aed8>] (__iommu_alloc_remap.isra.14+0x2c/0xfc) from [<c001b06c>] (arm_iommu_alloc_attrs+0xc4/0xf8) [ 9.224795] [<c001b06c>] (arm_iommu_alloc_attrs+0xc4/0xf8) from [<c011aa54>] (pool_alloc_page.constprop.5+0x6c/0xf8) [ 9.235309] [<c011aa54>] (pool_alloc_page.constprop.5+0x6c/0xf8) from [<c011ab60>] (dma_pool_alloc+0x80/0x170) [ 9.245304] [<c011ab60>] (dma_pool_alloc+0x80/0x170) from [<c03cbbcc>] (tegra_build_dtd+0x48/0x14c) [ 9.254344] [<c03cbbcc>] (tegra_build_dtd+0x48/0x14c) from [<c03cbd4c>] (tegra_req_to_dtd+0x7c/0xa8) [ 9.263467] [<c03cbd4c>] (tegra_req_to_dtd+0x7c/0xa8) from [<c03cc140>] (tegra_ep_queue+0x154/0x33c) [ 9.272592] [<c03cc140>] (tegra_ep_queue+0x154/0x33c) from [<c03dd5b4>] (composite_setup+0x364/0x6d4) [ 9.281804] [<c03dd5b4>] (composite_setup+0x364/0x6d4) from [<c03dd9dc>] (android_setup+0xb8/0x14c) [ 9.290843] [<c03dd9dc>] (android_setup+0xb8/0x14c) from [<c03cd144>] (setup_received_irq+0xbc/0x270) [ 9.300053] [<c03cd144>] (setup_received_irq+0xbc/0x270) from [<c03cda64>] (tegra_udc_irq+0x2ac/0x2c4) [ 9.309353] [<c03cda64>] (tegra_udc_irq+0x2ac/0x2c4) from [<c00b5708>] (handle_irq_event_percpu+0x78/0x2e0) [ 9.319087] [<c00b5708>] (handle_irq_event_percpu+0x78/0x2e0) from [<c00b59b4>] (handle_irq_event+0x44/0x64) [ 9.328907] [<c00b59b4>] (handle_irq_event+0x44/0x64) from [<c00b8688>] (handle_fasteoi_irq+0xc4/0x16c) [ 9.338294] [<c00b8688>] (handle_fasteoi_irq+0xc4/0x16c) from [<c00b4f14>] (generic_handle_irq+0x34/0x48) [ 9.347858] [<c00b4f14>] (generic_handle_irq+0x34/0x48) from [<c000f6f4>] (handle_IRQ+0x54/0xb4) [ 9.356637] [<c000f6f4>] (handle_IRQ+0x54/0xb4) from [<c00084b0>] (gic_handle_irq+0x2c/0x60) [ 9.365068] [<c00084b0>] (gic_handle_irq+0x2c/0x60) from [<c000e900>] (__irq_svc+0x40/0x70) [ 9.373405] Exception stack(0xc09edf10 to 0xc09edf58) [ 9.378447] df00: 00000000 000f4240 00000003 00000000 [ 9.386615] df20: 00000000 e55bbc00 ef66f3ca 00000001 00000000 412fc099 c0abb9c8 00000000 [ 9.394781] df40: 3b9ac9ff c09edf58 c027a9bc c0042880 20000113 ffffffff [ 9.401396] [<c000e900>] (__irq_svc+0x40/0x70) from [<c0042880>] (tegra_idle_enter_lp3+0x68/0x78) [ 9.410272] [<c0042880>] (tegra_idle_enter_lp3+0x68/0x78) from [<c04701d4>] (cpuidle_idle_call+0xdc/0x3a4) [ 9.419922] [<c04701d4>] (cpuidle_idle_call+0xdc/0x3a4) from [<c000fdd8>] (cpu_idle+0xd8/0x134) [ 9.428612] [<c000fdd8>] (cpu_idle+0xd8/0x134) from [<c0986818>] (start_kernel+0x27c/0x2cc) [ 9.436952] Code: e1a00004 e3a04000 eb002265 eaffffe0 (e7f001f2) [ 9.443038] ---[ end trace 1b75b31a2719ed24 ]--- [ 9.447645] Kernel panic - not syncing: Fatal exception in interrupt Hiroshi Doyu (4): ARM: dma-mapping: atomic_pool with struct page **pages ARM: dma-mapping: Refactor out to introduce __in_atomic_pool ARM: dma-mapping: Introduce __atomic_get_pages() for __iommu_get_pages() ARM: dma-mapping: IOMMU allocates pages from atomic_pool with GFP_ATOMIC arch/arm/mm/dma-mapping.c | 91 ++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 82 insertions(+), 9 deletions(-) -- 1.7.5.4

13 years, 11 months

Question about ION carveout heap support partial cache flush

by zhangfei gao

Hi, All We met question about dmac_map_area & dmac_flush_range from user addr. mcr would not return on armv7 processor. Existing ion carveout heap does not support partial cache flush. Total cache will be flushed at all. There is only one dirty bit for carveout heap, as well as sg_table->nents. drivers/gpu/ion/ion_carveout_heap.c ion_carveout_heap_map_dma -> sg_alloc_table(table, 1, GFP_KERNEL); ion_buffer_alloc_dirty -> pages = buffer->sg_table->nents; We want to support partial cache flush. Align to cache line, instead of PAGE_SIZE, for efficiency consideration. We have considered extended dirty bit, but looks like only align to PAGE_SIZE. For experiment we modify ioctl ION_IOC_SYNC on armv7. And directly use dmac_map_area & dmac_flush_range with add from user space. However, we find dmac_map_area can not work with this addr from user space. In fact, it is mcr can not work with addr from user space, it would hung. Also, ion_vm_falut would happen twice. The first time is from __dabt_usr, when we access the mmaped buffer, it is fine. The second is from __davt_svc, it is caused by mcr, it is strange? ION malloc carveout heap addr = user mmap user access addr, ion_vm_fault (__dabt_usr), build page table, and vm_insert_page. dmac_map_area & dmac_flush_range with addr -> ion_vm_fault (__davt_svc) mcr hung. Not understand why ion_vm_fault happen twice, where page table has been build. Why mcr will hung with addr from user space. Besides, no problem with ION on 3.0, which do not use ion_vm_fault. Any suggestion? Thanks

13 years, 11 months

Patch to show debugfs output for every heap->id instead of heap->type

by Nishanth Peethambaran

Hi, ION debugfs currently shows/groups output based on type. But, it is possible to have multiple heaps of the same type - for CMA and carveout types. It is more useful to get usage information for individual heaps. - Nishanth Peethambaran >From fa819b42fb69321a8e5db260ba9fd8ce7a2f16d2 Mon Sep 17 00:00:00 2001 From: Nishanth Peethambaran <nishanth(a)broadcom.com> Date: Tue, 28 Aug 2012 07:57:37 +0530 Subject: [PATCH] gpu: ion: Update debugfs to show for each id Update the debugfs read of client and heap to show based on 'id' instead of 'type'. Multiple heaps of the same type can be present, but id is unique. --- drivers/gpu/ion/ion.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c index 34c12df..65cedee 100644 --- a/drivers/gpu/ion/ion.c +++ b/drivers/gpu/ion/ion.c @@ -547,11 +547,11 @@ static int ion_debug_client_show(struct seq_file *s, void *unused) for (n = rb_first(&client->handles); n; n = rb_next(n)) { struct ion_handle *handle = rb_entry(n, struct ion_handle, node); - enum ion_heap_type type = handle->buffer->heap->type; + int id = handle->buffer->heap->id; - if (!names[type]) - names[type] = handle->buffer->heap->name; - sizes[type] += handle->buffer->size; + if (!names[id]) + names[id] = handle->buffer->heap->name; + sizes[id] += handle->buffer->size; } mutex_unlock(&client->lock); @@ -1121,7 +1121,7 @@ static const struct file_operations ion_fops = { }; static size_t ion_debug_heap_total(struct ion_client *client, - enum ion_heap_type type) + int id) { size_t size = 0; struct rb_node *n; @@ -1131,7 +1131,7 @@ static size_t ion_debug_heap_total(struct ion_client *client, struct ion_handle *handle = rb_entry(n, struct ion_handle, node); - if (handle->buffer->heap->type == type) + if (handle->buffer->heap->id == id) size += handle->buffer->size; } mutex_unlock(&client->lock); @@ -1149,7 +1149,7 @@ static int ion_debug_heap_show(struct seq_file *s, void *unused) for (n = rb_first(&dev->clients); n; n = rb_next(n)) { struct ion_client *client = rb_entry(n, struct ion_client, node); - size_t size = ion_debug_heap_total(client, heap->type); + size_t size = ion_debug_heap_total(client, heap->id); if (!size) continue; if (client->task) { -- 1.7.0.4

13 years, 11 months

sharing across process of ion/dma_buf created after fork

by Nishanth Peethambaran

How do we share ion buffers from user-space with other processes if they are exported/shared after fork? The ION_IOC_SHARE ioctl creates an fd for process-1. In 3.0 kernel, the ION_ION_IMPORT ioctl from process-2 calls ion_import_fd which calls fget(fd) which fails to find the file for the fd shared by process-1. In 3.4 kernel, dma_buf_get does the fget(fd) to get struct file which also fails for the same reason - fget searches in current->files. - Nishanth Peethambaran

13 years, 11 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig