diff options
Diffstat (limited to 'Documentation/misc-devices')
-rw-r--r-- | Documentation/misc-devices/dw-xdata-pcie.rst | 64 | ||||
-rw-r--r-- | Documentation/misc-devices/eeprom.rst | 107 | ||||
-rw-r--r-- | Documentation/misc-devices/index.rst | 10 | ||||
-rw-r--r-- | Documentation/misc-devices/mic/index.rst | 16 | ||||
-rw-r--r-- | Documentation/misc-devices/mic/mic_overview.rst | 85 | ||||
-rw-r--r-- | Documentation/misc-devices/mic/scif_overview.rst | 108 | ||||
-rw-r--r-- | Documentation/misc-devices/oxsemi-tornado.rst | 131 | ||||
-rw-r--r-- | Documentation/misc-devices/tps6594-pfsm.rst | 87 |
8 files changed, 286 insertions, 322 deletions
diff --git a/Documentation/misc-devices/dw-xdata-pcie.rst b/Documentation/misc-devices/dw-xdata-pcie.rst new file mode 100644 index 000000000000..781c6794a506 --- /dev/null +++ b/Documentation/misc-devices/dw-xdata-pcie.rst @@ -0,0 +1,64 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================================================================== +Driver for Synopsys DesignWare PCIe traffic generator (also known as xData) +=========================================================================== + +Supported chips: +Synopsys DesignWare PCIe prototype solution + +Datasheet: +Not freely available + +Author: +Gustavo Pimentel <gustavo.pimentel@synopsys.com> + +Description +----------- + +This driver should be used as a host-side (Root Complex) driver and Synopsys +DesignWare prototype that includes this IP. + +The dw-xdata-pcie driver can be used to enable/disable PCIe traffic +generator in either direction (mutual exclusion) besides allowing the +PCIe link performance analysis. + +The interaction with this driver is done through the module parameter and +can be changed in runtime. The driver outputs the requested command state +information to ``/var/log/kern.log`` or dmesg. + +Example +------- + +Write TLPs traffic generation - Root Complex to Endpoint direction +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Generate traffic:: + + # echo 1 > /sys/class/misc/dw-xdata-pcie.0/write + +Get link throughput in MB/s:: + + # cat /sys/class/misc/dw-xdata-pcie.0/write + 204 + +Stop traffic in any direction:: + + # echo 0 > /sys/class/misc/dw-xdata-pcie.0/write + +Read TLPs traffic generation - Endpoint to Root Complex direction +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Generate traffic:: + + # echo 1 > /sys/class/misc/dw-xdata-pcie.0/read + +Get link throughput in MB/s:: + + # cat /sys/class/misc/dw-xdata-pcie.0/read + 199 + +Stop traffic in any direction:: + + # echo 0 > /sys/class/misc/dw-xdata-pcie.0/read + diff --git a/Documentation/misc-devices/eeprom.rst b/Documentation/misc-devices/eeprom.rst deleted file mode 100644 index 008249675ccc..000000000000 --- a/Documentation/misc-devices/eeprom.rst +++ /dev/null @@ -1,107 +0,0 @@ -==================== -Kernel driver eeprom -==================== - -Supported chips: - - * Any EEPROM chip in the designated address range - - Prefix: 'eeprom' - - Addresses scanned: I2C 0x50 - 0x57 - - Datasheets: Publicly available from: - - Atmel (www.atmel.com), - Catalyst (www.catsemi.com), - Fairchild (www.fairchildsemi.com), - Microchip (www.microchip.com), - Philips (www.semiconductor.philips.com), - Rohm (www.rohm.com), - ST (www.st.com), - Xicor (www.xicor.com), - and others. - - ========= ============= ============================================ - Chip Size (bits) Address - ========= ============= ============================================ - 24C01 1K 0x50 (shadows at 0x51 - 0x57) - 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs) - 24C02 2K 0x50 - 0x57 - 24C04 4K 0x50, 0x52, 0x54, 0x56 - (additional data at 0x51, 0x53, 0x55, 0x57) - 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52, - 0x53, 0x55, 0x56, 0x57) - 24C16 16K 0x50 (additional data at 0x51 - 0x57) - Sony 2K 0x57 - - Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37 - Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37 - ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37 - ========= ============= ============================================ - - -Authors: - - Frodo Looijaard <frodol@dds.nl>, - - Philip Edelbrock <phil@netroedge.com>, - - Jean Delvare <jdelvare@suse.de>, - - Greg Kroah-Hartman <greg@kroah.com>, - - IBM Corp. - -Description ------------ - -This is a simple EEPROM module meant to enable reading the first 256 bytes -of an EEPROM (on a SDRAM DIMM for example). However, it will access serial -EEPROMs on any I2C adapter. The supported devices are generically called -24Cxx, and are listed above; however the numbering for these -industry-standard devices may vary by manufacturer. - -This module was a programming exercise to get used to the new project -organization laid out by Frodo, but it should be at least completely -effective for decoding the contents of EEPROMs on DIMMs. - -DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants. -The other devices will not be found on a DIMM because they respond to more -than one address. - -DDC Monitors may contain any device. Often a 24C01, which responds to all 8 -addresses, is found. - -Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the -specification, so it is guess work and far from being complete. - -The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional -software write protect register at 0x30 - 0x37 (0x20 less than the memory -location). The chip responds to "write quick" detection at this address but -does not respond to byte reads. If this register is present, the lower 128 -bytes of the memory array are not write protected. Any byte data write to -this address will write protect the memory array permanently, and the -device will no longer respond at the 0x30-37 address. The eeprom driver -does not support this register. - -Lacking functionality ---------------------- - -* Full support for larger devices (24C04, 24C08, 24C16). These are not - typically found on a PC. These devices will appear as separate devices at - multiple addresses. - -* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512). - These devices require two-byte address fields and are not supported. - -* Enable Writing. Again, no technical reason why not, but making it easy - to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy - to disable the DIMMs (potentially preventing the computer from booting) - until the values are restored somehow. - -Use ---- - -After inserting the module (and any other required SMBus/i2c modules), you -should have some EEPROM directories in ``/sys/bus/i2c/devices/*`` of names such -as "0-0050". Inside each of these is a series of files, the eeprom file -contains the binary data from EEPROM. diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst index 46072ce3d7ef..2d0ce9138588 100644 --- a/Documentation/misc-devices/index.rst +++ b/Documentation/misc-devices/index.rst @@ -7,25 +7,23 @@ Assorted Miscellaneous Devices Documentation This documentation contains information for assorted devices that do not fit into other categories. -.. class:: toc-title - - Table of contents - .. toctree:: + :caption: Table of contents :maxdepth: 2 ad525x_dpot apds990x bh1770glc - eeprom c2port + dw-xdata-pcie ibmvmc ics932s401 isl29003 lis3lv02d max6875 - mic/index + oxsemi-tornado pci-endpoint-test spear-pcie-gadget + tps6594-pfsm uacce xilinx_sdfec diff --git a/Documentation/misc-devices/mic/index.rst b/Documentation/misc-devices/mic/index.rst deleted file mode 100644 index 3a8d06367ef1..000000000000 --- a/Documentation/misc-devices/mic/index.rst +++ /dev/null @@ -1,16 +0,0 @@ -============================================= -Intel Many Integrated Core (MIC) architecture -============================================= - -.. toctree:: - :maxdepth: 1 - - mic_overview - scif_overview - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/misc-devices/mic/mic_overview.rst b/Documentation/misc-devices/mic/mic_overview.rst deleted file mode 100644 index 17d956bdaf7c..000000000000 --- a/Documentation/misc-devices/mic/mic_overview.rst +++ /dev/null @@ -1,85 +0,0 @@ -====================================================== -Intel Many Integrated Core (MIC) architecture overview -====================================================== - -An Intel MIC X100 device is a PCIe form factor add-in coprocessor -card based on the Intel Many Integrated Core (MIC) architecture -that runs a Linux OS. It is a PCIe endpoint in a platform and therefore -implements the three required standard address spaces i.e. configuration, -memory and I/O. The host OS loads a device driver as is typical for -PCIe devices. The card itself runs a bootstrap after reset that -transfers control to the card OS downloaded from the host driver. The -host driver supports OSPM suspend and resume operations. It shuts down -the card during suspend and reboots the card OS during resume. -The card OS as shipped by Intel is a Linux kernel with modifications -for the X100 devices. - -Since it is a PCIe card, it does not have the ability to host hardware -devices for networking, storage and console. We provide these devices -on X100 coprocessors thus enabling a self-bootable equivalent -environment for applications. A key benefit of our solution is that it -leverages the standard virtio framework for network, disk and console -devices, though in our case the virtio framework is used across a PCIe -bus. A Virtio Over PCIe (VOP) driver allows creating user space -backends or devices on the host which are used to probe virtio drivers -for these devices on the MIC card. The existing VRINGH infrastructure -in the kernel is used to access virtio rings from the host. The card -VOP driver allows card virtio drivers to communicate with their user -space backends on the host via a device page. Ring 3 apps on the host -can add, remove and configure virtio devices. A thin MIC specific -virtio_config_ops is implemented which is borrowed heavily from -previous similar implementations in lguest and s390. - -MIC PCIe card has a dma controller with 8 channels. These channels are -shared between the host s/w and the card s/w. 0 to 3 are used by host -and 4 to 7 by card. As the dma device doesn't show up as PCIe device, -a virtual bus called mic bus is created and virtual dma devices are -created on it by the host/card drivers. On host the channels are private -and used only by the host driver to transfer data for the virtio devices. - -The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a -low level communications API across PCIe currently implemented for MIC. -More details are available at scif_overview.txt. - -The Coprocessor State Management (COSM) driver on the host allows for -boot, shutdown and reset of Intel MIC devices. It communicates with a COSM -"client" driver on the MIC cards over SCIF to perform these functions. - -Here is a block diagram of the various components described above. The -virtio backends are situated on the host rather than the card given better -single threaded performance for the host compared to MIC, the ability of -the host to initiate DMA's to/from the card using the MIC DMA engine and -the fact that the virtio block storage backend can only be on the host:: - - +----------+ | +----------+ - | Card OS | | | Host OS | - +----------+ | +----------+ - | - +-------+ +--------+ +------+ | +---------+ +--------+ +--------+ - | Virtio| |Virtio | |Virtio| | |Virtio | |Virtio | |Virtio | - | Net | |Console | |Block | | |Net | |Console | |Block | - | Driver| |Driver | |Driver| | |backend | |backend | |backend | - +---+---+ +---+----+ +--+---+ | +---------+ +----+---+ +--------+ - | | | | | | | - | | | |User | | | - | | | |------|------------|--+------|------- - +---------+---------+ |Kernel | - | | | - +---------+ +---+----+ +------+ | +------+ +------+ +--+---+ +-------+ - |MIC DMA | | VOP | | SCIF | | | SCIF | | COSM | | VOP | |MIC DMA| - +---+-----+ +---+----+ +--+---+ | +--+---+ +--+---+ +------+ +----+--+ - | | | | | | | - +---+-----+ +---+----+ +--+---+ | +--+---+ +--+---+ +------+ +----+--+ - |MIC | | VOP | |SCIF | | |SCIF | | COSM | | VOP | | MIC | - |HW Bus | | HW Bus| |HW Bus| | |HW Bus| | Bus | |HW Bus| |HW Bus | - +---------+ +--------+ +--+---+ | +--+---+ +------+ +------+ +-------+ - | | | | | | | - | +-----------+--+ | | | +---------------+ | - | |Intel MIC | | | | |Intel MIC | | - | |Card Driver | | | | |Host Driver | | - +---+--------------+------+ | +----+---------------+-----+ - | | | - +-------------------------------------------------------------+ - | | - | PCIe Bus | - +-------------------------------------------------------------+ diff --git a/Documentation/misc-devices/mic/scif_overview.rst b/Documentation/misc-devices/mic/scif_overview.rst deleted file mode 100644 index 4c8ad9e43706..000000000000 --- a/Documentation/misc-devices/mic/scif_overview.rst +++ /dev/null @@ -1,108 +0,0 @@ -======================================== -Symmetric Communication Interface (SCIF) -======================================== - -The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a low -level communications API across PCIe currently implemented for MIC. Currently -SCIF provides inter-node communication within a single host platform, where a -node is a MIC Coprocessor or Xeon based host. SCIF abstracts the details of -communicating over the PCIe bus while providing an API that is symmetric -across all the nodes in the PCIe network. An important design objective for SCIF -is to deliver the maximum possible performance given the communication -abilities of the hardware. SCIF has been used to implement an offload compiler -runtime and OFED support for MPI implementations for MIC coprocessors. - -SCIF API Components -=================== - -The SCIF API has the following parts: - -1. Connection establishment using a client server model -2. Byte stream messaging intended for short messages -3. Node enumeration to determine online nodes -4. Poll semantics for detection of incoming connections and messages -5. Memory registration to pin down pages -6. Remote memory mapping for low latency CPU accesses via mmap -7. Remote DMA (RDMA) for high bandwidth DMA transfers -8. Fence APIs for RDMA synchronization - -SCIF exposes the notion of a connection which can be used by peer processes on -nodes in a SCIF PCIe "network" to share memory "windows" and to communicate. A -process in a SCIF node initiates a SCIF connection to a peer process on a -different node via a SCIF "endpoint". SCIF endpoints support messaging APIs -which are similar to connection oriented socket APIs. Connected SCIF endpoints -can also register local memory which is followed by data transfer using either -DMA, CPU copies or remote memory mapping via mmap. SCIF supports both user and -kernel mode clients which are functionally equivalent. - -SCIF Performance for MIC -======================== - -DMA bandwidth comparison between the TCP (over ethernet over PCIe) stack versus -SCIF shows the performance advantages of SCIF for HPC applications and -runtimes:: - - Comparison of TCP and SCIF based BW - - Throughput (GB/sec) - 8 + PCIe Bandwidth ****** - + TCP ###### - 7 + ************************************** SCIF %%%%%% - | %%%%%%%%%%%%%%%%%%% - 6 + %%%% - | %% - | %%% - 5 + %% - | %% - 4 + %% - | %% - 3 + %% - | % - 2 + %% - | %% - | % - 1 + - + ###################################### - 0 +++---+++--+--+-+--+--+-++-+--+-++-+--+-++-+- - 1 10 100 1000 10000 100000 - Transfer Size (KBytes) - -SCIF allows memory sharing via mmap(..) between processes on different PCIe -nodes and thus provides bare-metal PCIe latency. The round trip SCIF mmap -latency from the host to an x100 MIC for an 8 byte message is 0.44 usecs. - -SCIF has a user space library which is a thin IOCTL wrapper providing a user -space API similar to the kernel API in scif.h. The SCIF user space library -is distributed @ https://software.intel.com/en-us/mic-developer - -Here is some pseudo code for an example of how two applications on two PCIe -nodes would typically use the SCIF API:: - - Process A (on node A) Process B (on node B) - - /* get online node information */ - scif_get_node_ids(..) scif_get_node_ids(..) - scif_open(..) scif_open(..) - scif_bind(..) scif_bind(..) - scif_listen(..) - scif_accept(..) scif_connect(..) - /* SCIF connection established */ - - /* Send and receive short messages */ - scif_send(..)/scif_recv(..) scif_send(..)/scif_recv(..) - - /* Register memory */ - scif_register(..) scif_register(..) - - /* RDMA */ - scif_readfrom(..)/scif_writeto(..) scif_readfrom(..)/scif_writeto(..) - - /* Fence DMAs */ - scif_fence_signal(..) scif_fence_signal(..) - - mmap(..) mmap(..) - - /* Access remote registered memory */ - - /* Close the endpoints */ - scif_close(..) scif_close(..) diff --git a/Documentation/misc-devices/oxsemi-tornado.rst b/Documentation/misc-devices/oxsemi-tornado.rst new file mode 100644 index 000000000000..b33351bef6cf --- /dev/null +++ b/Documentation/misc-devices/oxsemi-tornado.rst @@ -0,0 +1,131 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================================================== +Notes on Oxford Semiconductor PCIe (Tornado) 950 serial port devices +==================================================================== + +Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven +by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. + +The baud rate produced by the baud generator is obtained from this input +frequency by dividing it by the clock prescaler, which can be set to any +value from 1 to 63.875 in increments of 0.125, and then the usual 16-bit +divisor is used as with the original 8250, to divide the frequency by a +value from 1 to 65535. Finally a programmable oversampling rate is used +that can take any value from 4 to 16 to divide the frequency further and +determine the actual baud rate used. Baud rates from 15625000bps down +to 0.933bps can be obtained this way. + +By default the oversampling rate is set to 16 and the clock prescaler is +set to 33.875, meaning that the frequency to be used as the reference +for the usual 16-bit divisor is 115313.653, which is close enough to the +frequency of 115200 used by the original 8250 for the same values to be +used for the divisor to obtain the requested baud rates by software that +is unaware of the extra clock controls available. + +The oversampling rate is programmed with the TCR register and the clock +prescaler is programmed with the CPR/CPR2 register pair [OX200]_ [OX952]_ +[OX954]_ [OX958]_. To switch away from the default value of 33.875 for +the prescaler the enhanced mode has to be explicitly enabled though, by +setting bit 4 of the EFR. In that mode setting bit 7 in the MCR enables +the prescaler or otherwise it is bypassed as if the value of 1 was used. +Additionally writing any value to CPR clears CPR2 for compatibility with +old software written for older conventional PCI Oxford Semiconductor +devices that do not have the extra prescaler's 9th bit in CPR2, so the +CPR/CPR2 register pair has to be programmed in the right order. + +By using these parameters rates from 15625000bps down to 1bps can be +obtained, with either exact or highly-accurate actual bit rates for +standard and many non-standard rates. + +Here are the figures for the standard and some non-standard baud rates +(including those quoted in Oxford Semiconductor documentation), giving +the requested rate (r), the actual rate yielded (a) and its deviation +from the requested rate (d), and the values of the oversampling rate +(tcr), the clock prescaler (cpr) and the divisor (div) produced by the +new ``get_divisor`` handler: + +:: + + r: 15625000, a: 15625000.00, d: 0.0000%, tcr: 4, cpr: 1.000, div: 1 + r: 12500000, a: 12500000.00, d: 0.0000%, tcr: 5, cpr: 1.000, div: 1 + r: 10416666, a: 10416666.67, d: 0.0000%, tcr: 6, cpr: 1.000, div: 1 + r: 8928571, a: 8928571.43, d: 0.0000%, tcr: 7, cpr: 1.000, div: 1 + r: 7812500, a: 7812500.00, d: 0.0000%, tcr: 8, cpr: 1.000, div: 1 + r: 4000000, a: 4000000.00, d: 0.0000%, tcr: 5, cpr: 3.125, div: 1 + r: 3686400, a: 3676470.59, d: -0.2694%, tcr: 8, cpr: 2.125, div: 1 + r: 3500000, a: 3496503.50, d: -0.0999%, tcr: 13, cpr: 1.375, div: 1 + r: 3000000, a: 2976190.48, d: -0.7937%, tcr: 14, cpr: 1.500, div: 1 + r: 2500000, a: 2500000.00, d: 0.0000%, tcr: 10, cpr: 2.500, div: 1 + r: 2000000, a: 2000000.00, d: 0.0000%, tcr: 10, cpr: 3.125, div: 1 + r: 1843200, a: 1838235.29, d: -0.2694%, tcr: 16, cpr: 2.125, div: 1 + r: 1500000, a: 1492537.31, d: -0.4975%, tcr: 5, cpr: 8.375, div: 1 + r: 1152000, a: 1152073.73, d: 0.0064%, tcr: 14, cpr: 3.875, div: 1 + r: 921600, a: 919117.65, d: -0.2694%, tcr: 16, cpr: 2.125, div: 2 + r: 576000, a: 576036.87, d: 0.0064%, tcr: 14, cpr: 3.875, div: 2 + r: 460800, a: 460829.49, d: 0.0064%, tcr: 7, cpr: 3.875, div: 5 + r: 230400, a: 230414.75, d: 0.0064%, tcr: 14, cpr: 3.875, div: 5 + r: 115200, a: 115207.37, d: 0.0064%, tcr: 14, cpr: 1.250, div: 31 + r: 57600, a: 57603.69, d: 0.0064%, tcr: 8, cpr: 3.875, div: 35 + r: 38400, a: 38402.46, d: 0.0064%, tcr: 14, cpr: 3.875, div: 30 + r: 19200, a: 19201.23, d: 0.0064%, tcr: 8, cpr: 3.875, div: 105 + r: 9600, a: 9600.06, d: 0.0006%, tcr: 9, cpr: 1.125, div: 643 + r: 4800, a: 4799.98, d: -0.0004%, tcr: 7, cpr: 2.875, div: 647 + r: 2400, a: 2400.02, d: 0.0008%, tcr: 9, cpr: 2.250, div: 1286 + r: 1200, a: 1200.00, d: 0.0000%, tcr: 14, cpr: 2.875, div: 1294 + r: 300, a: 300.00, d: 0.0000%, tcr: 11, cpr: 2.625, div: 7215 + r: 200, a: 200.00, d: 0.0000%, tcr: 16, cpr: 1.250, div: 15625 + r: 150, a: 150.00, d: 0.0000%, tcr: 13, cpr: 2.250, div: 14245 + r: 134, a: 134.00, d: 0.0000%, tcr: 11, cpr: 2.625, div: 16153 + r: 110, a: 110.00, d: 0.0000%, tcr: 12, cpr: 1.000, div: 47348 + r: 75, a: 75.00, d: 0.0000%, tcr: 4, cpr: 5.875, div: 35461 + r: 50, a: 50.00, d: 0.0000%, tcr: 16, cpr: 1.250, div: 62500 + r: 25, a: 25.00, d: 0.0000%, tcr: 16, cpr: 2.500, div: 62500 + r: 4, a: 4.00, d: 0.0000%, tcr: 16, cpr: 20.000, div: 48828 + r: 2, a: 2.00, d: 0.0000%, tcr: 16, cpr: 40.000, div: 48828 + r: 1, a: 1.00, d: 0.0000%, tcr: 16, cpr: 63.875, div: 61154 + +With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX +limitation imposed by ``serial8250_get_baud_rate`` standard baud rates +below 300bps become unavailable in the regular way, e.g. the rate of +200bps requires the baud base to be divided by 78125 and that is beyond +the unsigned 16-bit range. The historic spd_cust feature can still be +used by encoding the values for, the prescaler, the oversampling rate +and the clock divisor (DLM/DLL) as follows to obtain such rates if so +required: + +:: + + 31 29 28 20 19 16 15 0 + +-----+-----------------+-------+-------------------------------+ + |0 0 0| CPR2:CPR | TCR | DLM:DLL | + +-----+-----------------+-------+-------------------------------+ + +Use a value such encoded for the ``custom_divisor`` field along with the +ASYNC_SPD_CUST flag set in the ``flags`` field in ``struct serial_struct`` +passed with the TIOCSSERIAL ioctl(2), such as with the setserial(8) +utility and its ``divisor`` and ``spd_cust`` parameters, and then select +the baud rate of 38400bps. Note that the value of 0 in TCR sets the +oversampling rate to 16 and prescaler values below 1 in CPR2/CPR are +clamped by the driver to 1. + +For example the value of 0x1f4004e2 will set CPR2/CPR, TCR and DLM/DLL +respectively to 0x1f4, 0x0 and 0x04e2, choosing the prescaler value, +the oversampling rate and the clock divisor of 62.500, 16 and 1250 +respectively. These parameters will set the baud rate for the serial +port to 62500000 / 62.500 / 1250 / 16 = 50bps. + +Maciej W. Rozycki <macro@orcam.me.uk> + +.. [OX200] "OXPCIe200 PCI Express Multi-Port Bridge", Oxford Semiconductor, + Inc., DS-0045, 10 Nov 2008, Section "950 Mode", pp. 64-65 + +.. [OX952] "OXPCIe952 PCI Express Bridge to Dual Serial & Parallel Port", + Oxford Semiconductor, Inc., DS-0046, Mar 06 08, Section "950 Mode", + p. 20 + +.. [OX954] "OXPCIe954 PCI Express Bridge to Quad Serial Port", Oxford + Semiconductor, Inc., DS-0047, Feb 08, Section "950 Mode", p. 20 + +.. [OX958] "OXPCIe958 PCI Express Bridge to Octal Serial Port", Oxford + Semiconductor, Inc., DS-0048, Feb 08, Section "950 Mode", p. 20 diff --git a/Documentation/misc-devices/tps6594-pfsm.rst b/Documentation/misc-devices/tps6594-pfsm.rst new file mode 100644 index 000000000000..4ada37ccdcba --- /dev/null +++ b/Documentation/misc-devices/tps6594-pfsm.rst @@ -0,0 +1,87 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Texas Instruments TPS6594 PFSM driver +===================================== + +Author: Julien Panis (jpanis@baylibre.com) + +Overview +======== + +Strictly speaking, PFSM (Pre-configurable Finite State Machine) is not +hardware. It is a piece of code. + +The TPS6594 PMIC (Power Management IC) integrates a state machine which +manages operational modes. Depending on the current operational mode, +some voltage domains remain energized while others can be off. + +The PFSM driver can be used to trigger transitions between configured +states. It also provides R/W access to the device registers. + +Supported chips +--------------- + +- tps6594-q1 +- tps6593-q1 +- lp8764-q1 + +Driver location +=============== + +drivers/misc/tps6594-pfsm.c + +Driver type definitions +======================= + +include/uapi/linux/tps6594_pfsm.h + +Driver IOCTLs +============= + +:c:macro::`PMIC_GOTO_STANDBY` +All device resources are powered down. The processor is off, and +no voltage domains are energized. + +:c:macro::`PMIC_GOTO_LP_STANDBY` +The digital and analog functions of the PMIC, which are not +required to be always-on, are turned off (low-power). + +:c:macro::`PMIC_UPDATE_PGM` +Triggers a firmware update. + +:c:macro::`PMIC_SET_ACTIVE_STATE` +One of the operational modes. +The PMICs are fully functional and supply power to all PDN loads. +All voltage domains are energized in both MCU and Main processor +sections. + +:c:macro::`PMIC_SET_MCU_ONLY_STATE` +One of the operational modes. +Only the power resources assigned to the MCU Safety Island are on. + +:c:macro::`PMIC_SET_RETENTION_STATE` +One of the operational modes. +Depending on the triggers set, some DDR/GPIO voltage domains can +remain energized, while all other domains are off to minimize +total system power. + +Driver usage +============ + +See available PFSMs:: + + # ls /dev/pfsm* + +Dump the registers of pages 0 and 1:: + + # hexdump -C /dev/pfsm-0-0x48 + +See PFSM events:: + + # cat /proc/interrupts + +Userspace code example +---------------------- + +samples/pfsm/pfsm-wakeup.c |