summaryrefslogtreecommitdiff
path: root/Documentation/acpi/enumeration.txt
AgeCommit message (Collapse)Author
2017-03-17Documentation: acpi: Fix typosTamara Diaconita
Fix typos in acpi directory to make documentation grammatically correct. Signed-off-by: Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2016-12-06ACPI / property: Document usage rules for _DSD propertiesRafael J. Wysocki
Following some discussions during the Kernel Summit and LPC, document what can be returned from ACPI _DSD as device properties and when it is valid to use the special PRP0001 device ID. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviwed-by: Mark Brown <broonie@kernel.org>
2015-10-26mfd: core: redo ACPI matching of the children devicesAndy Shevchenko
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses _ADR to distinguish the devices under one actual device. Due to this we have to improve the quirk in the MFD core to handle that board. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2015-06-19ACPI: Constify ACPI device IDs in documentationMathias Krause
ACPI device ID arrays normally don't need to be written to as they're only ever read. The common usage -- embedding pointers to acpi_device_id arrays in other data structures -- reference them as 'const', e.g. as in struct acpi_driver / acpi_scan_handler / device_driver. The matchers are taking const pointers, too. So it's only natural, to propose using const arrays. Change the documentation accordingly. Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-19ACPI / enumeration: Document the rules regarding the PRP0001 device IDRafael J. Wysocki
Document how the ACPI device enumeration code uses the special PRP0001 device ID. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Darren Hart <dvhart@linux.intel.com>
2015-04-30ACPI / documentation: fix a sentence about GPIO resourcesAntonio Ospite
The sentence "These resources are used be used to pass ..." contains a suspicious repetition, likely the author meant "These resources can be used to pass ...". Simplify the wording. Signed-off-by: Antonio Ospite <ao2@ao2.it> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-18ACPI: Update GPIO documentation to mention _DSDMika Westerberg
Make sure that the ACPI enumeration.txt provides latest information on how to describe and retrieve GPIOs now that we can take advantage of _DSD device properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-22ACPI / Documentation: add a missing '='Yaowei Bai
Signed-off-by: Yaowei Bai <bywxiaobai@163.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-26mfd: Add ACPI supportMika Westerberg
If an MFD device is backed by ACPI namespace, we should allow subdevice drivers to access their corresponding ACPI companion devices through normal means (e.g using ACPI_COMPANION()). This patch adds such support to the MFD core. If the MFD parent device does not specify any ACPI _HID/_CID for the child device, the child device will share the parent ACPI companion device. Otherwise the child device will be assigned with the corresponding ACPI companion, if found in the namespace below the parent. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-07-12ACPI / documentation: Remove reference to acpi_platform_device_ids from ↵Darren Hart
enumeration.txt As of: 4845934 ACPI / scan: use platform bus type by default for _HID enumeration ACPI uses the platform bus by default, changing the opt-in to an opt-out policy, eliminating the acpi_platform_device_ids table and replacing it with forbidden_id_list[]. Remove the qualifying paragraph from the acpi/enumeration documentation as it no longer applies. Reported-by: Max Eliaser <max@meliaserlow.dyndns.tv> Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-23Documentation / ACPI: Fix location of GPIO documentationJarkko Nikula
Commit fd8e198cfcaa ("Documentation: gpiolib: document new interface") moved Documentation/gpio.txt to Documentation/gpio/gpio-legacy.txt and added new documents for descriptor-based interface so fix the the location here to point Documentation/gpio/ since that what commit ccb6fbb99020 ("Documentation / ACPI: update to GPIO descriptor API") was looking for. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-01-08Documentation / ACPI: update to GPIO descriptor APIMika Westerberg
Update the documentation also to reflect the fact that there are no ACPI specific GPIO interfaces anymore but drivers should instead use the descriptor based GPIO APIs. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-10-19gpiolib / ACPI: document the GPIO descriptor based interfaceMika Westerberg
In addition to the existing ACPI specific GPIO interface, document the new descriptor based GPIO interface in Documentation/acpi/enumeration.txt, so it is clear that this new interface is preferred over the ACPI specific version. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-09-06Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial tree from Jiri Kosina: "The usual trivial updates all over the tree -- mostly typo fixes and documentation updates" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (52 commits) doc: Documentation/cputopology.txt fix typo treewide: Convert retrun typos to return Fix comment typo for init_cma_reserved_pageblock Documentation/trace: Correcting and extending tracepoint documentation mm/hotplug: fix a typo in Documentation/memory-hotplug.txt power: Documentation: Update s2ram link doc: fix a typo in Documentation/00-INDEX Documentation/printk-formats.txt: No casts needed for u64/s64 doc: Fix typo "is is" in Documentations treewide: Fix printks with 0x%# zram: doc fixes Documentation/kmemcheck: update kmemcheck documentation doc: documentation/hwspinlock.txt fix typo PM / Hibernate: add section for resume options doc: filesystems : Fix typo in Documentations/filesystems scsi/megaraid fixed several typos in comments ppc: init_32: Fix error typo "CONFIG_START_KERNEL" treewide: Add __GFP_NOWARN to k.alloc calls with v.alloc fallbacks page_isolation: Fix a comment typo in test_pages_isolated() doc: fix a typo about irq affinity ...
2013-08-23i2c: move ACPI helpers into the coreMika Westerberg
This follows what has already been done for the DeviceTree helpers. Move the ACPI helpers from drivers/acpi/acpi_i2c.c to the I2C core and update documentation accordingly. This also solves a problem reported by Jerry Snitselaar that we can't build the ACPI I2C helpers as a module. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-23i2c: move OF helpers into the coreWolfram Sang
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-08-20Documentation/acpi/enumeration.txt fix a typoStefan Huber
Corrected the word configation to configuration. Signed-off-by: Stefan Huber <steffhip@gmail.com> Signed-off-by: Matthias Schid <aircrach115@gmail.com> Signed-off-by: Simon Puels <simon.puels@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-09Merge branch 'for-linus' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds
Pull slave-dmaengine updates from Vinod Koul: "This time we have dmatest improvements from Andy along with dw_dmac fixes. He has also done support for acpi for dmanegine. Also we have bunch of fixes going in DT support for dmanegine for various folks. Then Haswell and other ioat changes from Dave and SUDMAC support from Shimoda." * 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (53 commits) dma: tegra: implement suspend/resume callbacks dma:of: Use a mutex to protect the of_dma_list dma: of: Fix of_node reference leak dmaengine: sirf: move driver init from module_init to subsys_initcall sudmac: add support for SUDMAC dma: sh: add Kconfig at_hdmac: move to generic DMA binding ioatdma: ioat3_alloc_sed can be static ioatdma: Adding write back descriptor error status support for ioatdma 3.3 ioatdma: S1200 platforms ioatdma channel 2 and 3 falsely advertise RAID cap ioatdma: Adding support for 16 src PQ ops and super extended descriptors ioatdma: Removing hw bug workaround for CB3.x .2 and earlier dw_dmac: add ACPI support dmaengine: call acpi_dma_request_slave_channel as well dma: acpi-dma: introduce ACPI DMA helpers dma: of: Remove unnecessary list_empty check DMA: OF: Check properties value before running be32_to_cpup() on it DMA: of: Constant names ioatdma: skip silicon bug workaround for pq_align for cb3.3 ioatdma: Removing PQ val disable for cb3.3 ...
2013-04-15dma: acpi-dma: introduce ACPI DMA helpersAndy Shevchenko
There is a new generic API to get a DMA channel for a slave device (commit 9a6cecc8 "dmaengine: add helper function to request a slave DMA channel"). In similar fashion to the DT case (commit aa3da644 "of: Add generic device tree DMA helpers") we introduce helpers to the DMAC drivers which are enumerated by ACPI. The proposed extension provides the following API calls: acpi_dma_controller_register(), devm_acpi_dma_controller_register() acpi_dma_controller_free(), devm_acpi_dma_controller_free() acpi_dma_simple_xlate() acpi_dma_request_slave_chan_by_index() acpi_dma_request_slave_chan_by_name() The first two should be used, for example, at probe() and remove() of the corresponding DMAC driver. At the register stage the DMAC driver supplies a custom xlate() function to translate a struct dma_spec into struct dma_chan. Accordingly to the ACPI Fixed DMA resource specification the only two pieces of information the slave device has are the channel id and the request line (slave id). Those two are represented by struct dma_spec. The acpi_dma_request_slave_chan_by_index() provides access to the specifix FixedDMA resource by its index. Whereas dma_request_slave_channel() takes a string parameter to identify the DMA resources required by the slave device. To make a slave device driver work with both DeviceTree and ACPI enumeration a simple convention is established: "tx" corresponds to the index 0 and "rx" to the index 1. In case of robust configuration the slave device driver unfortunately needs to call acpi_dma_request_slave_chan_by_index() directly. Additionally the patch provides "managed" version of the register/free pair i.e. devm_acpi_dma_controller_register() and devm_acpi_dma_controller_free(). Usually, the driver uses only devm_acpi_dma_controller_register(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2013-04-12gpiolib-acpi: introduce acpi_get_gpio_by_index() helperMika Westerberg
Instead of open-coding ACPI GPIO resource lookup in each driver, we provide a helper function analogous to Device Tree version that allows drivers to specify which GPIO resource they are interested (using an index to the GPIO resources). The function then finds out the correct resource, translates the ACPI GPIO number to the corresponding Linux GPIO number and returns that. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-02-13ACPI / Documentation: refer to correct file for acpi_platform_device_ids[] tableMika Westerberg
When the ACPI platform device code was converted to the new ACPI scan handler facility, the the acpi_platform_device_ids[] was moved to drivers/acpi/acpi_platform.c. Update the documentation accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-03Documentation: remove __dev* attributes.Greg Kroah-Hartman
CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from the kernel documentation. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-12-07ACPI: add documentation about ACPI 5 enumerationMika Westerberg
Add a document that describes how to take advantage of ACPI enumeration for buses like platform, I2C and SPI. In addition to that we document how to translate ACPI GpioIo and GpioInt resources to be useful in Linux device drivers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>