1. 07 8月, 2014 1 次提交
  2. 09 7月, 2014 2 次提交
    • T
      firmware loader: allow disabling of udev as firmware loader · 5a1379e8
      Takashi Iwai 提交于
      [The patch was originally proposed by Tom Gundersen, and rewritten
       afterwards by me; most of changelogs below borrowed from Tom's
       original patch -- tiwai]
      
      Currently (at least) the dell-rbu driver selects FW_LOADER_USER_HELPER,
      which means that distros can't really stop loading firmware through
      udev without breaking other users (though some have).
      
      Ideally we would remove/disable the udev firmware helper in both the
      kernel and in udev, but if we were to disable it in udev and not the
      kernel, the result would be (seemingly) hung kernels as no one would
      be around to cancel firmware requests.
      
      This patch allows udev firmware loading to be disabled while still
      allowing non-udev firmware loading, as done by the dell-rbu driver, to
      continue working. This is achieved by only using the fallback
      mechanism when the uevent is suppressed.
      
      The patch renames the user-selectable Kconfig from FW_LOADER_USER_HELPER
      to FW_LOADER_USER_HELPER_FALLBACK, and the former is reverse-selected
      by the latter or the drivers that need userhelper like dell-rbu.
      
      Also, the "default y" is removed together with this change, since it's
      been deprecated in udev upstream, thus rather better to disable it
      nowadays.
      
      Tested with
          FW_LOADER_USER_HELPER=n
          LATTICE_ECP3_CONFIG=y
          DELL_RBU=y
      and udev without the firmware loading support, but I don't have the
      hardware to test the lattice/dell drivers, so additional testing would
      be appreciated.
      Reviewed-by: NTom Gundersen <teg@jklm.no>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Abhay Salunke <Abhay_Salunke@dell.com>
      Cc: Stefan Roese <sr@denx.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Kay Sievers <kay@vrfy.org>
      Tested-by: NBalaji Singh <B_B_Singh@DELL.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a1379e8
    • M
      fence: dma-buf cross-device synchronization (v18) · e941759c
      Maarten Lankhorst 提交于
      A fence can be attached to a buffer which is being filled or consumed
      by hw, to allow userspace to pass the buffer without waiting to another
      device.  For example, userspace can call page_flip ioctl to display the
      next frame of graphics after kicking the GPU but while the GPU is still
      rendering.  The display device sharing the buffer with the GPU would
      attach a callback to get notified when the GPU's rendering-complete IRQ
      fires, to update the scan-out address of the display, without having to
      wake up userspace.
      
      A driver must allocate a fence context for each execution ring that can
      run in parallel. The function for this takes an argument with how many
      contexts to allocate:
        + fence_context_alloc()
      
      A fence is transient, one-shot deal.  It is allocated and attached
      to one or more dma-buf's.  When the one that attached it is done, with
      the pending operation, it can signal the fence:
        + fence_signal()
      
      To have a rough approximation whether a fence is fired, call:
        + fence_is_signaled()
      
      The dma-buf-mgr handles tracking, and waiting on, the fences associated
      with a dma-buf.
      
      The one pending on the fence can add an async callback:
        + fence_add_callback()
      
      The callback can optionally be cancelled with:
        + fence_remove_callback()
      
      To wait synchronously, optionally with a timeout:
        + fence_wait()
        + fence_wait_timeout()
      
      When emitting a fence, call:
        + trace_fence_emit()
      
      To annotate that a fence is blocking on another fence, call:
        + trace_fence_annotate_wait_on(fence, on_fence)
      
      A default software-only implementation is provided, which can be used
      by drivers attaching a fence to a buffer when they have no other means
      for hw sync.  But a memory backed fence is also envisioned, because it
      is common that GPU's can write to, or poll on some memory location for
      synchronization.  For example:
      
        fence = custom_get_fence(...);
        if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
          dma_buf *fence_buf = seqno_fence->sync_buf;
          get_dma_buf(fence_buf);
      
          ... tell the hw the memory location to wait ...
          custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
        } else {
          /* fall-back to sw sync * /
          fence_add_callback(fence, my_cb);
        }
      
      On SoC platforms, if some other hw mechanism is provided for synchronizing
      between IP blocks, it could be supported as an alternate implementation
      with it's own fence ops in a similar way.
      
      enable_signaling callback is used to provide sw signaling in case a cpu
      waiter is requested or no compatible hardware signaling could be used.
      
      The intention is to provide a userspace interface (presumably via eventfd)
      later, to be used in conjunction with dma-buf's mmap support for sw access
      to buffers (or for userspace apps that would prefer to do their own
      synchronization).
      
      v1: Original
      v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
          that dma-fence didn't need to care about the sw->hw signaling path
          (it can be handled same as sw->sw case), and therefore the fence->ops
          can be simplified and more handled in the core.  So remove the signal,
          add_callback, cancel_callback, and wait ops, and replace with a simple
          enable_signaling() op which can be used to inform a fence supporting
          hw->hw signaling that one or more devices which do not support hw
          signaling are waiting (and therefore it should enable an irq or do
          whatever is necessary in order that the CPU is notified when the
          fence is passed).
      v3: Fix locking fail in attach_fence() and get_fence()
      v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
          we decided that we need to be able to attach one fence to N dma-buf's,
          so using the list_head in dma-fence struct would be problematic.
      v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
      v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
          about checking if fence fired or not. This is broken by design.
          waitqueue_active during destruction is now fatal, since the signaller
          should be holding a reference in enable_signalling until it signalled
          the fence. Pass the original dma_fence_cb along, and call __remove_wait
          in the dma_fence_callback handler, so that no cleanup needs to be
          performed.
      v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
          fence wasn't signaled yet, for example for hardware fences that may
          choose to signal blindly.
      v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
          header and fixed include mess. dma-fence.h now includes dma-buf.h
          All members are now initialized, so kmalloc can be used for
          allocating a dma-fence. More documentation added.
      v9: Change compiler bitfields to flags, change return type of
          enable_signaling to bool. Rework dma_fence_wait. Added
          dma_fence_is_signaled and dma_fence_wait_timeout.
          s/dma// and change exports to non GPL. Added fence_is_signaled and
          fence_enable_sw_signaling calls, add ability to override default
          wait operation.
      v10: remove event_queue, use a custom list, export try_to_wake_up from
          scheduler. Remove fence lock and use a global spinlock instead,
          this should hopefully remove all the locking headaches I was having
          on trying to implement this. enable_signaling is called with this
          lock held.
      v11:
          Use atomic ops for flags, lifting the need for some spin_lock_irqsaves.
          However I kept the guarantee that after fence_signal returns, it is
          guaranteed that enable_signaling has either been called to completion,
          or will not be called any more.
      
          Add contexts and seqno to base fence implementation. This allows you
          to wait for less fences, by testing for seqno + signaled, and then only
          wait on the later fence.
      
          Add FENCE_TRACE, FENCE_WARN, and FENCE_ERR. This makes debugging easier.
          An CONFIG_DEBUG_FENCE will be added to turn off the FENCE_TRACE
          spam, and another runtime option can turn it off at runtime.
      v12:
          Add CONFIG_FENCE_TRACE. Add missing documentation for the fence->context
          and fence->seqno members.
      v13:
          Fixup CONFIG_FENCE_TRACE kconfig description.
          Move fence_context_alloc to fence.
          Simplify fence_later.
          Kill priv member to fence_cb.
      v14:
          Remove priv argument from fence_add_callback, oops!
      v15:
          Remove priv from documentation.
          Explicitly include linux/atomic.h.
      v16:
          Add trace events.
          Import changes required by android syncpoints.
      v17:
          Use wake_up_state instead of try_to_wake_up. (Colin Cross)
          Fix up commit description for seqno_fence. (Rob Clark)
      v18:
          Rename release_fence to fence_release.
          Move to drivers/dma-buf/.
          Rename __fence_is_signaled and __fence_signal to *_locked.
          Rename __fence_init to fence_init.
          Make fence_default_wait return a signed long, and fix wait ops too.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: Thierry Reding <thierry.reding@gmail.com> #use smp_mb__before_atomic()
      Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: NDaniel Vetter <daniel@ffwll.ch>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e941759c
  3. 05 6月, 2014 1 次提交
  4. 26 4月, 2014 1 次提交
  5. 19 2月, 2014 2 次提交
    • A
      x86: align x86 arch with generic CPU modalias handling · 2b9c1f03
      Ard Biesheuvel 提交于
      The x86 CPU feature modalias handling existed before it was reimplemented
      generically. This patch aligns the x86 handling so that it
      (a) reuses some more code that is now generic;
      (b) uses the generic format for the modalias module metadata entry, i.e., it
          now uses 'cpu:type:x86,venVVVVfamFFFFmodMMMM:feature:,XXXX,YYYY' instead of
          the 'x86cpu:vendor:VVVV:family:FFFF:model:MMMM:feature:,XXXX,YYYY' that was
          used before.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b9c1f03
    • A
      cpu: add generic support for CPU feature based module autoloading · 67bad2fd
      Ard Biesheuvel 提交于
      This patch adds support for advertising optional CPU features over udev
      using the modalias, and for declaring compatibility with/dependency upon
      such a feature in a module.
      
      The mapping between feature numbers and actual features should be provided
      by the architecture in a file called <asm/cpufeature.h> which exports the
      following functions/macros:
      - cpu_feature(FEAT), a preprocessor macro that maps token FEAT to a
        numeric index;
      - bool cpu_have_feature(n), returning whether this CPU has support for
        feature #n;
      - MAX_CPU_FEATURES, an upper bound for 'n' in the previous function.
      
      The feature can then be enabled by setting CONFIG_GENERIC_CPU_AUTOPROBE
      for the architecture.
      
      For instance, a module that registers its module init function using
      
        module_cpu_feature_match(FEAT_X, module_init_function)
      
      will be probed automatically when the CPU's support for the 'FEAT_X'
      feature is advertised over udev, and will only allow the module to be
      loaded by hand if the 'FEAT_X' feature is supported.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67bad2fd
  6. 19 12月, 2013 1 次提交
  7. 02 7月, 2013 1 次提交
  8. 04 6月, 2013 1 次提交
  9. 04 2月, 2013 1 次提交
  10. 26 10月, 2012 1 次提交
  11. 23 10月, 2012 1 次提交
  12. 01 8月, 2012 1 次提交
  13. 21 5月, 2012 1 次提交
  14. 11 2月, 2012 1 次提交
    • L
      drivers/base: add bus for System-on-Chip devices · 74d1d82c
      Lee Jones 提交于
      Traditionally, any System-on-Chip based platform creates a flat list
      of platform_devices directly under /sys/devices/platform.
      
      In order to give these some better structure, this introduces a new
      bus type for soc_devices that are registered with the new
      soc_device_register() function.  All devices that are on the same
      chip should then be registered as child devices of the soc device.
      
      The soc bus also exports a few standardised device attributes which
      allow user space to query the specific type of soc.
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74d1d82c
  15. 13 1月, 2012 1 次提交
  16. 12 1月, 2012 1 次提交
  17. 06 1月, 2012 2 次提交
    • S
      dma-buf: mark EXPERIMENTAL for 1st release. · a125a394
      Sumit Semwal 提交于
      Mark dma-buf buffer sharing API as EXPERIMENTAL for first release.
      We will remove this in later versions, once it gets smoothed out
      and has more users.
      Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a125a394
    • S
      dma-buf: Introduce dma buffer sharing mechanism · d15bd7ee
      Sumit Semwal 提交于
      This is the first step in defining a dma buffer sharing mechanism.
      
      A new buffer object dma_buf is added, with operations and API to allow easy
      sharing of this buffer object across devices.
      
      The framework allows:
      - creation of a buffer object, its association with a file pointer, and
         associated allocator-defined operations on that buffer. This operation is
         called the 'export' operation.
      - different devices to 'attach' themselves to this exported buffer object, to
        facilitate backing storage negotiation, using dma_buf_attach() API.
      - the exported buffer object to be shared with the other entity by asking for
         its 'file-descriptor (fd)', and sharing the fd across.
      - a received fd to get the buffer object back, where it can be accessed using
         the associated exporter-defined operations.
      - the exporter and user to share the scatterlist associated with this buffer
         object using map_dma_buf and unmap_dma_buf operations.
      
      Atleast one 'attach()' call is required to be made prior to calling the
      map_dma_buf() operation.
      
      Couple of building blocks in map_dma_buf() are added to ease introduction
      of sync'ing across exporter and users, and late allocation by the exporter.
      
      For this first version, this framework will work with certain conditions:
      - *ONLY* exporter will be allowed to mmap to userspace (outside of this
         framework - mmap is not a buffer object operation),
      - currently, *ONLY* users that do not need CPU access to the buffer are
         allowed.
      
      More details are there in the documentation patch.
      
      This is based on design suggestions from many people at the mini-summits[1],
      most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
      Daniel Vetter <daniel@ffwll.ch>.
      
      The implementation is inspired from proof-of-concept patch-set from
      Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
      between two v4l2 devices. [2]
      
      [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
      [2]: http://lwn.net/Articles/454389Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NDave Airlie <airlied@redhat.com>
      Reviewed-and-Tested-by: NRob Clark <rob.clark@linaro.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d15bd7ee
  18. 23 7月, 2011 1 次提交
    • M
      regmap: Add generic non-memory mapped register access API · b83a313b
      Mark Brown 提交于
      There are many places in the tree where we implement register access for
      devices on non-memory mapped buses, especially I2C and SPI. Since hardware
      designers seem to have settled on a relatively consistent set of register
      interfaces this can be effectively factored out into shared code.  There
      are a standard set of formats for marshalling data for exchange with the
      device, with the actual I/O mechanisms generally being simple byte
      streams.
      
      We create an abstraction for marshaling data into formats which can be
      sent on the control interfaces, and create a standard method for
      plugging in actual transport underneath that.
      
      This is mostly a refactoring and renaming of the bottom level of the
      existing code for sharing register I/O which we have in ASoC. A
      subsequent patch in this series converts ASoC to use this.  The main
      difference in interface is that reads return values by writing to a
      location provided by a pointer rather than in the return value, ensuring
      we can use the full range of the type for register data.  We also use
      unsigned types rather than ints for the same reason.
      
      As some of the devices can have very large register maps the existing
      ASoC code also contains infrastructure for managing register caches.
      This cache work will be moved over in a future stage to allow for
      separate review, the current patch only deals with the physical I/O.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NGrant Likely <grant.likely@secretlab.ca>
      b83a313b
  19. 02 7月, 2011 3 次提交
  20. 12 5月, 2011 1 次提交
  21. 24 3月, 2011 1 次提交
    • R
      Introduce ARCH_NO_SYSDEV_OPS config option (v2) · d47d81c0
      Rafael J. Wysocki 提交于
      Introduce Kconfig option allowing architectures where sysdev
      operations used during system suspend, resume and shutdown have been
      completely replaced with struct sycore_ops operations to avoid
      building sysdev code that will never be used.
      
      Make callbacks in struct sys_device and struct sysdev_driver depend
      on ARCH_NO_SYSDEV_OPS to allows us to verify if all of the references
      have been actually removed from the code the given architecture
      depends on.
      
      Make x86 select ARCH_NO_SYSDEV_OPS.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d47d81c0
  22. 21 1月, 2011 1 次提交
    • D
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes 提交于
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a108a14
  23. 23 10月, 2010 1 次提交
    • R
      FW_LOADER: fix kconfig dependency warning on HOTPLUG · 5fc6e9cb
      Randy Dunlap 提交于
      Fix kconfig dependency warning for FW_LOADER.
      
      Lots of drivers select FW_LOADER without bothering to depend on
      HOTPLUG and/or without selecting HOTPLUG.  A kernel builds fine
      when FW_LOADER is enabled, whether HOTPLUG is enabled or not, and
      a kernel config file (make oldconfig) is not changed by this patch.
      (Yes, drivers/base/firmware_class.c uses interfaces from linux/kobject.h,
      which does have some CONFIG_HOTPLUG dependencies, but this patch does
      not change that.)
      
      warning: (MICROCODE || MICROCODE_INTEL && MICROCODE || MICROCODE_AMD && MICROCODE || PCMCIA_LOAD_CIS && PCCARD && PCMCIA && EXPERIMENTAL || USB_IRDA && NET && IRDA && USB || BT_HCIBCM203X && NET && BT && USB || BT_HCIBFUSB && NET && BT && USB || BT_HCIBT3C && NET && BT && PCMCIA || BT_MRVL_SDIO && NET
      ...
      !STAGING_EXCLUDE_BUILD && USB && (X86 || ARM) && WLAN || DRM_NOUVEAU && STAGING && !STAGING_EXCLUDE_BUILD && DRM && PCI || TI_ST && STAGING && !STAGING_EXCLUDE_BUILD && RFKILL || DELL_RBU && X86) selects FW_LOADER which has unmet direct dependencies (HOTPLUG)
      (5200 byte line reduced a lot)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5fc6e9cb
  24. 22 5月, 2010 1 次提交
  25. 08 3月, 2010 2 次提交
  26. 16 9月, 2009 1 次提交
    • K
      Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev · 2b2af54a
      Kay Sievers 提交于
      Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
      very early at kernel initialization, before any driver-core device
      is registered. Every device with a major/minor will provide a
      device node in devtmpfs.
      
      Devtmpfs can be changed and altered by userspace at any time,
      and in any way needed - just like today's udev-mounted tmpfs.
      Unmodified udev versions will run just fine on top of it, and will
      recognize an already existing kernel-created device node and use it.
      The default node permissions are root:root 0600. Proper permissions
      and user/group ownership, meaningful symlinks, all other policy still
      needs to be applied by userspace.
      
      If a node is created by devtmps, devtmpfs will remove the device node
      when the device goes away. If the device node was created by
      userspace, or the devtmpfs created node was replaced by userspace, it
      will no longer be removed by devtmpfs.
      
      If it is requested to auto-mount it, it makes init=/bin/sh work
      without any further userspace support. /dev will be fully populated
      and dynamic, and always reflect the current device state of the kernel.
      With the commonly used dynamic device numbers, it solves the problem
      where static devices nodes may point to the wrong devices.
      
      It is intended to make the initial bootup logic simpler and more robust,
      by de-coupling the creation of the inital environment, to reliably run
      userspace processes, from a complex userspace bootstrap logic to provide
      a working /dev.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NJan Blunck <jblunck@suse.de>
      Tested-By: NHarald Hoyer <harald@redhat.com>
      Tested-By: NScott James Remnant <scott@ubuntu.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2b2af54a
  27. 06 1月, 2009 1 次提交
  28. 17 10月, 2008 1 次提交
  29. 22 7月, 2008 1 次提交
    • A
      always enable FW_LOADER unless EMBEDDED=y · d9b19199
      Adrian Bunk 提交于
      James Bottomley recently discovered that we have
      {request,release}_firmware() dummies for the case of the actual
      functions not being available and has a fix for the bug that was
      actually causing build errors for built-in users with
      CONFIG_FW_LOADER=m.
      
      But now missing selects on FW_LOADER are no longer visible at
      compile-time at all and can become runtime problems.
      
      FW_LOADER is infrastructure with relatively small codesize we can safely
      enable for everyone, and only for people who really need small kernels
      (and can be expected to know what they are doing) it matters being able
      to disable it.
      
      This patch therefore always sets FW_LOADER=y and allows users only to
      disable it with EMBEDDED=y.
      
      As a bonus, we can then get rid of all "select FW_LOADER" plus the due
      to it required "depends on HOTPLUG" which removes some complexity from
      our Kconfig files.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d9b19199
  30. 10 7月, 2008 2 次提交
  31. 13 10月, 2007 1 次提交
  32. 10 2月, 2007 1 次提交
    • T
      devres: device resource management · 9ac7849e
      Tejun Heo 提交于
      Implement device resource management, in short, devres.  A device
      driver can allocate arbirary size of devres data which is associated
      with a release function.  On driver detach, release function is
      invoked on the devres data, then, devres data is freed.
      
      devreses are typed by associated release functions.  Some devreses are
      better represented by single instance of the type while others need
      multiple instances sharing the same release function.  Both usages are
      supported.
      
      devreses can be grouped using devres group such that a device driver
      can easily release acquired resources halfway through initialization
      or selectively release resources (e.g. resources for port 1 out of 4
      ports).
      
      This patch adds devres core including documentation and the following
      managed interfaces.
      
      * alloc/free	: devm_kzalloc(), devm_kzfree()
      * IO region	: devm_request_region(), devm_release_region()
      * IRQ		: devm_request_irq(), devm_free_irq()
      * DMA		: dmam_alloc_coherent(), dmam_free_coherent(),
      		  dmam_declare_coherent_memory(), dmam_pool_create(),
      		  dmam_pool_destroy()
      * PCI		: pcim_enable_device(), pcim_pin_device(), pci_is_managed()
      * iomap		: devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
      		  devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
      		  pcim_iomap(), pcim_iounmap()
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      9ac7849e
  33. 29 10月, 2006 1 次提交