From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753413AbbJ0EuX (ORCPT ); Tue, 27 Oct 2015 00:50:23 -0400 Received: from mail-bn1bn0108.outbound.protection.outlook.com ([157.56.110.108]:20064 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751147AbbJ0EuV (ORCPT ); Tue, 27 Oct 2015 00:50:21 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1445921408.701.303.camel@freescale.com> Subject: Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram 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: Mon, 26 Oct 2015 23:50:08 -0500 In-Reply-To: References: <1444806968-4627-1-git-send-email-qiang.zhao@freescale.com> <1444806968-4627-3-git-send-email-qiang.zhao@freescale.com> <1445569177.701.133.camel@freescale.com> <1445633947.701.231.camel@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [50.157.106.250] X-ClientProxiedBy: DM2PR0801CA0016.namprd08.prod.outlook.com (25.162.18.26) To BN3PR03MB1477.namprd03.prod.outlook.com (25.163.35.140) X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1477;2:9k2uOaihP1pEyZXueH82M3w8y0cbZGOPuiubflyWllL+kzLIWXmIaI2KF+oKu1EZwuWym78r0mWpPbzfqxk2vBLiqCHEVpfji4+atq3qaCwNAjiYeTZcMDGpyY4a3d8YZiEbOBbudWS6aAn6LdVPsCu/yNVQKnyWE5555lM8kBE=;3:AaycY8KHB4tSISgcFMrxYZ7yN3AvC5EBBJrS8S1q2gmUrdzi2kqLs0M11/S/M8wpz0ZCDHhaVhLJmNIFwMVX6D3hd2qWzjzplARmheFqlI85RyL0o+FeUWhuntENFm26+E6BaDOkuS7Jl10uESiS7w==;25:gq3zDVxxgEjgPP/BG7KvTwyl/jgPuhm+hcS8OnAs9hNiY4TEkltgR+aluJYok5Mf11XHDBhktGZ9QJnoSXX0Q8Hxh86gGXe9oax/L5lDJEGcMVu9bLjn8FeRu3FhGomEDKMsnC5WkcK7rsFi2rUEQLnSAhDdIkEhAeZn/zYqzfSPkU93EDBnPMNcCsU2AS7Z2P9yYQfdSMk5nWPZdAq7ApfvE4zPGrE2X8o102FlHut86Q+I6kfATui76is9tl+XpdXi/JmJU7K1+ihq1ij3dQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1477; X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1477;20:XumwlORi5McdAoL6ixsyDfaktlKve+VsrX0bI6NNyNyR9RrmKNS7ApDzdSVX+WV36HLG9SF77wJR/miC5NYFNs1ln5QlhL1MSAX7+cuFQoyGaEb/F9msN4+aGRLnlHlRy0Fjbv0J7opfeXeuXjA3Dcfwr1tWxHcsYEz8dGRNKGisSt8vDJKA+E5n/fweXQSQGmNlDB3R/MBd8KKji/q45w6denqqUEKuHOFSQybnkUs6f+kZmza6ekPB04NNKf2ip3OTjwcl6ZvqX72QBo4Oqg6jeaH4BXAitCPcQDJcblq3+tDoJPwzULfWbbY9/nax6f3PbVv6xCQNSzkDv1ljEPoqRt5zSeVt1kglazKjnPAGNT+uBeyoS0oevBWw+ZraEbIS+X3rZRIIJNzUk8l9uY1UBe4/f64kHq4Ll+9x0a4l2R7WYxOxYiXopeoke3AuLU3KcnstsW4McTG36euPOMK85I8i4JVRIAgsGdobszkr/W+wxDzm+EHbdrHwuEaS;4:1L53kPw7Q/2wgYfHUY7KRfYufP7Z44yNBgXAxsqju3oAXXj0RYInHymNIqaVaNyE2gotu5v0kg1Xh1PVExpEQ3e/hRmF3922IaGI9Ww0b6sDTroM9UunYRLZuTVzWBGXnzOPgYXqSrlbQuZ+yK3WPb3qpYwZUz3zOu0GrrWkBDbyIo4j1/nMRvlvEXZZybp9APdKpeUjJ0Fo2M+M7C8fz5INi32oHWxNzvQe1ad98sh8THyRL2wCNnb67SzsMFvrbqs4sOARpjwqESZwpVFW9iJH8iQ2rdWbtk7uhMhTz5hx00IlcshQeYVfMq86clido3aJI3xASTVW/sD+tD5YEh8vQkQfMYo4KUFtOcM68yFh4V8F5IoHcx59VbfXMMlM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(101931422205132); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(102215026);SRVR:BN3PR03MB1477;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1477; X-Forefront-PRVS: 0742443479 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(377454003)(189002)(24454002)(13464003)(57704003)(377424004)(19580395003)(40100003)(5004730100002)(77096005)(189998001)(103116003)(87976001)(92566002)(5008740100001)(122386002)(5007970100001)(5001960100002)(50466002)(4001150100001)(5820100001)(36756003)(2950100001)(97736004)(81156007)(110136002)(76176999)(66066001)(50986999)(19580405001)(23676002)(47776003)(4001450100002)(33646002)(93886004)(101416001)(105586002)(106356001)(42186005)(50226001)(86362001)(99106002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR03MB1477;H:snotra.local;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAzTUIxNDc3OzIzOkVOcmh5cG44TDJVYTlrVUNHRDVzNE54SUpy?= =?utf-8?B?Sk1JZnE5T0pKZG5DSWxDbVlJNGtYc1VCYVZja2laTWIwU2xZSmo1c3VPNXJq?= =?utf-8?B?RUV4U05rdzhPemhxMW5kb1dBMXRCa1FxZkVhOFhhOUVZZGpYbHBIbnFMU0FN?= =?utf-8?B?N0tLUUE5OVZzZXlrYnF2dnd4ZWZFa0dheDhqN3RHOUd4K3YxUWxFZFVCdmUx?= =?utf-8?B?dHdqRDFyNXBlbUJKMmNFVjdRUXhId1ZWWWplVHAzSEtEOG9KOWcxNFlYbVBl?= =?utf-8?B?SjBHWU9hc3MvL3VWbTFwMlBNN2MzMVd1bjRjWEQ2SVBLRmN5UWlaK2RPZGdL?= =?utf-8?B?ZXhkZXBlTVFwSlVVV2Nlc2Zza3h2NlBnbFVMaERxRU9RWml1Mkl6TFh6MXo1?= =?utf-8?B?TlRma1ZQd3oxV3ZIc1E3djhOdjRyN2k0UlhpalNrWUtVZjdkcHRCOU8yaFky?= =?utf-8?B?cG5URDNNdWZoNWZ0M25xUXkwSnUySVBBSndpQjE5azUyYXB2VlZoc3R3K2tl?= =?utf-8?B?eWEvdG5PenR4aCtwa1dlK240NlhPSTNtY1hrZW1NR1E1bGMyWDNxRVJQSlhO?= =?utf-8?B?N3BpcXg1OTFQdWdJb210UnBIeUFwTEhxRjgzKzlYbzJMWGdzVWQ2UVdReVM2?= =?utf-8?B?MmtnRmJIdUw2VXJJREpIdTlWczd1Nm16c0tPODBhaGp2ZWpoYmRFbHhKTE9w?= =?utf-8?B?T3pSLzAwa3E4WVBmMjlsdDlnbGVPbmhBNlJ6TUd2SUFXaG9EcnZLQUNjLzBR?= =?utf-8?B?WERMaWRSQ0wxN1NiNzQrTytPanB2T2JWenpmWm1STEtGQkhCVEpqTVdJM1lC?= =?utf-8?B?ZHFOMitYUUh2d1Ezdy9EQXVjOHpFUm01KzF5T0wxZ244Q2g5WXpCZlNMN1F6?= =?utf-8?B?YVprOEFEWHZidC84SmllSFlhL0dzbzlOcVRDZTloYXNRNmxhb1VFUWpoVzEw?= =?utf-8?B?SGtsaUthM092WXlJMWhudllyUEY2NUZDQ1d5OE9SU292TjI4d1dTbHBWRkt2?= =?utf-8?B?TmxtV0ZsNnNOL242R1BOeXI5NUtDNnJyVDlXa28rK25rSDE2RGZMWHFqWW01?= =?utf-8?B?RXJwYk9GVVUvYzB5cHJQQVRVSjBSaHhVWVhSR2lqeHRqOHlxclpPWURlVEFB?= =?utf-8?B?S3hWdHFsZ2pKcURWUUx0NDF2UjBvWlRnK3RNdyt3d09NVDJtTnEyNzNhZ2tI?= =?utf-8?B?WThjNVI2Sk84WUNwUFBQbHh1R0tlNkUwSHdySzlqR3FueE0xNzV3c0kyWk5t?= =?utf-8?B?VmVxSzVmdzhMdklsZVdud0JUWElFSGhYNzM5V0ttRkFTVVgraitxQUQxbExH?= =?utf-8?B?am5BTjljUjlScjZFZDJvYjU1dW9pU1FmVjI4dTB2eDR5QmljZWhQNUhQMC9K?= =?utf-8?B?b2hUbFNoZlpQbm9KQWVLWFppT01mQkJWallYYWxHSjBsTFJXVnBnbm5ZdEJt?= =?utf-8?B?VFBvZmVTOTRzN01HTEx1eTAyRUh3RVQvZ2pVVHNrRDhOQnR3alp0S0ZOMnU5?= =?utf-8?B?VmQ2QUsxcW1abDI5WTU4MlFKMEVGdjNnY2hNb1Q1VU1OZU5sN1l0WmtIWExE?= =?utf-8?B?dm9RNzZVNURrTFYrL1RCQ0NzSVlTbW1ZeWxBLzNCalJULzI1bXI2RWY4Q01Z?= =?utf-8?Q?7g/gDNBhR4e4HZL8edQC?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1477;5:DRBNtr/gX9aPFdHsluUsPVw6AEGkcfftPUhjX09KZJuirSTQxCEbZfcij/kd4oOmuT0ohxz3fzJEpF7ZJDlep1IbN+riyyXnh9k7qmP3cNV4a+aerINga6CWBiJ4zFi+NCwsuNIRKoeTWF8bOsPQOg==;24:+/6PW5AFaIJ+JM/wXT2I3+d6gzR/jXsJ2wYaVV31vscTwX93yFy06qJx9b4g2J4h3HCP1sKh29amqbQ7zk4/B/UszS2pSit16MuTkH2lrOw=;20:FxDBxD8KQQ87Um08R3jtqjIRtn4+hKzId+iu/5a+w8mHYBIKMQoLbKYtYe9EjoT8Z3g/OjyFMRlbNPJZAGld5Q== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2015 04:50:18.0017 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1477 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2015-10-25 at 22:15 -0500, Zhao Qiang-B45475 wrote: > On Sat, 2015-10-24 at 04:59 AM, Wood Scott-B07421 > wrote: > > -----Original Message----- > > From: Wood Scott-B07421 > > Sent: Saturday, October 24, 2015 4:59 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 v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram > > > > Don't send HTML e-mail. > > > > On Fri, 2015-10-23 at 02:06 -0500, Zhao Qiang-B45475 wrote: > > > On Fri, 2015-10-23 at 11:00 AM, Wood Scott-B07421 > > > > > > wrote: > > > > -----Original Message----- > > > > From: Wood Scott-B07421 > > > > Sent: Friday, October 23, 2015 11:00 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 v12 3/6] CPM/QE: use genalloc to manage CPM/QE > > > > muram > > > > > > > > On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote: > > > > > -/** > > > > > +/* > > > > > * cpm_muram_alloc - allocate the requested size worth of > > > > > multi-user > > > ram > > > > > * @size: number of bytes to allocate > > > > > * @align: requested alignment, in bytes @@ -141,59 +151,102 @@ > > > > > out: > > > > > */ > > > > > unsigned long cpm_muram_alloc(unsigned long size, unsigned long > > > > > align) { > > > > > - unsigned long start; > > > > > unsigned long flags; > > > > > - > > > > > + unsigned long start; > > > > > + static struct genpool_data_align muram_pool_data; > > > > > spin_lock_irqsave(&cpm_muram_lock, flags); > > > > > - cpm_muram_info.alignment = align; > > > > > - start = rh_alloc(&cpm_muram_info, size, "commproc"); > > > > > - memset(cpm_muram_addr(start), 0, size); > > > > > + muram_pool_data.align = align; > > > > > + gen_pool_set_algo(muram_pool, gen_pool_first_fit_align, > > > > > + &muram_pool_data); > > > > > + start = cpm_muram_alloc_common(size, &muram_pool_data); > > > > > spin_unlock_irqrestore(&cpm_muram_lock, flags); > > > > > - > > > > > return start; > > > > > } > > > > > EXPORT_SYMBOL(cpm_muram_alloc); > > > > > > > > Why is muram_pool_data static? Why is it being passed to > > > > gen_pool_set_algo()? > > > Cpm_muram use both align algo and fixed algo, so we need to set > > > corresponding algo and Algo data. > > > > The data gets passed in via gen_pool_alloc_data(). The point was to > > allow it to > > be on the caller's stack, not a long-lived data structure shared by all > > callers and > > needing synchronization. > > You mean it is not necessary to point pool->data to data, just passing the > data to gen_pool_alloc_data()? > However, the algo it needed to be set. > > > > > > > The whole reason we're adding gen_pool_alloc_data() is to avoid > > > > that. Do we need gen_pool_alloc_algo() too? > > > > > > We add gen_pool_alloc_data() to pass data to algo, because align algo > > > and fixed algo, Because align and fixed algos need specific data. > > > > And my point is that because of that, it seems like we need a version that > > accepts an algorithm as well. > > It the user just use only one algo, it doesn’t need to set algo, > However, qe_muram use two algos with alloc_align function > And alloc_fixed function. Yes. That is why gen_pool_alloc_data() does not accomplish what we want. When we were discussing gen_pool_alloc_data(), you had not yet mentioned the need for fixed allocations. -Scott