1. 13 11月, 2013 1 次提交
    • N
      lib/genalloc: add a helper function for DMA buffer allocation · 684f0d3d
      Nicolin Chen 提交于
      When using pool space for DMA buffer, there might be duplicated calling of
      gen_pool_alloc() and gen_pool_virt_to_phys() in each implementation.
      
      Thus it's better to add a simple helper function, a compatible one to the
      common dma_alloc_coherent(), to save some code.
      Signed-off-by: NNicolin Chen <b42378@freescale.com>
      Cc: "Hans J. Koch" <hjk@hansjkoch.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Eric Miao <eric.y.miao@gmail.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Kevin Hilman <khilman@deeprootsystems.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      684f0d3d
  2. 12 9月, 2013 1 次提交
  3. 30 4月, 2013 1 次提交
    • P
      genalloc: add devres support, allow to find a managed pool by device · 9375db07
      Philipp Zabel 提交于
      This patch adds three exported functions to lib/genalloc.c:
      devm_gen_pool_create, dev_get_gen_pool, and of_get_named_gen_pool.
      
      devm_gen_pool_create is a managed version of gen_pool_create that keeps
      track of the pool via devres and allows the management code to
      automatically destroy it after device removal.
      
      dev_get_gen_pool retrieves the gen_pool for a given device, if it was
      created with devm_gen_pool_create, using devres_find.
      
      of_get_named_gen_pool retrieves the gen_pool for a given device node and
      property name, where the property must contain a phandle pointing to a
      platform device node.  The corresponding platform device is then fed into
      dev_get_gen_pool and the resulting gen_pool is returned.
      
      [akpm@linux-foundation.org: make the of_get_named_gen_pool() stub static, fixing a zillion link errors]
      [akpm@linux-foundation.org: squish "struct device declared inside parameter list" warning]
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      Tested-by: NMichal Simek <monstr@monstr.eu>
      Cc: Fabio Estevam <fabio.estevam@freescale.com>
      Cc: Matt Porter <mporter@ti.com>
      Cc: Dong Aisheng <dong.aisheng@linaro.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Rob Herring <rob.herring@calxeda.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Javier Martin <javier.martin@vista-silicon.com>
      Cc: Huang Shijie <shijie8@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9375db07
  4. 06 10月, 2012 1 次提交
    • B
      genalloc: make it possible to use a custom allocation algorithm · ca279cf1
      Benjamin Gaignard 提交于
      Premit use of another algorithm than the default first-fit one.  For
      example a custom algorithm could be used to manage alignment requirements.
      
      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.
      
      An usage example may look like this:
      struct my_pool_constraints {
      	int align;
      	int bank;
      	...
      };
      
      unsigned long my_custom_algo(unsigned long *map, unsigned long size,
      		unsigned long start, unsigned int nr, void *data)
      {
      	struct my_pool_constraints *constraints = data;
      	...
      	deal with allocation contraints
      	...
      	return the index in bitmap where perform the allocation
      }
      
      void create_my_pool()
      {
      	struct my_pool_constraints c;
      	struct gen_pool *pool = gen_pool_create(...);
      	gen_pool_add(pool, ...);
      	gen_pool_set_algo(pool, my_custom_algo, &c);
      }
      
      Add of best-fit algorithm function:
      most of the time best-fit is slower then first-fit but memory fragmentation
      is lower. The random buffer allocation/free tests don't show any arithmetic
      relation between the allocation time and fragmentation but the
      best-fit algorithm
      is sometime able to perform the allocation when the first-fit can't.
      
      This new algorithm help to remove static allocations on ESRAM, a small but
      fast on-chip RAM of few KB, used for high-performance uses cases like DMA
      linked lists, graphic accelerators, encoders/decoders. On the Ux500
      (in the ARM tree) we have define 5 ESRAM banks of 128 KB each and use of
      static allocations becomes unmaintainable:
      cd arch/arm/mach-ux500 && grep -r ESRAM .
      ./include/mach/db8500-regs.h:/* Base address and bank offsets for ESRAM */
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BASE   0x40000000
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK_SIZE      0x00020000
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK0  U8500_ESRAM_BASE
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK1       (U8500_ESRAM_BASE + U8500_ESRAM_BANK_SIZE)
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK2       (U8500_ESRAM_BANK1 + U8500_ESRAM_BANK_SIZE)
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK3       (U8500_ESRAM_BANK2 + U8500_ESRAM_BANK_SIZE)
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_BANK4       (U8500_ESRAM_BANK3 + U8500_ESRAM_BANK_SIZE)
      ./include/mach/db8500-regs.h:#define U8500_ESRAM_DMA_LCPA_OFFSET     0x10000
      ./include/mach/db8500-regs.h:#define U8500_DMA_LCPA_BASE
      (U8500_ESRAM_BANK0 + U8500_ESRAM_DMA_LCPA_OFFSET)
      ./include/mach/db8500-regs.h:#define U8500_DMA_LCLA_BASE U8500_ESRAM_BANK4
      
      I want to use genalloc to do dynamic allocations but I need to be able to
      fine tune the allocation algorithm. I my case best-fit algorithm give
      better results than first-fit, but it will not be true for every use case.
      Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@stericsson.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ca279cf1
  5. 03 8月, 2011 1 次提交
    • H
      lib, Make gen_pool memory allocator lockless · 7f184275
      Huang Ying 提交于
      This version of the gen_pool memory allocator supports lockless
      operation.
      
      This makes it safe to use in NMI handlers and other special
      unblockable contexts that could otherwise deadlock on locks.  This is
      implemented by using atomic operations and retries on any conflicts.
      The disadvantage is that there may be livelocks in extreme cases.  For
      better scalability, one gen_pool allocator can be used for each CPU.
      
      The lockless operation only works if there is enough memory available.
      If new memory is added to the pool a lock has to be still taken.  So
      any user relying on locklessness has to ensure that sufficient memory
      is preallocated.
      
      The basic atomic operation of this allocator is cmpxchg on long.  On
      architectures that don't have NMI-safe cmpxchg implementation, the
      allocator can NOT be used in NMI handler.  So code uses the allocator
      in NMI handler should depend on CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7f184275
  6. 25 5月, 2011 2 次提交
  7. 02 10月, 2006 1 次提交
  8. 23 6月, 2006 1 次提交
  9. 22 6月, 2005 1 次提交
    • J
      [PATCH] ia64 uncached alloc · f14f75b8
      Jes Sorensen 提交于
      This patch contains the ia64 uncached page allocator and the generic
      allocator (genalloc).  The uncached allocator was formerly part of the SN2
      mspec driver but there are several other users of it so it has been split
      off from the driver.
      
      The generic allocator can be used by device driver to manage special memory
      etc.  The generic allocator is based on the allocator from the sym53c8xx_2
      driver.
      
      Various users on ia64 needs uncached memory.  The SGI SN architecture requires
      it for inter-partition communication between partitions within a large NUMA
      cluster.  The specific user for this is the XPC code.  Another application is
      large MPI style applications which use it for synchronization, on SN this can
      be done using special 'fetchop' operations but it also benefits non SN
      hardware which may use regular uncached memory for this purpose.  Performance
      of doing this through uncached vs cached memory is pretty substantial.  This
      is handled by the mspec driver which I will push out in a seperate patch.
      
      Rather than creating a specific allocator for just uncached memory I came up
      with genalloc which is a generic purpose allocator that can be used by device
      drivers and other subsystems as they please.  For instance to handle onboard
      device memory.  It was derived from the sym53c7xx_2 driver's allocator which
      is also an example of a potential user (I am refraining from modifying sym2
      right now as it seems to have been under fairly heavy development recently).
      
      On ia64 memory has various properties within a granule, ie.  it isn't safe to
      access memory as uncached within the same granule as currently has memory
      accessed in cached mode.  The regular system therefore doesn't utilize memory
      in the lower granules which is mixed in with device PAL code etc.  The
      uncached driver walks the EFI memmap and pulls out the spill uncached pages
      and sticks them into the uncached pool.  Only after these chunks have been
      utilized, will it start converting regular cached memory into uncached memory.
      Hence the reason for the EFI related code additions.
      Signed-off-by: NJes Sorensen <jes@wildopensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f14f75b8