From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753192AbcIBLw3 (ORCPT ); Fri, 2 Sep 2016 07:52:29 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:48430 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751589AbcIBLw0 (ORCPT ); Fri, 2 Sep 2016 07:52:26 -0400 X-AuditID: cbfec7f5-f792e6d0000013f5-99-57c967f6c1d2 Subject: Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document To: Stanimir Varbanov , Bjorn Andersson 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> 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 From: Marek Szyprowski Message-id: Date: Fri, 02 Sep 2016 13:52:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42I5/e/4Fd1v6SfDDVYe4bT4f9LY4vT+dywW 84+cY7WYuP8su8XlXXPYLJrPK1ksvX6RyeL36h/MFs8XAon/e3awW/w4081i0XbsGKtFS9sR JgdejzXz1jB6XO7rZfLYOesuu8emVZ1sHneu7WHz+LxJzuPTp31sAexRXDYpqTmZZalF+nYJ XBkX171hKujmqjh7qou9gXESRxcjJ4eEgIlE84QmFghbTOLCvfVsXYxcHEICSxkljrx4ygzh PGeUePPzGitIlbBAgETrnyVgtohAisS3ZSuhit4wS/xoWs8IkmAW6GWW6G4NALHZBAwlut52 AY3l4OAVsJP4cywfJMwioCqxqPEKI0hYVCBGYn1fAkiYV0BQ4sfke2AHcQJVX7h6gRViopnE l5eHoWx5ic1r3jJPYBSYhaRlFpKyWUjKFjAyr2IUTS1NLihOSs810itOzC0uzUvXS87P3cQI iZivOxiXHrM6xCjAwajEw7tB/0S4EGtiWXFl7iFGCQ5mJRHem2knw4V4UxIrq1KL8uOLSnNS iw8xSnOwKInzztz1PkRIID2xJDU7NbUgtQgmy8TBKdXAeOli65f7H++m+dluO9HBr3Wjgffu tfMB052ePlvClFV2SbE7f4b1gd1b+d3nn02WKmueGN8sbHIyvb/y1FmZub5fN/UmnxQ9eeTA iRkHQk8r/9PbOKluss2/1zH1VQe8VrM9qVq/1Tzw2oqWtDSTR95HF/7d06ep4hdV563wM1t8 woSO65MuX1diKc5INNRiLipOBACeczaRlAIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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