Message ID | 1432717920-43563-2-git-send-email-B45475@freescale.com (mailing list archive) |
---|---|
State | Rejected |
Headers | show |
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
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
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
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
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
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
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
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
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
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
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
> -----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
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
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
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
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
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
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 a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index 8dc1e24..5a63d35 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -41,7 +41,7 @@ #include <asm/page.h> #include <asm/pgtable.h> #include <asm/cpm2.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <asm/fs_pd.h> #include <sysdev/fsl_soc.h> diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c index 4f78695..3e06505 100644 --- a/arch/powerpc/sysdev/cpm_common.c +++ b/arch/powerpc/sysdev/cpm_common.c @@ -27,7 +27,7 @@ #include <asm/udbg.h> #include <asm/io.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <asm/cpm.h> #include <mm/mmu_decl.h> diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c index 85d9e37..cfe2e19 100644 --- a/arch/powerpc/sysdev/ppc4xx_ocm.c +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c @@ -27,7 +27,7 @@ #include <linux/dma-mapping.h> #include <linux/of.h> #include <linux/of_address.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <asm/ppc4xx_ocm.h> #include <linux/slab.h> #include <linux/debugfs.h> diff --git a/drivers/dma/bestcomm/Kconfig b/drivers/dma/bestcomm/Kconfig index 29e4270..9bb1bf8 100644 --- a/drivers/dma/bestcomm/Kconfig +++ b/drivers/dma/bestcomm/Kconfig @@ -6,7 +6,7 @@ config PPC_BESTCOMM tristate "Bestcomm DMA engine support" depends on PPC_MPC52xx default n - select PPC_LIB_RHEAP + select LIB_RHEAP help BestComm is the name of the communication coprocessor found on the Freescale MPC5200 family of processor. Its usage is diff --git a/drivers/soc/fsl/qe/Kconfig b/drivers/soc/fsl/qe/Kconfig index e6b8862..fe387ee 100644 --- a/drivers/soc/fsl/qe/Kconfig +++ b/drivers/soc/fsl/qe/Kconfig @@ -4,7 +4,7 @@ config QUICC_ENGINE bool "Freescale QUICC Engine (QE) Support" depends on FSL_SOC && PPC32 - select PPC_LIB_RHEAP + select LIB_RHEAP select CRC32 help The QUICC Engine (QE) is a new generation of communications diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index 2c56958..151d9e7 100644 --- a/drivers/soc/fsl/qe/qe.c +++ b/drivers/soc/fsl/qe/qe.c @@ -33,7 +33,7 @@ #include <asm/page.h> #include <asm/pgtable.h> #include <asm/prom.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <soc/fsl/immap_qe.h> #include <soc/fsl/qe.h> diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c index 382ee7c..7b495b6 100644 --- a/drivers/soc/fsl/qe/qe_common.c +++ b/drivers/soc/fsl/qe/qe_common.c @@ -26,7 +26,7 @@ #include <linux/slab.h> #include <linux/io.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <soc/fsl/qe.h> static spinlock_t qe_muram_lock; diff --git a/include/linux/fsl/bestcomm/sram.h b/include/linux/fsl/bestcomm/sram.h index b6d6689..117eaa1 100644 --- a/include/linux/fsl/bestcomm/sram.h +++ b/include/linux/fsl/bestcomm/sram.h @@ -12,7 +12,7 @@ #ifndef __BESTCOMM_SRAM_H__ #define __BESTCOMM_SRAM_H__ -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> #include <asm/mmu.h> #include <linux/spinlock.h> diff --git a/arch/powerpc/include/asm/rheap.h b/include/linux/fsl/rheap.h similarity index 100% rename from arch/powerpc/include/asm/rheap.h rename to include/linux/fsl/rheap.h diff --git a/lib/Kconfig b/lib/Kconfig index 334f772..f5d5e99 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -393,6 +393,9 @@ config CPU_RMAP bool depends on SMP +config LIB_RHEAP + bool + config DQL bool diff --git a/lib/Makefile b/lib/Makefile index ba967a1..dccdef1 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -193,3 +193,5 @@ quiet_cmd_build_OID_registry = GEN $@ clean-files += oid_registry_data.c obj-$(CONFIG_UCS2_STRING) += ucs2_string.o + +obj-$(CONFIG_LIB_RHEAP) += rheap.o diff --git a/arch/powerpc/lib/rheap.c b/lib/rheap.c similarity index 99% rename from arch/powerpc/lib/rheap.c rename to lib/rheap.c index a1060a8..af180fd 100644 --- a/arch/powerpc/lib/rheap.c +++ b/lib/rheap.c @@ -20,7 +20,7 @@ #include <linux/err.h> #include <linux/slab.h> -#include <asm/rheap.h> +#include <linux/fsl/rheap.h> /* * Fixup a list_head, needed when copying lists. If the pointers fall
qe need to use the rheap, so move it to public directory. Signed-off-by: Zhao Qiang <B45475@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%)