- Linaro-mm-sig - lists.linaro.org

Ideal Android device to do Audio Multimedia Android stuff

by Viswanath Puttagunta

Hi All, I lost the only Android Tablet that I had to hack around and in the market for new Android Tablet. Needs to be stuff I can buy personally, so Juno / Vexpress is out the window. What would you recommend I buy? Below are specific use cases i. Work on NEON optimizations for Audio libraries (Vorbis, FLAC etc) in **Android** context. ii. So, would obviously like to have a reference Android baseline build that is actively used in Linaro. Is anyone in LMG using builds available for Nexus10 <http://releases.linaro.org/14.09/android/nexus10> and Nexus7 <http://releases.linaro.org/14.09/android/nexus7-2013> actively right now? How official are these builds? Regards, Vish (Viswanath Puttagunta) Cell: 972-342-0205 Technical Program Manager Member Services, Linaro

11 years, 4 months

1
0
0 0

Install Ubuntu on Samsung Chromebook 2

by Viswanath Puttagunta

Hi All, Does any one have instructions to install Ubuntu natively on Samsung Chromebook2 that worked for you? Regards, Vish (Viswanath Puttagunta) Cell: 972-342-0205 Technical Program Manager Member Services, Linaro

11 years, 4 months

1
0
0 0

Changing PAGE_ALLOC_COSTLY_ORDER from 3 to 2

by Pintu Kumar

Hi, I wanted to know about the impact of changing PAGE_ALLOC_COSTLY_ORDER value from 3 to 2. This macro is defined in include/linux/mmzone.h #define PAGE_ALLOC_COSTLY_ORDER 3 As I know this value should never be changed irrespective of the type of the system. Is it good to change this value for RAM size: 512MB, 256MB or 128MB? If anybody have changed this value and experience any kind of problem or benefits please let us know. We noticed that for one of the Android product with 512MB RAM, the PAGE_ALLOC_COSTLY_ORDER was set to 2. We could not figure out why this value was decreased from 3 to 2. As per my analysis, I observed that kmalloc fails little early, if we change this value to 2. This is also visible from the _slowpath_ in page_alloc.c Apart from this we could not find any other impact. If anybody is aware of any other impact, please let us know. Thank you! Regards, Pintu Kumar

11 years, 4 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Daniel Vetter

On Sun, Sep 14, 2014 at 12:36:43PM +0200, Christian König wrote: > Yeah, right. Providing the fd to reassign to a fence would indeed reduce the > create/close overhead. > > But it would still be more overhead than for example a simple on demand > growing ring buffer which then uses 64bit sequence numbers in userspace to > refer to a fence in the kernel. > > Apart from that I'm pretty sure that when we do the syncing completely in > userspace we need more fences open at the same time than fds are available > by default. If you do the syncing completely in userspace you don't need kernel fences at all. Kernel fences are only required if you sync with a different process (where the pure userspace syncing might not work out) or with different devices. tbh I don't see any use-case at all where you'd need 10k such fences. That means your driver gets to deal with 2 kinds of fences, but so be it. Since not using fds for cross-device or cross-process syncing imo just doesn't make sense, so that one pretty much will have to stick. > As long as our internal handle or sequence based fence are easily > convertible to a fence fd I actually don't really see a problem with that. > Going to hack that approach into my prototype and then we can see how bad > the code looks after all. My plan for i915 is to start out with fd fences only, and once we have some clarity on the exact requirements probably add some pure userspace-controlled fences for tightly coupled stuff. Those might be fully internal to the opencl userspace driver though and never get out of there, ever. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

11 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jesse Barnes

On Fri, 12 Sep 2014 18:08:23 +0200 Christian König <christian.koenig(a)amd.com> wrote: > > As Daniel said using fd is most likely the way we want to do it but this > > remains vague. > Separating the discussion if it should be an fd or not. Using an fd > sounds fine to me in general, but I have some concerns as well. > > For example what was the maximum number of opened FDs per process again? > Could that become a problem? etc... You can check out the i915 patches I posted if you want to see examples. Max fds may be an issue if userspace doesn't clean up its fences. The implementation is pretty easy with the stuff Maarten has done recently. The changes I still need to make to mine: - sit on top of Chris's request/seqno changes (driver internals really) - switch over to execbuf as the main API on the render side (like you're doing) - add support for display and other timelines As far as compat goes, I don't think it should be too hard. Even with GPU scheduling, a given context's buffers should all be in-order with respect to one another, so we ought to be able to mix & match clients using explicit fencing and implicit fencing. Though in Mesa I still haven't looked at how to handle server vs client side arb_sync with the scheduler and explicit fencing in place; might need some extra work there... -- Jesse Barnes, Intel Open Source Technology Center

11 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jerome Glisse

On Fri, Sep 12, 2014 at 05:58:09PM +0200, Christian König wrote: > Am 12.09.2014 um 17:48 schrieb Jerome Glisse: > >On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian König wrote: > >>Am 12.09.2014 um 17:33 schrieb Jerome Glisse: > >>>On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: > >>>>On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse <j.glisse(a)gmail.com> wrote: > >>>>>On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > >>>>>>On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter <daniel(a)ffwll.ch> wrote: > >>>>>>>On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > >>>>>>>>Hello everyone, > >>>>>>>> > >>>>>>>>to allow concurrent buffer access by different engines beyond the multiple > >>>>>>>>readers/single writer model that we currently use in radeon and other > >>>>>>>>drivers we need some kind of synchonization object exposed to userspace. > >>>>>>>> > >>>>>>>>My initial patch set for this used (or rather abused) zero sized GEM buffers > >>>>>>>>as fence handles. This is obviously isn't the best way of doing this (to > >>>>>>>>much overhead, rather ugly etc...), Jerome commented on this accordingly. > >>>>>>>> > >>>>>>>>So what should a driver expose instead? Android sync points? Something else? > >>>>>>>I think actually exposing the struct fence objects as a fd, using android > >>>>>>>syncpts (or at least something compatible to it) is the way to go. Problem > >>>>>>>is that it's super-hard to get the android guys out of hiding for this :( > >>>>>>> > >>>>>>>Adding a bunch of people in the hopes that something sticks. > >>>>>>More people. > >>>>>Just to re-iterate, exposing such thing while still using command stream > >>>>>ioctl that use implicit synchronization is a waste and you can only get > >>>>>the lowest common denominator which is implicit synchronization. So i do > >>>>>not see the point of such api if you are not also adding a new cs ioctl > >>>>>with explicit contract that it does not do any kind of synchronization > >>>>>(it could be almost the exact same code modulo the do not wait for > >>>>>previous cmd to complete). > >>>>Our thinking was to allow explicit sync from a single process, but > >>>>implicitly sync between processes. > >>>This is a BIG NAK if you are using the same ioctl as it would mean you are > >>>changing userspace API, well at least userspace expectation. Adding a new > >>>cs flag might do the trick but it should not be about inter-process, or any > >>>thing special, it's just implicit sync or no synchronization. Converting > >>>userspace is not that much of a big deal either, it can be broken into > >>>several step. Like mesa use explicit synchronization all time but ddx use > >>>implicit. > >>The thinking here is that we need to be backward compatible for DRI2/3 and > >>support all kind of different use cases like old DDX and new Mesa, or old > >>Mesa and new DDX etc... > >> > >>So for my prototype if the kernel sees any access of a BO from two different > >>clients it falls back to the old behavior of implicit synchronization of > >>access to the same buffer object. That might not be the fastest approach, > >>but is as far as I can see conservative and so should work under all > >>conditions. > >> > >>Apart from that the planning so far was that we just hide this feature > >>behind a couple of command submission flags and new chunks. > >Just to reproduce IRC discussion, i think it's a lot simpler and not that > >complex. For explicit cs ioctl you do not wait for any previous fence of > >any of the buffer referenced in the cs ioctl, but you still associate a > >new fence with all the buffer object referenced in the cs ioctl. So if the > >next ioctl is an implicit sync ioctl it will wait properly and synchronize > >properly with previous explicit cs ioctl. Hence you can easily have a mix > >in userspace thing is you only get benefit once enough of your userspace > >is using explicit. > > Yes, that's exactly what my patches currently implement. > > The only difference is that by current planning I implemented it as a per BO > flag for the command submission, but that was just for testing. Having a > single flag to switch between implicit and explicit synchronization for > whole CS IOCTL would do equally well. Doing it per BO sounds bogus to me. But otherwise yes we are in agreement. As Daniel said using fd is most likely the way we want to do it but this remains vague. > > >Note that you still need a way to have explicit cs ioctl to wait on a > >previos "explicit" fence so you need some api to expose fence per cs > >submission. > > Exactly, that's what this mail thread is all about. > > As Daniel correctly noted you need something like a functionality to get a > fence as the result of a command submission as well as pass in a list of > fences to wait for before beginning a command submission. > > At least it looks like we are all on the same general line here, its just > nobody has a good idea how the details should look like. > > Regards, > Christian. > > > > >Cheers, > >Jérôme > > > >>Regards, > >>Christian. > >> > >>>Cheers, > >>>Jérôme > >>> > >>>>Alex > >>>> > >>>>>Also one thing that the Android sync point does not have, AFAICT, is a > >>>>>way to schedule synchronization as part of a cs ioctl so cpu never have > >>>>>to be involve for cmd stream that deal only one gpu (assuming the driver > >>>>>and hw can do such trick). > >>>>> > >>>>>Cheers, > >>>>>Jérôme > >>>>> > >>>>>>-Daniel > >>>>>>-- > >>>>>>Daniel Vetter > >>>>>>Software Engineer, Intel Corporation > >>>>>>+41 (0) 79 365 57 48 - http://blog.ffwll.ch > >>>>>_______________________________________________ > >>>>>dri-devel mailing list > >>>>>dri-devel(a)lists.freedesktop.org > >>>>>http://lists.freedesktop.org/mailman/listinfo/dri-devel >

11 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Jerome Glisse

On Fri, Sep 12, 2014 at 05:42:57PM +0200, Christian König wrote: > Am 12.09.2014 um 17:33 schrieb Jerome Glisse: > >On Fri, Sep 12, 2014 at 11:25:12AM -0400, Alex Deucher wrote: > >>On Fri, Sep 12, 2014 at 10:50 AM, Jerome Glisse <j.glisse(a)gmail.com> wrote: > >>>On Fri, Sep 12, 2014 at 04:43:44PM +0200, Daniel Vetter wrote: > >>>>On Fri, Sep 12, 2014 at 4:09 PM, Daniel Vetter <daniel(a)ffwll.ch> wrote: > >>>>>On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > >>>>>>Hello everyone, > >>>>>> > >>>>>>to allow concurrent buffer access by different engines beyond the multiple > >>>>>>readers/single writer model that we currently use in radeon and other > >>>>>>drivers we need some kind of synchonization object exposed to userspace. > >>>>>> > >>>>>>My initial patch set for this used (or rather abused) zero sized GEM buffers > >>>>>>as fence handles. This is obviously isn't the best way of doing this (to > >>>>>>much overhead, rather ugly etc...), Jerome commented on this accordingly. > >>>>>> > >>>>>>So what should a driver expose instead? Android sync points? Something else? > >>>>>I think actually exposing the struct fence objects as a fd, using android > >>>>>syncpts (or at least something compatible to it) is the way to go. Problem > >>>>>is that it's super-hard to get the android guys out of hiding for this :( > >>>>> > >>>>>Adding a bunch of people in the hopes that something sticks. > >>>>More people. > >>>Just to re-iterate, exposing such thing while still using command stream > >>>ioctl that use implicit synchronization is a waste and you can only get > >>>the lowest common denominator which is implicit synchronization. So i do > >>>not see the point of such api if you are not also adding a new cs ioctl > >>>with explicit contract that it does not do any kind of synchronization > >>>(it could be almost the exact same code modulo the do not wait for > >>>previous cmd to complete). > >>Our thinking was to allow explicit sync from a single process, but > >>implicitly sync between processes. > >This is a BIG NAK if you are using the same ioctl as it would mean you are > >changing userspace API, well at least userspace expectation. Adding a new > >cs flag might do the trick but it should not be about inter-process, or any > >thing special, it's just implicit sync or no synchronization. Converting > >userspace is not that much of a big deal either, it can be broken into > >several step. Like mesa use explicit synchronization all time but ddx use > >implicit. > > The thinking here is that we need to be backward compatible for DRI2/3 and > support all kind of different use cases like old DDX and new Mesa, or old > Mesa and new DDX etc... > > So for my prototype if the kernel sees any access of a BO from two different > clients it falls back to the old behavior of implicit synchronization of > access to the same buffer object. That might not be the fastest approach, > but is as far as I can see conservative and so should work under all > conditions. > > Apart from that the planning so far was that we just hide this feature > behind a couple of command submission flags and new chunks. Just to reproduce IRC discussion, i think it's a lot simpler and not that complex. For explicit cs ioctl you do not wait for any previous fence of any of the buffer referenced in the cs ioctl, but you still associate a new fence with all the buffer object referenced in the cs ioctl. So if the next ioctl is an implicit sync ioctl it will wait properly and synchronize properly with previous explicit cs ioctl. Hence you can easily have a mix in userspace thing is you only get benefit once enough of your userspace is using explicit. Note that you still need a way to have explicit cs ioctl to wait on a previos "explicit" fence so you need some api to expose fence per cs submission. Cheers, Jérôme > > Regards, > Christian. > > > > >Cheers, > >Jérôme > > > >>Alex > >> > >>>Also one thing that the Android sync point does not have, AFAICT, is a > >>>way to schedule synchronization as part of a cs ioctl so cpu never have > >>>to be involve for cmd stream that deal only one gpu (assuming the driver > >>>and hw can do such trick). > >>> > >>>Cheers, > >>>Jérôme > >>> > >>>>-Daniel > >>>>-- > >>>>Daniel Vetter > >>>>Software Engineer, Intel Corporation > >>>>+41 (0) 79 365 57 48 - http://blog.ffwll.ch > >>>_______________________________________________ > >>>dri-devel mailing list > >>>dri-devel(a)lists.freedesktop.org > >>>http://lists.freedesktop.org/mailman/listinfo/dri-devel >

11 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] Question on UAPI for fences

by Daniel Vetter

On Fri, Sep 12, 2014 at 03:23:22PM +0200, Christian König wrote: > Hello everyone, > > to allow concurrent buffer access by different engines beyond the multiple > readers/single writer model that we currently use in radeon and other > drivers we need some kind of synchonization object exposed to userspace. > > My initial patch set for this used (or rather abused) zero sized GEM buffers > as fence handles. This is obviously isn't the best way of doing this (to > much overhead, rather ugly etc...), Jerome commented on this accordingly. > > So what should a driver expose instead? Android sync points? Something else? I think actually exposing the struct fence objects as a fd, using android syncpts (or at least something compatible to it) is the way to go. Problem is that it's super-hard to get the android guys out of hiding for this :( Adding a bunch of people in the hopes that something sticks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

11 years, 5 months

3
6
0 0

[PATCH] drm: sti: do not iterate over the info frame array

by Benjamin Gaignard

avi infoframe is a 13 bytes array, do not read after this limite. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/drm/sti/sti_hdmi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index 284e541..90ee20a 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -298,7 +298,6 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi *hdmi) hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD2(HDMI_IFRAME_SLOT_AVI)); val = frame[0xC]; - val |= frame[0xD] << 8; hdmi_write(hdmi, val, HDMI_SW_DI_N_PKT_WORD3(HDMI_IFRAME_SLOT_AVI)); /* Enable transmission slot for AVI infoframe -- 1.9.1

11 years, 5 months

1
0
0 0

[PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

by Marek Szyprowski

Hello Everyone, A lot of things has happened in the area of improving Exynos IOMMU driver and discussion about generic IOMMU bindings, which finally motivated me to get back to IOMMU related tasks. Just to remind, here are those 2 important threads: 1. [PATCH v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT: https://lkml.org/lkml/2014/5/12/34 2. [PATCH v4] devicetree: Add generic IOMMU device tree bindings: https://lkml.org/lkml/2014/7/4/349 As a follow up of those discussions I've decided to finish our internal code, which adapts Exynos SYSMMU driver to meet generic IOMMU bindings requirements and implement all needed glue code to finally demonstare seemless integration IOMMU controller with DMA-mapping subsystem for the drivers available on Exynos SoCs. 1. Introduction - a few words for those who are not fully aware of the Exynos SoC hardware Exynos SoC consists of various devices integrated directly into SoCs. Most of them are multimedia devices, which usually process large buffers. Some of them (like i.e. MFC - a multimedia codec or FIMD - a multi-window framebuffer device & lcd panel controller) are equipped with more than one memory interface for higher processing performance. There are also really complex subsystems (like ISP, the camera sensor interface & processor), which consist of many sub-blocks, each having its own memory interface/channel/bus (different names are used for the same thing). Each such memory controller might be equipped with SYSMMU device, which acts as IOMMU controller for the parent device (called master device, a device which that memory interface belongs to). Each SYSMMU controller has its own register set and clock, belongs to the same power domain as master device. There is also some non-direct relation from master's device gate clock - SYSMMU registers can be accessed only when master's gate clock is enabled. Basically we have following dependencies between hardware and drivers: - each multimedia device might have 1 or more SYSMMU controller - each SYSMMU controller belongs only to 1 master device - all SYSMMU controllers are independent of each other, there is no global hardware ID that must be assigned to enable given SYSMMU controller - multimedia devices are modeled usually by a separate node in device tree with it's own compatible string and separate driver for them - sub-blocks of complex devices right now are not modeled by a separate device tree nodes, but this might be changed in the future - some multimedia devices have limited address space per each memory controller/channel (i.e. codec might access buffers only in a 256MiB window for each of it's memory channels) - some drivers for independent device are used together to provide a more complex subsystem, i.e. FIMD, HDMI-mixer and others form together Exynos DRM subsystem; it is highly welcome to let them to operate in the same, shared DMA address space to simplify buffer sharing 2. Introduction part 2 - a few word of summary of the discussions about generic IOMMU DT bindings There have been a lot of discussions on the method of modeling IOMMU controllers in device tree. The approach which has been selected as the generic IOMMU binding candidate has been described in the '[PATCH v4] devicetree: Add generic IOMMU device tree bindings' thread. Those bindings describe how to link an IOMMU controller with its master device. Basically an 'iommus' property placed in the master's device node has been introduced. This property contains phandle to IOMMU controller node. Optional properties of the particular binding can also be specified after the phandle, assuming that IOMMU controller node contains '#iommu-cells' property, which defines number of cells used for those parameters. Those parameters are then interpreted by particular IOMMU controller driver. Those parameters might be some hw channel id required for correct hardware setup, base address and size pair for limited IO address space window or others hardware dependant properties. 3. IOMMU integration to DMA-mapping subsystem By default we assume that each master device, which has been equipped with IOMMU controller gets its own DMA (IO) address space. This is created automatically and transparently without any changes in the device driver code. All DMA-mapping functions are replaced with the IOMMU aware versions. This has to be done somewhere by the architecture or SoC startup code, so when master's driver probe() function is called, everything is in place. However some device drivers might need (for various reasons) to manually manage DMA (IO) address space. For this case a driver need to notify kernel about that and do the management of DMA address space on its own. This has been achieved by introducing DRIVER_HAS_OWN_IOMMU_MANAGER flag, which can be set in struct device_driver. This way the startup code can easily determine if creating the default per-device separate DMA address space is required for a given driver or not without any unneeded alloc/free call sequences. 4. Linux DMA-mapping subsystem and more than one DMA address space DMA-mapping subsystem assumes that there is only one DMA (IO) address space associated with the given struct device entity. Usually struct device is mapped in one-to-one relation to a node describing given device in device tree. To let driver to access other DMA (IO) address spaces a sub-device has been introduced. This approach has been already used by s5p-mfc driver (drivers/media/platform/s5p-mfc/s5p_mfc.c). The only question is how and when sub-devices are created. In the proposed approach, such additional address spaces are named with the names of the respective IOMMU controllers (iommu-names property in master's DT node). To let driver to access an address space, a sub-device named 'parent_device_name:address_space_name' need to be created and added as a child to master's struct device. A good example is codec device, which on Exynos4412 SoC is instantiated as '13400000.codec' device. It has 2 memory interfaces ('left' and 'right'), so the sub-devices called '13400000.codec:left' and '13400000.codec:right' must be created by a driver and added as children of '13400000.codec' device. Once then the driver is allowed to allocate 2 separate dma-mapping address spaces by calling arm_iommu_create_mapping() and arm_iommu_detach_device() functions or newly introduced helper arm_iommu_create_default_mapping(). For more details, please refer to the last patch in this series. Exactly the same approach is planned to be done for memory regions and DMA-mapping implemented on top of CMA or DMA-coherent memory allocators. When driver doesn't specify that it wants to manage its DMA (IO) address spaces, a default DMA (IO) address space will be created and all SYSMMU controllers will be bound to it, so this space will be shared across master's device IO channels / memory interfaces. This way IOMMU support might be added only to drivers which really benefit from having separate IO address space per memory interface without a need to alter the other drivers. Why driver might need to manage the IO address space on its own? Once again the codec device on Exynos4 series is a good example. Memory interfaces found in the mentioned codec device are limited and can address only 256MiB window. If we bind both interfaces to common address space, driver is able only to access memory buffers, which fits into 256MiB window. If we use separate spaces for each memory interface, codec device will be able to access buffers of total 2*256MiB=512MiB, which is a significant advantage over the default case of shared address space. 5. Power management (runtime) Runtime power management is the most tricky part of the proposed solution. I assumed that it is a sane requirement that from the master's device driver the operation without IOMMU and with IOMMU (with default, per-device mapping) should be exactly the same. The runtime power management, which is now mainly limited to enabling and disabling hardware power domains is done by the master's device driver. However from the hardware perspective, there is also a need to save SYSMMU context before switch pm domain off and restore it after switching pm domain on. To achieve this way of SYSMMU operation, a notifiers for power domains have been introduces. With such an approach no changes are needed in master's device driver and SYSMMU driver seamlessly integrates with master's device runtime pm operations. 6. Proposed patches and changes Patch 0001 "pm: Add PM domain notifications" adds support for power domain notifiers (see chapter 5 above). Patch 0002 "ARM: Exynos: bind power domains earlier, on device creation" changes the time, when Exynos power domains are bound to the device. Now this happens on DEVICE_ADD event instead of DRIVER_BIND, so when SYSMMU driver is being initialized, the power domains are already bound and notifiers can be added. Patch 0003 "clk: exynos: add missing smmu_g2d clock and update comments" simply simply adds missing sysmmu related entities to Exynos clock driver. Patch 0004 "drivers: base: add notifier for failed driver bind" add event for failed driver bind, so things prepared in DRIVER_BIND event can be cleaned up, similar to DRIVER_UNBOUND. Patch 0005 "drivers: convert suppress_bind_attrs parameter into flags" is preparation for adding new flags to struct device_driver. Patch 0006 "drivers: iommu: add notify about failed bind" adds support for recently introduced failed driver bind event to IOMMU subsystem. Patch 0007 "ARM: dma-mapping: arm_iommu_attach_device: automatically set max_seg_size" moves common operation of setting dma max_seg_size directly to arm_iommu_attach_device function. Patch 0008 "ARM: dma-mapping: add helpers for managing default per-device dma mappings" adds convenient helpers for the most common case of setting up per-device, separate DMA (IO) address space. Patch 0009 "ARM: dma-mapping: provide stubs if no ARM_DMA_USE_IOMMU has been selected" fixes usage of IOMMU related ARM DMA-mapping functions in common code. Patch 0010 "drivers: add DRIVER_HAS_OWN_IOMMU_MANAGER flag" adds a flag described in chapter 3. Patch 0011 "DRM: exynos: add DRIVER_HAS_OWN_IOMMU_MANAGER flag to all sub-drivers" marks all Exynos DRM sub-drivers with a flag notifying that they perform own management of DMA (IO) address space. All the code to setup dma-mapping and attach all devices is realy there. Patch 0012 "DRM: Exynos: fix window clear code" is a simple bugfix of broken init code, which triggers issues when used with IOMMU (page fault happens on systems, where bootloader has left framebuffer enabled). Patch 0013 "temporary: media: s5p-mfc: remove DT hacks & initialization custom memory init code" removes all custom memory region handling, to let later demonstrate how to use separate DMA (IO) address spaces from master's device driver. Patch 0014 "devicetree: Update Exynos SYSMMU device tree bindings" adds a few words about proposed solution to SYSMMU device tree bindings documentation. Patch 0015 "ARM: DTS: Exynos4: add System MMU nodes" adds device tree nodes for all SYSMMU controllers found in Exynos 4210 and 4x12 SoC and respective properties to their master devices. Patch 0016-0021 are simple bugfixes and code refactoring to simplify the driver: "iommu: exynos: make driver multiarch friendly", "iommu: exynos: don't read version register on every tlb", "iommu: exynos: remove unused functions", "iommu: exynos: remove useless spinlock", "iommu: exynos: refactor function parameters to simplify code", "iommu: exynos: remove unused functions, part 2". Patch 0022 "iommu: exynos: add support for binding more than one sysmmu to master device" adds support for storing a list of SYSMMU controllers in the master's iommu arch data structure. Patch 0023 "iommu: exynos: init iommu controllers from device tree" finally implements bindings described in patch 0015 and access to particular DMA address space managed by SYSMMU controller via sub-device of predefined name (see chapter 4). Patch 0024 "iommu: exynos: create default iommu-based dma-mapping for master devices" does what patch title says. Patch 0025 "iommu: exynos: add support for runtime_pm" implements power management scheme described in chapter 5. Patch 0026-0028 are cleanup and refactoring to make the code easier to understand: "iommu: exynos: rename variables to reflect their purpose", "iommu: exynos: document internal structures", "iommu: exynos: remove excessive includes and sort others alphabetically". Patch 0029 "temporary: media: s5p-mfc: add support for IOMMU" demonstrates how to use sub-devices to get access to separate DMA (IO) address spaces. The driver is able to work both with and without this patch. Without this patch a common shared address space is created for both SYSMMU controllers (so only 256MiB of total address space is available, see end of chapter 4). 7. Summary All the development of those patches have been done on Exynos4412-based OdroidU3 board and Exynos4210-based UniversalC210, on top of v3.16 kernel with some additional patches to enable HDMI support on Odroid board. This version is available in the following GIT repository: http://git.linaro.org/git/people/marek.szyprowski/linux-dma-mapping.git on branch v3.16-odroid-iommu. However, the version posted here has been rebased on top of linux-next kernel (next-20140804 tag), to make marging the easier once v3.17-rc1 is out. 8. Diffstat .../devicetree/bindings/iommu/samsung,sysmmu.txt | 93 ++- Documentation/power/notifiers.txt | 14 + arch/arm/boot/dts/exynos4.dtsi | 118 ++++ arch/arm/boot/dts/exynos4210.dtsi | 23 + arch/arm/boot/dts/exynos4x12.dtsi | 82 +++ arch/arm/include/asm/dma-iommu.h | 36 ++ arch/arm/mach-exynos/pm_domains.c | 12 +- arch/arm/mach-integrator/impd1.c | 2 +- arch/arm/mm/dma-mapping.c | 47 ++ drivers/base/bus.c | 4 +- drivers/base/dd.c | 10 +- drivers/base/platform.c | 2 +- drivers/base/power/domain.c | 70 ++- drivers/clk/samsung/clk-exynos4.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 + drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 + drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 1 + drivers/iommu/exynos-iommu.c | 663 +++++++++++++-------- drivers/iommu/iommu.c | 3 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 107 ++-- drivers/pci/host/pci-mvebu.c | 2 +- drivers/pci/host/pci-rcar-gen2.c | 2 +- drivers/pci/host/pci-tegra.c | 2 +- drivers/pci/host/pcie-rcar.c | 2 +- drivers/soc/tegra/pmc.c | 2 +- include/dt-bindings/clock/exynos4.h | 10 +- include/linux/device.h | 12 +- include/linux/iommu.h | 1 + include/linux/pm.h | 2 + include/linux/pm_domain.h | 19 + 33 files changed, 1016 insertions(+), 356 deletions(-) Best regards Marek Szyprowski Samsung R&D Institute Poland

11 years, 5 months

9
49
0 0

[PATCH] android: fix reference leak in sync_fence_create

by Maarten Lankhorst

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. This fixes a memory leak introduced in 3.17's android fence rework. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Cc: Colin Cross <ccross(a)google.com> Cc: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e0234196..69139ce7420d 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -199,7 +199,6 @@ struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt) fence->num_fences = 1; atomic_set(&fence->status, 1); - fence_get(&pt->base); fence->cbs[0].sync_pt = &pt->base; fence->cbs[0].fence = fence; if (fence_add_callback(&pt->base, &fence->cbs[0].cb, -- 2.0.4

11 years, 5 months

1
0
0 0

[PATCH 1/2] android: fix reference leak in sync_fence_create

by Maarten Lankhorst

According to the documentation sync_fence_create takes ownership of the point, not a reference on the point. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Cc: Colin Cross <ccross(a)google.com> --- drivers/staging/android/sync.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index e7b2e0234196..69139ce7420d 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -199,7 +199,6 @@ struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt) fence->num_fences = 1; atomic_set(&fence->status, 1); - fence_get(&pt->base); fence->cbs[0].sync_pt = &pt->base; fence->cbs[0].fence = fence; if (fence_add_callback(&pt->base, &fence->cbs[0].cb, -- 2.0.4

11 years, 5 months

4
10
0 0

[GIT PULL]: few dma-buf updates for 3.17-rc3

by Sumit Semwal

Hi Linus, The major changes for 3.17 already went via Greg-KH's tree this time as well; this is a small pull request for dma-buf - all documentation related. Could you please pull? The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d: Merge branch 'sec-v3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security (2014-08-27 17:32:37 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/for-3.17-rc3 for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295: dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530) ---------------------------------------------------------------- Small dma-buf pull request for 3.17-rc3 ---------------------------------------------------------------- Gioh Kim (1): Documentation/dma-buf-sharing.txt: update API descriptions Thierry Reding (2): dma-buf/fence: Fix a kerneldoc warning dma-buf/fence: Fix one more kerneldoc warning Documentation/dma-buf-sharing.txt | 14 ++++++++------ drivers/dma-buf/fence.c | 2 +- include/linux/seqno-fence.h | 1 + 3 files changed, 10 insertions(+), 7 deletions(-)

11 years, 5 months

1
0
0 0

[PATCH 0/2] ARM: Remove lowmem limit for default CMA region

by Marek Szyprowski

Hello, Russell King recently noticed that limiting default CMA region only to low memory on ARM architecture causes serious memory management issues with machines having a lot of memory (which is mainly available as high memory). More information can be found the following thread: http://thread.gmane.org/gmane.linux.ports.arm.kernel/348441/ Those two patches removes this limit letting kernel to put default CMA region into high memory when this is possible (there is enough high memory available and architecture specific DMA limit fits). This should solve strange OOM issues on systems with lots of RAM (i.e. >1GiB) and large (>256M) CMA area. Best regards Marek Szyprowski Samsung R&D Institute Poland Marek Szyprowski (2): mm: cma: adjust address limit to avoid hitting low/high memory boundary ARM: mm: don't limit default CMA region only to low memory arch/arm/mm/init.c | 2 +- mm/cma.c | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) -- 1.9.2

11 years, 5 months

6
15
0 0

[PATCH v2 0/4] CMA & device tree, once again

by Marek Szyprowski

Hello, This is one more respin of the patches which add support for creating reserved memory regions defined in device tree. The last attempt (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html) ended in merging only half of the code, so right now we have complete documentation merged and only basic code, which implements a half of it is written in the documentation. Although the merged patches allow to reserve memory, there is no way of using it for devices and drivers. This situation makes CMA rather useless, as the main architecture (ARM), which used it, has been converted from board-file based system initialization to device tree. Thus there is no place to use direct calls to dma_declare_contiguous() and some new solution, which bases on device tree, is urgently needed. This patch series fixes this issue. It provides two, already widely discussed and already present in the kernel, drivers for reserved memory: first based on DMA-coherent allocator, second using Contiguous Memory Allocator. The first one nicely implements typical 'carved out' reserved memory way of allocating contiguous buffers in a kernel-style way. The memory is used exclusively by devices assigned to the given memory region. The second one allows to reuse reserved memory for movable kernel pages (like disk buffers, anonymous memory) and migrates it out when device to allocates contiguous memory buffer. Both driver provides memory buffers via standard dma-mapping API. The patches have been rebased on top of latest CMA and mm changes merged to akmp kernel tree. To define a 64MiB CMA region following node is needed: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; reusable; size = <0x4000000>; alignment = <0x400000>; }; Similarly, one can define 64MiB region with DMA coherent memory: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; no-map; size = <0x4000000>; alignment = <0x400000>; }; Then the defined region can be assigned to devices: scaler: scaler@12500000 { memory-region = <&multimedia_reserved>; /* ... */ }; codec: codec@12600000 { memory-region = <&multimedia_reserved>; /* ... */ }; Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg343702.html) - fixed possible memory leak in case of reserved memory allocation failure (thanks to Joonsoo Kim) Changes since the version posted in '[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again' thread http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html: - rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code' patch series on v3.16-rc3 - improved dma-coherent driver, now it correctly handles assigning more than one device to the given memory region Patch summary: Marek Szyprowski (4): drivers: of: add automated assignment of reserved regions to client devices drivers: of: initialize and assign reserved memory to newly created devices drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 40 +++++++++++++++++++++++ drivers/base/dma-contiguous.c | 60 +++++++++++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 70 +++++++++++++++++++++++++++++++++++++++++ drivers/of/platform.c | 7 +++++ include/linux/cma.h | 3 ++ include/linux/of_reserved_mem.h | 7 +++++ mm/cma.c | 62 +++++++++++++++++++++++++++++------- 7 files changed, 238 insertions(+), 11 deletions(-) -- 1.9.2

11 years, 5 months

2
8
0 0

[git pull] sti driver fixes 3.17-rc2

by Benjamin Gaignard

Hello David, I have tested the 6 patches send on mailing list since you merge the sti driver. I haven't seen issue with those patches except for the missing dependency on Kconfig where I have change "depends on" to "select". You can found the patches in this directory: git://git.linaro.org/people/benjamin.gaignard/kernel.git on drm-3.17-rc2-sti-fixes branch. Regards, Benjamin Jingoo Han (1): drm: sti: Add missing dependency on RESET_CONTROLLER Kiran Padwal (1): drm: sti: Make of_device_id array const Wei Yongjun (4): drm: sti: tvout: fix return value check in sti_tvout_probe() drm: sti: hdmi: fix return value check in sti_hdmi_probe() drm: sti: hda: fix return value check in sti_hda_probe() drm: sti: Fix return value check in sti_drm_platform_probe() drivers/gpu/drm/sti/Kconfig | 1 + drivers/gpu/drm/sti/sti_drm_drv.c | 4 ++-- drivers/gpu/drm/sti/sti_hda.c | 10 +++++----- drivers/gpu/drm/sti/sti_hdmi.c | 10 +++++----- drivers/gpu/drm/sti/sti_tvout.c | 6 +++--- 5 files changed, 16 insertions(+), 15 deletions(-) -- 1.9.1

11 years, 5 months

1
0
0 0

[PATCH 0/7] CMA & device tree, another approach

by Marek Szyprowski

Hello, This is another approach to finish support for reserved memory regions defined in device tree. Previous attempts (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html and https://lkml.org/lkml/2014/7/14/108) ended in merging parts of the code and documentation. Merged patches allow to reserve memory, but there is still no reserved memory drivers nor any code that actually uses reserved memory regions. The final conclusion from the above mentioned threads is that there is no automated reserved memory initialization. All drivers that want to use reserved memory, should initialize it on their own. This patch series provides two driver for reserved memory regions (one based on CMA and one based on dma_coherent allocator). The main improvement comparing to the previous version is removal of automated reserved memory for every device and support for named memory regions. Support for more than one reserved memory region can be considered as a separate DMA address space, so support for more than one region per device has been implemented the same way as support for separate IO/DMA address spaces in my Exynos IOMMU dma-mapping proposal: http://thread.gmane.org/gmane.linux.kernel.samsung-soc/36079 Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since '[PATCH v2 RESEND 0/4] CMA & device tree, once again' version: (https://lkml.org/lkml/2014/7/14/108) - added return error value to of_reserved_mem_device_init() - added support for named memory regions (so more than one region can be defined per device) - added usage example - converted custom reserved memory code used by s5p-mfc driver to the generic reserved memory handling code Patch summary: Marek Szyprowski (7): drivers: of: add return value to of_reserved_mem_device_init drivers: of: add support for named memory regions drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree media: s5p-mfc: replace custom reserved memory init code with generic one ARM: Exynos: convert MFC to generic reserved memory bindings ARM: DTS: exynos4412-odroid*: enable MFC device .../devicetree/bindings/media/s5p-mfc.txt | 16 +-- .../bindings/reserved-memory/reserved-memory.txt | 6 +- arch/arm/boot/dts/exynos4210-origen.dts | 22 +++- arch/arm/boot/dts/exynos4210-smdkv310.dts | 22 +++- arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24 ++++ arch/arm/boot/dts/exynos4412-origen.dts | 22 +++- arch/arm/boot/dts/exynos4412-smdk4412.dts | 22 +++- arch/arm/boot/dts/exynos5250-arndale.dts | 22 +++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 +++- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 22 +++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 22 +++- arch/arm/mach-exynos/exynos.c | 18 --- arch/arm/mach-exynos/mfc.h | 16 --- arch/arm/plat-samsung/Kconfig | 5 - arch/arm/plat-samsung/Makefile | 1 - arch/arm/plat-samsung/s5p-dev-mfc.c | 94 -------------- drivers/base/dma-coherent.c | 138 ++++++++++++++++++--- drivers/base/dma-contiguous.c | 71 +++++++++++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 102 ++++++--------- drivers/of/of_reserved_mem.c | 102 ++++++++++----- include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 9 +- mm/cma.c | 62 +++++++-- 23 files changed, 552 insertions(+), 291 deletions(-) delete mode 100644 arch/arm/mach-exynos/mfc.h delete mode 100644 arch/arm/plat-samsung/s5p-dev-mfc.c -- 1.9.2

11 years, 5 months

1
7
0 0

[PATCH v2] dma-mapping: Provide write-combine allocations

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> Provide an implementation for dma_{alloc,free,mmap}_writecombine() when the architecture supports DMA attributes. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- Changes in v2: - Add a generic dma_mmap_writecombine() function arch/arm/include/asm/dma-mapping.h | 16 ---------------- include/asm-generic/dma-mapping-common.h | 8 -------- include/linux/dma-mapping.h | 26 ++++++++++++++++++++++++++ 3 files changed, 26 insertions(+), 24 deletions(-) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index c45b61a4b4a5..85738b200023 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -265,22 +265,6 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, dma_addr_t dma_addr, size_t size, struct dma_attrs *attrs); -static inline void *dma_alloc_writecombine(struct device *dev, size_t size, - dma_addr_t *dma_handle, gfp_t flag) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_alloc_attrs(dev, size, dma_handle, flag, &attrs); -} - -static inline void dma_free_writecombine(struct device *dev, size_t size, - void *cpu_addr, dma_addr_t dma_handle) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_free_attrs(dev, size, cpu_addr, dma_handle, &attrs); -} - /* * This can be called during early boot to increase the size of the atomic * coherent DMA pool above the default value of 256KiB. It must be called diff --git a/include/asm-generic/dma-mapping-common.h b/include/asm-generic/dma-mapping-common.h index de8bf89940f8..d137431bf26f 100644 --- a/include/asm-generic/dma-mapping-common.h +++ b/include/asm-generic/dma-mapping-common.h @@ -205,14 +205,6 @@ dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma, void *cpu_addr, #define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL) -static inline int dma_mmap_writecombine(struct device *dev, struct vm_area_struct *vma, - void *cpu_addr, dma_addr_t dma_addr, size_t size) -{ - DEFINE_DMA_ATTRS(attrs); - dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); - return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs); -} - int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt, void *cpu_addr, dma_addr_t dma_addr, size_t size); diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 931b70986272..d5d388160f42 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -263,6 +263,32 @@ struct dma_attrs; #define dma_unmap_sg_attrs(dev, sgl, nents, dir, attrs) \ dma_unmap_sg(dev, sgl, nents, dir) +#else +static inline void *dma_alloc_writecombine(struct device *dev, size_t size, + dma_addr_t *dma_addr, gfp_t gfp) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_alloc_attrs(dev, size, dma_addr, gfp, &attrs); +} + +static inline void dma_free_writecombine(struct device *dev, size_t size, + void *cpu_addr, dma_addr_t dma_addr) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_free_attrs(dev, size, cpu_addr, dma_addr, &attrs); +} + +static inline int dma_mmap_writecombine(struct device *dev, + struct vm_area_struct *vma, + void *cpu_addr, dma_addr_t dma_addr, + size_t size) +{ + DEFINE_DMA_ATTRS(attrs); + dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs); + return dma_mmap_attrs(dev, vma, cpu_addr, dma_addr, size, &attrs); +} #endif /* CONFIG_HAVE_DMA_ATTRS */ #ifdef CONFIG_NEED_DMA_MAP_STATE -- 2.0.0

11 years, 5 months

4
5
0 0

Re: [Linaro-mm-sig] [PATCH] dma-buf: fix <linux/seqno-fence.h> kernel-doc warning

by Sumit Semwal

Hi Randy, ~ typing on a mobile device, kindly excuse any typos On Aug 17, 2014 2:45 AM, "Randy Dunlap" <rdunlap(a)infradead.org> wrote: > > From: Randy Dunlap <rdunlap(a)infradead.org> > > Fix kernel-doc warning, missing parameter description: > > Warning(..//include/linux/seqno-fence.h:99): No description found for parameter 'cond' Thanks for your patch; this is already fixed by Thierry Reading's patch and is queued in for-next. [1] > > Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> > Cc: Rob Clark <robdclark(a)gmail.com> > Cc: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> > --- > include/linux/seqno-fence.h | 1 + > 1 file changed, 1 insertion(+) > > Index: lnx-317-rc1/include/linux/seqno-fence.h > =================================================================== > --- lnx-317-rc1.orig/include/linux/seqno-fence.h > +++ lnx-317-rc1/include/linux/seqno-fence.h > @@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence) > * @context: the execution context this fence is a part of > * @seqno_ofs: the offset within @sync_buf > * @seqno: the sequence # to signal on > + * @cond: the fence condition to check > * @ops: the fence_ops for operations on this seqno fence > * > * This function initializes a struct seqno_fence with passed parameters, Best regards, Sumit. [1]: https://lkml.org/lkml/2014/8/8/191

11 years, 6 months

1
0
0 0

[PATCH] dma-buf/fence: Fix one more kerneldoc warning

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> The seqno_fence_init() function's cond argument isn't described in the kerneldoc comment. Fix that to silence a warning when building DocBook documentation. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- include/linux/seqno-fence.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h index 3d6003de4b0d..a1ba6a5ccdd6 100644 --- a/include/linux/seqno-fence.h +++ b/include/linux/seqno-fence.h @@ -62,6 +62,7 @@ to_seqno_fence(struct fence *fence) * @context: the execution context this fence is a part of * @seqno_ofs: the offset within @sync_buf * @seqno: the sequence # to signal on + * @cond: fence wait condition * @ops: the fence_ops for operations on this seqno fence * * This function initializes a struct seqno_fence with passed parameters, -- 2.0.4

11 years, 6 months

1
0
0 0

[PATCH] dma-buf/fence: Fix a kerneldoc warning

by Thierry Reding

From: Thierry Reding <treding(a)nvidia.com> kerneldoc doesn't know how to parse variables, so don't let it try. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/dma-buf/fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index 4222cb2aa96a..7bb9d65d9a2c 100644 --- a/drivers/dma-buf/fence.c +++ b/drivers/dma-buf/fence.c @@ -29,7 +29,7 @@ EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on); EXPORT_TRACEPOINT_SYMBOL(fence_emit); -/** +/* * fence context counter: each execution context should have its own * fence context, this allows checking if fences belong to the same * context or not. One device can have multiple separate contexts, -- 2.0.4

11 years, 6 months

1
0
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by pintu_agarwal

Dear Joonsoo, I tried your changes which are present at the below link. https://github.com/JoonsooKim/linux/tree/cma-fix-up-v3.0-next-20140625 But unfortunately for me it did not help much. After running various apps that uses ION nonmovable memory, it fails to allocate memory after some time. When I see the pagetypeinfo shows lots of CMA pages available and non-movable were very less and thus nonmovable allocation were failing. However I noticed the failure was little delayed. Also I noticed that the CMA utilized and the CMA free is not matching with total CMA size. In my system RAM is 256MB and CMA configured is 56MB. And free memory was hanging around 30-40MB during failure. Am I missing something? My kernel version is 3.10 and I applied the changes manually. If there are other sets of patches that needs to be applied, please let me know. Note, I did not apply the ALLOC_CMA removal patches. Now I am experimenting more and will share if I have any findings. Thank you! Pintu Sent from Samsung Mobile -------- Original message -------- From: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Date: 29/07/2014 5:06 PM (GMT+09:00) To: 'pintu_agarwal' <pintu_agarwal(a)yahoo.com>,linux-mm@kvack.org,linux-arm-kernel@lists.infradead.org,linaro-mm-sig@lists.linaro.org,ritesh.list@gmail.com Cc: pintu.k@outlook.com,pintu.k@samsung.com,vishu_1385@yahoo.com,m.szyprowski@samsung.com,mina86@mina86.com,ngupta@vflare.org,iqbalblr@gmail.com Subject: RE: [linux-3.10.17] Could not allocate memory from free CMA areas From: pintu_agarwal [mailto:pintu_agarwal@yahoo.com] Sent: Friday, July 25, 2014 12:15 AM To: PINTU KUMAR; linux-mm(a)kvack.org; linux-arm-kernel(a)lists.infradead.org; linaro-mm-sig(a)lists.linaro.org; iamjoonsoo.kim(a)lge.com; ritesh.list(a)gmail.com Cc: pintu.k(a)outlook.com; pintu.k(a)samsung.com; vishu_1385(a)yahoo.com; m.szyprowski(a)samsung.com; mina86(a)mina86.com; ngupta(a)vflare.org; iqbalblr(a)gmail.com Subject: RE: [linux-3.10.17] Could not allocate memory from free CMA areas Dear joonsoo kim, > I have your patches for: Aggressively allocate memory from cma .... > We are facing almost similar problem here. > If any of your patches still working for you please let us know here. > I would like to try those approach. Hello, I stopped to implement it, because there are other bugs on CMA related codes. Although aggressively allocate... doesn't have bugs itself, it enlarges existing freepage counting bugs significantly so I'm first trying to fix those bugs. See the below link. https://lkml.org/lkml/2014/7/4/79 I will restart to implement aggressively... after fixing these bugs. If you have interest on next version of aggressively allocate..., see the following link. https://github.com/JoonsooKim/linux/tree/cma-fix-up-v3.0-next-20140625 Thanks.

11 years, 6 months

3
3
0 0

[PATCH v2 RESEND 0/4] CMA & device tree, once again

by Marek Szyprowski

Hello, (please ignore previous patchset, I've attached wrong version of patches) This is one more respin of the patches which add support for creating reserved memory regions defined in device tree. The last attempt (http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html) ended in merging only half of the code, so right now we have complete documentation merged and only basic code, which implements a half of it is written in the documentation. Although the merged patches allow to reserve memory, there is no way of using it for devices and drivers. This situation makes CMA rather useless, as the main architecture (ARM), which used it, has been converted from board-file based system initialization to device tree. Thus there is no place to use direct calls to dma_declare_contiguous() and some new solution, which bases on device tree, is urgently needed. This patch series fixes this issue. It provides two, already widely discussed and already present in the kernel, drivers for reserved memory: first based on DMA-coherent allocator, second using Contiguous Memory Allocator. The first one nicely implements typical 'carved out' reserved memory way of allocating contiguous buffers in a kernel-style way. The memory is used exclusively by devices assigned to the given memory region. The second one allows to reuse reserved memory for movable kernel pages (like disk buffers, anonymous memory) and migrates it out when device to allocates contiguous memory buffer. Both driver provides memory buffers via standard dma-mapping API. The patches have been rebased on top of latest CMA and mm changes merged to akmp kernel tree. To define a 64MiB CMA region following node is needed: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; reusable; size = <0x4000000>; alignment = <0x400000>; }; Similarly, one can define 64MiB region with DMA coherent memory: multimedia_reserved: multimedia_mem_region { compatible = "shared-dma-pool"; no-map; size = <0x4000000>; alignment = <0x400000>; }; Then the defined region can be assigned to devices: scaler: scaler@12500000 { memory-region = <&multimedia_reserved>; /* ... */ }; codec: codec@12600000 { memory-region = <&multimedia_reserved>; /* ... */ }; Best regards Marek Szyprowski Samsung R&D Institute Poland Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg343702.html) - fixed possible memory leak in case of reserved memory allocation failure (thanks to Joonsoo Kim) Changes since the version posted in '[PATCH v6 00/11] reserved-memory regions/CMA in devicetree, again' thread http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html: - rebased on top of '[PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code' patch series on v3.16-rc3 - improved dma-coherent driver, now it correctly handles assigning more than one device to the given memory region Patch summary: Marek Szyprowski (4): drivers: of: add automated assignment of reserved regions to client devices drivers: of: initialize and assign reserved memory to newly created devices drivers: dma-coherent: add initialization from device tree drivers: dma-contiguous: add initialization from device tree drivers/base/dma-coherent.c | 137 ++++++++++++++++++++++++++++++++++------ drivers/base/dma-contiguous.c | 67 ++++++++++++++++++++ drivers/of/of_reserved_mem.c | 70 ++++++++++++++++++++ drivers/of/platform.c | 7 ++ include/linux/cma.h | 3 + include/linux/of_reserved_mem.h | 7 ++ mm/cma.c | 62 ++++++++++++++---- 7 files changed, 323 insertions(+), 30 deletions(-) -- 1.9.2

11 years, 6 months

2
13
0 0

[PATCH v5 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 5: - Rework sti_drm_drv probes functions to support deferred probe. This allow hdmi to delayed framebuffer creation until I2C is available. - Add ops functsions 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 | 17 + drivers/gpu/drm/sti/NOTES | 58 ++ drivers/gpu/drm/sti/sti_compositor.c | 264 +++++++ drivers/gpu/drm/sti/sti_compositor.h | 90 +++ drivers/gpu/drm/sti/sti_drm_crtc.c | 419 +++++++++++ drivers/gpu/drm/sti/sti_drm_crtc.h | 21 + drivers/gpu/drm/sti/sti_drm_drv.c | 244 +++++++ drivers/gpu/drm/sti/sti_drm_drv.h | 29 + drivers/gpu/drm/sti/sti_drm_plane.c | 192 +++++ drivers/gpu/drm/sti/sti_drm_plane.h | 17 + drivers/gpu/drm/sti/sti_gdp.c | 549 ++++++++++++++ drivers/gpu/drm/sti/sti_gdp.h | 16 + drivers/gpu/drm/sti/sti_hda.c | 790 ++++++++++++++++++++ drivers/gpu/drm/sti/sti_hdmi.c | 808 +++++++++++++++++++++ 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 | 206 ++++++ drivers/gpu/drm/sti/sti_layer.h | 125 ++++ drivers/gpu/drm/sti/sti_mixer.c | 249 +++++++ drivers/gpu/drm/sti/sti_mixer.h | 54 ++ drivers/gpu/drm/sti/sti_tvout.c | 657 +++++++++++++++++ drivers/gpu/drm/sti/sti_vid.c | 138 ++++ drivers/gpu/drm/sti/sti_vid.h | 12 + drivers/gpu/drm/sti/sti_vtac.c | 211 ++++++ drivers/gpu/drm/sti/sti_vtg.c | 356 +++++++++ drivers/gpu/drm/sti/sti_vtg.h | 28 + 33 files changed, 6419 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

11 years, 6 months

5
26
0 0

Re: [Linaro-mm-sig] [linux-3.10.17] Could not allocate memory from free CMA areas

by pintu_agarwal

Dear joonsoo kim, I have your patches for: Aggressively allocate memory from cma .... We are facing almost similar problem here. If any of your patches still working for you please let us know here. I would like to try those approach. Thank you Sent from Samsung Mobile -------- Original message -------- From: PINTU KUMAR <pintu_agarwal(a)yahoo.com> Date: 09/07/2014 8:41 AM (GMT+09:00) To: linux-mm@kvack.org,linux-mm@kvack.org,linux-arm-kernel@lists.infradead.org,linaro-mm-sig@lists.linaro.org Cc: pintu.k@outlook.com,pintu.k@samsung.com,vishu_1385@yahoo.com,m.szyprowski@samsung.com,mina86@mina86.com,ngupta@vflare.org,iqbalblr@gmail.com Subject: [linux-3.10.17] Could not allocate memory from free CMA areas Hi, We are facing one problem on linux 3.10 when we try to use CMA as large as 56MB for 256MB RAM device. We found that after certain point of time (during boot), min watermark check is failing when "free_pages" and "free_cma_pages" are almost equal and falls below the min level. system details: ARM embedded device: RAM: 256MB Kernel version: 3.10.17 Fixed Reserved memory: ~40MB Available memory: 217MB CMA reserved 1 : 56MB ZRAM configured: 128MB or 64MB min_free_kbytes: 1625 (default) Memory controller group enabled (MEMCG) After boot-up the "free -tm" command shows free memory as: ~50MB CMA is used for all UI display purposes. CMA used during bootup is close to ~6MB. Thus most of the free memory is in the form of CMA free memory. ZRAM getting uses was around ~5MB. During boot-up itself we observe that the following conditions are met. if (free_pages - free_cma <= min + lowmem_reserve) { printk"[PINTU]: __zone_watermark_ok: failed !\n"); return false; } Here: free_pages was: 12940, free_cma was: 12380, min: 566, lowmem: 0 Thus is condition is met most of the time. And because of this watermark failure, Kswapd is waking up frequently. The /proc/pagetypeinfo reports that most of the higher order pages are from CMA regions. We also observed that ZRAM is trying to allocate memory from CMA region and failing. We also tried by decreasing the CMA region to 20MB. With this the watermark failure is not happening in boot time. But if we launch more than 3 apps {Browser, music-player etc}, again the watermark started failing. Also we tried decreasing the min_free_kbytes=256, and with this also watermark is passed. Our observation is that ZRAM/zsmalloc trying to allocate memory from CMA areas and failed. Please let us know if anybody have come across the same problem and how to resolve this issue. Thank You! Regards, Pintu

11 years, 6 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig