2005-04-17 02:20:36 +04:00
menu "Device Drivers"
source "drivers/base/Kconfig"
2012-08-22 12:40:02 +04:00
source "drivers/bus/Kconfig"
2005-09-12 06:15:07 +04:00
source "drivers/connector/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/mtd/Kconfig"
2007-05-01 10:40:36 +04:00
source "drivers/of/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/parport/Kconfig"
source "drivers/pnp/Kconfig"
source "drivers/block/Kconfig"
2006-10-17 11:09:25 +04:00
# misc before ide - BLK_DEV_SGIIOC4 depends on SGI_IOC4
source "drivers/misc/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/ide/Kconfig"
source "drivers/scsi/Kconfig"
2006-08-10 15:31:37 +04:00
source "drivers/ata/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/md/Kconfig"
[SCSI] target: Add LIO target core v4.0.0-rc6
LIO target is a full featured in-kernel target framework with the
following feature set:
High-performance, non-blocking, multithreaded architecture with SIMD
support.
Advanced SCSI feature set:
* Persistent Reservations (PRs)
* Asymmetric Logical Unit Assignment (ALUA)
* Protocol and intra-nexus multiplexing, load-balancing and failover (MC/S)
* Full Error Recovery (ERL=0,1,2)
* Active/active task migration and session continuation (ERL=2)
* Thin LUN provisioning (UNMAP and WRITE_SAMExx)
Multiprotocol target plugins
Storage media independence:
* Virtualization of all storage media; transparent mapping of IO to LUNs
* No hard limits on number of LUNs per Target; maximum LUN size ~750 TB
* Backstores: SATA, SAS, SCSI, BluRay, DVD, FLASH, USB, ramdisk, etc.
Standards compliance:
* Full compliance with IETF (RFC 3720)
* Full implementation of SPC-4 PRs and ALUA
Significant code cleanups done by Christoph Hellwig.
[jejb: fix up for new block bdev exclusive interface. Minor fixes from
Randy Dunlap and Dan Carpenter.]
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2010-12-17 22:11:26 +03:00
source "drivers/target/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/message/fusion/Kconfig"
2009-12-26 03:36:53 +03:00
source "drivers/firewire/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/message/i2o/Kconfig"
source "drivers/macintosh/Kconfig"
2005-07-12 08:03:49 +04:00
source "drivers/net/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/isdn/Kconfig"
# input before char - char/joystick depends on it. As does USB.
source "drivers/input/Kconfig"
source "drivers/char/Kconfig"
source "drivers/i2c/Kconfig"
[PATCH] spi: simple SPI framework
This is the core of a small SPI framework, implementing the model of a
queue of messages which complete asynchronously (with thin synchronous
wrappers on top).
- It's still less than 2KB of ".text" (ARM). If there's got to be a
mid-layer for something so simple, that's the right size budget. :)
- The guts use board-specific SPI device tables to build the driver
model tree. (Hardware probing is rarely an option.)
- This version of Kconfig includes no drivers. At this writing there
are two known master controller drivers (PXA/SSP, OMAP MicroWire)
and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML
mentions of other drivers in development.
- No userspace API. There are several implementations to compare.
Implement them like any other driver, and bind them with sysfs.
The changes from last version posted to LKML (on 11-Nov-2005) are minor,
and include:
- One bugfix (removes a FIXME), with the visible effect of making device
names be "spiB.C" where B is the bus number and C is the chipselect.
- The "caller provides DMA mappings" mechanism now has kerneldoc, for
DMA drivers that want to be fancy.
- Hey, the framework init can be subsys_init. Even though board init
logic fires earlier, at arch_init ... since the framework init is
for driver support, and the board init support uses static init.
- Various additional spec/doc clarifications based on discussions
with other folk. It adds a brief "thank you" at the end, for folk
who've helped nudge this framework into existence.
As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.
From: Mark Underwood <basicmark@yahoo.com>
Update the SPI framework to remove a potential priority inversion case by
reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-09 00:34:19 +03:00
source "drivers/spi/Kconfig"
2014-02-12 23:44:22 +04:00
source "drivers/spmi/Kconfig"
2010-04-16 20:01:02 +04:00
source "drivers/hsi/Kconfig"
2009-06-18 03:28:37 +04:00
source "drivers/pps/Kconfig"
2011-04-22 14:03:08 +04:00
source "drivers/ptp/Kconfig"
drivers: create a pin control subsystem
This creates a subsystem for handling of pin control devices.
These are devices that control different aspects of package
pins.
Currently it handles pinmuxing, i.e. assigning electronic
functions to groups of pins on primarily PGA and BGA type of
chip packages which are common in embedded systems.
The plan is to also handle other I/O pin control aspects
such as biasing, driving, input properties such as
schmitt-triggering, load capacitance etc within this
subsystem, to remove a lot of ARM arch code as well as
feature-creepy GPIO drivers which are implementing the same
thing over and over again.
This is being done to depopulate the arch/arm/* directory
of such custom drivers and try to abstract the infrastructure
they all need. See the Documentation/pinctrl.txt file that is
part of this patch for more details.
ChangeLog v1->v2:
- Various minor fixes from Joe's and Stephens review comments
- Added a pinmux_config() that can invoke custom configuration
with arbitrary data passed in or out to/from the pinmux driver
ChangeLog v2->v3:
- Renamed subsystem folder to "pinctrl" since we will likely
want to keep other pin control such as biasing in this
subsystem too, so let us keep to something generic even though
we're mainly doing pinmux now.
- As a consequence, register pins as an abstract entity separate
from the pinmux. The muxing functions will claim pins out of the
pin pool and make sure they do not collide. Pins can now be
named by the pinctrl core.
- Converted the pin lookup from a static array into a radix tree,
I agreed with Grant Likely to try to avoid any static allocation
(which is crap for device tree stuff) so I just rewrote this
to be dynamic, just like irq number descriptors. The
platform-wide definition of number of pins goes away - this is
now just the sum total of the pins registered to the subsystem.
- Make sure mappings with only a function name and no device
works properly.
ChangeLog v3->v4:
- Define a number space per controller instead of globally,
Stephen and Grant requested the same thing so now maps need to
define target controller, and the radix tree of pin descriptors
is a property on each pin controller device.
- Add a compulsory pinctrl device entry to the pinctrl mapping
table. This must match the pinctrl device, like "pinctrl.0"
- Split the file core.c in two: core.c and pinmux.c where the
latter carry all pinmux stuff, the core is for generic pin
control, and use local headers to access functionality between
files. It is now possible to implement a "blank" pin controller
without pinmux capabilities. This split will make new additions
like pindrive.c, pinbias.c etc possible for combined drivers
and chunks of functionality which is a GoodThing(TM).
- Rewrite the interaction with the GPIO subsystem - the pin
controller descriptor now handles this by defining an offset
into the GPIO numberspace for its handled pin range. This is
used to look up the apropriate pin controller for a GPIO pin.
Then that specific GPIO range is matched 1-1 for the target
controller instance.
- Fixed a number of review comments from Joe Perches.
- Broke out a header file pinctrl.h for the core pin handling
stuff that will be reused by other stuff than pinmux.
- Fixed some erroneous EXPORT() stuff.
- Remove mispatched U300 Kconfig and Makefile entries
- Fixed a number of review comments from Stephen Warren, not all
of them - still WIP. But I think the new mapping that will
specify which function goes to which pin mux controller address
50% of your concerns (else beat me up).
ChangeLog v4->v5:
- Defined a "position" for each function, so the pin controller now
tracks a function in a certain position, and the pinmux maps define
what position you want the function in. (Feedback from Stephen
Warren and Sascha Hauer).
- Since we now need to request a combined function+position from
the machine mapping table that connect mux settings to drivers,
it was extended with a position field and a name field. The
name field is now used if you e.g. need to switch between two
mux map settings at runtime.
- Switched from a class device to using struct bus_type for this
subsystem. Verified sysfs functionality: seems to work fine.
(Feedback from Arnd Bergmann and Greg Kroah-Hartman)
- Define a per pincontroller list of GPIO ranges from the GPIO
pin space that can be handled by the pin controller. These can
be added one by one at runtime. (Feedback from Barry Song)
- Expanded documentation of regulator_[get|enable|disable|put]
semantics.
- Fixed a number of review comments from Barry Song. (Thanks!)
ChangeLog v5->v6:
- Create an abstract pin group concept that can sort pins into
named and enumerated groups no matter what the use of these
groups may be, one possible usecase is a group of pins being
muxed in or so. The intention is however to also use these
groups for other pin control activities.
- Make it compulsory for pinmux functions to associate with
at least one group, so the abstract pin group concept is used
to define the groups of pins affected by a pinmux function.
The pinmux driver interface has been altered so as to enforce
a function to list applicable groups per function.
- Provide an optional .group entry in the pinmux machine map
so the map can select beteween different available groups
to be used with a certain function.
- Consequent changes all over the place so that e.g. debugfs
present reasonable information about the world.
- Drop the per-pin mux (*config) function in the pinmux_ops
struct - I was afraid that this would start to be used for
things totally unrelated to muxing, we can introduce that to
the generic struct pinctrl_ops if needed. I want to keep
muxing orthogonal to other pin control subjects and not mix
these things up.
ChangeLog v6->v7:
- Make it possible to have several map entries matching the
same device, pin controller and function, but using
a different group, and alter the semantics so that
pinmux_get() will pick all matching map entries, and
store the associated groups in a list. The list will
then be iterated over at pinmux_enable()/pinmux_disable()
and corresponding driver functions called for each
defined group. Notice that you're only allowed to map
multiple *groups* to the same
{ device, pin controller, function } triplet, attempts
to map the same device to multiple pin controllers will
for example fail. This is hopefully the crucial feature
requested by Stephen Warren.
- Add a pinmux hogging field to the pinmux mapping entries,
and enable the pinmux core to hog pinmux map entries.
This currently only works for pinmuxes without assigned
devices as it looks now, but with device trees we can
look up the corresponding struct device * entries when
we register the pinmux driver, and have it hog each
pinmux map in turn, for a simple approach to
non-dynamic pin muxing. This addresses an issue from
Grant Likely that the machine should take care of as
much of the pinmux setup as possible, not the devices.
By supplying a list of hogs, it can now instruct the
core to take care of any static mappings.
- Switch pinmux group retrieveal function to grab an
array of strings representing the groups rather than an
array of unsigned and rewrite accordingly.
- Alter debugfs to show the grouplist handled by each
pinmux. Also add a list of hogs.
- Dynamically allocate a struct pinmux at pinmux_get() and
free it at pinmux_put(), then add these to the global
list of pinmuxes active as we go along.
- Go over the list of pinmux maps at pinmux_get() time
and repeatedly apply matches.
- Retrieve applicable groups per function from the driver
as a string array rather than a unsigned array, then
lookup the enumerators.
- Make the device to pinmux map a singleton - only allow the
mapping table to be registered once and even tag the
registration function with __init so it surely won't be
abused.
- Create a separate debugfs file to view the pinmux map at
runtime.
- Introduce a spin lock to the pin descriptor struct, lock it
when modifying pin status entries. Reported by Stijn Devriendt.
- Fix up the documentation after review from Stephen Warren.
- Let the GPIO ranges give names as const char * instead of some
fixed-length string.
- add a function to unregister GPIO ranges to mirror the
registration function.
- Privatized the struct pinctrl_device and removed it from the
<linux/pinctrl/pinctrl.h> API, the drivers do not need to know
the members of this struct. It is now in the local header
"core.h".
- Rename the concept of "anonymous" mux maps to "system" muxes
and add convenience macros and documentation.
ChangeLog v7->v8:
- Delete the leftover pinmux_config() function from the
<linux/pinctrl/pinmux.h> header.
- Fix a race condition found by Stijn Devriendt in pin_request()
ChangeLog v8->v9:
- Drop the bus_type and the sysfs attributes and all, we're not on
the clear about how this should be used for e.g. userspace
interfaces so let us save this for the future.
- Use the right name in MAINTAINERS, PIN CONTROL rather than
PINMUX
- Don't kfree() the device state holder, let the .remove() callback
handle this.
- Fix up numerous kerneldoc headers to have one line for the function
description and more verbose documentation below the parameters
ChangeLog v9->v10:
- pinctrl: EXPORT_SYMBOL needs export.h, folded in a patch
from Steven Rothwell
- fix pinctrl_register error handling, folded in a patch from
Axel Lin
- Various fixes to documentation text so that it's consistent.
- Removed pointless comment from drivers/Kconfig
- Removed dependency on SYSFS since we removed the bus in
v9.
- Renamed hopelessly abbreviated pctldev_* functions to the
more verbose pinctrl_dev_*
- Drop mutex properly when looking up GPIO ranges
- Return NULL instead of ERR_PTR() errors on registration of
pin controllers, using cast pointers is fragile. We can
live without the detailed error codes for sure.
Cc: Stijn Devriendt <highguy@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-02 22:50:54 +04:00
source "drivers/pinctrl/Kconfig"
2008-02-05 09:28:17 +03:00
source "drivers/gpio/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/w1/Kconfig"
2007-05-04 00:27:45 +04:00
source "drivers/power/Kconfig"
2005-07-02 20:15:49 +04:00
source "drivers/hwmon/Kconfig"
2008-01-17 10:51:08 +03:00
source "drivers/thermal/Kconfig"
2007-08-17 12:38:02 +04:00
source "drivers/watchdog/Kconfig"
2007-09-18 23:12:50 +04:00
source "drivers/ssb/Kconfig"
2011-05-09 20:56:46 +04:00
source "drivers/bcma/Kconfig"
2005-08-18 13:06:59 +04:00
source "drivers/mfd/Kconfig"
2008-10-15 14:53:34 +04:00
source "drivers/regulator/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/media/Kconfig"
source "drivers/video/Kconfig"
source "sound/Kconfig"
2006-12-08 20:41:30 +03:00
source "drivers/hid/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/usb/Kconfig"
2008-09-17 19:34:11 +04:00
source "drivers/uwb/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/mmc/Kconfig"
2008-02-09 21:20:54 +03:00
source "drivers/memstick/Kconfig"
2006-03-31 14:31:04 +04:00
source "drivers/leds/Kconfig"
2008-04-30 11:54:51 +04:00
source "drivers/accessibility/Kconfig"
2005-04-17 02:20:36 +04:00
source "drivers/infiniband/Kconfig"
2006-01-19 04:44:13 +03:00
source "drivers/edac/Kconfig"
2006-03-27 13:16:34 +04:00
source "drivers/rtc/Kconfig"
2006-05-24 04:18:44 +04:00
source "drivers/dma/Kconfig"
2007-10-16 12:27:41 +04:00
source "drivers/dca/Kconfig"
2007-02-10 12:44:32 +03:00
source "drivers/auxdisplay/Kconfig"
2006-12-07 12:58:29 +03:00
source "drivers/uio/Kconfig"
2008-04-02 21:54:13 +04:00
2012-07-31 18:16:22 +04:00
source "drivers/vfio/Kconfig"
2009-06-17 02:33:53 +04:00
source "drivers/vlynq/Kconfig"
2013-05-01 02:28:44 +04:00
source "drivers/virt/Kconfig"
2011-07-05 18:06:14 +04:00
source "drivers/virtio/Kconfig"
2011-11-18 21:41:42 +04:00
source "drivers/hv/Kconfig"
2008-04-02 21:54:13 +04:00
source "drivers/xen/Kconfig"
2008-09-25 01:46:44 +04:00
source "drivers/staging/Kconfig"
2008-12-01 08:09:47 +03:00
source "drivers/platform/Kconfig"
2010-11-17 12:04:33 +03:00
source "drivers/clk/Kconfig"
2011-02-17 20:52:03 +03:00
source "drivers/hwspinlock/Kconfig"
2011-05-08 21:47:58 +04:00
source "drivers/clocksource/Kconfig"
2013-01-28 20:13:14 +04:00
source "drivers/mailbox/Kconfig"
2011-06-02 03:48:05 +04:00
source "drivers/iommu/Kconfig"
2011-10-20 18:52:46 +04:00
source "drivers/remoteproc/Kconfig"
2011-10-20 23:10:55 +04:00
source "drivers/rpmsg/Kconfig"
PM: Introduce devfreq: generic DVFS framework with device-specific OPPs
With OPPs, a device may have multiple operable frequency and voltage
sets. However, there can be multiple possible operable sets and a system
will need to choose one from them. In order to reduce the power
consumption (by reducing frequency and voltage) without affecting the
performance too much, a Dynamic Voltage and Frequency Scaling (DVFS)
scheme may be used.
This patch introduces the DVFS capability to non-CPU devices with OPPs.
DVFS is a techique whereby the frequency and supplied voltage of a
device is adjusted on-the-fly. DVFS usually sets the frequency as low
as possible with given conditions (such as QoS assurance) and adjusts
voltage according to the chosen frequency in order to reduce power
consumption and heat dissipation.
The generic DVFS for devices, devfreq, may appear quite similar with
/drivers/cpufreq. However, cpufreq does not allow to have multiple
devices registered and is not suitable to have multiple heterogenous
devices with different (but simple) governors.
Normally, DVFS mechanism controls frequency based on the demand for
the device, and then, chooses voltage based on the chosen frequency.
devfreq also controls the frequency based on the governor's frequency
recommendation and let OPP pick up the pair of frequency and voltage
based on the recommended frequency. Then, the chosen OPP is passed to
device driver's "target" callback.
When PM QoS is going to be used with the devfreq device, the device
driver should enable OPPs that are appropriate with the current PM QoS
requests. In order to do so, the device driver may call opp_enable and
opp_disable at the notifier callback of PM QoS so that PM QoS's
update_target() call enables the appropriate OPPs. Note that at least
one of OPPs should be enabled at any time; be careful when there is a
transition.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Mike Turquette <mturquette@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-10-02 02:19:15 +04:00
source "drivers/devfreq/Kconfig"
2012-04-20 09:16:22 +04:00
source "drivers/extcon/Kconfig"
2012-04-27 16:24:05 +04:00
source "drivers/memory/Kconfig"
2012-04-25 18:54:59 +04:00
source "drivers/iio/Kconfig"
PCI-Express Non-Transparent Bridge Support
A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
connecting 2 systems, providing electrical isolation between the two subsystems.
A non-transparent bridge is functionally similar to a transparent bridge except
that both sides of the bridge have their own independent address domains. The
host on one side of the bridge will not have the visibility of the complete
memory or I/O space on the other side of the bridge. To communicate across the
non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
the local system. Writes to these apertures are mirrored to memory on the
remote system. Communications can also occur through the use of doorbell
registers that initiate interrupts to the alternate domain, and scratch-pad
registers accessible from both sides.
The NTB device driver is needed to configure these memory windows, doorbell, and
scratch-pad registers as well as use them in such a way as they can be turned
into a viable communication channel to the remote system. ntb_hw.[ch]
determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
the underlying hardware to provide access and a common interface to the doorbell
registers, scratch pads, and memory windows. These hardware interfaces are
exported so that other, non-mainlined kernel drivers can access these.
ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
communication channel(s) and provide a reliable way of transferring data from
one side to the other, which it then exports so that "client" drivers can access
them. These client drivers are used to provide a standard kernel interface
(i.e., Ethernet device) to NTB, such that Linux can transfer data from one
system to the other in a standard way.
Signed-off-by: Jon Mason <jon.mason@intel.com>
Reviewed-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-11-17 06:27:12 +04:00
source "drivers/ntb/Kconfig"
2012-04-26 23:34:58 +04:00
source "drivers/vme/Kconfig"
2011-01-28 11:40:40 +03:00
source "drivers/pwm/Kconfig"
ARM: bcm2835: add interrupt controller driver
The BCM2835 contains a custom interrupt controller, which supports 72
interrupt sources using a 2-level register scheme. The interrupt
controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence the symbol naming in the
code.
This patch was extracted from git://github.com/lp0/linux.git branch
rpi-split as of 2012/09/08, and modified as follows:
* s/bcm2708/bcm2835/.
* Modified device tree vendor prefix.
* Moved implementation to drivers/irchip/.
* Added devicetree documentation, and hence removed list of IRQs from
bcm2835.dtsi.
* Changed shift in MAKE_HWIRQ() and HWIRQ_BANK() from 8 to 5 to reduce
the size of the hwirq space, and pass the total size of the hwirq space
to irq_domain_add_linear(), rather than just the number of valid hwirqs;
the two are different due to the hwirq space being sparse.
* Added the interrupt controller DT node to the top-level of the DT,
rather than nesting it inside a /axi node. Hence, changed the reg value
since /axi had a ranges property. This seems simpler to me, but I'm not
sure if everyone will like this change or not.
* Don't set struct irq_domain_ops.map = irq_domain_simple_map, hence
removing the need to patch include/linux/irqdomain.h or
kernel/irq/irqdomain.c.
* Simplified armctrl_of_init() using of_iomap().
* Removed unused IS_VALID_BANK()/IS_VALID_IRQ() macros.
* Renamed armctrl_handle_irq() to prevent possible symbol clashes.
* Made armctrl_of_init() static.
* Removed comment "Each bank is registered as a separate interrupt
controller" since this is no longer true.
* Removed FSF address from license header.
* Added my name to copyright header.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Signed-off-by: Dom Cobley <dc4@broadcom.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
2012-09-13 05:57:26 +04:00
source "drivers/irqchip/Kconfig"
2012-11-16 20:14:18 +04:00
source "drivers/ipack/Kconfig"
2012-11-19 20:23:13 +04:00
source "drivers/reset/Kconfig"
2013-06-12 11:13:25 +04:00
source "drivers/fmc/Kconfig"
2013-09-27 10:23:25 +04:00
source "drivers/phy/Kconfig"
2013-10-12 03:54:57 +04:00
source "drivers/powercap/Kconfig"
2005-04-17 02:20:36 +04:00
endmenu
