On Wed, 2015-09-09 at 21:26 -0500, Zhao Qiang-B45475 wrote:

On Wed, 2015-09-10 at 12:38AM -0500, Wood Scott-B07421 wrote:

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Thursday, September 10, 2015 12:38 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 Sat, 2015-09-05 at 22:13 -0500, Zhao Qiang-B45475 wrote:

quoted

On Wed, 2015-09-02 at 10:18AM +0800, Wood Scott-B07421 wrote:

quoted

-----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:

quoted

On Wed, 2015-09-02 at 08:38AM +0800, Wood Scott-B07421 wrote:

quoted

-----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:

quoted

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 <redacted>
---
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.

quoted

quoted

quoted

quoted

This seems to be describing more than just the changes in this

patch.

quoted

quoted

quoted

quoted

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;

quoted

quoted

quoted

      return bitmap_find_next_zero_area(map, size, start +
offset_bit,

nr,

quoted

                        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.

quoted

quoted

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).

cpm_muram_alloc_fixed() is not "search starting at this offset".  It is
"reserve this exact range or fail".

Yes, you are right! How about to add a new algo into genalloc to search 
At offset, then handle it in muram layer, if the address return from 
genalloc
Is not equal to offset, return negative number?

If you're adding a new algorithm, why not make it actually do what you want 
rather than adding something different and fixing it up in the caller?

-Scott