From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document References: <1471622000-1906-1-git-send-email-stanimir.varbanov@linaro.org> <1471622000-1906-4-git-send-email-stanimir.varbanov@linaro.org> <20160823173259.GA13327@rob-hp-laptop> <20160825000521.GH15161@tuxbot> <3429173a-d55a-51e1-0973-7e5bd31be297@linaro.org> <20160826222345.GK15161@tuxbot> <5afd7f2f-ec1b-d2ce-b833-81df010e24de@linaro.org> <20160830171742.GN15161@tuxbot> From: Marek Szyprowski Message-id: Date: Fri, 02 Sep 2016 13:52:20 +0200 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit To: Stanimir Varbanov , Bjorn Andersson Cc: Rob Herring , Andy Gross , Ohad Ben-Cohen , Stephen Boyd , Mark Rutland , Rob Clark , Srinivas Kandagatla , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org List-ID: Hi, On 2016-09-01 16:58, Stanimir Varbanov wrote: > Hi, > > Cc: Marek > ... >>>> But I presume we have the implementation issue of dma_alloc_coherent() >>>> failing in either case with the 5MB size. I think we need to look into >>> I'd be good to include Marek Szyprowski? At least he will know what >>> design restrictions there are. >>> >> Please do. The more I look at this the more I think we must use the >> existing infrastructure for allocating "dma memory". Getting >> dma_alloc_coherent() supporting non-power-of-2 memory regions would > Just to be precise it should be dma_alloc_from_coherent(). > > Marek, what is your opinion on that, can we make dma_alloc_from_coherent > able to allocate memory for sizes with bigger granularity. > > For your convenience here [1] is the mail thread. There should be no technical restrictions to add support for bigger granularity than power-of-2. dma_alloc_from_coherent uses standard bitmap based allocator, so it already support tracking allocations of arbitrary size. However for the small allocations (smaller than 64KiB?, 512KiB?) it would make sense to keep nearest-power-of-2 round up to prevent memory fragmentation. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland