From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752960AbbIBCde (ORCPT ); Tue, 1 Sep 2015 22:33:34 -0400 Received: from mail-bn1on0146.outbound.protection.outlook.com ([157.56.110.146]:18880 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752905AbbIBCdb (ORCPT ); Tue, 1 Sep 2015 22:33:31 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1441161203.4966.126.camel@freescale.com> Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with bytes-alignment to genalloc From: Scott Wood To: Zhao Qiang-B45475 CC: "linux-kernel@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "lauraa@codeaurora.org" , Xie Xiaobo-R63061 , "benh@kernel.crashing.org" , Li Yang-Leo-R58472 , "paulus@samba.org" Date: Tue, 1 Sep 2015 21:33:23 -0500 In-Reply-To: References: <1441011520-15424-1-git-send-email-qiang.zhao@freescale.com> <1441153816.4966.109.camel@freescale.com> <1441160299.4966.122.camel@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:448:8100:f9f:12bf:48ff:fe84:c9a0] X-ClientProxiedBy: BLUPR16CA0034.namprd16.prod.outlook.com (25.164.14.44) To BN3PR03MB1480.namprd03.prod.outlook.com (25.163.35.143) X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1480;2:LDb0ZDZ0ZhBqs8QhohnYnIw1owqzjukebKMrgG19BgeSdNKT+9q2p3gdmol6+KbbhjqTgr5G4Kf3fZdI9xKMtTePD/ntI42fJiHskDRq7i29vnEZwprvmWaaj8i/TUBY5knpSqSUHr127LyuX8SXgTrYGvkDBU99Qjs/ZhMnLSg=;3:N2nAw4lHqt04J4ERNsPnvswtQ2pCsqv+GVLXiEt7ibrGDFoZCrvwPbXWpkbkOEa1EgGUkzVgILKKbJ8bQiXNbzVJasECPggs6PYhE1EpJMmUO1qvzRi4o4x23f5imZLvctUJhALWlpTQ9WPQqbYrcA==;25:rdSKF1gWgFBdfcR83n0aUTwAxwQqPF3HplGsRrxSLSSBNeXOk22ASEF0etEAK6kDaTAtuPKFafapbRopCmsNkdYEmqToOaC9ze4i0Oz28C/poQs69c8KwfaOdlRlUveHVMBESk+hHxWhm8rHrfvn4wSX/J7A2ZmX8Pcy1//eOwelO4CnQy4NOIv5FdB3XX6wZ/klRXnqEytTFd2I8Fz5wk7BpUpmaH6+VNsAJ6oid9iuYFJuvH+w4nAYAo3VDtro7AY8W4U65ctAJk1Qp4Ns7A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1480; X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1480;20:UMtqSJ3+sdXRgC5vO6g7kybfKJDFfRqdsi8gaPrTWLO+BjUo7NnRVefRHUc8weunOCE4gjk1mXDe8SHCzZEjT5M1xK3mU6X1ONDf/sJ4sp1aSZ8C3wNQzwDs5nfcV7wS9DTczyRG3xBHXszPE4pqQWN/UR7gX6IwbGy6gKABAW6ZIh5xYls+b8Dl69A5r+01AciYBdMbD7XfbrdrGLaQbzSx/OKhPUCNJL06ZFfE+XXR1BX89Duvg/IOnvAb0NhGzJnISgrTTl/B+52GYxMlPFVtZPEJpxfz5SROSMt4zCw1+Hr+cAGPT/qEkDS4QDUdKcjihnbBJYN8q0CyTONAcSOv1vD7mTL9q5lTkajgUqlLWahBxupsj+8BMzMjsC6VwhQyZB73bOcekTymGnPvclWCOdXG+S2VAkls7Z7O65uzmO/2ytKr0TKztkgCfkjT2oPYZEmsxorioe8D6uY/eQNIziOTYrrslbxc50HmfgRUB3loZbdFaSRks9ZkiKgH;4:nlsebq4ANp5eAvPsMLaS1OqpYo0dfnDUCbHstkWUPc62FosIv3I54YdqmxqRDNYNKlJSlh/Yj78owXYqD7xqmnzpEV75pVDmAHQJRGrQUCB/tBDvh8GJkpqw1+siO9F0hTD2jn8tmif08mfGFVSBeVCoM9PIo3G+RIKy1Tcf9PhGTOAzBIa75OULayoGC7VIn/D8QbyEC5C1fIk/3rcBC0TAKn7u8Myf/UFQrCBhmMd/GxWjJtDcHHaztWdSzpjkL7B6U8GGeKhMeAbg052r5wNGgxxOsyKGobY3ZJN3HH1QGROQwSeIMlQZzedIw3zo X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(8121501046)(3002001);SRVR:BN3PR03MB1480;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1480; X-Forefront-PRVS: 0687389FB0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(377454003)(189002)(377424004)(199003)(24454002)(13464003)(54534003)(93886004)(50986999)(76176999)(5820100001)(50226001)(101416001)(4001450100002)(110136002)(5001830100001)(189998001)(5001960100002)(5001860100001)(23676002)(19580395003)(19580405001)(36756003)(42186005)(47776003)(50466002)(64706001)(87976001)(92566002)(86362001)(103116003)(46102003)(2950100001)(4001540100001)(68736005)(77156002)(62966003)(97736004)(77096005)(81156007)(40100003)(122386002)(105586002)(106356001)(5004730100002)(33646002)(5007970100001)(99106002)(3826002)(5001840100002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR03MB1480;H:[IPv6:2601:448:8100:f9f:12bf:48ff:fe84:c9a0];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAzTUIxNDgwOzIzOlZlckhCSE1BcWs0b0J1VFJpZDcyczlqYTF2?= =?utf-8?B?b1NNaERCNEswZG5rTU9NellSVHkvZTVLbmR6S2ZWSFNvVEFtVkpDUHVSdXEr?= =?utf-8?B?SDdUQUp4VlhXOVo3MkNwNm4xaG53TUxwdndzdVo4N0FuYlRqeGRkcjVIcktP?= =?utf-8?B?VVFvTElkMVF2WlZLdWlqSUUwMFBORVdSeHhuZVB1TG1maGlKek1kR1pkbSsr?= =?utf-8?B?UkJJTE8xelBhdlpRazZrMThPaHpZb2doVnY1L2k4K1JTbEgyMHZicTVOeVlY?= =?utf-8?B?YzBLeW5VNkN6L2ZKbGZlVFZXMUxOSmhlWGpsMGRXekpnR2pqSDRoa096c0Fo?= =?utf-8?B?SVVzTDY2bUFpRHV3WHJqKzU5cHV5emtSQmhrUjQ5Z3c1VFdUOUFKMmh1bjRZ?= =?utf-8?B?RkR6TW1qbTkrS0NCODFuWSt3WUowYWJKejlGUkhQdkR2QXZaK0hFQXV2NXVq?= =?utf-8?B?VURua0JpekNYTFJSZDBNVmxLTm5oQ0FIYVNzUUFvaXhzMStjRllsNGM3V1dp?= =?utf-8?B?N3YwNGhCVmtWcWJSNXdRdUxoNFIxOVIwbVNLc1l2aHpYM2xzK3ZldW9vNmYv?= =?utf-8?B?dE1CeWZJYkUxYjV6TGRTSnQrVzJmbWNQZ3h0WlduWXkvVUJtcUlWZmhyR1dP?= =?utf-8?B?YXY1RjhOaW1BVlpTQi84NE5VSm5HSXJObmJJTTlnUVJBRDU5U1h6T25JYmQv?= =?utf-8?B?RjNzS1Z3UnFuSkxjd2t5R2dsekpLbU0zek1GL3ZveHRpSGNnNWVxUDRkeUN1?= =?utf-8?B?RFk4aW9YMUpWMEQ4ajVCcjg4eU9nNlovbDE0b2JTeEtQRlhuVmxPL0RGUzZN?= =?utf-8?B?Ui9RUXh1alpIWDgyNWl4UkN5cDQ4WFpWQSt3NFJvd2VGb1VmNGlZNllOVHlI?= =?utf-8?B?SVVzN1pvWk5ZQ1hRYUk0cWxCTFkvbnRrMmhGYmQ4UEtyVGNBM0RZSkFFUHN5?= =?utf-8?B?cGFrazRSb1dZcmVNM3FnaEw0TmpIWUU0Wm9qVUtVZE5TSFJrbVp2d2VKMklH?= =?utf-8?B?eDQxOU5kQXdjd1FIVEFNaEFUUER1d1pmVzZaZHpJL0RnTVNiUG9UcFh3S3A0?= =?utf-8?B?MmFHUFZTMWFibmtvcURMTERtc0UzaGxWVVZ4RW9qZ0tzd1lvcnRZOGZ4SG5D?= =?utf-8?B?WnJKVDlMeFJLMzlKSU9mMHVaT0JYdlpvOFJyL1FHOU1kKzBhQnd1MjRYcHdy?= =?utf-8?B?bnBvRHZQZkxOaWhRRk5tYkd4N1dPOWdualczMndTaFUxclc3d3p5UVlzdUU1?= =?utf-8?B?ZFNiRXJKQjNXWUNQclVhRlg0NTBYTnBlT0pvS1QzQkt2Vjg1L2VVUVZRQWpM?= =?utf-8?B?bVRMK002eU0xdmNkRE01UjRPRUpwb2NEMHIxTHRUMzMwOFRRZ2hrcnlUc0lo?= =?utf-8?B?UGFFSDgycFQvdW8yMVd2ZkhWZ3ZWTXoxL3BIdEJCVFYwNmtGSEdob0ViRmtn?= =?utf-8?B?d3lXL0hBcVo1MlVMbnVQOTg5M0Zqeno3aUMxVUtvMVpCYy9xZUM3TWNscVhs?= =?utf-8?B?VHRQU0ErNnVONklScVpSRHM1OWRQL2ZYTUI2SDU3UXdrVFJibmZGdzRNRUdY?= =?utf-8?B?NVFUUGNwalNBcUx2WEdsNDNGRmF5b2wzNXVROXFPY1FncWJ1MDl2Zm1jTkZj?= =?utf-8?B?VGJycnBMa3JkZkR2SHlabjB4QnlmOVdqQ2FsQVhBRzhadlFDR1B3blRwOXdY?= =?utf-8?B?NDRPelI1VXBpRVI3dEtDeUtjWlBWWmxkNnJZelNPUmxCcDZESmp1UVk2Slgx?= =?utf-8?B?VzZFdE44bWdObFJsTDkvQ0JFcHNVSGZrVjFjUXZHVTdXRVZ3NWhDbEVFcVRo?= =?utf-8?B?Mm41SE5ZRGlObEFCVk51VGJwV1F1V1JCYmE1SkVmQU4wVlE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1480;5:SdJ1nFGYmcC7G1V6kVSCEdK9jKP8GnTaaYuEMrLQambwfwde750ikfHyrB5QLhLR/BFnNogcZ48cKxQZnQNx0LHlTKWxd8WusUU5dY4jfXTS9WPWLRIvLErTmLlrPBTlPdiFdb0Ic7nhkjf0UxiOkg==;24:b7HiFQ2kwEr9PWAUkCQtkWrWezIJ2LXBEzHYIrIrdFKlukpmjuajXCkbZo4ZKHOR7Y2/10VKJ7ptPmkJp3P+8yrAB9+xWH59yGOz0DCEI28=;20:0GKOzLe6BpNt4BJUGQ0VBGAGlUBvo6r2H4ksse7fn76QEGachRtpYcEiYetBYoa0np5WkkeX4JL1r8F3YOSI1Q== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2015 02:33:28.1615 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1480 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-09-01 at 21:29 -0500, Zhao Qiang-B45475 wrote: > On Wed, 2015-09-02 at 10:18AM -0500, Wood Scott-B07421 wrote: > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Wednesday, September 02, 2015 10:18 AM > > To: Zhao Qiang-B45475 > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; Li > > Yang-Leo-R58472; paulus@samba.org > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > bytes-alignment to genalloc > > > > On Tue, 2015-09-01 at 21:10 -0500, Zhao Qiang-B45475 wrote: > > > On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote: > > > > -----Original Message----- > > > > From: Wood Scott-B07421 > > > > Sent: Wednesday, September 02, 2015 8:30 AM > > > > To: Zhao Qiang-B45475 > > > > Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > > > lauraa@codeaurora.org; Xie Xiaobo-R63061; benh@kernel.crashing.org; > > > > Li Yang-Leo-R58472; paulus@samba.org > > > > Subject: Re: [PATCH V7 1/3] genalloc:support memory-allocation with > > > > bytes-alignment to genalloc > > > > > > > > On Mon, 2015-08-31 at 16:58 +0800, Zhao Qiang wrote: > > > > > Bytes alignment is required to manage some special RAM, so add > > > > > gen_pool_first_fit_align to genalloc, meanwhile add > > > > > gen_pool_alloc_data to pass data to > > > > > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper) > > > > > > > > > > Signed-off-by: Zhao Qiang > > > > > --- > > > > > Changes for v6: > > > > > - patches set v6 include a new patch because of using > > > > > - genalloc to manage QE MURAM, patch 0001 is the new > > > > > - patch, adding bytes alignment for allocation for use. > > > > > Changes for v7: > > > > > - cpm muram also need to use genalloc to manage, it has > > > > > a function to reserve a specific region of muram, > > > > > add offset to genpool_data for start addr to be allocated. > > > > > > > > This seems to be describing more than just the changes in this patch. > > > > What does also handling cpm have to do with this patch? Are you > > > > adding support for reserving a specific region in this patch? I > > > > don't see it, and in any case it should go in a different patch. > > > > > > Yes, I added. The code below can support the function. > > > offset_bit = (alignment->offset + (1UL << order) - 1) >> order; > > > return bitmap_find_next_zero_area(map, size, start + offset_bit, > > nr, > > > align_mask); > > > > > > CPM has an function cpm_muram_alloc_fixed, needing to allocate muram > > > from a Specific offset. So I add the code and add offset to struct data. > > > > I thought the offset was related to the previous discussion of checking > > for allocation failure. Are you using it to implement alloc_fixed()? If > > so, please don't. Besides the awkward implementation (what does it > > logically have to do with gen_pool_first_fit_align?), it does not appear > > to be correct - > > - what happens with multiple chunks? What happens if part of the region > > the caller is trying to reserve is already taken? Implement a proper > > function to reserve a fixed genalloc region. > > This offset is totally different with the workaround OFFSET! There's a reason why we write changelogs that describe what the patch is doing, and avoid combining logically distinct changes in the same patch. > This offset is the offset of the muram. The offset of the muram relative to what? Or do you mean the offset into muram? > CPM need to allocate block from a specific offset due to hardware > restriction. > So I must handle this offset in genalloc. Again, if you need to be able to mark a specific range reserved, add a function that does that properly. Don't try to hack it in the way you did. -Scott