Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-09 Thread Scott Wood 
On Thu, 2015-07-09 at 01:05 -0500, Zhao Qiang-B45475 wrote:
 On Wed, 2015-07-09 at 11:51 -0500, Wood Scott wrote:
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, July 09, 2015 11:51 AM
  To: Zhao Qiang-B45475
  Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
  Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
  lib/
  
  That doesn't involve a different alignment for each allocation.  It uses
  the same alignment for all of them, and the alignment that cpm_common.c
  provides to rh_init() is 1 byte.
  
  ...but sigh, cpm_muram_alloc() is changing cpm_muram_info.alignment
  behind the rheap code's back.  Despite the existence of rh_alloc_align().
  
  So yes, add aligned allocation functionality to genalloc, but don't
  duplicate
  gen_pool_alloc() to do so.  Instead, rename gen_pool_alloc() to
  gen_pool_alloc_align() with an alignment parameter (also modifying the
  algo function to take an alignment arg, which
  gen_pool_first_fit_order_align() would ignore), and provide a
 
 Here, I don’t understand how to handle the algo In your mind. 
 Can you explain more detailly?

The algorithms would be unchanged except that they would receive a new 
alignment (or alignment mask) parameter.  gen_pool_first_fit_order_align() 
would ignore it, but the other algorithms would pass it through to the bitmap 
allocator.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-09 Thread Zhao Qiang 
On Wed, 2015-07-09 at 11:51 -0500, Wood Scott wrote:

 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, July 09, 2015 11:51 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Wed, 2015-07-08 at 22:18 -0500, Zhao Qiang-B45475 wrote:
   -Original Message-
   From: Wood Scott-B07421
   Sent: Thursday, July 09, 2015 2:59 AM
   To: Zhao Qiang-B45475
   Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
   Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/
   to lib/
  
   On Wed, 2015-07-08 at 02:25 -0500, Zhao Qiang-B45475 wrote:
So I will add two func for my use, do you think it is ok?
I need to align the address of allocated muram.
And I will set algo = gen_pool_first_fit_align.
   
+unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t
 size,
+   unsigned long align)
  
   Again, please explain why you need this for CPM/QE.  I don't see
   rh_alloc_align() currently being used by either.
  
   Also, please stop top-posting.
 
 
  unsigned long rh_alloc(struct _rh_info *info, int size, const char
  *owner) {
  return rh_alloc_align(info, size, info-alignment, owner); }
  EXPORT_SYMBOL_GPL(rh_alloc);
 
 That doesn't involve a different alignment for each allocation.  It uses
 the same alignment for all of them, and the alignment that cpm_common.c
 provides to rh_init() is 1 byte.
 
 ...but sigh, cpm_muram_alloc() is changing cpm_muram_info.alignment
 behind the rheap code's back.  Despite the existence of rh_alloc_align().
 
 So yes, add aligned allocation functionality to genalloc, but don't
 duplicate
 gen_pool_alloc() to do so.  Instead, rename gen_pool_alloc() to
 gen_pool_alloc_align() with an alignment parameter (also modifying the
 algo function to take an alignment arg, which
 gen_pool_first_fit_order_align() would ignore), and provide a

Here, I don’t understand how to handle the algo In your mind. 
Can you explain more detailly?

 gen_pool_alloc() wrapper that specifies 1 as the required alignment.
 Also be sure to CC lkml on the patchset since you're touching core code
 that doesn't have its own maintainer or list.
 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-09 Thread Zhao Qiang 
On Wed, 2015-07-09 at 02:09PM -0500, Wood Scott wrote:

 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, July 09, 2015 2:09 PM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Thu, 2015-07-09 at 01:05 -0500, Zhao Qiang-B45475 wrote:
  On Wed, 2015-07-09 at 11:51 -0500, Wood Scott wrote:
 
   -Original Message-
   From: Wood Scott-B07421
   Sent: Thursday, July 09, 2015 11:51 AM
   To: Zhao Qiang-B45475
   Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
   Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/
   to lib/
  
   That doesn't involve a different alignment for each allocation.  It
   uses the same alignment for all of them, and the alignment that
   cpm_common.c provides to rh_init() is 1 byte.
  
   ...but sigh, cpm_muram_alloc() is changing cpm_muram_info.alignment
   behind the rheap code's back.  Despite the existence of
 rh_alloc_align().
  
   So yes, add aligned allocation functionality to genalloc, but don't
   duplicate
   gen_pool_alloc() to do so.  Instead, rename gen_pool_alloc() to
   gen_pool_alloc_align() with an alignment parameter (also modifying
   the algo function to take an alignment arg, which
   gen_pool_first_fit_order_align() would ignore), and provide a
 
  Here, I don’t understand how to handle the algo In your mind.
  Can you explain more detailly?
 
 The algorithms would be unchanged except that they would receive a new
 alignment (or alignment mask) parameter.  gen_pool_first_fit_order_align()
 would ignore it, but the other algorithms would pass it through to the
 bitmap allocator.

How about to add an align_mask parameter to gen_pool_first_fit? 

 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-09 Thread Scott Wood 
On Thu, 2015-07-09 at 01:14 -0500, Zhao Qiang-B45475 wrote:
 On Wed, 2015-07-09 at 02:09PM -0500, Wood Scott wrote:
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, July 09, 2015 2:09 PM
  To: Zhao Qiang-B45475
  Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
  Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
  lib/
  
  On Thu, 2015-07-09 at 01:05 -0500, Zhao Qiang-B45475 wrote:
   On Wed, 2015-07-09 at 11:51 -0500, Wood Scott wrote:
   
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 09, 2015 11:51 AM
To: Zhao Qiang-B45475
Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/
to lib/

That doesn't involve a different alignment for each allocation.  It
uses the same alignment for all of them, and the alignment that
cpm_common.c provides to rh_init() is 1 byte.

...but sigh, cpm_muram_alloc() is changing cpm_muram_info.alignment
behind the rheap code's back.  Despite the existence of
  rh_alloc_align().

So yes, add aligned allocation functionality to genalloc, but don't
duplicate
gen_pool_alloc() to do so.  Instead, rename gen_pool_alloc() to
gen_pool_alloc_align() with an alignment parameter (also modifying
the algo function to take an alignment arg, which
gen_pool_first_fit_order_align() would ignore), and provide a
   
   Here, I don’t understand how to handle the algo In your mind.
   Can you explain more detailly?
  
  The algorithms would be unchanged except that they would receive a new
  alignment (or alignment mask) parameter.  gen_pool_first_fit_order_align()
  would ignore it, but the other algorithms would pass it through to the
  bitmap allocator.
 
 How about to add an align_mask parameter to gen_pool_first_fit? 

All of the algorithms have to have the same function signature.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-08 Thread Zhao Qiang 
So I will add two func for my use, do you think it is ok?
I need to align the address of allocated muram.
And I will set algo = gen_pool_first_fit_align.

+unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,
+   unsigned long align)
+{
+   struct gen_pool_chunk *chunk;
+   unsigned long addr = 0;
+   unsigned long align_mask;
+   int order = pool-min_alloc_order;
+   int nbits, start_bit = 0, end_bit, remain;
+
+#ifndef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
+   BUG_ON(in_nmi());
+#endif
+
+   if (size == 0)
+   return 0;
+
+   align_mask = ((align + (1UL  order) - 1)  order) - 1;
+   nbits = (size + (1UL  order) - 1)  order;
+   rcu_read_lock();
+   list_for_each_entry_rcu(chunk, pool-chunks, next_chunk) {
+   if (size  atomic_read(chunk-avail))
+   continue;
+
+   end_bit = chunk_size(chunk)  order;
+retry:
+   start_bit = pool-algo(chunk-bits, end_bit, start_bit, nbits,
+   pool-data, align_mask);
+   if (start_bit = end_bit)
+   continue;
+   remain = bitmap_set_ll(chunk-bits, start_bit, nbits);
+   if (remain) {
+   remain = bitmap_clear_ll(chunk-bits, start_bit,
+nbits - remain);
+   BUG_ON(remain);
+   goto retry;
+   }
+
+   addr = chunk-start_addr + ((unsigned long)start_bit  order);
+   size = nbits  order;
+   atomic_sub(size, chunk-avail);
+   break;
+   }
+   rcu_read_unlock();
+   return addr;
+}
+EXPORT_SYMBOL(gen_pool_alloc);

+ * gen_pool_first_fit_align - find the first available region
+ * of memory matching the size requirement. The region will be aligned
+ * to the order of the size specified.
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: additional data - unused
+ */
+unsigned long gen_pool_first_fit_align(unsigned long *map,
+   unsigned long size, unsigned long start,
+   unsigned int nr, void *data, unsigned long align_mask)
+{
+   return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
+}
+EXPORT_SYMBOL(gen_pool_first_fit_align);
+

Best Regards
Zhao Qiang


 -Original Message-
 From: Wood Scott-B07421
 Sent: Wednesday, July 08, 2015 11:28 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Tue, 2015-07-07 at 22:26 -0500, Zhao Qiang-B45475 wrote:
  Now the point is, genalloc is not so proper to qe muram while rheap is
  written to manage muram,
 
 rheap is not specific to muram.
 
  if use genalloc instead of rheap, there will be amounts of work to do.
 
 Not much.  I think I've spent more time responding to continual e-mails
 on this topic than it would have taken to convert it. :-P
 
  I have a suggestion, how about to put rheap under drivers/soc/qe,
  because rheap is To manage muram when it is added to sdk.
 
 No.
 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-08 Thread Scott Wood 
On Wed, 2015-07-08 at 22:18 -0500, Zhao Qiang-B45475 wrote:
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, July 09, 2015 2:59 AM
  To: Zhao Qiang-B45475
  Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
  Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
  lib/
 
  On Wed, 2015-07-08 at 02:25 -0500, Zhao Qiang-B45475 wrote:
   So I will add two func for my use, do you think it is ok?
   I need to align the address of allocated muram.
   And I will set algo = gen_pool_first_fit_align.
  
   +unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,
   +   unsigned long align)
 
  Again, please explain why you need this for CPM/QE.  I don't see
  rh_alloc_align() currently being used by either.
 
  Also, please stop top-posting.
  
  
 unsigned long rh_alloc(struct _rh_info *info, int size, const char *owner)
 {
 return rh_alloc_align(info, size, info-alignment, owner);
 }
 EXPORT_SYMBOL_GPL(rh_alloc);

That doesn't involve a different alignment for each allocation.  It uses the 
same alignment for all of them, and the alignment that cpm_common.c provides 
to rh_init() is 1 byte.

...but sigh, cpm_muram_alloc() is changing cpm_muram_info.alignment behind 
the rheap code's back.  Despite the existence of rh_alloc_align().

So yes, add aligned allocation functionality to genalloc, but don't duplicate 
gen_pool_alloc() to do so.  Instead, rename gen_pool_alloc() to 
gen_pool_alloc_align() with an alignment parameter (also modifying the algo 
function to take an alignment arg, which gen_pool_first_fit_order_align() 
would ignore), and provide a gen_pool_alloc() wrapper that specifies 1 as the 
required alignment.  Also be sure to CC lkml on the patchset since you're 
touching core code that doesn't have its own maintainer or list.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-08 Thread Zhao Qiang 
 -Original Message-

 From: Wood Scott-B07421

 Sent: Thursday, July 09, 2015 2:59 AM

 To: Zhao Qiang-B45475

 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061

 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to

 lib/



 On Wed, 2015-07-08 at 02:25 -0500, Zhao Qiang-B45475 wrote:

  So I will add two func for my use, do you think it is ok?

  I need to align the address of allocated muram.

  And I will set algo = gen_pool_first_fit_align.

 

  +unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,

  +   unsigned long align)



 Again, please explain why you need this for CPM/QE.  I don't see

 rh_alloc_align() currently being used by either.



 Also, please stop top-posting.





unsigned long rh_alloc(struct _rh_info *info, int size, const char *owner)

{

return rh_alloc_align(info, size, info-alignment, owner);

}

EXPORT_SYMBOL_GPL(rh_alloc);





 -Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-08 Thread Scott Wood 
On Wed, 2015-07-08 at 02:25 -0500, Zhao Qiang-B45475 wrote:
 So I will add two func for my use, do you think it is ok?
 I need to align the address of allocated muram.
 And I will set algo = gen_pool_first_fit_align.
 
 +unsigned long gen_pool_alloc_align(struct gen_pool *pool, size_t size,
 +   unsigned long align)

Again, please explain why you need this for CPM/QE.  I don't see 
rh_alloc_align() currently being used by either.

Also, please stop top-posting.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-07 Thread Zhao Qiang 
I need to ensure one thing, 
In your point, you want me to use lib/genalloc.c instead of rheap.c.
Or just think rheap.c is not proper to put into lib?

Best Regards
Zhao Qiang


 -Original Message-
 From: Wood Scott-B07421
 Sent: Friday, June 05, 2015 6:41 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Thu, 2015-06-04 at 04:27 -0500, Zhao Qiang-B45475 wrote:
  On Thu, 2015-06-04 at 2:14PM, Wood Scott wrote:
 
 
   -Original Message-
   From: Wood Scott-B07421
   Sent: Thursday, June 04, 2015 2:14 PM
   To: Zhao Qiang-B45475
   Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
   Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/
   to lib/
  
   On Thu, 2015-06-04 at 00:56 -0500, Zhao Qiang-B45475 wrote:
On Thu, 2015-05-28 at 1:37AM +0800, Wood Scott wrote:
   
   
 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, May 28, 2015 1:37 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie
 Xiaobo-
 R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from
 arch/powerpc/lib/ to lib/

 On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
  qe need to use the rheap, so move it to public directory.

 You've been previously asked to use lib/genalloc.c rather than
 introduce duplicate functionality into /lib.  NACK.
   
Can't use lib/genalloc.c instead of rheap.c.
Qe need to alloc muram of qe, not DIMM.
  
   lib/genalloc.h is not for allocating main memory.  It is for
   allocating special regions.  It is serving the same purpose as
   rheap.
 
  I need to use the func rh_alloc_align, what it the similar func?
  I just find a func gen_pool_first_fit_order_align.
 
 I don't see anywhere the QE code currently calls rh_alloc_align() -- and
 cpm_muram_init() calls rh_init() with an alignment of 1.
 
 If you do need some functionality that genalloc doesn't offer, add the
 functionality to genalloc.
 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-07 Thread Scott Wood 
On Tue, 2015-07-07 at 21:54 -0500, Zhao Qiang-B45475 wrote:
 I need to ensure one thing, 
 In your point, you want me to use lib/genalloc.c instead of rheap.c.
 Or just think rheap.c is not proper to put into lib?
 
 Best Regards
 Zhao Qiang

I want you to use lib/genalloc.c.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-07 Thread Zhao Qiang 
Now the point is, genalloc is not so proper to qe muram while rheap is written 
to manage muram,
if use genalloc instead of rheap, there will be amounts of work to do.
I have a suggestion, how about to put rheap under drivers/soc/qe, because rheap 
is 
To manage muram when it is added to sdk.

Best Regards
Zhao Qiang


 -Original Message-
 From: Wood Scott-B07421
 Sent: Wednesday, July 08, 2015 10:55 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Tue, 2015-07-07 at 21:54 -0500, Zhao Qiang-B45475 wrote:
  I need to ensure one thing,
  In your point, you want me to use lib/genalloc.c instead of rheap.c.
  Or just think rheap.c is not proper to put into lib?
 
  Best Regards
  Zhao Qiang
 
 I want you to use lib/genalloc.c.
 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-07-07 Thread Scott Wood 
On Tue, 2015-07-07 at 22:26 -0500, Zhao Qiang-B45475 wrote:
 Now the point is, genalloc is not so proper to qe muram while rheap is 
 written to manage muram,

rheap is not specific to muram.

 if use genalloc instead of rheap, there will be amounts of work to do.

Not much.  I think I've spent more time responding to continual e-mails on 
this topic than it would have taken to convert it. :-P

 I have a suggestion, how about to put rheap under drivers/soc/qe, because 
 rheap is 
 To manage muram when it is added to sdk.

No.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-06-04 Thread Scott Wood 
On Thu, 2015-06-04 at 04:27 -0500, Zhao Qiang-B45475 wrote:
 On Thu, 2015-06-04 at 2:14PM, Wood Scott wrote:
 
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, June 04, 2015 2:14 PM
  To: Zhao Qiang-B45475
  Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
  Subject: Re: [PATCH 2/2] rheap: move rheap.c from 
  arch/powerpc/lib/ to
  lib/
  
  On Thu, 2015-06-04 at 00:56 -0500, Zhao Qiang-B45475 wrote:
   On Thu, 2015-05-28 at 1:37AM +0800, Wood Scott wrote:
   
   
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, May 28, 2015 1:37 AM
To: Zhao Qiang-B45475
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie 
Xiaobo-
R63061
Subject: Re: [PATCH 2/2] rheap: move rheap.c from 
arch/powerpc/lib/
to lib/

On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
 qe need to use the rheap, so move it to public directory.

You've been previously asked to use lib/genalloc.c rather than
introduce duplicate functionality into /lib.  NACK.
   
   Can't use lib/genalloc.c instead of rheap.c.
   Qe need to alloc muram of qe, not DIMM.
  
  lib/genalloc.h is not for allocating main memory.  It is for 
  allocating
  special regions.  It is serving the same purpose as rheap.
 
 I need to use the func rh_alloc_align, what it the similar func?
 I just find a func gen_pool_first_fit_order_align.

I don't see anywhere the QE code currently calls rh_alloc_align() -- 
and cpm_muram_init() calls rh_init() with an alignment of 1.

If you do need some functionality that genalloc doesn't offer, add the 
functionality to genalloc.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-06-04 Thread Scott Wood 
On Thu, 2015-06-04 at 00:56 -0500, Zhao Qiang-B45475 wrote:
 On Thu, 2015-05-28 at 1:37AM +0800, Wood Scott wrote:
 
 
  -Original Message-
  From: Wood Scott-B07421
  Sent: Thursday, May 28, 2015 1:37 AM
  To: Zhao Qiang-B45475
  Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-
  R63061
  Subject: Re: [PATCH 2/2] rheap: move rheap.c from 
  arch/powerpc/lib/ to
  lib/
  
  On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
   qe need to use the rheap, so move it to public directory.
  
  You've been previously asked to use lib/genalloc.c rather than 
  introduce
  duplicate functionality into /lib.  NACK.
 
 Can't use lib/genalloc.c instead of rheap.c.
 Qe need to alloc muram of qe, not DIMM.

lib/genalloc.h is not for allocating main memory.  It is for 
allocating special regions.  It is serving the same purpose as rheap.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-06-04 Thread Zhao Qiang 
On Thu, 2015-06-04 at 2:14PM, Wood Scott wrote:


 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, June 04, 2015 2:14 PM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Thu, 2015-06-04 at 00:56 -0500, Zhao Qiang-B45475 wrote:
  On Thu, 2015-05-28 at 1:37AM +0800, Wood Scott wrote:
 
 
   -Original Message-
   From: Wood Scott-B07421
   Sent: Thursday, May 28, 2015 1:37 AM
   To: Zhao Qiang-B45475
   Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-
   R63061
   Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/
   to lib/
  
   On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
qe need to use the rheap, so move it to public directory.
  
   You've been previously asked to use lib/genalloc.c rather than
   introduce duplicate functionality into /lib.  NACK.
 
  Can't use lib/genalloc.c instead of rheap.c.
  Qe need to alloc muram of qe, not DIMM.
 
 lib/genalloc.h is not for allocating main memory.  It is for allocating
 special regions.  It is serving the same purpose as rheap.

I need to use the func rh_alloc_align, what it the similar func?
I just find a func gen_pool_first_fit_order_align.

 
 -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-06-03 Thread Zhao Qiang 
On Thu, 2015-05-28 at 1:37AM +0800, Wood Scott wrote:


 -Original Message-
 From: Wood Scott-B07421
 Sent: Thursday, May 28, 2015 1:37 AM
 To: Zhao Qiang-B45475
 Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061
 Subject: Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to
 lib/
 
 On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
  qe need to use the rheap, so move it to public directory.
 
 You've been previously asked to use lib/genalloc.c rather than introduce
 duplicate functionality into /lib.  NACK.

Can't use lib/genalloc.c instead of rheap.c.
Qe need to alloc muram of qe, not DIMM.

 
 Also, please don't use coreid-based e-mail addresses with no real names
 associated, which makes it hard to tell who has been CCed.
 
 -Scott
Best Regards
Zhao Qiang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-05-27 Thread Zhao Qiang 
qe need to use the rheap, so move it to public directory.

Signed-off-by: Zhao Qiang b45...@freescale.com
---
 arch/powerpc/Kconfig| 3 ---
 arch/powerpc/include/asm/fsl_85xx_cache_sram.h  | 2 +-
 arch/powerpc/lib/Makefile   | 2 --
 arch/powerpc/platforms/44x/Kconfig  | 2 +-
 arch/powerpc/platforms/85xx/Kconfig | 2 +-
 arch/powerpc/platforms/Kconfig  | 2 +-
 arch/powerpc/platforms/Kconfig.cputype  | 2 +-
 arch/powerpc/sysdev/cpm1.c  | 2 +-
 arch/powerpc/sysdev/cpm2.c  | 2 +-
 arch/powerpc/sysdev/cpm_common.c| 2 +-
 arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
 drivers/dma/bestcomm/Kconfig| 2 +-
 drivers/soc/fsl/qe/Kconfig  | 2 +-
 drivers/soc/fsl/qe/qe.c | 2 +-
 drivers/soc/fsl/qe/qe_common.c  | 2 +-
 include/linux/fsl/bestcomm/sram.h   | 2 +-
 {arch/powerpc/include/asm = include/linux/fsl}/rheap.h | 0
 lib/Kconfig | 3 +++
 lib/Makefile| 2 ++
 {arch/powerpc/lib = lib}/rheap.c   | 2 +-
 20 files changed, 20 insertions(+), 20 deletions(-)
 rename {arch/powerpc/include/asm = include/linux/fsl}/rheap.h (100%)
 rename {arch/powerpc/lib = lib}/rheap.c (99%)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d003409..c9b16bf 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -1069,7 +1069,4 @@ config KEYS_COMPAT
 
 source crypto/Kconfig
 
-config PPC_LIB_RHEAP
-   bool
-
 source arch/powerpc/kvm/Kconfig
diff --git a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h 
b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
index 2af2bdc..e57888a 100644
--- a/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
+++ b/arch/powerpc/include/asm/fsl_85xx_cache_sram.h
@@ -26,7 +26,7 @@
 #ifndef __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
 #define __ASM_POWERPC_FSL_85XX_CACHE_SRAM_H__
 
-#include asm/rheap.h
+#include linux/fsl/rheap.h
 #include linux/spinlock.h
 
 /*
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 59fa2de..c73dff8 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -32,8 +32,6 @@ obj-$(CONFIG_SMP) += locks.o
 obj-$(CONFIG_ALTIVEC)  += vmx-helper.o
 endif
 
-obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
-
 obj-y  += code-patching.o
 obj-y  += feature-fixups.o
 obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
diff --git a/arch/powerpc/platforms/44x/Kconfig 
b/arch/powerpc/platforms/44x/Kconfig
index 4d88f6a..c7994ff 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -282,7 +282,7 @@ config PPC4xx_GPIO
 config PPC4xx_OCM
bool PPC4xx On Chip Memory (OCM) support
depends on 4xx
-   select PPC_LIB_RHEAP
+   select LIB_RHEAP
help
  Enable OCM support for PowerPC 4xx platforms with on chip memory,
  OCM provides the fast place for memory access to improve performance.
diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index f22635a..0a7cb9d 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -16,7 +16,7 @@ if PPC32
 
 config FSL_85XX_CACHE_SRAM
bool
-   select PPC_LIB_RHEAP
+   select LIB_RHEAP
help
  When selected, this option enables cache-sram support
  for memory allocation on P1/P2 QorIQ platforms.
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index ae8879c..25740c4 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -281,7 +281,7 @@ config CPM2
bool Enable support for the CPM2 (Communications Processor Module)
depends on (FSL_SOC_BOOKE  PPC32) || 8260
select CPM
-   select PPC_LIB_RHEAP
+   select LIB_RHEAP
select PPC_PCI_CHOICE
select ARCH_REQUIRE_GPIOLIB
help
diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index a41bd02..0bb8c58 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -33,7 +33,7 @@ config PPC_8xx
bool Freescale 8xx
select FSL_SOC
select 8xx
-   select PPC_LIB_RHEAP
+   select LIB_RHEAP
 
 config 40x
bool AMCC 40x
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
index 5e6ff38..c6f5762 100644
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -38,7 +38,7 @@
 #include asm/cpm1.h
 #include asm/io.h
 #include asm/tlbflush.h
-#include asm/rheap.h
+#include linux/fsl/rheap.h
 #include asm/prom.h
 #include asm/cpm.h
 
diff --git

Re: [PATCH 2/2] rheap: move rheap.c from arch/powerpc/lib/ to lib/

2015-05-27 Thread Scott Wood 
On Wed, 2015-05-27 at 17:12 +0800, Zhao Qiang wrote:
 qe need to use the rheap, so move it to public directory.

You've been previously asked to use lib/genalloc.c rather than 
introduce duplicate functionality into /lib.  NACK.

Also, please don't use coreid-based e-mail addresses with no real 
names associated, which makes it hard to tell who has been CCed.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev