From: Zhao Qiang <qiang.zhao@freescale.com>
To: Laura Abbott <labbott@redhat.com>, Scott Wood <scottwood@freescale.com>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
        "lauraa@codeaurora.org" <lauraa@codeaurora.org>,
        Xiaobo Xie <X.Xie@freescale.com>,
        "benh@kernel.crashing.org" <benh@kernel.crashing.org>,
        Li Leo <LeoLi@freescale.com>, "paulus@samba.org" <paulus@samba.org>
Subject: RE: [PATCH v6 1/3] genalloc:support memory-allocation with
 bytes-alignment to genalloc
Thread-Topic: [PATCH v6 1/3] genalloc:support memory-allocation with
 bytes-alignment to genalloc
Thread-Index: AQHQ3lB3c5XRxGvlik2abkrI76vQZZ4bx5eAgAA6DyCAABcmAIAAQ7LA
Date: Tue, 25 Aug 2015 08:09:56 +0000
Message-ID: <SN1PR0301MB1550544FC379016F263EDCDD9B610@SN1PR0301MB1550.namprd03.prod.outlook.com>
References: <1440408703-6113-1-git-send-email-qiang.zhao@freescale.com>
 <55DBA477.5020608@redhat.com>
 <SN1PR0301MB155021CDD677EFB6D1EAE79F9B610@SN1PR0301MB1550.namprd03.prod.outlook.com>
 <55DBE896.9030702@redhat.com>
In-Reply-To: <55DBE896.9030702@redhat.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2015 08:09:56.5623
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0784
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4530
Lines: 120

On 08/25/2015 12:01 PM, Laura Abbott wrote:

> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Tuesday, August 25, 2015 12:01 PM
> To: Zhao Qiang-B45475; Wood Scott-B07421
> 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 v6 1/3] genalloc:support memory-allocation with
> bytes-alignment to genalloc
> 
> On 08/24/2015 07:40 PM, Zhao Qiang wrote:
> > On 08/25/2015 07:11 AM, Laura Abbott wrote:
> >> -----Original Message-----
> >> From: Laura Abbott [mailto:labbott@redhat.com]
> >> Sent: Tuesday, August 25, 2015 7:11 AM
> >> To: Zhao Qiang-B45475; Wood Scott-B07421
> >> 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 v6 1/3] genalloc:support memory-allocation with
> >> bytes-alignment to genalloc
> >>
> >> On 08/24/2015 02:31 AM, 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 <qiang.zhao@freescale.com>
> >>> ---
> >>> 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.
> >>>
> >>>    include/linux/genalloc.h | 23 +++++++++++++++----
> >>>    lib/genalloc.c           | 58
> >> +++++++++++++++++++++++++++++++++++++++++++-----
> >>>    2 files changed, 72 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
> >>> index 1ccaab4..55da07e 100644
> >>> --- a/include/linux/genalloc.h
> >>> +++ b/include/linux/genalloc.h
> >>> @@ -34,6 +34,7 @@
> >>>
> >>>    struct device;
> >>>    struct device_node;
> >>> +struct gen_pool;
> >>>
> >>>    /**
> >>>     * Allocation callback function type definition @@ -47,7 +48,7 @@
> >>> typedef unsigned long (*genpool_algo_t)(unsigned long *map,
> >>>    			unsigned long size,
> >>>    			unsigned long start,
> >>>    			unsigned int nr,
> >>> -			void *data);
> >>> +			void *data, struct gen_pool *pool);
> >>>
> >>>    /*
> >>>     *  General purpose special memory pool descriptor.
> >>> @@ -73,6 +74,13 @@ struct gen_pool_chunk {
> >>>    	unsigned long bits[0];		/* bitmap for allocating memory
> chunk
> >> */
> >>>    };
> >>>
> >>> +/*
> >>> + *  gen_pool data descriptor for gen_pool_first_fit_align.
> >>> + */
> >>> +struct genpool_data_align {
> >>> +	int align;		/* alignment by bytes for starting address */
> >>> +};
> >>> +
> >>
> >> (sorry for chiming in late, I've been traveling)
> >>
> >> Is there an advantage here to wrapping this in a structure instead of
> >> just passing a pointer to an align integer?
> >
> >
> > Please look at the commit message for
> > ca279cf1065fb689abea1dc7d8c11787729bb185 which adds "data":
> >
> > "As I can't predict all the possible requirements/needs for all
> > allocation uses cases, I add a "free" field 'void *data' to pass any
> > needed information to the allocation function.  For example 'data'
> > could be used to handle a structure where you store the alignment, the
> > expected memory bank, the requester device, or any information that
> > could influence the allocation algorithm."
> >
> 
> Right, I understand what the purpose is but I'm not sure what you're
> getting from the structure vs passing a pointer, e.g.
> 
> int align;
> 
> align = 4;
> 
> gen_pool_alloc_data(&pool, size, &align);
> 
> it just seems to obfuscate what's going on by wrapping a single integer
> in a structure that's narrowly defined in a generic function right now. I
> guess it could change later which would necessitate having the structure
> but again it's so generic I'm not sure what else you would pass that
> would be applicable to all clients.

Scott and me have discussed about this issue in my RFC patch.
Please review: http://patchwork.ozlabs.org/patch/493297/

> 
> Thanks,
> Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/