[PATCH v4 03/63] Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST
Mauro Carvalho Chehab
mchehab+samsung at kernel.org
Wed Apr 24 06:42:23 AEST 2019
Em Wed, 24 Apr 2019 00:28:32 +0800
Changbin Du <changbin.du at gmail.com> escreveu:
> This converts the plain text documentation to reStructuredText format and
> add it to Sphinx TOC tree. No essential content change.
Just looking at the conversion itself, it looks good to me.
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung at kernel.org>
>
> Signed-off-by: Changbin Du <changbin.du at gmail.com>
> ---
> .../acpi/enumeration.rst} | 135 ++++++++++--------
> Documentation/firmware-guide/acpi/index.rst | 1 +
> 2 files changed, 74 insertions(+), 62 deletions(-)
> rename Documentation/{acpi/enumeration.txt => firmware-guide/acpi/enumeration.rst} (87%)
>
> diff --git a/Documentation/acpi/enumeration.txt b/Documentation/firmware-guide/acpi/enumeration.rst
> similarity index 87%
> rename from Documentation/acpi/enumeration.txt
> rename to Documentation/firmware-guide/acpi/enumeration.rst
> index 7bcf9c3d9fbe..ce755e963714 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/firmware-guide/acpi/enumeration.rst
> @@ -1,5 +1,9 @@
> -ACPI based device enumeration
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============================
> +ACPI Based Device Enumeration
> +=============================
> +
> ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus,
> SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave
> devices behind serial bus controllers.
> @@ -11,12 +15,12 @@ that are accessed through memory-mapped registers.
> In order to support this and re-use the existing drivers as much as
> possible we decided to do following:
>
> - o Devices that have no bus connector resource are represented as
> - platform devices.
> + - Devices that have no bus connector resource are represented as
> + platform devices.
>
> - o Devices behind real busses where there is a connector resource
> - are represented as struct spi_device or struct i2c_device
> - (standard UARTs are not busses so there is no struct uart_device).
> + - Devices behind real busses where there is a connector resource
> + are represented as struct spi_device or struct i2c_device
> + (standard UARTs are not busses so there is no struct uart_device).
>
> As both ACPI and Device Tree represent a tree of devices (and their
> resources) this implementation follows the Device Tree way as much as
> @@ -31,7 +35,8 @@ enumerated from ACPI namespace. This handle can be used to extract other
> device-specific configuration. There is an example of this below.
>
> Platform bus support
> -~~~~~~~~~~~~~~~~~~~~
> +====================
> +
> Since we are using platform devices to represent devices that are not
> connected to any physical bus we only need to implement a platform driver
> for the device and add supported ACPI IDs. If this same IP-block is used on
> @@ -39,7 +44,7 @@ some other non-ACPI platform, the driver might work out of the box or needs
> some minor changes.
>
> Adding ACPI support for an existing driver should be pretty
> -straightforward. Here is the simplest example:
> +straightforward. Here is the simplest example::
>
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id mydrv_acpi_match[] = {
> @@ -61,12 +66,13 @@ configuring GPIOs it can get its ACPI handle and extract this information
> from ACPI tables.
>
> DMA support
> -~~~~~~~~~~~
> +===========
> +
> DMA controllers enumerated via ACPI should be registered in the system to
> provide generic access to their resources. For example, a driver that would
> like to be accessible to slave devices via generic API call
> dma_request_slave_channel() must register itself at the end of the probe
> -function like this:
> +function like this::
>
> err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
> /* Handle the error if it's not a case of !CONFIG_ACPI */
> @@ -74,7 +80,7 @@ function like this:
> and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
> is enough) which converts the FixedDMA resource provided by struct
> acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
> -could look like:
> +could look like::
>
> #ifdef CONFIG_ACPI
> struct filter_args {
> @@ -114,7 +120,7 @@ provided by struct acpi_dma.
> Clients must call dma_request_slave_channel() with the string parameter that
> corresponds to a specific FixedDMA resource. By default "tx" means the first
> entry of the FixedDMA resource array, "rx" means the second entry. The table
> -below shows a layout:
> +below shows a layout::
>
> Device (I2C0)
> {
> @@ -138,12 +144,13 @@ acpi_dma_request_slave_chan_by_index() directly and therefore choose the
> specific FixedDMA resource by its index.
>
> SPI serial bus support
> -~~~~~~~~~~~~~~~~~~~~~~
> +======================
> +
> Slave devices behind SPI bus have SpiSerialBus resource attached to them.
> This is extracted automatically by the SPI core and the slave devices are
> enumerated once spi_register_master() is called by the bus driver.
>
> -Here is what the ACPI namespace for a SPI slave might look like:
> +Here is what the ACPI namespace for a SPI slave might look like::
>
> Device (EEP0)
> {
> @@ -163,7 +170,7 @@ Here is what the ACPI namespace for a SPI slave might look like:
>
> The SPI device drivers only need to add ACPI IDs in a similar way than with
> the platform device drivers. Below is an example where we add ACPI support
> -to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
> +to at25 SPI eeprom driver (this is meant for the above ACPI snippet)::
>
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id at25_acpi_match[] = {
> @@ -182,7 +189,7 @@ to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
>
> Note that this driver actually needs more information like page size of the
> eeprom etc. but at the time writing this there is no standard way of
> -passing those. One idea is to return this in _DSM method like:
> +passing those. One idea is to return this in _DSM method like::
>
> Device (EEP0)
> {
> @@ -202,7 +209,7 @@ passing those. One idea is to return this in _DSM method like:
> }
>
> Then the at25 SPI driver can get this configuration by calling _DSM on its
> -ACPI handle like:
> +ACPI handle like::
>
> struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_object_list input;
> @@ -220,14 +227,15 @@ ACPI handle like:
> kfree(output.pointer);
>
> I2C serial bus support
> -~~~~~~~~~~~~~~~~~~~~~~
> +======================
> +
> The slaves behind I2C bus controller only need to add the ACPI IDs like
> with the platform and SPI drivers. The I2C core automatically enumerates
> any slave devices behind the controller device once the adapter is
> registered.
>
> Below is an example of how to add ACPI support to the existing mpu3050
> -input driver:
> +input driver::
>
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id mpu3050_acpi_match[] = {
> @@ -251,56 +259,57 @@ input driver:
> };
>
> GPIO support
> -~~~~~~~~~~~~
> +============
> +
> ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
> and GpioInt. These resources can be used to pass GPIO numbers used by
> the device to the driver. ACPI 5.1 extended this with _DSD (Device
> Specific Data) which made it possible to name the GPIOs among other things.
>
> -For example:
> +For example::
>
> -Device (DEV)
> -{
> - Method (_CRS, 0, NotSerialized)
> + Device (DEV)
> {
> - Name (SBUF, ResourceTemplate()
> + Method (_CRS, 0, NotSerialized)
> {
> - ...
> - // Used to power on/off the device
> - GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> - IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
> - 0x00, ResourceConsumer,,)
> + Name (SBUF, ResourceTemplate()
> {
> - // Pin List
> - 0x0055
> - }
> + ...
> + // Used to power on/off the device
> + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
> + IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
> + 0x00, ResourceConsumer,,)
> + {
> + // Pin List
> + 0x0055
> + }
> +
> + // Interrupt for the device
> + GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
> + 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
> + {
> + // Pin list
> + 0x0058
> + }
> +
> + ...
>
> - // Interrupt for the device
> - GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
> - 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
> - {
> - // Pin list
> - 0x0058
> }
>
> - ...
> -
> + Return (SBUF)
> }
>
> - Return (SBUF)
> - }
> -
> - // ACPI 5.1 _DSD used for naming the GPIOs
> - Name (_DSD, Package ()
> - {
> - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> - Package ()
> + // ACPI 5.1 _DSD used for naming the GPIOs
> + Name (_DSD, Package ()
> {
> - Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
> - Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
> - }
> - })
> - ...
> + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> + Package ()
> + {
> + Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
> + Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
> + }
> + })
> + ...
>
> These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
> specifies the path to the controller. In order to use these GPIOs in Linux
> @@ -310,7 +319,7 @@ There is a standard GPIO API for that and is documented in
> Documentation/gpio/.
>
> In the above example we can get the corresponding two GPIO descriptors with
> -a code like this:
> +a code like this::
>
> #include <linux/gpio/consumer.h>
> ...
> @@ -334,21 +343,22 @@ See Documentation/acpi/gpio-properties.txt for more information about the
> _DSD binding related to GPIOs.
>
> MFD devices
> -~~~~~~~~~~~
> +===========
> +
> The MFD devices register their children as platform devices. For the child
> devices there needs to be an ACPI handle that they can use to reference
> parts of the ACPI namespace that relate to them. In the Linux MFD subsystem
> we provide two ways:
>
> - o The children share the parent ACPI handle.
> - o The MFD cell can specify the ACPI id of the device.
> + - The children share the parent ACPI handle.
> + - The MFD cell can specify the ACPI id of the device.
>
> For the first case, the MFD drivers do not need to do anything. The
> resulting child platform device will have its ACPI_COMPANION() set to point
> to the parent device.
>
> If the ACPI namespace has a device that we can match using an ACPI id or ACPI
> -adr, the cell should be set like:
> +adr, the cell should be set like::
>
> static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
> .pnpid = "XYZ0001",
> @@ -366,7 +376,8 @@ the MFD device and if found, that ACPI companion device is bound to the
> resulting child platform device.
>
> Device Tree namespace link device ID
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +====================================
> +
> The Device Tree protocol uses device identification based on the "compatible"
> property whose value is a string or an array of strings recognized as device
> identifiers by drivers and the driver core. The set of all those strings may be
> @@ -423,4 +434,4 @@ the _DSD of the device object itself or the _DSD of its ancestor in the
> Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible"
> property returned by it is meaningless.
>
> -Refer to DSD-properties-rules.txt for more information.
> +Refer to :doc:`DSD-properties-rules` for more information.
> diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
> index 210ad8acd6df..99677c73f1fb 100644
> --- a/Documentation/firmware-guide/acpi/index.rst
> +++ b/Documentation/firmware-guide/acpi/index.rst
> @@ -8,3 +8,4 @@ ACPI Support
> :maxdepth: 1
>
> namespace
> + enumeration
Thanks,
Mauro
More information about the Linuxppc-dev
mailing list