[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN1PR0301MB1550C782E61600D8268C91B79B550@SN1PR0301MB1550.namprd03.prod.outlook.com>
Date: Sun, 6 Sep 2015 03:13:04 +0000
From: Zhao Qiang <qiang.zhao@...escale.com>
To: Scott Wood <scottwood@...escale.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"lauraa@...eaurora.org" <lauraa@...eaurora.org>,
Xiaobo Xie <X.Xie@...escale.com>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
Li Leo <LeoLi@...escale.com>,
"paulus@...ba.org" <paulus@...ba.org>
Subject: RE: [PATCH V7 1/3] genalloc:support memory-allocation with
bytes-alignment to genalloc
On Wed, 2015-09-02 at 10:18AM +0800, 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@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org;
> lauraa@...eaurora.org; Xie Xiaobo-R63061; benh@...nel.crashing.org; Li
> Yang-Leo-R58472; paulus@...ba.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@...r.kernel.org; linuxppc-dev@...ts.ozlabs.org;
> > > lauraa@...eaurora.org; Xie Xiaobo-R63061; benh@...nel.crashing.org;
> > > Li Yang-Leo-R58472; paulus@...ba.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 <qiang.zhao@...escale.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.
> > > > 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.
>
The offset is which allocation block address need to be larger than,
Not equal to, it really like the parameter start of the algo(the bitnumber
To start searching at).
>
> > > > +/*
> > > > + * gen_pool data descriptor for gen_pool_first_fit_align.
> > > > + */
> > > > +struct genpool_data_align {
> > > > + int align; /* alignment by bytes for starting
> > > address */
> > > > + unsigned long offset; /* the offset of allocation start
> addr*/
> > > > +};
> > >
>
> -Scott
>
-Zhao
Powered by blists - more mailing lists