diff options
Diffstat (limited to 'Documentation')
361 files changed, 44310 insertions, 889 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index cd077ca0e1b8..e39561d41f8b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -91,6 +91,8 @@ basic_profiling.txt - basic instructions for those who wants to profile Linux kernel. bcache.txt - Block-layer cache on fast SSDs to improve slow (raid) I/O performance. +bif-framework.txt + - information about MIPI-BIF support in the Linux kernel. binfmt_misc.txt - info on the kernel support for extra binary formats. blackfin/ diff --git a/Documentation/ABI/testing/sysfs-class-dual-role-usb b/Documentation/ABI/testing/sysfs-class-dual-role-usb new file mode 100644 index 000000000000..a900fd75430c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-dual-role-usb @@ -0,0 +1,71 @@ +What: /sys/class/dual_role_usb/.../ +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + Provide a generic interface to monitor and change + the state of dual role usb ports. The name here + refers to the name mentioned in the + dual_role_phy_desc that is passed while registering + the dual_role_phy_intstance through + devm_dual_role_instance_register. + +What: /sys/class/dual_role_usb/.../supported_modes +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + This is a static node, once initialized this + is not expected to change during runtime. "dfp" + refers to "downstream facing port" i.e. port can + only act as host. "ufp" refers to "upstream + facing port" i.e. port can only act as device. + "dfp ufp" refers to "dual role port" i.e. the port + can either be a host port or a device port. + +What: /sys/class/dual_role_usb/.../mode +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + The mode node refers to the current mode in which the + port is operating. "dfp" for host ports. "ufp" for device + ports and "none" when cable is not connected. + + On devices where the USB mode is software-controllable, + userspace can change the mode by writing "dfp" or "ufp". + On devices where the USB mode is fixed in hardware, + this attribute is read-only. + +What: /sys/class/dual_role_usb/.../power_role +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + The power_role node mentions whether the port + is "sink"ing or "source"ing power. "none" if + they are not connected. + + On devices implementing USB Power Delivery, + userspace can control the power role by writing "sink" or + "source". On devices without USB-PD, this attribute is + read-only. + +What: /sys/class/dual_role_usb/.../data_role +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + The data_role node mentions whether the port + is acting as "host" or "device" for USB data connection. + "none" if there is no active data link. + + On devices implementing USB Power Delivery, userspace + can control the data role by writing "host" or "device". + On devices without USB-PD, this attribute is read-only + +What: /sys/class/dual_role_usb/.../powers_vconn +Date: June 2015 +Contact: Badhri Jagan Sridharan<badhri@google.com> +Description: + The powers_vconn node mentions whether the port + is supplying power for VCONN pin. + + On devices with software control of VCONN, + userspace can disable the power supply to VCONN by writing "n", + or enable the power supply by writing "y". diff --git a/Documentation/ABI/testing/sysfs-class-stm b/Documentation/ABI/testing/sysfs-class-stm index c9aa4f3fc9a7..77ed3da0f68e 100644 --- a/Documentation/ABI/testing/sysfs-class-stm +++ b/Documentation/ABI/testing/sysfs-class-stm @@ -12,3 +12,13 @@ KernelVersion: 4.3 Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com> Description: Shows the number of channels per master on this STM device. + +What: /sys/class/stm/<stm>/hw_override +Date: March 2016 +KernelVersion: 4.7 +Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com> +Description: + Reads as 0 if master numbers in the STP stream produced by + this stm device will match the master numbers assigned by + the software or 1 if the stm hardware overrides software + assigned masters. diff --git a/Documentation/ABI/testing/sysfs-kernel-wakeup_reasons b/Documentation/ABI/testing/sysfs-kernel-wakeup_reasons new file mode 100644 index 000000000000..acb19b91c192 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-wakeup_reasons @@ -0,0 +1,16 @@ +What: /sys/kernel/wakeup_reasons/last_resume_reason +Date: February 2014 +Contact: Ruchi Kandoi <kandoiruchi@google.com> +Description: + The /sys/kernel/wakeup_reasons/last_resume_reason is + used to report wakeup reasons after system exited suspend. + +What: /sys/kernel/wakeup_reasons/last_suspend_time +Date: March 2015 +Contact: jinqian <jinqian@google.com> +Description: + The /sys/kernel/wakeup_reasons/last_suspend_time is + used to report time spent in last suspend cycle. It contains + two numbers (in seconds) separated by space. First number is + the time spent in suspend and resume processes. Second number + is the time spent in sleep state.
\ No newline at end of file diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index 18dc52c4f2a0..2ad68dbbaaae 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt @@ -100,3 +100,57 @@ allocated by dma_alloc_attrs() function from individual pages if it can be mapped as contiguous chunk into device dma address space. By specifying this attribute the allocated buffer is forced to be contiguous also in physical memory. + +DMA_ATTR_STRONGLY_ORDERED +------------------------- + +DMA_ATTR_STRONGLY_ORDERED allocates memory with a very restrictive type +of mapping (no unaligned accesses, no re-ordering, no write merging, no +buffering, no pre-fetching). This has severe performance penalties and +should not be used for general purpose DMA allocations. It should only +be used if one of the restrictions on strongly ordered memory is required. + +DMA_ATTR_NO_DELAYED_UNMAP +------------------------- + +DMA_ATTR_NO_DELAYED_UNMAP is used only by the msm specific lazy mapping +feature. By default, the lazy mapping and unmapping holds an additional +reference so that when the buffer is freed, the mapping is not destroyed +and can be re-used. By specifying this attribute, an additional reference +will NOT be held by the lazy mapping code and it will be released as soon +as the buffer is freed. + +DMA_ATTR_EXEC_MAPPING +--------------------- + +By default, the DMA mappings are non-executable. Some use cases might require +an executable mapping. This attribute can be used to indicate to the DMA +subsystem to create an executable mappings for the buffer. + +DMA_ATTR_FORCE_COHERENT +----------------------- + +When passed to a DMA map call the DMA_ATTR_FORCE_COHERENT DMA +attribute can be used to force a buffer to be mapped as IO coherent. + +When the DMA_ATTR_FORCE_COHERENT attribute is set during a map call ensure +that it is also set during for the matching unmap call to ensure that the +correct cache maintenance is carried out. + +This DMA attribute is only currently supported for arm64 stage 1 IOMMU +mappings. + +DMA_ATTR_FORCE_NON_COHERENT +--------------------------- +When passed to a DMA map call the DMA_ATTR_FORCE_NON_COHERENT DMA +attribute can be used to force a buffer to not be mapped as IO +coherent. +The DMA_ATTR_FORCE_NON_COHERENT DMA attribute overrides the buffer IO +coherency configuration set by making the device IO coherent. + +When the DMA_ATTR_FORCE_NON_COHERENT attribute is set during a map call +ensure that it is also set during for the matching unmap call to ensure +that the correct cache maintenance is carried out. + +This DMA attribute is only currently supported for arm64 stage 1 IOMMU +mappings. diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index f9b9ad7894f5..eaadf60f4692 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -136,6 +136,8 @@ !Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt !Finclude/net/cfg80211.h cfg80211_ibss_joined !Finclude/net/cfg80211.h cfg80211_connect_result +!Finclude/net/cfg80211.h cfg80211_connect_bss +!Finclude/net/cfg80211.h cfg80211_connect_timeout !Finclude/net/cfg80211.h cfg80211_roamed !Finclude/net/cfg80211.h cfg80211_disconnected !Finclude/net/cfg80211.h cfg80211_ready_on_channel diff --git a/Documentation/android.txt b/Documentation/android.txt new file mode 100644 index 000000000000..0f40a78b045f --- /dev/null +++ b/Documentation/android.txt @@ -0,0 +1,121 @@ + ============= + A N D R O I D + ============= + +Copyright (C) 2009 Google, Inc. +Written by Mike Chan <mike@android.com> + +CONTENTS: +--------- + +1. Android + 1.1 Required enabled config options + 1.2 Required disabled config options + 1.3 Recommended enabled config options +2. Contact + + +1. Android +========== + +Android (www.android.com) is an open source operating system for mobile devices. +This document describes configurations needed to run the Android framework on +top of the Linux kernel. + +To see a working defconfig look at msm_defconfig or goldfish_defconfig +which can be found at http://android.git.kernel.org in kernel/common.git +and kernel/msm.git + + +1.1 Required enabled config options +----------------------------------- +After building a standard defconfig, ensure that these options are enabled in +your .config or defconfig if they are not already. Based off the msm_defconfig. +You should keep the rest of the default options enabled in the defconfig +unless you know what you are doing. + +ANDROID_PARANOID_NETWORK +ASHMEM +CONFIG_FB_MODE_HELPERS +CONFIG_FONT_8x16 +CONFIG_FONT_8x8 +CONFIG_YAFFS_SHORT_NAMES_IN_RAM +DAB +EARLYSUSPEND +FB +FB_CFB_COPYAREA +FB_CFB_FILLRECT +FB_CFB_IMAGEBLIT +FB_DEFERRED_IO +FB_TILEBLITTING +HIGH_RES_TIMERS +INOTIFY +INOTIFY_USER +INPUT_EVDEV +INPUT_GPIO +INPUT_MISC +LEDS_CLASS +LEDS_GPIO +LOCK_KERNEL +LkOGGER +LOW_MEMORY_KILLER +MISC_DEVICES +NEW_LEDS +NO_HZ +POWER_SUPPLY +PREEMPT +RAMFS +RTC_CLASS +RTC_LIB +SWITCH +SWITCH_GPIO +TMPFS +UID_STAT +UID16 +USB_FUNCTION +USB_FUNCTION_ADB +USER_WAKELOCK +VIDEO_OUTPUT_CONTROL +WAKELOCK +YAFFS_AUTO_YAFFS2 +YAFFS_FS +YAFFS_YAFFS1 +YAFFS_YAFFS2 + + +1.2 Required disabled config options +------------------------------------ +CONFIG_YAFFS_DISABLE_LAZY_LOAD +DNOTIFY + + +1.3 Recommended enabled config options +------------------------------ +ANDROID_PMEM +PSTORE_CONSOLE +PSTORE_RAM +SCHEDSTATS +DEBUG_PREEMPT +DEBUG_MUTEXES +DEBUG_SPINLOCK_SLEEP +DEBUG_INFO +FRAME_POINTER +CPU_FREQ +CPU_FREQ_TABLE +CPU_FREQ_DEFAULT_GOV_ONDEMAND +CPU_FREQ_GOV_ONDEMAND +CRC_CCITT +EMBEDDED +INPUT_TOUCHSCREEN +I2C +I2C_BOARDINFO +LOG_BUF_SHIFT=17 +SERIAL_CORE +SERIAL_CORE_CONSOLE + + +2. Contact +========== +website: http://android.git.kernel.org + +mailing-lists: android-kernel@googlegroups.com diff --git a/Documentation/arm/msm/boot.txt b/Documentation/arm/msm/boot.txt new file mode 100644 index 000000000000..1a41cd532020 --- /dev/null +++ b/Documentation/arm/msm/boot.txt @@ -0,0 +1,23 @@ +Introduction +============= +The power management integrated circuit (PMIC) records the reason the +Application processor was powered on in Shared Memory. +The hardware and software used is the shared memory interface. This document +is not for the purpose of describing this interface, but to identify the +possible values for this data item. + +Description +=========== +Shared memory item (SMEM_POWER_ON_STATUS_INFO) is read to get access to +this data. The table below identifies the possible values stored. + +power_on_status values set by the PMIC for power on event: +---------------------------------------------------------- +0x01 -- keyboard power on +0x02 -- RTC alarm +0x04 -- cable power on +0x08 -- SMPL +0x10 -- Watch Dog timeout +0x20 -- USB charger +0x40 -- Wall charger +0xFF -- error reading power_on_status value diff --git a/Documentation/arm/msm/glink.txt b/Documentation/arm/msm/glink.txt new file mode 100644 index 000000000000..814c11804242 --- /dev/null +++ b/Documentation/arm/msm/glink.txt @@ -0,0 +1,1239 @@ +Introduction +============ + +G-Link, short for Generic Link, is a generic link-layer transport that supports +a plug-in framework for physical transports. This allows it to adapt to +different physical transports such as shared memory, UARTs, buses, and DMA. + +It is designed to enable zero copy, is power aware, and supports version and +feature negotiation to enable phased upgrades. The design is symmetrical with +the same high-level design and the same client API across all subsystems +regardless of OS. + +Hardware description +==================== + +The hardware is managed by the transport plug-in. In the initial +driver version, this is done by the SMEM Native Transport which requires +shared memory and an interrupt in each direction between the local and remote +subsystems. This transport is a replacement for SMD. + +Software description +================================= + +G-Link consists of: + * Client API + * Core that implements the high-level protocol + * Transport plug-ins that handle translation of the high-level protocol to wire + format + +The below diagram shows the organization of G-Link. Clients use G-Link to +interface with the Transport Plug-in, which interfaces directly with the +physical transport. The G-Link component is shown in further detail in the +"Design" section. + + +-----------+ +---------+ +-----------+ + | G-Link |---->|Transport|----->| Physical | + | |<----| Plug-in |<-----| Transport | + +-----------+ +---------+ +-----------+ + +Design +====== + +G-Link is conceptually broken down into a command and data queue. The command +queue is used to pass commands for synchronizing buffer status, channel state, +and for the equivalent of packet headers. The data queue is reserved for raw +client data. + +For every packet in the data queue, there is at least one command +that acts as the packet header that goes through the command queue. This +separation is necessary to support the zero-copy use case for data packets and +for DMA-type transports that need to have the transfer size known ahead of time. + +For copy-based transports, the command and data transports can be merged +together in the transport plug-in resulting in traditional packet headers like +we have today in other common protocols such as IP. + +As shown in the diagram below, the client itself communicates directly with the +G-Link core, and uses the Transport Interface and the G-Link Core interface to +create the transport plug-in. + + +-----------+ + +------+ +---------+ | | + | |<---|Transport|-| | + +-------+ | | | IF | | | + |Clients|<-->| | +---------+ | Transport | + +-------+ |G-Link| | Plug-in | + | Core | | | + | | +-------+ | | + | |-|G-Link |----->| | + | | |Core IF| | | + +------+ +-------+ | | + +-----------+ + +A channel is a discrete data pipe used by a client to communicate with a +remote system. All channels are multiplexed onto one or more physical +transports. + +A receive intent is queued by a client to indicate that it is ready to receive +a packet up to the specified size. The intent is sent to the remote side to +let clients know that they can transmit and expect the client to be able to +process it. + +Intents provide back-pressure to transmitting clients and remove the +requirement for flow control. In addition, the intent size is used for +copy-based transports to either reserve buffer space or allocate buffers to +receive data to prevent blocking the underlying transport. Multiple intents +can be queued. + +Transport Plug-in +----------------- +The transport plug-in is responsible for marshaling data and commands between +the G-Link core and the physical transport. If the remote side is not running +G-Link, then the transport plug-in will be more complex and will handle +translating G-Link core commands and data into the proper protocol to +interact with the remote system. + +Client API +---------- +The API into the G-Link core is asynchronous by default, but may have blocking +variants. If necessary, a thin client layer can be built on top of the +asynchronous API to create a synchronous API for clients. All client +notifications are serialized to ensure in-order notification of events. + +The G-Link client API includes the following functions for the following +operations. Details of each function are described later in this section. + * glink_open() - Open a G-Link channel + * glink_close() - Close a G-Link channel + * glink_tx() - Transmit data + * glink_txv() - Transmit a buffer chain + * glink_queue_rx_intent() - Queue a receive intent + * glink_rx_done() - Signal consumption of the receive buffer + * glink_sigs_set() - Set a 32-bit signal field for client-specific signaling. + Standard TIOCM bits are reserved in the upper bits of the + field as a conviencence for users, but they are 100 + percent pass-through. + * glink_sigs_local_get() - Get the local 32-bit control signal field + * glink_sigs_remote_get() - Get the remote 32-bit control signal field + +The TIOCM bitmasks are defined as follows: + #define SMD_CTR_SIG_SHFT 31 + #define SMD_CTS_SIG_SHFT 30 + #define SMD_CD_SIG_SHFT 29 + #define SMD_RI_SIG_SHFT 28 + +When a channel is opened by a client, the client provides an open +configuration to the G-Link core as a parameter to the glink_open() function. +This open configuration contains the following information: + * The name of the transport (optional) + * The name of the edge (remote processor) + * The name of the channel + +The open configuration also contains function pointers for the following +operations, which are defined by the client: + * notify_rx() - Notify the client that data has been received + * notify_rxv() - Notify the client that vector data has been received + * notify_tx_done() - Notify the client that data has been transmitted + * notify_state() - Notify the client that the channel's state has changed + * notify_rx_intent_req() - Notify the client whether their request for a + receive intent was granted + * notify_rx_sigs() - Notify the client that there has been a change in the + state of the remote side's control signals + * notify_rx_abort() - During channel close, return structures associated + with receive intents to the client + * notify_tx_abort() - During channel close, return structures associated + with TX packets to the client + * notify_rx_tracer_pkt() - Notify the client that a tracer packet has been + received + +Buffer ownership is transferred between the local G-Link and the remote G-Link +using message passing. A typical transmit sequence is as follows: + + 1. The remote side queues an RX intent. When the remote client queues the + intent by calling glink_queue_rx_intent(), the ownership of the buffer + transfers to the remote G-Link core, which notifies the local G-Link core + of the receive intent. The remote G-Link core is now ready to receive data + from the local client. In the zero-copy case, the remote G-Link core does + not need to allocate a buffer. + + +------+ +------+ +------+ + |Local | |Remote| |Remote| + |G-Link| |G-Link| |Client| + +------+ +------+ +------+ + | | | + | | glink_queue_rx_intent()| + | +-+<---------------------+-+ + | |-| |-| + | |-|(allocate/reserve |-| + | |-| buffer) |-| + | |-|-----+ |-| + | |-| | |-| + | |-|<----+ |-| + | +-+ +-+ + | send_intent() | | + |<--------------------------+ | + | | | + | (signal) | | + +-+<-------------------------| | + |-| | | + |-| | | + |-| | | + +-+ | | + | | | + +------+ +------+ +------+ + |Local | |Remote| |Remote| + |G-Link| |G-Link| |Client| + +------+ +------+ +------+ + + 2. The local client can allocate a buffer, fill it, and send it to the remote + side. If multiple receive intents are available, then a first-fit + algorithm is used to select the receive intent. + + +------+ +------+ +------+ +------+ + |Local | |Local | |Remote| |Remote| + |Client| |G-Link| |G-Link| |Client| + +------+ +------+ +------+ +------+ + | | | | + | (Allocate tx buffer) | | | + +-+--------+ | | | + |-| | | | | + |-|<-------+ | | | + |-| | | | + |-| (Copy data into | | | + |-| tx buffer) | | | + |-|--------+ | | | + |-| | | | | + |-|<-------+ | | | + |-| | | | + |-| glink_tx() | | | + |-|------------------->+-+ tx() | | + |-| |-|---------->+-+ notify_rx() | + |-| |-| |-|------------>+-+ + +-+ |-| (signal) |-| |-| + | |-|---------->|-| |-| + | +-+ |-| |-| + | | +-+ |-| + | | | +-+ + | | | | + +------+ +------+ +------+ +------+ + |Local | |Local | |Remote| |Remote| + |Client| |G-Link| |G-Link| |Client| + +------+ +------+ +------+ +------+ + + 3. The transmit buffer ownership is returned to the local client after the + remote client has finished with it. At this point, the local client can + destroy/reuse the buffer. + + +------+ +------+ +------+ +------+ + |Local | |Local | |Remote| |Remote| + |Client| |G-Link| |G-Link| |Client| + +------+ +------+ +------+ +------+ + | | | | + | | | glink_rx_done() | + | | +-+<----------------+-+ + | | |-| |-| + | | |-| (copy-based |-| + | | |-| transport: |-| + | | |-| destroy/reuse |-| + | | |-| buffer) |-| + | | |-|----------+ +-+ + | | |-| | | + | | |-| | | + | | |-|<---------+ | + | | tx_done()|-| | + | +-+<----------|-| | + | |-| |-| | + | |-| (signal) |-| | + | notify_tx_done()|-|<----------|-| | + +-+<---------------|-| |-| | + |-| |-| +-+ | + |-| |-| | | + |-| +-+ | | + +-+ | | | + | | | | + +------+ +------+ +------+ +------+ + |Local | |Local | |Remote| |Remote| + |Client| |G-Link| |G-Link| |Client| + +------+ +------+ +------+ +------+ + +Transport Interface +------------------- +The transport interface is used for function calls from the G-Link core to a +G-Link transport. Modules which implement this interface are G-Link +transports. All function calls include the pointer to the transport instance +and the data fields that should be encoded into a command packet to be sent to +the remote processor. These functions act on the transport itself - they +translate the commands into actions for each different transport. This interface +contains APIs for transport negotiation, channel state, channel data, and +power. Requests that change state always have an ACK to synchronize +the state between the local and remote subsystems. + +The transport interface is implemented as follows: + +struct glink_transport_if { + /* Negotiation */ + void (*tx_cmd_version)(struct glink_transport_if *if_ptr, + uint32_t version, + uint32_t features); + void (*tx_cmd_version_ack)(struct glink_transport_if *if_ptr, + uint32_t version, + uint32_t features); + void (*set_version)(struct glink_transport_if *if_ptr, uint32_t version, + uint32_t features); + + /* channel state */ + int (*tx_cmd_ch_open)(struct glink_transport_if *if_ptr, uint32_t lcid, + const char *name); + int (*tx_cmd_ch_close)(struct glink_transport_if *if_ptr, + uint32_t lcid); + void (*tx_cmd_ch_remote_open_ack)(struct glink_transport_if *if_ptr, + uint32_t rcid); + void (*tx_cmd_ch_remote_close_ack)(struct glink_transport_if *if_ptr, + uint32_t rcid); + int (*ssr)(struct glink_transport_if *if_ptr); + + /* channel data */ + int (*allocate_rx_intent)(size_t size, + struct glink_core_rx_intent *intent); + int (*deallocate_rx_intent)(struct glink_core_rx_intent *intent); + + int (*tx_cmd_local_rx_intent)(struct glink_transport_if *if_ptr, + uint32_t lcid, size_t size, uint32_t liid); + void (*tx_cmd_local_rx_done)(struct glink_transport_if *if_ptr, + uint32_t lcid, uint32_t liid); + int (*tx)(struct glink_transport_if *if_ptr, uint32_t lcid, + struct glink_core_tx_pkt *pctx); + int (*tx_cmd_rx_intent_req)(struct glink_transport_if *if_ptr, + uint32_t lcid, size_t size); + int (*tx_cmd_remote_rx_intent_req_ack)( + struct glink_transport_if *if_ptr, + uint32_t lcid, bool granted); + int (*tx_cmd_set_sigs)(struct glink_transport_if *if_ptr, + uint32_t lcid, uint32_t sigs); + + /* Optional. If NULL at xprt registration, dummies will be used */ + int (*poll)(struct glink_transport_if *if_ptr, uint32_t lcid); + int (*mask_rx_irq)(struct glink_transport_if *if_ptr, uint32_t lcid, + bool mask, void *pstruct); + int (*wait_link_down)(struct glink_transport_if *if_ptr); + int (*tx_cmd_tracer_pkt)(struct glink_transport_if *if_ptr, + uint32_t lcid, struct glink_core_tx_pkt *pctx); + + /* private pointer for core */ + struct glink_core_xprt_ctx *glink_core_priv; + + /* core pointer (set during transport registration) */ + struct glink_core_if *glink_core_if_ptr; +}; + +G-Link Core Interface +--------------------- +The G-Link Core Interface is used by the transport to call back into G-Link +core for messages or events received from the transport. This interface has +APIs for transport negotiation, power, channel state, and channel data. +Like the transport interface, requests that change state always have an ACK +to synchronize the state between the local and remote subsystems. + +The G-Link Core Interface is implemented as follows: + +struct glink_core_if { + /* Negotiation */ + void (*link_up)(struct glink_transport_if *if_ptr); + void (*rx_cmd_version)(struct glink_transport_if *if_ptr, + uint32_t version, + uint32_t features); + void (*rx_cmd_version_ack)(struct glink_transport_if *if_ptr, + uint32_t version, + uint32_t features); + + /* channel management */ + void (*rx_cmd_ch_remote_open)(struct glink_transport_if *if_ptr, + uint32_t rcid, const char *name); + void (*rx_cmd_ch_open_ack)(struct glink_transport_if *if_ptr, + uint32_t lcid); + void (*rx_cmd_ch_remote_close)(struct glink_transport_if *if_ptr, + uint32_t rcid); + void (*rx_cmd_ch_close_ack)(struct glink_transport_if *if_ptr, + uint32_t lcid); + void (*ch_state_local_trans)(struct glink_transport_if *if_ptr, + uint32_t lcid, + enum local_channel_state_e new_state); + + /* channel data */ + struct glink_core_rx_intent *(*rx_get_pkt_ctx)( + struct glink_transport_if *if_ptr, + uint32_t rcid, uint32_t liid); + void (*rx_put_pkt_ctx)(struct glink_transport_if *if_ptr, uint32_t rcid, + struct glink_core_rx_intent *intent_ptr, bool complete); + void (*rx_cmd_remote_rx_intent_put)(struct glink_transport_if *if_ptr, + uint32_t rcid, uint32_t riid, size_t size); + void (*rx_cmd_tx_done)(struct glink_transport_if *if_ptr, uint32_t rcid, + uint32_t riid); + void (*rx_cmd_remote_rx_intent_req)(struct glink_transport_if *if_ptr, + uint32_t rcid, size_t size); + void (*rx_cmd_rx_intent_req_ack)(struct glink_transport_if *if_ptr, + uint32_t rcid, bool granted); + void (*rx_cmd_remote_sigs)(struct glink_transport_if *if_ptr, + uint32_t rcid, uint32_t sigs); + + /* channel scheduling */ + void (*tx_resume)(struct glink_transport_if *if_ptr); +}; + +Power Management +================ + +Power management has yet to be implemented. See the "To do" section for more +information. + +SMP/multi-core +============== + +Locking and synchronization will be done using mutexes or spinlocks where +appropriate. + +Security +======== + +No known security issues. + +Performance +=========== + +No known performance issues. + +Client Interface +================ + +Open +---- +void *glink_open(const struct glink_open_config *cfg) + +Opens a logical channel. When this function is called, a notification is sent +to the remote processor. Once the remote processor responds with an open +command, the channel will be opened locally. At this point, the channel is +considered fully open and ready for data operations. The client will be notified +at this point with a GLINK_CONNECTED notification. + +When a channel is opened by calling glink_open(), a structure of configuration +information (struct glink_open_config) is passed to it. This includes the name +of the transport, the name of the edge, and the name of the channel, along with +pointers to notification functions: + * notify_rx() - Notify the client that data has been received + * notify_tx_done() - Notify the client that data has been transmitted + * notify_state() - Notify the client that the channel's state has + changed + * notify_rx_intent_req() - Notify the client whether their request for a + receive intent was granted + * notify_rxv() - Receive notification for vector buffers + * notify_rx_sigs() - Notification callback for change in state of remote + side's control signals. + * notify_rx_abort() - During channel close, return structures associated with + receive intents to the client. + * notify_tx_abort() - During channel close, return structures associated with + TX packets to the client. + * notify_rx_tracer_pkt() - Receive notification for tracer packet + +This structure is copied internally during the glink_open() call. The full +definition of the structure is below: + +struct glink_open_config { + unsigned options; + + const char *transport; + const char *edge; + const char *name; + + struct glink_ch_ctx (*notify_rx)(void *handle, const void *priv, + const void *pkt_priv, const void *ptr, size_t size); + struct glink_ch_ctx (*notify_tx_done)(void *handle, const void *priv, + const void *pkt_priv, const void *ptr); + struct glink_ch_ctx (*notify_state)(void *handle, const void *priv, + unsigned event); + bool (*notify_rx_intent_req)(void *handle, const void *priv, + size_t req_size); + struct glink_ch_ctx (*notify_rxv)(void *handle, const void *priv, + const void *pkt_priv, void *iovec, size_t size, + void *(*vbuf_provider)(void *iovec, size_t offset, + size_t *size), + void *(*pbuf_provider)(void *iovec, size_t offset, + size_t *size)); + struct glink_ch_ctx (*notify_rx_sigs)(void *handle, const void *priv, + uint32_t old_sigs, uint32_t new_sigs); + struct glink_ch_ctx (*notify_rx_abort)(void *handle, const void *priv, + const void *pkt_priv); + struct glink_ch_ctx (*notify_tx_abort)(void *handle, const void *priv, + const void *pkt_priv); + struct glink_ch_ctx (*notify_rx_tracer_pkt)(void *handle, + const void *priv, const void *pkt_priv, const void *ptr, + size_t size); +}; + +The following are the possible event notification values. The GLINK_CONNECTED +notification is sent using the notify_state() callback once the channel has +been fully opened. See the Close section for the closing state details. +enum { + GLINK_CONNECTED, + GLINK_LOCAL_DISCONNECTED, + GLINK_REMOTE_DISCONNECTED, +}; + +glink_open() returns the following standard error codes: + * ERR_PTR(-EINVAL) - The glink_open_config structure which was passed to + glink_open() is invalid. + * ERR_PTR(-ENODEV) - No transport is available. + * ERR_PTR(-EBUSY) - The requested channel is not ready to be re-opened. + +Close +----- +int glink_close (void *handle) + +Closes the logical channel. Once the close request has been processed by the +remote processor, the GLINK_LOCAL_DISCONNECTED notification is sent to the +client. If the remote processor closes the channel first, then the +GLINK_REMOTE_DISCONNECTED notification is sent to the client. After the +GLINK_LOCAL_DISCONNECTED notification is sent, no additional activity will occur +on the channel, regardless of whether the GLINK_REMOTE_DISCONNECTED notification +was sent or not. At this point, it's safe for the callbacks and/or their +resources to be destroyed. If the client wishes to re-establish communication +on the channel, then the client will need to re-open the channel. + +glink_close() returns the following standard error codes: + * -EINVAL - The channel to be closed is NULL. + * -EBUSY - The channel to be closed is already closing. + +If the channel to be closed is already closed, 0 is returned. + +Transmit Data +------------- +int glink_tx(void *handle, void *pkt_priv, void *data, size_t size, + bool req_intent) + +Arguments: +handle: The handle returned by glink_open() +pkt_priv: Opaque data value that will be returned to client with the + notify_tx_done() notification +data: Pointer to the data being sent +size: Size of the data being sent +req_intent: Boolean indicating whether or not to request an intent from the + remote channel + +Transmit data packet for a matching RX Intent. + +If a client would like to transmit a packet, but a suitable RX Intent has not +been queued, the client can request that glink_tx() block and request a +receive intent from the remote system. The remote system can still deny the +request at which point glink_tx() will return -EAGAIN to the client. The call +sequence for this exchange is: + + 1. Client wants to transmit a packet, and sets the req_intent flag to true in + the call to glink_tx() in order to request an intent if one is not already + available. + 3. Remote G-Link calls its client's notify_rx_intent_req() function and that + client returns a boolean indicating whether the intent will be granted or + not + 4. If the client grants the remote intent request, glink_tx() receives the + intent and returns success + 5. If the client rejects the remote intent request, glink_tx() returns an error + +int glink_txv(void *handle, void* pkt_priv, const void *iovec, size_t size, + glink_buffer_provider_fn vbuff_provider, + glink_buffer_proivder_fn pbuff_provider, + bool req_intent) + +Arguments: +handle: The handle returned by glink_open() +pkt_priv: Opaque data value that will be returned to client with the + notify_tx_done() notification +iovec: Pointer to the vector +size: Size of the data being sent +vbuf_provider: Client-provided helper function to iterate the vector in + virtual address space +pbuf_provider: Client-provided helper function to iterate the vector in + physical address space +req_intent: Boolean indicating whether or not to request an intent from the + remote channel + +glink_txv() provides a transmit function that accommodates clients using vector +buffer implementations (DSM, SKB, etc.), and allows transports to operate on +virtual or physical address mappings when necessary. This is done through the +vbuf_provider() and pbuf_provider() functions, which are defined by the client +and return a pointer to the contiguous vector data after iteration. After +assembling the data from the vector, the call sequence is the same as +glink_tx(). + +Queue Receive Intent +-------------------- +int glink_queue_rx_intent(void *handle, const void *pkt_priv, size_t size) + +Queues a receive intent. A receive intent indicates that the client is ready to +receive a packet up to the specified size. The transport interface will either +reserve space for this packet or allocate a buffer to receive this packet such +that the packet can be received without stalling the physical transport. + +The pkt_priv parameter is an opaque value provided by the client that is +returned in the notify_rx() callback. + +Signal Consumption of Receive Buffer +------------------------------------ +int glink_rx_done(void *handle, const void *ptr) + +This function is called by the client to signal that they are done with the +receive buffer. The remote client is notified that it now owns the buffer again. + +Set Control Signal Field +------------------------ +glink_sigs_set(void *handle, uint32 *sig_value) + +This function is called by the client to set a 32-bit control signal field. +Depending on the transport, it may take appropriate actions on the set bit-mask, +or transmit the entire 32-bit value to the remote host. + +Get Local Control Signal Field +------------------------------ +glink_sigs_local_get(void *handle, uint32 *sig_value) + +This function is called by the client to retrieve the cached signals sent +using glink_sigs_set(). + +Get Remote Control Signal Field +------------------------------- +glink_sigs_remote_get(void *handle, uint32 *sig_value) + +This function is called by the client to retrieve the cached remote signals +that were passed to notify_rx_sigs(). + +Register a Transport +-------------------- +int glink_core_register_transport(struct glink_transport_if *if_ptr, + struct glink_core_transport_cfg *cfg) + +Register a new transport with the G-Link Core. The if_ptr parameter is the +interface to the transport, and the cfg parameter is the configuration, which +contains the following information: + * The name of the transport + * The edge of the transport, i.e. remote processor name + * An array of the transport versions supported + * The maximum number of entries in the versions array + * The maximum number of channel identifiers supported + * The maximum number of intent identifiers supported + +The implementation of this transport configuration structure is below. + +struct glink_core_transport_cfg { + const char *name; + const char *edge; + const struct glink_core_version *versions; + size_t versions_count; + uint32_t max_cid; + uint32_t max_iid; +}; + +The initial state of a transport after it is registered is GLINK_XPRT_DOWN. +The possible states of a transport are as follows: +enum transport_state_e { + GLINK_XPRT_DOWN, + GLINK_XPRT_NEGOTIATING, + GLINK_XPRT_OPENED, + GLINK_XPRT_FAILED, +} + +Unregister a Transport +---------------------- +void glink_core_unregister_transport(struct glink_transport_if *if_ptr) + +Unregister/destroy an existing transport. The transport's state is changed to +GLINK_XPRT_DOWN, and the following values are reset: + * the next local channel ID + * The local version index + * The remote version index + * The version negotiation completion flag + * The list of channels on the transport (list is deleted) + +Driver parameters +================= + +The G-Link core and G-Link Loopback Server modules both have a module parameter +called "debug_mask". The possible values are detailed in the "Config options" +section. + +Config options +============== + +G-Link supports several logging configurations. The following options are +available for the core and loopback client. They can be bitwise OR'ed together +to have multiple options at once. + +QCOM_GLINK_INFO - The default option. Turn on only INFO messages +QCOM_GLINK_DEBUG - Turn on debug log messages - much more verbose logging to + aid in debugging. +QCOM_GLINK_PERF - Performance logging. This removes all other logging except + for logging messages that are created through a special + set of macros. These logs can be post-processed for + performance metrics. + +The values of these options are as follows: +enum { + QCOM_GLINK_INFO = 1U << 0, + QCOM_GLINK_DEBUG = 1U << 1, + QCOM_GLINK_PERF = 1U << 2, +}; + +Dependencies +============ + +IPC Logging is a dependency of the G-Link core. The Transport Plug-ins will have +their own dependencies. The SMEM Native Transport depends on SMEM and the +interrupt subsystem. + +DebugFS +======= + +Several DebugFS nodes are exported under the glink directory for testing and +debugging. The directory structure below allows listing information by +subsystem, channel, and transport. + +glink Directory +--------------- +`-- debugfs + `-- glink + |-- channel + | |-- channels <- lists all of the channels in the system, their + | | state, the transport they are assigned to, etc. + | |-- SUBSYSTEM_NAME <- directory (such as "mpss") + | | `-- CHANNEL_NAME <- one directory per channel + | | |-- intents <- list of all open intents, their size, and + | | | their ID + | | `-- stats <- statistics for the channel (contents TBD) + `-- xprt + |-- xprts <- lists all of the transports in the system and basic + | transport-specific state + |-- XPRT_NAME <-- directory (such as "smem") + `-- XPRT_INFO <-- transport specific files + +User space utilities +==================== + +A user space driver is provided which can export a character device for a single +channel based upon Device Tree configuration. The full DT schema is detailed in +Documentation/devicetree/bindings/arm/msm/glinkpkt.txt. The user space driver +implements the standard file operations of open, release, read, write, poll, and +mmap. An ioctl is defined to queue RX intents. + +The file operations map to the G-Link Client API as follows: +open() -> glink_open() (Open a channel. Exported channels configured + through DT) +write() -> glink_tx() (Transmit data) +read() -> Receive data and send RX done notification (glink_rx_done()) +release() -> glink_close() (Close a channel) +ioctl() -> glink_queue_rx_intent() + +Other operations are: +poll() -> Poll waiting for the channel to become available +mmap() -> Prevent having to do a copy between kernel space and user space + for clients that need that performance. + +A typical transmit and receive call flow is as follows: +1. G-Link user space driver opens the channel using open(), which returns a + file descriptor for the channel +2. An ioctl is sent to queue an RX intent on the channel +3. Data is transmitted on the channel using write() +4. The data is received using read(). read() also sends an RX done + notification. + +Version/Feature Negotiation +=========================== + +To enable upgrading transports, G-Link supports a version number and feature +flags for each transport. The combination of the version number and feature +flags enable: + 1. G-Link software updates to be rolled out to each processor + separately. + 2. Individual features to be enabled or disabled on an edge-by-edge + basis. + +Endpoints negotiate both the version and the feature flags when the transport +is opened; they cannot be changed after negotiation has been completed. + +The version number represents any change in G-Link or the transport that +breaks compatibility between processors. Examples would be a change in the +shared data structures or changes to fundamental behavior in either the +transport or in G-Link Core. Each full implementation of G-Link must support a +minimum of the current version, the previous version, and the base negotiation +version called v0. For resource-constrained devices, this can be relaxed to +only support the latest version of the protocol and the v0 version. + +The feature flags represent any changes in G-Link that are optional and +backwards-compatible. Feature flags can be version-specific, but to limit code +maintenance and documentation overhead, feature flags should not be re-used +unless the limit of 32 feature flags has been reached. + +Negotiation Algorithm +--------------------- +After a transport is registered with G-Link core, it should be configured with +the v0 transport settings. Once communication can be done without losing +messages, the link_up() call in the G-Link core should be made to start the +negotiation process. Both the local and remote sides will follow the same +negotiation state machines. + +Since both sides follow the same sequence and both sides start once the link is +up, it is possible that both sides may start the negotiation sequence at the +same time resulting in a perceived race condition. However, both negotiation +sequences are independent and the transport is not considered opened until both +negotiation sequences are complete, so this is not a true race condition and +both sides will converge to the same version and feature set even if they +start with different versions and feature sets. Since this sequence is not +performance-critical, the extra complexity in the negotiation algorithm to +short-circuit the process is not deemed necessary. + +Local-Initiated Negotiation Sequence +------------------------------------ +The following local negotiation sequence is initiated and followed by each +side. The processor that is running this algorithm will be matched by the +remote processor following the Remote-Initiated Negotiation Sequence. + + 1. Set current version and feature variables to the maximum supported version + and feature set + 2. Send Version Command (glink_transport_if::tx_cmd_version()) with local + version and feature set + 3. If version is 0, then negotiation has failed and the transport should be + marked as having failed negotiation and the negotiation sequence + terminated. + 4. When Version ACK is received (glink_core_if::rx_cmd_version_ack()): + a. Compare ACK version to the sent version and: + i. If equal, we are done with version negotiation + ii. Else set current version to the lower of: + 1. Remote version number + 2. Highest supported local version + b. Compare ACK features to the sent features and: + i. If equal, we are done with the negotiation sequence + ii. Else, call glink_core_version:: negotiate_features() for the + current version to set the features to either the bitwise AND of + the ACK features and the locally supported features or a lesser + feature set for cases where only certain combinations of features + are valid. + c. Go back to step 2 to send the updated version/feature set + +Remote-Initiated Negotiation Sequence +------------------------------------- +The following remote negotiation sequence is followed by each side based upon +receiving a Version Command. + + 1. Receive Version Command (glink_core_if::rx_cmd_version()) + 2. Compare received version with the locally supported version and: + a. If equal, set ACK version to the received version + b. Else, set ACK version to the lower of: + i. Remote version number + ii. Highest supported local version + iii. Version 0 if no supported version less than or equal to + the remote version number can be found. + 3. Compare received features with the locally supported features and: + a. If equal, set ACK features to the received features + b. Else, call glink_core_version:: negotiate_features() for the current + version to set the features to either the bitwise AND of the ACK + features and the locally supported features or a lesser feature set + for cases where only certain combinations of features are valid. + 4. Send the Version ACK Command (glink_transport_if::tx_cmd_version_ack()). + +Packets +======= + +Packets are scheduled in a round-robin fashion from all active channels. Large +packets can be fragmented by the transport to ensure fairness between channels +and ensure latency. + +Channel Migration +================= + +The G-Link core has the capability of selecting the best transport available on +an edge-by-edge basis. The transport is selected based upon a pre-defined +transport priority and from optional transport selection information passed in +by the client in the glink_open_config structure. + +Subsystem Restart (SSR) +======================= + +In order to properly clean up channel state and recover buffer ownership +consistently across different physical transports, G-Link requires an +additional SSR notification system on top of the existing SSR framework. The +notification system is a star topology with the application processor as the +master. When a subsystem is restarted, all other subsystems are notified by the +application processor and must respond after cleaning up all affected channels +before the SSR event is allowed to continue. + +The solution has four components: + 1. Target-specific configuration for each subsystem, which consists of a list + of which subsystems should be notified in the event of SSR, specified in + Device Tree + 2. SSR module that uses the G-Link Client API to isolate SSR functionality, + and handles calls to the SSR Framework, Device Tree parsing, etc. + 3. SSR notification messages between the application processor and + other subsystems, which will be exchanged using G-Link. + 4. SSR API: + a. glink_ssr(const char *subsystem_name) - G-Link Client API + b. ssr(struct glink_transport_if *if_ptr) - Transport Interface + +1. Target-specific configuration using Device Tree +-------------------------------------------------- +The target-specific configuration provides the G-Link SSR module with a list +of subsystems that should be notified in the event of SSR. This is necessary +to simplify handling of cases where there are multiple SoCs in one device - +there is no need to notify a subsystem on a second SoC of a restart in the +first SoC. The configuration also provides a mapping of the subsystem's name +in the SSR framework to its name as a G-Link edge, and allows the specification +of a transport for each notification. The figures below provide an example: + ++----+ +------+ +-------------------+ +|SSR |----->|G-Link|------->|Subsystem A | +|Name| |Name | |Subsystem B: xprt x| ++----+ +------+ |Subsystem C | + +-------------------+ + ++-------+ +------+ +--------------+ +|"modem"|----->|"mpss"|------->|"wcnss" | ++-------+ +------+ |"lpass": "smd"| + |"dsps" | + +--------------+ + +The above configuration tells the G-Link SSR module to notify all subsystems +on G-Link edges "wcnss", "lpass", and "dsps" that the subsystem on edge "mpss" +has restarted, and to send the notifications to the "lpass" edge on the "smd" +transport. + +2. G-Link SSR Module (glink_ssr) +-------------------------------- +This module is a G-Link client which handles notifications from the SSR +framework on the application processor and triggers local clean-up in response +to these notifications by calling glink_ssr(const char *subsystem). This +module also sends notifications to any subsystems that need to be notified of +the SSR event, and ensures that they respond within the standard timeout (500 +ms). If the subsystem fails to respond, it is restarted. + +3. G-Link SSR Messages +---------------------- +When an SSR event occurs, the application processor notifies all necessary +subsystems by sending a "do_cleanup" message. After the subsystem performs the +necessary clean-up, it sends back a "cleanup_done" message. If the +"cleanup_done" message for a given subsystem is not received within the +standard timeout (500 ms), the subsystem is restarted. + +SSR "do_cleanup" Message +------------------------ ++-----------------+-----------------------+------------------------------+ +| Element | Type | Description | ++=================+=======================+==============================+ +| version | uint32_t | G-Link SSR Protocol Version | ++-----------------+-----------------------+------------------------------+ +| command | uint32_t | do_cleanup message (0) | ++-----------------+-----------------------+------------------------------+ +| sequence_number | uint32_t | Sequence number | ++-----------------+-----------------------+------------------------------+ +| name_len | uint32_t | Name length of the subsystem | +| | | being restarted | ++-----------------+-----------------------+------------------------------+ +| name | char[GLINK_NAME_SIZE] | NULL-terminated name of the | +| | | subsystem being restarted | +| | | (GLINK_NAME_SIZE == 32) | ++-----------------+-----------------------+------------------------------+ + +SSR "cleanup_done" Message +-------------------------- ++-----------------+-----------------------+------------------------------+ +| Element | Type | Description | ++=================+=======================+==============================+ +| version | uint32_t | G-Link SSR Protocol Version | ++-----------------+-----------------------+------------------------------+ +| response | uint32_t | cleanup_done message (1) | ++-----------------+-----------------------+------------------------------+ +| sequence_number | uint32_t | Sequence number | ++-----------------+-----------------------+------------------------------+ + +G-Link SSR Protocol Sequence Diagram +------------------------------------ + +------+ +------+ ++---------+ |G-Link| |G-Link| +----------+ +|SSR | |SSR | |Client| +---------+ |Remote | +|Framework| |Module| |API | |Transport| |Processors| ++---------+ +------+ +------+ +---------+ +----------+ + | | | | | + | SSR | | | | + | Notification | | | | + +--------------->| | | | + | | | | | + | | | | | + | | | | | + | | do_cleanup | | | + | +------------------------------------------------>| + | | | | | + | | glink_ssr(subsystem) | | + | +------------->| | | + | | | | | + | | | | | + | | | ssr(if_ptr) | | + | | +-------------->| | + | | | | | + | | | | | + | | | | | + | | | | cleanup_done | + | |<------------------------------------------------+ + | | | | | + | | | | | + | | | | | + | ssr(subsystem)| | | | + |<---------------+ | | | + | | | | | + | +-----------+---------+ | | | + | |If no cleanup_done | | | | + | |response is received,| | | | + | |restart the subsystem| | | | + | +-----------+---------+ | | | + | | | | | + | | | | | + | | | | | + | | | | | + | | | | | ++---------+ +------+ +------+ +---------+ +----------+ +|SSR | |G-Link| |G-Link| |Transport| |Remote | +|Framework| |SSR | |Client| +---------+ |Processors| ++---------+ |Module| |API | +----------+ + +------+ +------+ + +4. SSR API +---------- +glink_ssr(const char *subsystem_name) +------------------------------------- +Called by the G-Link SSR Module, this function calls into the transport using +ssr(struct glink_transport_if *if_ptr) to allow the transport to perform any +necessary clean-up, and simulates receiving a remote close from the restarting +subsystem for all channels on the affected edge. + +ssr(struct glink_transport_if *if_ptr) +-------------------------------------- +The ssr() function is part of the Transport Interface, and as mentioned above is +used to perform any necessary clean-up on the transport. + +Tracer Packet Framework +======================= + +A tracer packet is a special type of packet that can be used to trace the timing +of events. This helps profile the latency experienced by a packet, and provides +granular information regarding the individual latencies that make up the overall +latency. The information obtained using the tracer packet can be used to +configure the Power Management Quality of Service (PM QoS) in the system in +order to achieve a client's desired packet latency. The tracer packet moves +through the system along with other normal traffic without any impact on the +normal traffic. + +When a transport is registered with the local G-Link core, it performs a +transport-specific version and feature negotiation with the remote G-Link core. +Based on this negotiation, the transport reports its capability of supporting +tracer packets to the local G-Link core. + +Once the transport has successfully completed the negotiation, the clients open +the G-Link channel over the concerned transport. After the channel is open, the +clients can exchange tracer packets over G-Link, in a way similar to normal +traffic. + +When a tracer packet is exchanged over a G-Link channel, the G-Link core and the +transport log events related to packet exchange and their time. + +1. Tracer Packet Format +----------------------- +The tracer packet contains a header and a payload. The header contains +identification and configuration information associated with a tracer packet. +The payload contains a series of event logs. The below diagram shows the layout +of the tracer packet: + +Tracer Packet Header Layout +--------------------------- + 31 16 15 14 13 12 11 4 3 0 ++-------------------------------+-----+---+----+------+---------+ +| Packet Length (words) | CCL | Q | ID | Res. | Version | ++-------------------------------+-------------------------------+ +| Client Event Cfg. | Packet Offset (words) | +| Bit Mask | | ++-------------------------------+-------------------------------+ +| G-Link Event Config Bit Mask | ++---------------------------------------------------------------+ +| Base Timestamp (MS 32 bits) | ++---------------------------------------------------------------+ +| Base Timestamp (LS 32 bits) | ++---------------------------------------------------------------+ +| Client Cookie | ++---------------------------------------------------------------+ + +Tracer Packet Payload Layout +---------------------------- + 31 16 15 0 ++-------------------------------+-------------------------------+ +| Reserved | Event 1 ID | ++-------------------------------+-------------------------------+ +| Event 1 Timestamp (LS 32 bits) | ++---------------------------------------------------------------+ + . + . + . ++-------------------------------+-------------------------------+ +| Reserved | Event N ID | ++-------------------------------+-------------------------------+ +| Event N Timestamp (LS 32 bits) | ++---------------------------------------------------------------+ + +Tracer Packet Header Fields +--------------------------- +Version - This field contains the tracer packet version. The current version + of tracer packet supported by G-Link is 1. If a version of the tracer + packet is not supported by G-Link or its transport abstraction layer, + the tracer packet is still exchanged, but no events are logged. + +Reserved - The reserved bit fields are set to 0 and can be used for future + extension of tracer packet functionality. + +ID - The ID bit field indicates the presence or absence of the Source Processor + ID, Destination Processor ID and Transport ID fields in the tracer + packet. Currently this field is set to 0 and the concerned IDs are not + defined. + +CoreSight ("Q" in the diagram above) - This bit field is used to indicate the + location of the log events. If this bit + field is set, the log events are logged + into CoreSight, otherwise the log events + are logged into the packet itself. If the + log events are logged into the packet, + then the number of events logged into the + packet depends on the size of the packet. + +CCL - The tracer packet framework allows clients to differentiate multiple + tracer packets through a client-specified cookie. The Client Cookie Length + (CCL) bit field indicates the length of that cookie in units of words. + +Packet Length - These 16 bits indicate the length of the tracer packet in units + of words. + +Packet Offset - This field is used when events are logged into the packet. This + 16-bit field indicates the offset into the packet, in units of + words, to log an event. Once an event is logged, this field is + updated with the appropriate offset to log future events. + +Client Configuration Bit Mask - This bit-mask is used to enable/disable the + G-Link client-specific events. The procedure to + enable/disable client events is dependent upon + the client's implementation and is not included + in this document. + +G-Link Configuration Bit Mask - This bit-mask is used to enable/disable the + G-Link-specific events. When a bit is set, the + concerned event logging is enabled. + +Base Timestamp - The base timestamp contains the starting time of the tracer + packet exchange. The timestamp logged along with the event is + used as an offset from this base timestamp. This optimization + helps in reducing the log size of an event. + +Client Cookie - The tracer packet framework allows clients to differentiate + multiple tracer packets through a client-specified cookie. + +Tracer Packet Payload Fields +---------------------------- +Event ID - The Event ID field uniquely identifies the G-Link and client-specific + tracer packet events. This field is present only when the events are + logged into the packet. The G-Link and client event IDs are assigned + a unique range. Refer to the table below for more information + regarding the event ID definition. + +Reserved - The reserved field is set to 0 and can be used for future extension + of tracer packet functionality. + +Event Timestamp - The Event Timestamp field contains the time at which the event + is logged. This field is used as an offset from the Base + Timestamp field in the header to calculate the actual event + timestamp. This field is present only when the events are + logged into the packet. + +2. Tracer Packet Events +----------------------- +Each event has a uniquely defined ID. Since G-Link clients can use the tracer +packet framework, G-Link events and G-Link client events are defined in mutually +exclusive ranges. Since client events are client-context specific, the event +IDs can be reused among the clients. The ranges are detailed in the table below: ++--------------------------+-----------------------+ +| Event Type | Range | ++==========================+=======================+ +| G-Link | 1-255 | ++--------------------------+-----------------------+ +| Client | 255 and above | ++--------------------------+-----------------------+ + +The G-Link specific events and their associated IDs are defined in the below +table: ++--------------------------+-----------------------+ +| G-Link Event | ID | ++==========================+=======================+ +| GLINK_CORE_TX | 1 | ++--------------------------+-----------------------+ +| GLINK_QUEUE_TO_SCHEDULER | 2 | ++--------------------------+-----------------------+ +| GLINK_SCHEDULER_TX | 3 | ++--------------------------+-----------------------+ +| GLINK_XPRT_TX | 4 | ++--------------------------+-----------------------+ +| GLINK_XPRT_RX | 5 | ++--------------------------+-----------------------+ +| GLINK_CORE_RX | 6 | ++--------------------------+-----------------------+ + +3. Tracer Packet API +-------------------- +tracer_pkt_init(void *data, size_t data_len, uint16_t client_event_cfg, + uint32_t glink_event_cfg, void *pkt_priv, size_t pkt_priv_len) +-------------------------------------------------------------------------- +Initialize a buffer with the tracer packet header. The tracer packet header +includes the data passed in the parameters. + +tracer_pkt_set_event_cfg(void *data, uint16_t client_event_cfg, + uint32_t glink_event_cfg) +--------------------------------------------------------------- +Initialize a buffer with the event configuration mask passed in the parameters. + +tracer_pkt_log_event(void *data, uint32_t event_id) +--------------------------------------------------- +Log an event specific to the tracer packet. The event is logged either into +the tracer packet itself or a different tracing mechanism as configured. + +tracer_pkt_calc_hex_dump_size(void *data, size_t data_len) +---------------------------------------------------------- +Calculate the length of the buffer required to hold the hex dump of the tracer +packet. + +tracer_pkt_hex_dump(void *buf, size_t buf_len, void *data, size_t data_len) +--------------------------------------------------------------------------- +Dump the contents of the tracer packet into a buffer in a specific hexadecimal +format. The hex dump buffer can then be dumped through debugfs. + +Known issues +============ + +No known issues. + +To do +===== + +Power Management +---------------- +An internal power voting API will be defined to bring the transport out of power +collapse for SMUX and BAM DMUX-type systems. In addition, power for +request/response type systems can be optimized to prevent powering down +unnecessarily after sending a request only to power up immediately to process +the response. + +Round-Robin Scheduling +---------------------- +Add deficit round-robin schedule to ensure fairness between channels that have +a large number of small packets and channels that are sending the maximum +MTU-sized packets. + +Transport Filter Internal API +----------------------------- +An internal transport filter API will be defined. This can be plugged into a +filter chain at the transport level to easily add data coding, encryption, +integrity hashes, etc. diff --git a/Documentation/arm/msm/glink_pkt.txt b/Documentation/arm/msm/glink_pkt.txt new file mode 100644 index 000000000000..c6c7740472aa --- /dev/null +++ b/Documentation/arm/msm/glink_pkt.txt @@ -0,0 +1,196 @@ +Introduction +============ + +Glink packet drivers are companion adaptation driver which use the kernel APIs +to expose the Glink core logical channels as charecter devices to the +user-space clients. + +The Glink core APIs are detailed in Documentation/arm/msm/glink.txt. + +Software description +==================== + +Glink packet drivers supports the Glink core APIs to user-space client through +standard file operations like open, read, write, ioctl, poll and release etc. +The standard Linux permissions are used for the device node and SELinux does +further security checks. + + + Device node [0..n] + | + | + ------------------- + | VFS Framework | + ------------------- + | | + | | + ------- ------- + | CDEV | | CDEV | + | Dev 0 |...| Dev n | + ---------------------- +| Glink packet driver | + ---------------------- + | + | + ----------------- + | | + | G-Link core | + | | + ----------------- + | + | + To Remote System + + +The file operations map to the G-link client API as follows: + +Open(): +---------- +The Open system call is mapped to glink_open() which opens a channel. The +expected channel configuration has to done through DT files. The full DT schema +is detailed in Documentation/devicetree/bindings/arm/msm/glinkpkt.txt. + +Open on the glink packet character device is a blocking call which blocks until +the channel is fully open by both local processor and remote processor. +Clients can configure the blocking time through a device configurable parameter +defined per device. + +The timeout value is specified in seconds with a default timeout of 1 second. +A negative value indicates an infinite wait. + +Example: +# get open timeout value + cat /sys/class/glinkpkt/device_name/open_timeout +# set to 20 seconds value + echo 20 > /sys/class/glinkpkt/device_name/open_timeout + +If the channel is not opened by remote processor or any other problem which +fails the channel to be ready will result in timeout and -ETIMEOUT will return +to client. Open on success returns the valid file descriptor to client and on +fail case standard Linux error codes. + +The same device can be opened by multiple clients but passing the same file +descriptor from multiple threads may lead unexpected results. + +Write(): +---------- +The Write system call is mapped to glink_tx() which transmits the data over the +glink channel. + +Read(): +---------- +The Read system call consumes any pending data on the channel. Glink signals +incoming data through the glink_notify_rx() call back and the glink packet +driver queues the data internally and provides to client through read system +call. Once the Read is completed, the glink packet driver calls glink_rx_done() +API to notify the completion of receiving operation to Glink core. + + + + User-Space | Kernel-Space + | + | ++---------+ | +----------+ +------------+ +| Local | | | GlinkPKT | | | +| Client | | | Driver | | Glink core | +| | | | | | | ++---------+ | +----------+ +------------+ + | + + | + + + | | | | + | open() | glink_pkt_open() | glink_open() | + | +--------------> | +-----------------> | +-----------------> | + | | | | + | File Handle[fd]| Valid Fd | Handle | + | <--------------+ | <-----------------+ | <-----------------+ | + | | | | + | Ioctl() | | | + | QUEUE_RX_INTENT | glink_pkt_ioctl() | glink_queue_rx_intent() + | +--------------> | +-----------------> | +-----------------> | + | | | | + | | | | + | <----------------------------------------------------------+ | + | | | | + | Read() | glink_pkt_read() | | + | +--------------> | +-----------------> | +---+ | + | | | | | + | | Wait for data | + | | | <---+ | + | | | glink_notify_rx() | + | | | <-----------------+ | + | | Wake-up read() | | + | | copy_to_user() | | + | read() return | <-----------------+ | | + | <--------------+ | | | + + | + + + | + | + + + +Clients can also poll on device node for POLLIN mask to get notification for +any incoming data. Clients have to call the GLINK_PKT_IOCTL_QUEUE_RX_INTENT +ioctl to queue the RX buffer to glink core in advance. + +Release(): +---------- +The Release system call is mapped to glink_close() to close a channel and free +the resources. + +Poll(): +---------- +The Poll system call provides waiting operation like wait for incoming data on +POLLIN mask and to get the TIOCM signal notification on POLLPRI mask. Clients +can wait on poll for POLLPRI mask to get any notification regarding TICOM +signals. In SSR case Poll call will return with POLLHUP mask and in this case +client has to close and re-open the port. + +* POLLPRI - TIOCM bits changed +* POLLIN - RX data available +* POLLHUP - link is down due to either remote side closing or an SSR + +Ioctl(): +---------- +Multiple ioctls are supported to get the TICOM signal status and to queue the +Rx intent with Glink core. Supported ioctls are TIOCMSET, TIOCMGET, TIOCMBIS, +TIOCMBIC and GLINK_PKT_IOCTL_QUEUE_RX_INTENT. + +The GLINK_PKT_IOCTL_QUEUE_RX_INTENT ioctl is mapped to glink_queue_rx_intent() +API which queues an RX intent with Glink core. + +Signals: +========== +Glink protocol provoide 32-bit control signal field to pass through for the +clients-specific signaling where as Glink packet driver client which are from +user space can use the signal filed as mentioned below. + +* 31:28 - Reserved for SMD RS-232 signals +* 27:16 - Pass through for client usage +* 15:0 - TICOM bits + +SSR operation: +============== +On remote subsystem restart all open channels on that edge will be closed and +local clients have to close and re-open the channel to re-start the +communication. All blocking calls such as open, read and write will be returned +with -ENETRESET and the poll call will be return with the POLLHUP error codes. + +Files: +========== +Documentation/devicetree/bindings/arm/msm/glinkpkt.txt +drivers/soc/qcom/msm_glink_pkt.c + +Wakelock: +========== +By default, GLINK PKT will acquire a wakelock for 2 seconds. To optimize this +behavior, use the poll() function: + 1. Client calls poll() which blocks until data is available to read + 2. Data comes in, GLINK PKT grabs a wakelock and poll()is unblocked + 3. Client grabs wakelock to prevent system from suspending + 4. Client calls GLINK PKT read() to read the data + 5. GLINK PKT releases its wakelock + 6. Client Processes the data + 7. Client releases the wakelock + +Logging: +========== + cat /d/ipc_logging/glink_pkt/log_cont + diff --git a/Documentation/arm/msm/msm_ipc_logging.txt b/Documentation/arm/msm/msm_ipc_logging.txt new file mode 100644 index 000000000000..9d4220017cce --- /dev/null +++ b/Documentation/arm/msm/msm_ipc_logging.txt @@ -0,0 +1,361 @@ +Introduction +============ + +This module will be used to log the events by any module/driver which +enables Inter Processor Communication (IPC). Some of the IPC drivers such +as Message Routers, Multiplexers etc. which act as a passive pipe need +some mechanism to log their events. Since all such IPC drivers handle a +large amount of traffic/events, using kernel logs renders kernel logs +unusable by other drivers and also degrades the performance of IPC +drivers. This new module will help in logging such high frequency IPC +driver events while keeping the standard kernel logging mechanism +intact. + +Hardware description +==================== + +This module does not drive any hardware resource and will only use the +kernel memory-space to log the events. + +Software description +==================== + +Design Goals +------------ +This module is designed to + * support logging for drivers handling large amount of + traffic/events + * define & differentiate events/logs from different drivers + * support both id-based and stream-based logging + * support extracting the logs from both live target & memory dump + +IPC Log Context +---------------- + +This module will support logging by multiple drivers. To differentiate +between the multiple drivers that are using this logging mechanism, each +driver will be assigned a unique context by this module. Associated with +each context is the logging space, dynamically allocated from the kernel +memory-space, specific to that context so that the events logged using that +context will not interfere with other contexts. + +Event Logging +-------------- + +Every event will be logged as a <Type: Size: Value> combination. Type +field identifies the type of the event that is logged. Size field represents +the size of the log information. Value field represents the actual +information being logged. This approach will support both id-based logging +and stream-based logging. This approach will also support logging sub-events +of an event. This module will provide helper routines to encode/decode the +logs to/from this format. + +Encode Context +--------------- + +Encode context is a temporary storage space that will be used by the client +drivers to log the events in <Type: Size: Value> format. The client drivers +will perform an encode start operation to initialize the encode context +data structure. Then the client drivers will log their events into the +encode context. Upon completion of event logging, the client drivers will +perform an encode end operation to finalize the encode context data +structure to be logged. Then this updated encode context data structure +will be written into the client driver's IPC Log Context. The maximum +event log size will be defined as 256 bytes. + +Log Space +---------- + +Each context (Figure 1) has an associated log space, which is dynamically +allocated from the kernel memory-space. The log space is organized as a list of +1 or more kernel memory pages. Each page (Figure 2) contains header information +which is used to differentiate the log kernel page from the other kernel pages. + + + 0 --------------------------------- + | magic_no = 0x25874452 | + --------------------------------- + | nmagic_no = 0x52784425 | + --------------------------------- + | version | + --------------------------------- + | user_version | + --------------------------------- + | log_id | + --------------------------------- + | header_size | + --------------------------------- + | | + | | + | name [20 chars] | + | | + | | + --------------------------------- + | run-time data structures | + --------------------------------- + Figure 1 - Log Context Structure + + + 31 0 + 0 --------------------------------- + | magic_no = 0x52784425 | + --------------------------------- + | nmagic_no = 0xAD87BBDA | + --------------------------------- + |1| page_num | + --------------------------------- + | read_offset | write_offset | + --------------------------------- + | log_id | + --------------------------------- + | start_time low word | + | start_time high word | + --------------------------------- + | end_time low word | + | end_time high word | + --------------------------------- + | context offset | + --------------------------------- + | run-time data structures | + . . . . . + --------------------------------- + | | + | Log Data | + . . . + . . . + | | + --------------------------------- PAGE_SIZE - 1 + Figure 2 - Log Page Structure + +In addition to extracting logs at runtime through DebugFS, IPC Logging has been +designed to allow extraction of logs from a memory dump. The magic numbers, +timestamps, and context offset are all added to support the memory-dump +extraction use case. + +Design +====== + +Alternate solutions discussed include using kernel & SMEM logs which are +limited in size and hence using them render them unusable by other drivers. +Also kernel logging into serial console is slowing down the performance of +the drivers by multiple times and sometimes lead to APPs watchdog bite. + +Power Management +================ + +Not-Applicable + +SMP/multi-core +============== + +This module uses spinlocks & mutexes to handle multi-core safety. + +Security +======== + +Not-Applicable + +Performance +=========== + +This logging mechanism, based on experimental data, is not expected to +cause a significant performance degradation. Under worst case, it can +cause 1 - 2 percent degradation in the throughput of the IPC Drivers. + +Interface +========= + +Exported Data Structures +------------------------ +struct encode_context { + struct tsv_header hdr; + char buff[MAX_MSG_SIZE]; + int offset; +}; + +struct decode_context { + int output_format; + char *buff; + int size; +}; + +Kernel-Space Interface APIs +---------------------------- +/* + * ipc_log_context_create: Create a ipc log context + * + * @max_num_pages: Number of pages of logging space required (max. 10) + * @mod_name : Name of the directory entry under DEBUGFS + * @user_version : Version number of user-defined message formats + * + * returns reference to context on success, NULL on failure + */ +void * ipc_log_context_create(int max_num_pages, + const char *mod_name); + +/* + * msg_encode_start: Start encoding a log message + * + * @ectxt: Temporary storage to hold the encoded message + * @type: Root event type defined by the module which is logging + */ +void msg_encode_start(struct encode_context *ectxt, uint32_t type); + +/* + * msg_encode_end: Complete the message encode process + * + * @ectxt: Temporary storage which holds the encoded message + */ +void msg_encode_end(struct encode_context *ectxt); + +/* + * tsv_timestamp_write: Writes the current timestamp count + * + * @ectxt: Context initialized by calling msg_encode_start() + * + * Returns 0 on success, -ve error code on failure + */ +int tsv_timestamp_write(struct encode_context *ectxt); + +/* + * tsv_pointer_write: Writes a data pointer + * + * @ectxt: Context initialized by calling msg_encode_start() + * @pointer: Pointer value to write + * + * Returns 0 on success, -ve error code on failure + */ +int tsv_pointer_write(struct encode_context *ectxt, void *pointer); + +/* + * tsv_int32_write: Writes a 32-bit integer value + * + * @ectxt: Context initialized by calling msg_encode_start() + * @n: Integer to write + * + * Returns 0 on success, -ve error code on failure + */ +int tsv_int32_write(struct encode_context *ectxt, int32_t n); + +/* + * tsv_byte_array_write: Writes a byte array + * + * @ectxt: Context initialized by calling msg_encode_start() + * @data: Location of data + * @data_size: Size of data to be written + * + * Returns 0 on success, -ve error code on failure + */ +int tsv_byte_array_write(struct encode_context *ectxt, + void *data, int data_size); + +/* + * ipc_log_write: Write the encoded message into the log space + * + * @ctxt: IPC log context where the message has to be logged into + * @ectxt: Temporary storage containing the encoded message + */ +void ipc_log_write(unsigned long ctxt, struct encode_context *ectxt); + +/* + * ipc_log_string: Helper function to log a string + * + * @dlctxt: IPC Log Context created using ipc_log_context_create() + * @fmt: Data specified using format specifiers + */ +int ipc_log_string(unsigned long dlctxt, const char *fmt, ...); + +/* + * tsv_timestamp_read: Reads a timestamp + * + * @ectxt: Context retrieved by reading from log space + * @dctxt: Temporary storage to hold the decoded message + * @format: Output format while dumping through DEBUGFS + */ +void tsv_timestamp_read(struct encode_context *ectxt, + struct decode_context *dctxt, const char *format); + +/* + * tsv_pointer_read: Reads a data pointer + * + * @ectxt: Context retrieved by reading from log space + * @dctxt: Temporary storage to hold the decoded message + * @format: Output format while dumping through DEBUGFS + */ +void tsv_pointer_read(struct encode_context *ectxt, + struct decode_context *dctxt, const char *format); + +/* + * tsv_int32_read: Reads a 32-bit integer value + * + * @ectxt: Context retrieved by reading from log space + * @dctxt: Temporary storage to hold the decoded message + * @format: Output format while dumping through DEBUGFS + */ +void tsv_int32_read(struct encode_context *ectxt, + struct decode_context *dctxt, const char *format); + +/* + * tsv_byte_array_read: Reads a byte array/string + * + * @ectxt: Context retrieved by reading from log space + * @dctxt: Temporary storage to hold the decoded message + * @format: Output format while dumping through DEBUGFS + */ +void tsv_byte_array_read(struct encode_context *ectxt, + struct decode_context *dctxt, const char *format); + +/* + * add_deserialization_func: Register a deserialization function to + * to unpack the subevents of a main event + * + * @ctxt: IPC log context to which the deserialization function has + * to be registered + * @type: Main/Root event, defined by the module which is logging, to + * which this deserialization function has to be registered. + * @dfune: Deserialization function to be registered + * + * return 0 on success, -ve value on FAILURE + */ +int add_deserialization_func(unsigned long ctxt, int type, + void (*dfunc)(struct encode_context *, + struct decode_context *)); + +Driver parameters +================= + +Not-Applicable + +Config options +============== + +Not-Applicable + +Dependencies +============ + +This module will partially depend on CONFIG_DEBUGFS, in order to dump the +logs through debugfs. If CONFIG_DEBUGFS is disabled, the above mentioned +helper functions will perform no operation and return appropriate error +code if the return value is non void. Under such circumstances the logs can +only be extracted through the memory dump. + +User space utilities +==================== + +DEBUGFS + +Other +===== + +Not-Applicable + +Known issues +============ + +None + +To do +===== + +None diff --git a/Documentation/arm/msm/msm_ipc_router.txt b/Documentation/arm/msm/msm_ipc_router.txt new file mode 100644 index 000000000000..f8626ec70de4 --- /dev/null +++ b/Documentation/arm/msm/msm_ipc_router.txt @@ -0,0 +1,404 @@ +Introduction +============ + +Inter Process Communication(IPC) Message Router + +IPC Router provides a connectionless message routing service between +multiple processes in a MSM setup. The communicating processes can +run either in the same processor or in a different processor within +the MSM setup. The IPC Router has been designed to + 1) Route messages of any types + 2) Support a broader network of processors +The IPC Router follows the same protocol as the existing RPC Router +in the kernel while communicating with its peer IPC Routers. + +Hardware description +==================== + +The IPC Router doesn't implement any specific hardware driver. +The IPC Router uses the existing hardware drivers to transport messages +across to the peer router. IPC Router contains a XPRT interface layer to +handle the different types of transports/links. This interface layer +abstracts the underlying transport complexities from the router and +provides a packet/message interface with the transports. + +Software description +==================== + +The IPC Router is designed to support a client-server model. The +clients and servers communicate with one another by exchanging data +units known as messages. A message is a byte string from 1 to 64K bytes +long. The IPC Router provides a connectionless message routing service +between the clients and servers i.e. any client/server can communicate +with any other client/server in the network of processors. + +Network Topology Overview: +-------------------------- + +The system is organized as a network of nodes. Each processor in the +network is the most fundamental element called node. The complete +network is hierarchically structured i.e. the network is divided into +tiers and each tier is fully-meshed. The following figure shows an +example network topology. + + + ---N1--- ---N4--- + | | | | + | | | | + N2----N3-------N5-----N6 + | | + | | + ---N7---- + | | + | | + N8------N9 + +Each node in the complete network is identified using a unique node id +(Nx in the example network). In the example network, nodes N1, N2 & N3 +are fully-meshed to form a tier 1 network. Similarly nodes N4, N5 & N6 +form another tier 1 network and nodes N7, N8 & N9 form third tier 1 +network. These three tier 1 networks are fully-meshed to form a tier 2 +network. + +Each transport/link in the network is identified using a unique name/id +called XPRT id. This XPRT id is used by the nodes to identify the +link to be used while sending message to a specific destination. +In addition, each transport/link in the network is assigned a link id. +This link id is used to identify the tier to which the link belongs to. +This link marking is used to avoid the routing loops while forwarding +the broadcast messages. The incoming messages are only forwarded onto an +egress link which has a link id different from that of an ingress link. + +IPC Router Addressing Overview: +------------------------------- + +Each client/server in the network is identified using a unique +<Node_id:Port_id> combination. Node_id identifies the processor on which +a client/server is running. Port_id is a unique id within a node. This +Port_id is assigned by the IPC Router in that node when a client/server +comes up. The Node_id & Port_id are 32 bits each. + +Port_id 0xFFFFFFFE is reserved for Router & +0xFFFFFFFF is reserved for broadcast messages. + +Each server in the network can also be addressed using a service name. +The service name is of the form <service(32 bits):instance(32 bits)>. +When a server comes up, it binds itself with a service name. This name +information along with the <Node_id:Port_id> is broadcast onto the +entire network. + +Control Path: +------------- + +IPC Router uses the control messages to communicate and propagate the +system wide events to the other routers in the system. Some of the +events include: + 1) Node Status + 2) Server Status + 3) Client Status + 4) Flow Control Request/Confirmation + +Message Header: +--------------- + +IPC Router prepends a header to every message that it communicates with +other IPC Router. The receiving IPC Routers use the header to identify +the source and destination of the message, size of the message, type +of the message and handle any flow control requests. The IPC Router +header format is as follows: + + 0 31 + ------------------------------------------------- + | Version | + ------------------------------------------------- + | Message Type | + ------------------------------------------------- + | Source Node ID | + ------------------------------------------------- + | Source Port ID | + ------------------------------------------------- + | Confirm RX | + ------------------------------------------------- + | Payload Length | + ------------------------------------------------- + | Destination Node ID | + ------------------------------------------------- + | Destination Port ID | + ------------------------------------------------- + +Message Header v2(Optimized): +----------------------------- + +The following optimization has been done to the IPC Router header to +make it concise, align with the system requirement and enable future +expansion: + + 0 8 16 24 31 + ----------------------------------------------------------------- + | Version | Message Type | Control Flag | + ----------------------------------------------------------------- + | Payload Length | + ----------------------------------------------------------------- + | Source Node ID | Source Port ID | + ----------------------------------------------------------------- + | Destination Node ID | Destination Port ID | + ----------------------------------------------------------------- + +Control Flag: + + 0 14 15 + ------------------------------------------------------------------ + | Reserved | Opt. Hdr. | Confirm RX | + ------------------------------------------------------------------ + +IPC Router identifies and processes the header depending on the version +field. The Confirm RX field in message header v1 becomes part of the +control flag. All the other fields are reduced in size to align with the +system requirement. + +Optional Header: +An optional header bit field is introduced in the control flag to handle +any unforeseen future requirement that this header cannot handle. When +that bit is set, an optional header follows the current header. The +optional header format is as follows: + + 0 8 16 31 + ----------------------------------------------------------------- + | Length(words) | Type | Control Flag | + ----------------------------------------------------------------- + | | + | Optional Header Contents | + | | + ----------------------------------------------------------------- + +Design +====== + +The IPC Router is organized into 2 layers: + 1) Router Core layer + 2) Router - XPRT Interface layer + + +This organization allows the router to abstract the XPRT's complexities +from that of the core router functionalities. The Router Core layer +performs the following core functions: + 1) Message Routing + 2) Distributed name service + 3) Flow control between ports +The Router core layer contains the following important data structures +to perform the core functions in their respective order: + 1) Routing Table + 2) Table of Active Servers + 3) Table of Active Remote ports +All these data structures get updated based on the events passed through +the control path. + + +The Router - XPRT Interface layer hides the underlying transport +complexities and provides and abstracted packet interface to the +Router Core layer. The Router - XPRT Interface layer registers itself +with the Router Core layer upon complete initialization of the XPRT. +The Router - XPRT Interface layer upon registration exports the +following functionalities to the Router Core: + 1) Read from the XPRT + 2) # of bytes of data available to read + 3) Write to the XPRT + 4) Space available to write to the XPRT + 5) Close the XPRT + + +The user behavioral model of the IPC Router should be + 1) Create a port + 2) If server, register a name to the port + 3) If remote port not known, lookup through the name + 4) Send messages over the port to the remote port + 5) Receive messages along with the source info from the port + 6) Repeat steps 3, 4 & 5 as required + 7) If server, unregister the name from the port + 8) Close the port + +Power Management +================ + +IPC Message Router uses wakelocks to ensure that the system does not go +into suspend mode while there are pending messages to be handled. Once all +the messages are handled, IPC Message Router releases the wakelocks to +allow the system to go into suspend mode and comply with the system power +management requirement. + +SMP/multi-core +============== + +The IPC Router uses mutexes & spinlocks to protect the shared data +structures to be SMP/multi-core safe. + +Security +======== + +None + +Performance +=========== + +None + +Interface +========= + +Kernel-space APIs: +------------------ + +/* + * msm_ipc_router_create_port - Create a IPC Router port + * + * @msm_ipc_port_notify: notification function which will notify events + * like READ_DATA_AVAIL, WRITE_DONE etc. + * @priv: caller private context pointer, passed to the notify callback. + * + * @return: a valid port pointer on success, NULL on failure + * + */ +struct msm_ipc_port * msm_ipc_router_create_port( + void (*msm_ipc_port_notify)(unsigned event, void *data, + void *addr, void *priv), + void *priv) + + +/* + * msm_ipc_router_close_port - Close down the port + * + * @port: Port to be closed + * + * @return: 0 on success, -ve value on failure + * + */ +int msm_ipc_router_close_port(struct msm_ipc_port *port) + + +/* + * msm_ipc_router_send_to - Send data to a remote port + * + * @from_port: Source port of the message + * @data: Data to be sent + * @to_addr: Destination port name or address + * + * @return: number of bytes sent on success, -ve value on failure + * + */ +int msm_ipc_router_send_to(struct msm_ipc_port *from_port, + struct sk_buff_head *data, + struct msm_ipc_addr *to_addr) + + +/* + * msm_ipc_router_recv_from - Receive data over a port + * + * @port: Port from which the data has to be read + * @data: Pointer to the data + * @src_addr: If valid, filled with the source address of the data + * @timeout: Time to wait for the data, if already not present + * + * @return: number of bytes received on success, -ve value on failure + * + */ +int msm_ipc_router_recv_from(struct msm_ipc_port *port, + struct sk_buff_head **data, + struct msm_ipc_addr *src_addr, + unsigned long timeout) + +/* + * msm_ipc_router_register_server - Bind a local port with a service + * name + * + * @server_port: Port to be bound with a service name + * @name: Name to bind with the port + * + * @return: 0 on success, -ve value on failure + * + */ +int msm_ipc_router_register_server(struct msm_ipc_port *server_port, + struct msm_ipc_addr *name) + + +/* + * msm_ipc_router_unregister_server - Unbind the local port from its + * service name + * + * @server_port: Port to be unbound from its service name + * + * @return: 0 on success, -ve value on failure + * + */ +int msm_ipc_router_unregister_server(struct msm_ipc_port *server_port) + + +/* + * msm_ipc_router_lookup_server - Lookup port address for the port name + * + * @name: Name to be looked up for + * + * @return: Port address corresponding to the service name on success, + * NULL on failure + * + */ +struct msm_ipc_addr * msm_ipc_router_lookup_server( + struct msm_ipc_addr *name) + + +User-space APIs: +---------------- + +User-space applications/utilities can use the socket APIs to interface +with the IPC Router. IPC Router, in order to support the socket APIs, +will register a new socket Address/Protocol Family with the kernel +Socket layer. The identity of the new Address/Protocol Family will be +defined using the macro AF_MSM_IPC/PF_MSM_IPC (hardcoded to 38) in +include/linux/socket.h file. Since IPC Router supports only message +oriented transfer, only SOCK_DGRAM type of sockets will be supported +by the IPC Router. + +Driver parameters +================= + +debug_mask - This module parameter is used to enable/disable Router +log messages in the kernel logs. This parameter can take any value +from 0 to 255. + +Dependencies +============ + +Drivers in this project: +----------------------- + +The following drivers are present in this project, listed in the +bottom - up order of the stack. + +1a) Router - SMD XPRT Interface driver. This driver is used to interface +the Router with the SMD transport. +1b) Router - HSIC XPRT Interface driver. This driver is used to interface +the Router with the HSIC_IPC Bridge transport for off-chip communication. +2) Core Router driver. This driver performs the core functionalities +3) Socket - Router Interface driver. This driver enables the socket +interface to be used with the IPC Router. + +In the write/send direction, these drivers interact by invoking the +exported APIs from the underlying drivers. In the read/receive +directions, these drivers interact by passing messages/events. + +Drivers Needed: +--------------- + + 1) SMD + 2) Kernel Socket Layer + 3) Platform Driver + 4) HSIC IPC Bridge Driver + +To do +===== +Improvements: +------------- + +The IPC Router is designed to route any messages, as long as the system +follows the network architecture and addressing schemes. But the +implementation in progress will route only QMI messages. With few +additional enhancements, it can route existing RPC messages too. diff --git a/Documentation/arm/msm/msm_qmi.txt b/Documentation/arm/msm/msm_qmi.txt new file mode 100644 index 000000000000..d4bdd1e365fc --- /dev/null +++ b/Documentation/arm/msm/msm_qmi.txt @@ -0,0 +1,519 @@ +Introduction +============ + +Qualcomm MSM Interface(QMI) is a messaging format used to communicate +between software components in the modem and other peripheral subsystems. +This document proposes an architecture to introduce the QMI messaging +into the kernel. This document proposes introducing a QMI encode/decode +library to enable QMI message marshaling and an interface library to enable +sending and receiving QMI messages through MSM IPC Router. + +Hardware description +==================== + +QMI is a messaging format used to interface with the components in modem +and other subsystems. QMI does not drive or manage any hardware resources. + +Software description +==================== +QMI communication is based on a client-server model, where clients and +servers exchange messages in QMI wire format. A module can act as a client +of any number of QMI services and a QMI service can serve any number of +clients. + +QMI communication is of request/response type or an unsolicited event type. +QMI client driver sends a request to a QMI service and receives a response. +QMI client driver registers with the QMI service to receive indications +regarding a system event and the QMI service sends the indications to the +client when the event occurs in the system. + +The wire format of QMI message is as follows: + + ---------------------------------------------------- + | QMI Header | TLV 0 | TLV 1 | ... | TLV N | + ---------------------------------------------------- + +QMI Header: +----------- + -------------------------------------------------------- + | Flags | Transaction ID | Message ID | Message Length | + -------------------------------------------------------- + +The flags field is used to indicate the kind of QMI message - request, +response or indication. The transaction ID is a client specific field +to uniquely match the QMI request and the response. The message ID is +also a client specific field to indicate the kind of information present +in the QMI payload. The message length field holds the size information +of the QMI payload. + +Flags: +------ + * 0 - QMI Request + * 2 - QMI Response + * 4 - QMI Indication + +TLV: +---- +QMI payload is represented using a series of Type, Length and Value fields. +Each information being passed is encoded into a type, length and value +combination. The type element identifies the type of information being +encoded. The length element specifies the length of the information/values +being encoded. The information can be of a primitive type or a structure +or an array. + + ------------------------------------------- + | Type | Length | Value 0 | ... | Value N | + ------------------------------------------- + +QMI Message Marshaling and Transport: +------------------------------------- +QMI encode/decode library is designed to encode the kernel C data +structures into QMI wire format and to decode the QMI messages into kernel +C data strcuture format. This library will provide a single interface to +transform any data structure into a QMI message and vice-versa. + +QMI interface library is designed to send and receive QMI messages over +IPC Router. + + + ---------------------------------- + | Kernel Drivers | + ---------------------------------- + | | + | | + ----------------- ----------------- + | QMI Interface |___| QMI Enc/Dec | + | Library | | Library | + ----------------- ----------------- + | + | + ------------------- + | IPC Message | + | Router | + ------------------- + | + | + ------- + | SMD | + ------- + +Design +====== + +The design goals of this proposed QMI messaging mechanism are: + * To enable QMI messaging from within the kernel + * To provide a common library to marshal QMI messages + * To provide a common interface library to send/receive QMI messages + * To support kernel QMI clients which have latency constraints + +The reason behind this design decision is: + * To provide a simple QMI marshaling interface to the kernel users + * To hide the complexities of QMI message transports + * To minimize code redundancy + +In order to provide a single encode/decode API, the library expects +the kernel drivers to pass the: + * starting address of the data structure to be encoded/decoded + * starting address of the QMI message buffer + * a table containing information regarding the data structure to + be encoded/decoded + +The design is based on the idea that any complex data structure is a +collection of primary data elements. Hence the information about any +data structure can be constructed as an array of information about its +primary data elements. The following structure is defined to describe +information about a primary data element. + +/** + * elem_info - Data structure to specify information about an element + * in a data structure. An array of this data structure + * can be used to specify info about a complex data + * structure to be encoded/decoded. + * @data_type: Data type of this element + * @elem_len: Array length of this element, if an array + * @elem_size: Size of a single instance of this data type + * @is_array: Array type of this element + * @tlv_type: QMI message specific type to identify which element + * is present in an incoming message + * @offset: To identify the address of the first instance of this + * element in the data structure + * @ei_array: Array to provide information about the nested structure + * within a data structure to be encoded/decoded. + */ +struct elem_info { + enum elem_type data_type; + uint32_t elem_len; + uint32_t elem_size; + enum array_type is_array; + uint8_t tlv_type; + uint32_t offset; + struct elem_info *ei_array; +}; + +The alternate design discussions include manual encoding/decoding of QMI +messages. From RPC experience, this approach has mostly been error prone. +This in turn lead to increased development and debugging effort. Another +approach included data-structure specific marshaling API -- i.e. every +data structure to be encoded/decoded should have a unique auto-generated +marshaling API. This approach comes with the cost of code redundancy and +was therefore rejected. + +Power Management +================ + +N/A + +SMP/multi-core +============== + +The QMI encode/decode library does not access any global or shared data +structures. Hence it does not require any locking mechanisms to ensure +multi-core safety. + +The QMI interface library uses mutexes while accessing shared resources. + +Security +======== + +N/A + +Performance +=========== + +This design proposal is to support kernel QMI clients which have latency +constraints. Hence the number and size of QMI messages are expected to be +kept short, in order to achieve latency of less than 1 ms consistently. + +Interface +========= + +Kernel-APIs: +------------ + +Encode/Decode Library APIs: +--------------------------- + +/** + * elem_type - Enum to identify the data type of elements in a data + * structure. + */ +enum elem_type { + QMI_OPT_FLAG = 1, + QMI_DATA_LEN, + QMI_UNSIGNED_1_BYTE, + QMI_UNSIGNED_2_BYTE, + QMI_UNSIGNED_4_BYTE, + QMI_UNSIGNED_8_BYTE, + QMI_SIGNED_2_BYTE_ENUM, + QMI_SIGNED_4_BYTE_ENUM, + QMI_STRUCT, + QMI_END_OF_TYPE_INFO, +}; + +/** + * array_type - Enum to identify if an element in a data structure is + * an array. If so, then is it a static length array or a + * variable length array. + */ +enum array_type { + NO_ARRAY = 0, + STATIC_ARRAY = 1, + VAR_LEN_ARRAY = 2, +}; + +/** + * msg_desc - Describe about the main/outer structure to be + * encoded/decoded. + * @msg_id: Message ID to identify the kind of QMI message. + * @max_msg_len: Maximum possible length of the QMI message. + * @ei_array: Array to provide information about a data structure. + */ +struct msg_desc { + uint16_t msg_id; + int max_msg_len; + struct elem_info *ei_array; +}; + +/** + * qmi_kernel_encode() - Encode to QMI message wire format + * @desc: Structure describing the data structure to be encoded. + * @out_buf: Buffer to hold the encoded QMI message. + * @out_buf_len: Length of the buffer to hold the QMI message. + * @in_c_struct: C Structure to be encoded. + * + * @return: size of encoded message on success, + * -ve value on failure. + */ +int qmi_kernel_encode(struct msg_desc *desc, + void *out_buf, uint32_t out_buf_len, + void *in_c_struct); + +/** + * qmi_kernel_decode() - Decode to C Structure format + * @desc: Structure describing the data structure format. + * @out_c_struct: Buffer to hold the decoded C structure. + * @in_buf: Buffer containg the QMI message to be decoded. + * @in_buf_len: Length of the incoming QMI message. + * + * @return: 0 on success, -ve value on failure. + */ +int qmi_kernel_decode(struct msg_desc *desc, void *out_c_struct, + void *in_buf, uint32_t in_buf_len); + +Interface Library APIs: +----------------------- + +/** + * qmi_svc_event_notifier_register() - Register a notifier block to receive + * events regarding a QMI service + * @service_id: Service ID to identify the QMI service. + * @instance_id: Instance ID to identify the instance of the QMI service. + * @nb: Notifier block used to receive the event. + * + * @return: 0 if successfully registered, < 0 on error. + */ +int qmi_svc_event_notifier_register(uint32_t service_id, + uint32_t instance_id, + struct notifier_block *nb); + +/** + * qmi_handle_create() - Create a QMI handle + * @notify: Callback to notify events on the handle created. + * @notify_priv: Private info to be passed along with the notification. + * + * @return: Valid QMI handle on success, NULL on error. + */ +struct qmi_handle *qmi_handle_create( + void (*notify)(struct qmi_handle *handle, + enum qmi_event_type event, void *notify_priv), + void *notify_priv); + +/** + * qmi_connect_to_service() - Connect the QMI handle with a QMI service + * @handle: QMI handle to be connected with the QMI service. + * @service_id: Service id to identify the QMI service. + * @instance_id: Instance id to identify the instance of the QMI service. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_connect_to_service(struct qmi_handle *handle, + uint32_t service_id, uint32_t instance_id); + +/** + * qmi_register_ind_cb() - Register the indication callback function + * @handle: QMI handle with which the function is registered. + * @ind_cb: Callback function to be registered. + * @ind_cb_priv: Private data to be passed with the indication callback. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_register_ind_cb(struct qmi_handle *handle, + void (*ind_cb)(struct qmi_handle *handle, + unsigned int msg_id, void *msg, + unsigned int msg_len, void *ind_cb_priv), + void *ind_cb_priv); + +/** + * qmi_send_req_wait() - Send a synchronous QMI request + * @handle: QMI handle through which the QMI request is sent. + * @req_desc: Structure describing the request data structure. + * @req: Buffer containing the request data structure. + * @req_len: Length of the request data structure. + * @resp_desc: Structure describing the response data structure. + * @resp: Buffer to hold the response data structure. + * @resp_len: Length of the response data structure. + * @timeout_ms: Timeout before a response is received. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_send_req_wait(struct qmi_handle *handle, + struct msg_desc *req_desc, + void *req, unsigned int req_len, + struct msg_desc *resp_desc, + void *resp, unsigned int resp_len, + unsigned long timeout_ms); + +/** + * qmi_send_req_nowait() - Send an asynchronous QMI request + * @handle: QMI handle through which the QMI request is sent. + * @req_desc: Structure describing the request data structure. + * @req: Buffer containing the request data structure. + * @req_len: Length of the request data structure. + * @resp_desc: Structure describing the response data structure. + * @resp: Buffer to hold the response data structure. + * @resp_len: Length of the response data structure. + * @resp_cb: Callback function to be invoked when the response arrives. + * @resp_cb_data: Private information to be passed along with the callback. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_send_req_nowait(struct qmi_handle *handle, + struct msg_desc *req_desc, + void *req, unsigned int req_len, + struct msg_desc *resp_desc, + void *resp, unsigned int resp_len, + void (*resp_cb)(struct qmi_handle *handle, + unsigned int msg_id, void *msg, + void *resp_cb_data), + void *resp_cb_data); + +/** + * qmi_recv_msg() - Receive the QMI message + * @handle: Handle for which the QMI message has to be received. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_recv_msg(struct qmi_handle *handle); + +/** + * qmi_handle_destroy() - Destroy the QMI handle + * @handle: QMI handle to be destroyed. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_handle_destroy(struct qmi_handle *handle); + +/** + * qmi_svc_event_notifier_unregister() - Unregister service event notifier block + * @service_id: Service ID to identify the QMI service. + * @instance_id: Instance ID to identify the instance of the QMI service. + * @nb: Notifier block registered to receive the events. + * + * @return: 0 if successfully registered, < 0 on error. + */ +int qmi_svc_event_notifier_unregister(uint32_t service_id, + uint32_t instance_id, + struct notifier_block *nb); + +/** + * qmi_svc_ops_options - Operations and options to be specified when + * a service registers. + * @version: Version field to identify the ops_options structure. + * @service_id: Service ID of the service being registered. + * @instance_id: Instance ID of the service being registered. + * @connect_cb: Callback when a new client connects with the service. + * @disconnect_cb: Callback when the client exits the connection. + * @req_desc_cb: Callback to get request structure and its descriptor + * for a message id. + * @req_cb: Callback to process the request. + */ +struct qmi_svc_ops_options { + unsigned version; + uint32_t service_id; + uint32_t instance_id; + int (*connect_cb)(struct qmi_handle *handle, + struct qmi_svc_clnt *clnt); + int (*disconnect_cb)(struct qmi_handle *handle, + struct qmi_svc_clnt *clnt); + struct msg_desc *(*req_desc_cb)(unsigned int msg_id, + void **req, + unsigned int req_len); + int (*req_cb)(struct qmi_handle *handle, + struct qmi_svc_clnt *clnt, + void *req_handle, + unsigned int msg_id, + void *req); +}; + +/** + * qmi_svc_register() - Register a QMI service with a QMI handle + * @handle: QMI handle on which the service has to be registered. + * @ops_options: Service specific operations and options. + * + * @return: 0 if successfully registered, < 0 on error. + */ +int qmi_svc_register(struct qmi_handle *handle, + void *ops_options); + +/** + * qmi_send_resp() - Send response to a request + * @handle: QMI handle from which the response is sent. + * @clnt: Client to which the response is sent. + * @req_handle: Request for which the response is sent. + * @resp_desc: Descriptor explaining the response structure. + * @resp: Pointer to the response structure. + * @resp_len: Length of the response structure. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_send_resp(struct qmi_handle *handle, + struct qmi_svc_clnt *clnt, + void *req_handle, + struct msg_desc *resp_desc, + void *resp, + unsigned int resp_len); + +/** + * qmi_send_ind() - Send unsolicited event/indication to a client + * @handle: QMI handle from which the indication is sent. + * @clnt: Client to which the indication is sent. + * @ind_desc: Descriptor explaining the indication structure. + * @ind: Pointer to the indication structure. + * @ind_len: Length of the indication structure. + * + * @return: 0 on success, < 0 on error. + */ +int qmi_send_ind(struct qmi_handle *handle, + struct qmi_svc_clnt *clnt, + struct msg_desc *ind_desc, + void *ind, + unsigned int ind_len); + +/** + * qmi_svc_unregister() - Unregister the service from a QMI handle + * @handle: QMI handle from which the service has to be unregistered. + * + * return: 0 on success, < 0 on error. + */ +int qmi_svc_unregister(struct qmi_handle *handle); + +User-space APIs: +---------------- +This proposal is meant only for kernel QMI clients/services and hence no +user-space interface is defined as part of this proposal. + +Driver parameters +================= + +N/A + +Config options +============== + +The QMI encode/decode library will be enabled by default in the kernel. +It can be disabled using CONFIG_QMI_ENCDEC kernel config option. + +The QMI Interface library will be disabled by default in the kernel, +since it depends on other components which are disabled by dafault. +It can be enabled using CONFIG_MSM_QMI_INTERFACE kernel config option. + +Dependencies +============ + +The QMI encode/decode library is a stand-alone module and is not +dependent on any other kernel modules. + +The QMI Interface library depends on QMI Encode/Decode library and +IPC Message Router. + +User space utilities +==================== + +N/A + +Other +===== + +N/A + +Known issues +============ + +N/A + +To do +===== + +Look into the possibility of making QMI Interface Library transport +agnostic. This may involve the kernel drivers to register the transport, +with the QMI Interface Library, to be used for transporting QMI messages. diff --git a/Documentation/arm/msm/msm_rng-driver.txt b/Documentation/arm/msm/msm_rng-driver.txt new file mode 100644 index 000000000000..3e7d1e9f460f --- /dev/null +++ b/Documentation/arm/msm/msm_rng-driver.txt @@ -0,0 +1,75 @@ +Introduction: +============= + +The msm_rng device driver handles random number generation +using hardware present in MSM chipsets. + +Hardware description: +===================== + +The supported hardware is a macro block within a system-on-a-chip (SoC). +The hardware is pseudo random number generator (PRNG) with four oscillators +setup with a linear feedback shift register (LFSR). +The hardware must be initially configured once for normal operation and +a 32bit FIFO is read to obtain hardware generated pseudo random numbers. +Currently the driver configures the hardware registers during initialization +and the future plan is to have the boot loader configure these registers and +write lock them so only host OS can read them and the driver writes will be +ignored. + +Software description +==================== + +The driver is based on the platform_driver model. It registers an entry, +exit and probe functions. Once the probe function is called, the driver +registers a callback function with the hwrng (Hardware Random Number Generator) +subsystem that is called when the hardware device (i.e. /dev/hw_random) is +requesting random data from this device. +Once the callback is issued from the hwrng subsystem, the driver checks to +make sure the hardware has random data available and determines the maximum +data it can return and returns that much data back. + +Power Management +================ + +Initially, no services are provided in the area of power management. + +SMP/multi-core +============== + +The locking mechanism for the hwrng operations is taken care of by the hwrng +framework. There are no SMP situations within the driver that need addressing. + +Driver parameters +================= + +This driver is built and statically linked into the kernel; therefore, +there are no module parameters supported by this driver. + +There are no kernel command line parameters supported by this driver. + +Config options +============== + +This driver is enabled by the kernel config option CONFIG_HW_RANDOM_MSM. +The option CONFIG_HW_RANDOM_MSM depends on HW_RANDOM && ARCH_MSM. + +Dependencies: +============= + +This driver depends on the HW_RANDOM subsystem to register with and get +callbacks to request random data. + +User space utilities: +===================== + +The driver alone does not feed random numbers into kernel but just provides a +method to get random numbers to a known device (i.e. /dev/hw_random). A user- +space utility is required to monitor the /dev/random device entropy pool and +feed it from the /dev/hw_random device. This application also must perform some +sort of sanity checking on the returned data to make sure the data is not all +the same. + +There is currently a GPL v2 tool called rng-tools that has a daemon called, +"rngd" that performs this functionality. There is also a test tool in this +package that tests the whole random subsystem. diff --git a/Documentation/arm/msm/msm_smem.txt b/Documentation/arm/msm/msm_smem.txt new file mode 100644 index 000000000000..6d31344a17a1 --- /dev/null +++ b/Documentation/arm/msm/msm_smem.txt @@ -0,0 +1,595 @@ +Introduction +============ +The Shared Memory (SMEM) protocol allows multiple processors in Qualcomm +Technologies, Inc. MSM System on Chips to communicate at a low level using a +segment of shared system memory that is accessible by any of the processors. +This is accomplished by an operating-system independent mechanism that allows a +client on any processor to dynamically allocate a block of memory from shared +system memory which is then visible and accessible to clients on other +processors for the purpose of storing and exchanging data. + + + +-------------+ + SMEM | Processor 1 | + +---------+ +------------+ +-------------+ + | |+--------------->| Item 1 |<----------------+ ^ + | Linux | | | | + | |<---------------+| |+-------------------+ + +---------+ +------------+ + ^ + | Item 2 | +-------------+ + | | | |<--------------+| Processor 2 | + | | | |+-------------->| | + | | | | +-------------+ + | | | | + | | | | +-------------+ + | | +------------+ | Processor 3 | + | | . +-------------+ + | | . + ^ . + | | +------------+ | | . + | +----------------->| Item N |<-----------------+ | . + +---------------------+| |+--------------------+ . + | | +-------------+ + | |+-------------->| | + | | | Processor N | + | |<--------------+| | + +------------+ +-------------+ + +The SMEM driver supports all known versions of the SMEM protocol. + +Hardware description +==================== +The SMEM protocol requires a contiguous segment of system memory that is +accessible by both the local processor and one or more remote processors. +Each processor supporting the SMEM protocol must configure their MMUs and other +applicable hardware such that accesses to shared memory are non-cacheable. + +Optionally, additional segments of system memory may be provided to act as +auxiliary memory areas for the SMEM protocol. Such segments may provide +performance benefits to certain processors by optimizing access latency. Such +auxiliary memory areas must be a slave to the single main SMEM area. + +While the SMEM protocol has provisions for software-based remote spinlocks to +manage synchronization between processors, this functionality may be +substituted with dedicated hardware. Such hardware is expected to be managed +by another driver providing a standardized API. + +Software description +==================== +At its core, the SMEM protocol is a heap memory management system. The core +functionality consists of allocating segments of memory, and lookup operations +to find the address of existing segments of memory. There is no provision to +free memory that is allocated. + +Allocated segments of memory are called SMEM items. Each SMEM item has a unique +32-bit identifier which maps each specific SMEM item to a slot in the table of +contents that lives at the start of the SMEM region. + +A SMEM client that wishes to allocate a SMEM item will provide the item +identifier and a desired size in bytes. Assuming there is enough free space in +the SMEM region to accommodate the request, the amount of desired bytes will be +carved out, and the base address and size for the item will be stored in the +table of contents. The base address will be returned as a pointer to the +client, so that the client may use the SMEM item as if it were normal memory +allocated through "malloc". + +A SMEM client that wishes to find an already allocated SMEM item will provide +the item identifier and the size in bytes that the client expects for the item. +A lookup in the table of contents for the specified item identifier will be +performed. Assuming a matching SMEM item is found, the size of the item that +is stored in the table of contents will be compared to the size specified by the +client. This sanity check of the expected vs actual size is done to ensure that +all users of a particular SMEM item agree on the size of the data to be +exchanged under the assumption that if the users do not agree on the item size, +then they will not be able to sucessfully communicate as one or more sides may +view a corruption of the data stored in the SMEM item. Assuming the sizes +match, the virtual address corresponding to the base address stored in the table +of contents for the item will be returned to the client. + + +------+ Request +-----------+ Memory + |Client|+----------------->|SMEM Driver| +---------------+ + +------+ Item X of size Y +-----------+ | | + ^ + | | + | | Lookup/Alloc +---------------+ Find X + | +--------------->| TOC[X] |+--------+ + | +---------------+ | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | Return pointer for client +---------------+ | + +---------------------------------------------+| Item X |<--------+ + +---------------+ + | | + | | + | | + +---------------+ + +The SMEM driver depends on the kernel memory management subsystem for managing +the system memory that SMEM uses. The main SMEM memory region is statically +mapped at boot, and the virtual address for the base of the region is stored +in MSM_SHARED_RAM_BASE. Auxiliary memory regions are ioremap'd at driver init. +All SMEM regions are mapped as non-cacheable. + +Although the SMEM driver is aware of auxiliary memory regions, and capable of +understanding SMEM items that exist in auxiliary memory regions, the SMEM +driver does not allocate from the auxiliary memory regions. A detailed +description of the purpose and use of auxiliary memory regions is outside the +scope of this document. + +Design +====== +The SMEM protocol requires that the system bootloader initialize (zero out) and +bootstrap the main SMEM region before any processor in the system has booted to +avoid an initialization race condition. + +SMEM regions are configured as non-cachable memory. While this results in a +small performance hit, it significantly reduces the complexity for the SMEM +driver and clients in terms of cache management and memory barriers. Clients +are generally able to treat their SMEM items like regular local memory, which +eases the requirements to write correct code. + +The unsigned data type is assumed to be an unsigned 32-bit integer value. + +The root structure at the base of the main SMEM region is: + +#define SMD_HEAP_SIZE 512 + +struct smem_shared { + struct smem_proc_comm proc_comm[4]; + unsigned version[32]; + struct smem_heap_info heap_info; + struct smem_heap_entry heap_toc[SMD_HEAP_SIZE]; +}; + +This structure and its fields are initialized by the bootloader. + +The proc_comm field is reserved as the first part of the SMEM region to maintain +compatibility with legacy systems, but is otherwise deprecated. While the +proc comm driver is beyond the scope of this document, the remaining structure +definition to fully define smem_shared is: + +struct smem_proc_comm { + unsigned command; + unsigned status; + unsigned data1; + unsigned data2; +}; + +The version field of the smem_shared struct is an array of version entries +specifying the SMEM protocol version of every supporting processor active in the +system. Each unsigned value in the array corresponds to one entry. This +provides a mechanism for ensuring protocol version compatability between +processors. While the full table of assigned and reserved entries in the array +is beyond the scope of this document, index 8 (smem_shared.version[8]) is +reserved for any future use by Linux. The bootloader always initializes it's +entry (index 7, or smem_shared.version[7]) to the SMEM protocol version +supported by the bootloader. Checking the value of the bootloader's entry can +be used as a sanity check to determine if the SMEM region was sucessfully +initialized. + +The heap_info field of smem_shared contains basic information of the SMEM heap. +The bootloader fills in values corresponding to the main SMEM region when it +initializes the heap. It is defined as: + +struct smem_heap_info { + unsigned initialized; + unsigned free_offset; + unsigned heap_remaining; + unsigned reserved; +}; + +The initialized field is set to 1 by the bootloader when it initializes the +heap. The free_offset field contains the offset from the base of the SMEM +region for the first free byte in the heap. When a new SMEM item is allocated, +free_offset is incremented by the size of the allocated item. SMEM item sizes +are 8-byte aligned. The heap_remaining field contains the number of free bytes +remaining in the heap. When a new SMEM item is allocated, heap_remaining is +decremented by the size of the item. The reserved field is defined to be 0. + +The heap_toc field of smem_shared is the heap table of contents. It is an array +containing a slot for every defined SMEM item. SMEM item identifiers index into +this array. The structures definition is: + +struct smem_heap_entry { + unsigned allocated; + unsigned offset; + unsigned size; + unsigned reserved; /* bits 1:0 reserved, bits 31:2 aux smem base addr */ +}; + +If an SMEM item is allocated, the allocated field is 1. The offset field is +either the offset from the main SMEM region base where this SMEM item exists, or +the offset from the auxiliary SMEM region base specified in the reserved field. +The size field contains the size of the SMEM item in bytes. The size is defined +to be 8-byte aligned. The reserved field is 0 if the SMEM item is located in +the main SMEM region, or bits 31(MSB) to 2 specify the physical address of the +auxiliary SMEM region where the SMEM item resides. If reserved is used as a +physical address, then the address must be 4-byte aligned per ARM architectural +requirements. + +The bootloader allocates and intializes the following SMEM items: + +Name ID Size (bytes) +---------------------------------------------------- +SMEM_PROC_COMM 0 64 +SMEM_HEAP_INFO 1 16 +SMEM_ALLOCATION_TABLE 2 8192 +SMEM_VERSION_INFO 3 128 +SMEM_HW_RESET_DETECT 4 8 +SMEM_AARM_WARM_BOOT 5 4 +SMEM_DIAG_ERR_MESSAGE 6 200 +SMEM_SPINLOCK_ARRAY 7 32 +SMEM_MEMORY_BARRIER_LOCATION 8 4 + +All other SMEM items are dynamically allocated by processors in the system. + +Although the SMEM protocol requires the bootloader to initialize the SMEM region +before any processor in the system is active, early development of new systems +do not always have a fully functional bootloader. To determine if the +bootloader initialized the main SMEM region properly, the SMEM driver will check +the expected values of smem_shared.heap_info.initialized, +smem_shared.heap_info.reserved, and the bootloader entry of the +SMEM_VERSION_INFO SMEM item. If this check fails, the SMEM driver will print +an error message to the kernel log, and enter a disabled state. + +Security Feature +---------------- +The SMEM protocol supports an optional security feature that segments the main +SMEM region into multiple partitions. Each partition becomes a unique item +namespace. Access to partitions is restricted to a maximum of two processors +and enforced by Memory Protection Units (MPUs). The exceptions to this are the +Partition Table of Contents partition, which is read-only accessible by all +processors, and the Legacy/Default partition, which is freely accessible by all +processors. + + +-------------------------+ SMEM Base address + |Legacy/Default | + |SMEM Partition | + +-------------------------+ + |SMEM Partition 0 | + |Processor 1 - Processor 2| + +-------------------------+ + |SMEM Partition 1 | + |Processor 1 - Processor 3| + +-------------------------+ + |SMEM Partition 2 | + |Processor 4 - Processor 5| + +-------------------------+ + . + . + . + +-------------------------+ + |SMEM Partition N | + |Processor N - Processor M| + +-------------------------+ SMEM Base address + SMEM size - 4k + |Table of Contents | + | | + +-------------------------+ SMEM Base address + SMEM size + +SMEM items which are point-to-point in nature and accessed by two or fewer +processors may be allocated from a partition that is restricted to those +processors. SMEM items which are non-sensitive, accessed by 3 or more +processors, and/or do not correspond to a secured partition are allocated from +the Legacy/Default partition. + +During the firmware boot process, the Table of Contents is initialized with a +description of all the secured partitions. Each secured partition is also +initialized. The required MPU settings to protect the Table of Contents and the +secured partitions are also established. The Table of Contents is located 4k +bytes prior to the end of the main SMEM region so that it is in a known position +for all processors to find and do local configuration. + +The Table of Contents is defined as: + +struct smem_toc { + /* + * Identifier is a constant for use in debugging and identifying this + * struct in a binary capture. Set to 0x434f5424 ("$TOC"). + */ + uint32_t identifier; + + /* Version number */ + uint32_t version; + + /* Number of entries in the table */ + uint32_t num_entries; + + uint32_t reserved[5]; + + /* Zero or more entries follow */ + struct smem_toc_entry entry[]; +}; + +Each entry in the Table of Contents is defined as: + +struct smem_toc_entry { + /* Offset in bytes from SMEM base of the region */ + uint32_t offset; + + /* Size in bytes of the region */ + uint32_t size; + + /* Flags for this region */ + uint32_t flags; + + /* + * IDs for the 2 subsystems which have access to this partition. + * Order does not matter. + * For the entry which describes the TOC itself, these are both set to + * SMEM_INVALID_HOST. + * Use uint16_t, rather than enum type, to ensure size. + */ + uint16_t host0; + uint16_t host1; + + /* + * Lowest common multiple of cacheline sizes for both endpoints. For + * example, if host0 has cacheline size of 32 and host1 has cacheline + * size of 64, this value is set to 64. + */ + uint32_t size_cacheline; + + uint32_t reserved[3]; + + /* + * Sizes of sub ranges that are part of the region, but are excluded + * from the SMEM heap. These are allocated from the end of the region + * starting with sizes[0]. Set to 0 when not used. + */ + uint32_t exclusion_sizes[SMEM_TOC_MAX_EXCLUSIONS]; +}; + +While the Legacy/Default partition maintains the structure and format of the +main SMEM region with the security feature disabled, the secured partitions have +a different format and structure: + + +--------------+ +--------------------------+ Partition Base Address + | | | Partition Header | + | | | | + + | Uncached Page| +--------------------------+ | + | | | Item A Header | | + | | +--------------------------+ | + | | | Item A Data | | + +--------------+ | | | + | | | | | + | | +--------------------------+ | + | Uncached Page| | Item B Header | |Direction of heap growth + | | +--------------------------+ | + | | | Item B Data | | + | | | | | + +--------------+ | | | + | | +--------------------------+ | + | | | | | + | Uncached Page| | Unused Heap | | + | | | space to | v + | | | page boundry | + | | | | + +--------------+ +--------------------------+<----------+ End of heap + . . . . . . + Free Space + Can be used for + either heap. + . . . . . . + +--------------+ +--------------------------+<----------+ End of heap + | | | | + | | | Unused Heap | + | Cached Page | | space to | ^ + | | | page boundry | | + | | +--------------------------+ | + | | | Item Y Data | | + +--------------+ | | | + | | +--------------------------+ | + | | | Item Y Header | | + | Cached Page | +--------------------------+ | + | | | Item Y Header Padding | |Direction of heap growth + | | +--------------------------+ | + | | | Item Z Data | | + +--------------+ | | | + | | | | | + | | | | | + | Cached Page | +--------------------------+ | + | | | Item Z Header | | + | | +--------------------------+ + Padding is here to ensure + | | | Item Z Header Padding | the the data buffer start + +--------------+ +--------------------------+ and end addresses are + | | aligned to cachelines for + | | Exclusion Range both endpoints. + | Uncached Page|. . . Free Space . . . + | | +--------------------------+ + | | | Exclusion Ranges 0..N | + | | | | + +--------------+ +--------------------------+ Partition Base Address + size + +The design of the secured partitions has two advantages over the Legacy/Default +Partition + 1. Using a linked list instead of a static array to track allocated SMEM + items maximizes space utilization + 2. Creating two heaps allows one to be cacheline aligned, thus providing + an option for a higher level of performance to clients (requires + client to specify they want their SMEM item allocated in the + cached area) + +The partition header struct is defined as: + +struct smem_partition_header { + /* Identifier magic number - 0x54525024 ("$PRT") */ + uint32_t identifier; + + /* + * IDs for the 2 subsystems which have access to this partition. + * Order does not matter. + * Use uint16_t, rather than enum type, to ensure size. + */ + uint16_t host0; + uint16_t host1; + + /* Partition size, in bytes, not including the exclusion ranges */ + uint32_t size; + + /* Offset of the byte following the last allocation in uncached heap */ + uint32_t offset_free_uncached; + + /* Offset of the byte following the last allocation in cached heap */ + uint32_t offset_free_cached; + + uint32_t reserved[3]; +}; + +The allocated SMEM item header struct is defined as: + +struct smem_partition_allocation_header { + /* 0xa5a5 canary value to detect overrun problems */ + uint16_t canary; + + /* SMEM item ID. Use uint16_t here, rather than enum, to ensure size. */ + uint16_t smem_id; + + /* Size of the allocated item, includes any necessary padding. */ + uint32_t size; + + /* Size of the data padding for cacheline alignment, if applicable */ + uint16_t data_padding; + + /* Size of the header padding for cacheline alignment, if applicable */ + uint16_t header_padding; + + uint32_t reserved[1]; +}; + +SMP/multi-core +============== +The SMEM driver expects a remote spinlock driver to provide inter-processor +synchronization primitives which not only provide locking between multiple cores +but locking between multiple processors to protect the state of structures +stored in SMEM regions during allocation and lookup. Once a pointer to a SMEM +item is returned to a client, that client is expected to provide all the +necessary locking and other synchronization as required. + +The remote spinlocks may make use of the SMEM_SPINLOCK_ARRAY SMEM item (typical +of legacy systems). + +SMEM regions are non-cachable to maintain a consistent state of the data +throughout all operations. This simplifies cache management and memory barrier +requirements to a few key points in the SMEM item allocation process, and allows +clients to treat SMEM items like local memory once allocated. + +Security +======== +SMEM by default provides no security of SMEM items. If a SMEM item is intended +to only be used between clients on processors A and B, malicious clients on +processor C are free to sniff or inject data into the SMEM item. + +An optional security feature may be enabled that makes use of Memory Protection +Units (MPUs) to limit access of special segments of the main SMEM region. +Access to these partitions is limited to two processors, so only point-to-point +traffic (such as SMD or SMP2P) is able to be protected. Auxiliary SMEM regions +are not protected under this feature. Support for this feature is activated by +a Device Tree property. + +Performance +=========== +Some client use cases such as SMD may benefit from caching, but that places an +additional burden of cache maintenance and protocol design onto the clients. + +Interface +========= +Kernel-space APIs: + +/** + * smem_alloc() - Find an existing item, otherwise allocate it with security + * support + * + * @id: ID of SMEM item + * @size_in: Size of the SMEM item + * @to_proc: SMEM host that shares the item with apps + * @flags: Item attribute flags + * @returns: Pointer to SMEM item, NULL if it couldn't be found/allocated, or + * -EPROBE_DEFER if the driver is not ready + */ +void *smem_alloc(unsigned id, unsigned size_in, unsigned to_proc, + unsigned flags); + +/** + * smem_get_entry() - Get existing item with security support + * + * @id: ID of SMEM item + * @size: Pointer to size variable for storing the result + * @to_proc: SMEM host that shares the item with apps + * @flags: Item attribute flags + * @returns: Pointer to SMEM item, NULL if it doesn't exist, or -EPROBE_DEFER + * if the driver isn't ready + */ +void *smem_get_entry(unsigned id, unsigned *size, unsigned to_proc, + unsigned flags); + +/** + * smem_get_entry_no_rlock() - Get existing item without using remote spinlock. + * + * @id: ID of SMEM item + * @size_out: Pointer to size variable for storing the result + * @to_proc: SMEM host that shares the item with apps + * @flags: Item attribute flags + * @returns: Pointer to SMEM item, NULL if it doesn't exist, or -EPROBE_DEFER + * if the driver isn't ready + * + * This function does not lock the remote spinlock and should only be used in + * failure-recover cases such as retrieving the subsystem failure reason during + * subsystem restart. + */ +void *smem_get_entry_no_rlock(unsigned id, unsigned *size_out, unsigned to_proc, + unsigned flags); + +/** + * smem_find() - Find existing item with security support + * + * @id: ID of SMEM item + * @size_in: Size of the SMEM item + * @to_proc: SMEM host that shares the item with apps + * @flags: Item attribute flags + * @returns: Pointer to SMEM item, NULL if it doesn't exist, or -EPROBE_DEFER + * if the driver is not ready + */ +void *smem_find(unsigned id, unsigned size); + +/** + * smem_virt_to_phys() - Convert SMEM address to physical address. + * + * @smem_address: Address of SMEM item (returned by smem_alloc(), etc) + * @returns: Physical address (or NULL if there is a failure) + * + * This function should only be used if an SMEM item needs to be handed + * off to a DMA engine. This function will not return a version of EPROBE_DEFER + * if the driver is not ready since the caller should obtain @smem_address from + * one of the other public APIs and get EPROBE_DEFER at that time, if + * applicable. + */ +phys_addr_t smem_virt_to_phys(void *smem_address); + +Driver parameters +================= +Module parameters: +debug_mask - 0 for off (default), 1 for on. + Enables or disables printing debug messages to the kernel log + +Config options +============== +Configuration of SMEM regions is done via Device Tree per the format in +Documentation/devicetree/bindings/arm/msm/smem.txt. + +Dependencies +============ +Drivers needed: + Remote spinlocks + +Depends on the system bootloader to initialize the main SMEM region. + +Known issues +============ +None. + +To do +===== +Convert use of the unsigned data type to well defined value such as uint32_t for +better portability. diff --git a/Documentation/arm/msm/msm_smp2p.txt b/Documentation/arm/msm/msm_smp2p.txt new file mode 100644 index 000000000000..34d22f0e4635 --- /dev/null +++ b/Documentation/arm/msm/msm_smp2p.txt @@ -0,0 +1,478 @@ +Introduction +============ +The Shared Memory Point to Point (SMP2P) protocol facilitates communication of +a single 32-bit value between two processors. Each value has a single writer +(the local side) and a single reader (the remote side). Values are uniquely +identified in the system by the directed edge (local processor ID to remote +processor ID) and a string identifier. + +Version and feature negotiation has been included in the design to allow for +phased upgrades of all processors. + +Software Architecture Description +================================= +The data and interrupt coupling between processors is shown in Fig. 1. Each +processor is responsible for creating the outgoing SMEM items and each item is +writable by the local processor and readable by the remote processor. By using +two separate SMEM items that are single-reader and single-writer, SMP2P does +not require any remote locking mechanisms. + +The client API uses the Linux GPIO and interrupt framework to expose a virtual +GPIO and a virtual interrupt controller for each entry. + + ================= + | | + -----write------>|SMEM item A->B |-----read------ + | | | | + | ================= | + | | + | v + GPIO API => ------------ ======= Interrupt line ======> ------------ + Processor A Processor B + Interrupt <= ------------ <====== Interrupt line ======= ------------ + API ^ | + | | + | | + | ================= | + | | | | + ------read-------|SMEM item A<-B |<-----write---- + | | + ================= + + Fig 1 + + +Design +====== +Each SMEM item contains a header that is used to identify and manage the edge +along with an array of actual entries. The overall structure is captured in +Fig 2 and the details of the header and entries are covered later in this +section. The memory format of all shared structures is little-endian. + + ----------------------------------------------- + | SMEM item A->B | + | | + | ----------------------------------------- | + | |31 24| 16| 8| 0| | + | |----------|---------|----------|---------| | + | | Identifier Constant(Magic Number) | | + | |----------|---------|----------|---------| | + | | Feature Flags |Version | | + | | |Number | | + | |----------|---------|----------|---------| | + | | Remote Proc ID |Local Proc ID | | + | |----------|---------|----------|---------| | + | | Entries Valid | Entries Total | | + | |-----------------------------------------| | + | | + | | + | ----------------------------------------- | + | | Entry 0 | | + | | ---------------------------------- | | + | | | Identifier String | | | + | | |---------------------------------| | | + | | | Data | | | + | | |---------------------------------| | | + | |---------------------------------------| | + | ----------------------------------------- | + | | Entry 1 | | + | | ---------------------------------- | | + | | | Identifier String | | | + | | |---------------------------------| | | + | | | Data | | | + | | |---------------------------------| | | + | |---------------------------------------| | + | - | + | - | + | - | + | ----------------------------------------- | + | | Entry N | | + | | ---------------------------------- | | + | | | Identifier String | | | + | | |---------------------------------| | | + | | | Data | | | + | | |---------------------------------| | | + | |---------------------------------------| | + ----------------------------------------------- + + Fig 2 + + +The header of each SMEM item contains metadata that describes the processors +using the edge, the version information, and the entry count. The constant +identifier is used as a magic number to enable extraction of the items from a +memory dump. The size of each entry depends upon the version, but the number +of total entries (and hence the size of each SMEM item) is configurable with a +suggested value of 16. + +The number of valid entries is used to indicate how many of the Entries Total +are currently used and are current valid. + + --------------------------------------------------------------------------- + |Field Size Description Valid Values | + --------------------------------------------------------------------------- + | Identifier 4 Bytes Value used to identify | + | Constant structure in memory. Must be set to $SMP | + | Useful for debugging. (0x504D5324) | + --------------------------------------------------------------------------- + | Local 2 Bytes Writing processor ID. Refer Processor ID Table 3| + | Processor | + | ID | + --------------------------------------------------------------------------- + | Remote 2 Bytes Reading processor ID. Refer Processor ID Table 3| + | Processor | + | ID | + --------------------------------------------------------------------------- + | Version 1 Bytes Refer to Version | + | Number Feature Negotiation Must be set to 1. | + | section. | + --------------------------------------------------------------------------- + | Feature 3 Bytes Refer to Version | + | flags and Feature Negotiation | + | section for details. | + | bit 0 SSR_ACK Feature Supported when set to 1 | + | bits 1:31 Reserved Must be set to 0. | + --------------------------------------------------------------------------- + | Entries 2 Bytes Total number of Must be 0 or greater. | + | Total entries. | + --------------------------------------------------------------------------- + | Entries 2 Bytes Number of valid Must be between 0 | + | Valid entries. and Entries Total. | + --------------------------------------------------------------------------- + | Flags 4 Bytes | + | bit 0 RESTART_DONE Toggle for every restart | + | bit 1 RESTART_ACK Toggle to ACK remote | + | RESTART_DONE | + | bits 2:31 Reserved Must be set to 0. | + --------------------------------------------------------------------------- + Table 1 - SMEM Item Header + +The content of each SMEM entries is described in Table 2 and consists of a +string identifier and a 32-bit data value. The string identifier must be +unique for each SMEM item. The data value is opaque to SMP2P giving the client +complete flexibility as to its usage. + + ----------------------- --------------------- ----------------------------- + | Field | Size | Description | Valid Values | + ------------|----------|---------------------|----------------------------- + | | | | | + | Identifier | 16 Bytes | Null Terminated | NON-NULL for | + | String | | ASCII string. | valid entries. | + | | | | | + ------------|----------|---------------------|----------------------------- + | Data | 4 Bytes | Data | Any (client defined) | + ------------ ---------- --------------------- ----------------------------- + Table 2 - Entry Format + + +The processor IDs in the system are fixed and new processors IDs will be +added to the end of the list (Table 3). + + ------------------------------------------------- + | Processor Name | ID value | + ------------------------------------------------- + | Application processor | 0 | + ------------------------------------------------- + | Modem processor | 1 | + ------------------------------------------------- + | Audio processor | 2 | + ------------------------------------------------- + | Sensor processor | 3 | + ------------------------------------------------- + | Wireless processor | 4 | + ------------------------------------------------- + | CDSP processor | 5 | + ------------------------------------------------- + | Power processor | 6 | + ------------------------------------------------- + | TrustZone processor | 7 | + ------------------------------------------------- + | NUM PROCESSORS | 8 | + ------------------------------------------------- + Table 3 - Processor IDs + +SMEM Item +--------- +The responsibility of creating an SMEM item is with the local processor that is +initiating outbound traffic. After creating the item, the local and remote +processors negotiate the version and feature flags for the item to ensure +compatibility. + +Table 4 lists the SMEM item base identifiers. To get the SMEM item ID for a +particular edge, the remote processor ID (Table 3) is added to the base item ID +for the local processor (Table 4). For example, the Apps ==> Modem (id 1) SMEM +Item ID will be 427 + 1 = 428. + + --------------------------------------------------- + | Description | SMEM ID value | + --------------------------------------------------- + | CDSP SMEM Item base | 94 | + --------------------------------------------------- + | Apps SMP2P SMEM Item base | 427 | + --------------------------------------------------- + | Modem SMP2P SMEM Item base | 435 | + --------------------------------------------------- + | Audio SMP2P SMEM Item base | 443 | + --------------------------------------------------- + | Sensors SMP2P SMEM Item base | 481 | + --------------------------------------------------- + | Wireless SMP2P SMEM Item base | 451 | + --------------------------------------------------- + | Power SMP2P SMEM Item base | 459 | + --------------------------------------------------- + | TrustZone SMP2P SMEM Item base | 489 | + --------------------------------------------------- + Table 4 - SMEM Items Base IDs + + +Version and Feature Negotiation +------------------------------- +To enable upgrading without breaking the system and to enable graceful feature +fall-back support, SMP2P supports a version number and feature flags. The +combination of the version number and feature flags enable: + 1) SMP2P software updates to be rolled out to each processor separately. + 2) Individual features to be enabled or disabled per connection or edge. + +The version number represents any change in SMP2P that breaks compatibility +between processors. Examples would be a change in the shared data structures +or changes to fundamental behavior. Each implementation of SMP2P must be able +to support a minimum of the current version and the previous version. + +The feature flags represent any changes in SMP2P that are optional and +backwards compatible. Endpoints will negotiate the supported flag when the +SMEM items are created and they cannot be changed after negotiation has been +completed. + + +Negotiation Algorithm +---------------------- +While creating the SMEM item the following algorithm shall be used. + + if remote endpoint's SMEM Item exists + Read remote version number and flags + Local version number must be lower of + - remote version number + - highest supported local version number + Flags value is bitwise AND of + - remote feature flags + - locally supported flags + Create SMEM item and populate negotiated number and flags + Interrupt remote processor + if version and flags match, negotiation is complete, else wait + for remote interrupt below. + Else + Create SMEM item and populate it with highest supported version and any + requested feature flag. + Interrupt remote processor. + Wait for Interrupt below. + +Upon receiving the interrupt from remote processor and negotiation is not +complete, check the version number and feature flags: + if equal, negotiation is complete. + if remote number is less than local number, and remote number is + supported: + Set local version number to remote version number + Bitwise AND local flags with remote flags + Interrupt remote processor + Negotiation is complete + if remote number is not supported, then negotiation has failed + Set version number to 0xFF and report failure in kernel log. + if remote number is more than local number: + Wait for remote endpoint to process our interrupt and negotiate down. + + +Creating an SMEM Entry +---------------------- +Each new SMEM entry used in data transfer must be created at the end of the +entry array in the SMEM item and cannot be deleted until the system is +rebooted. The following sequence is be followed: + 1) Compare Entries Valid and Entries Total to verify if there is room in the + entry array for this request (if not, return error code to client). + 2) Populate the Identifier of new entry and do a write memory barrier. + 3) Update Entries Valid and Entries Total and do a write memory barrier. + 4) Interrupt remote endpoint. + + +Entry Write +----------- +An entry write is achieved by the following sequence of operations: + 1) Update data field in the entry and do a write memory barrier. + 2) Interrupt remote endpoint. + + +Entry Read / Receiving Interrupts +--------------------------------- +An interrupt will be received from the remote system for one or more of the following events: + 1) Initialization + 2) Entry change + 3) New Entry + +As long as the SMEM item initialization is complete, then each interrupt should +trigger SMP2P to: + 1) Compare valid entry data value to cached value and notify client if it + has changed. + 2) Compare Entries Valid to cached value. If changed, initialize new entries. + +Security +======== +Since the implementation resides in the kernel and does not expose interfaces +to userspace, no security issues are anticipated. The usage of separate SMEM +items allows for future security enhancements in SMEM. + +Performance +=========== +No performance issues are anticipated as the signaling rate is expected to be +low and is performed in interrupt context which minimizes latency. + +Interfaces +================ +SMP2P is only supported in the kernel and interfaces with clients through the +GPIO and interrupt subsystems. + +To map an entry to the client, the client must add two nodes to the Device +Tree: + 1) A node that matches "qcom,smp2pgpio" to create the entry + 2) A node that matches the client driver to provide the GPIO pin mapping + +The details of the device tree entries for the GPIO interface are contained in +the file Documentation/devicetree/bindings/gpio/gpio-smp2p.txt. + + /* SMP2P Test Driver for inbound entry. */ + smp2pgpio_smp2p_7_in: qcom,smp2pgpio-smp2p-7-in { + compatible = "qcom,smp2pgpio"; + qcom,entry-name = "smp2p"; + qcom,remote-pid = <7>; + qcom,is-inbound; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* SMP2P Test Client for inbound entry. */ + qcom,smp2pgpio_test_smp2p_7_in { + compatible = "qcom,smp2pgpio_test_smp2p_7_in"; + gpios = <&smp2pgpio_smp2p_7_in 0 0>, + <&smp2pgpio_smp2p_7_in 1 0>, + . . . + <&smp2pgpio_smp2p_7_in 31 0>; + }; + + /* SMP2P Test Driver for outbound entries */ + smp2pgpio_smp2p_345_out: qcom,smp2pgpio-smp2p-7-out { + compatible = "qcom,smp2pgpio"; + qcom,entry-name = "smp2p"; + qcom,remote-pid = <7>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* SMP2P Test Client for outbound entry. */ + qcom,smp2pgpio_test_smp2p_7_out { + compatible = "qcom,smp2pgpio_test_smp2p_7_out"; + gpios = <&smp2pgpio_smp2p_7_out 0 0>, + <&smp2pgpio_smp2p_7_out 1 0>, + . . . + <&smp2pgpio_smp2p_7_out 31 0>; + +The client can use a match entry for "qcom,smp2pgpio_test_smp2p_7_in" to +retrieve the Device Tree configuration node. Once that node has been +retrieved, the client can call of_get_gpio() to get the virtual GPIO pin and +also use gpio_to_irq() to map the GPIO pin to a virtual interrupt. After that +point, the standard GPIO and Interrupt APIs can be used to manipulate the SMP2P +entries and receive notifications of changes. Examples of typical function +calls are shown below: + of_get_gpio() + gpio_get_value() + gpio_set_value() + gpio_to_irq() + request_irq() + free_irq() + +Please reference the unit test code for example usage. + +Subsystem Restart +================= +SMP2P is unaffected by SubSystem Restart (SSR) on the high-level OS side and is +actually used as an underlying communication mechanism for SSR. On the +peripheral system that is being restarted, SMP2P will zero out all existing +state entries upon reboot as part of the SMP2P initialization process and if the +SSR_ACK feature is enabled, then it waits for an acknowledgement as outlined in +the following subsections. + +SSR_ACK Feature - Reboot Use Case (Non-HLOS Only) +------------------------------------------------- +If a remote system boots up after an SSR and sees that the remote and local +version numbers and feature flags are equal, then it zeros out entry values. If +the SSR_ACK feature is enabled, it will wait for an acknowledgement from the other +processor that it has seen the zero entry before completing the negotiation +sequence. + + if remote and local version numbers and feature flags are equal + Zero out all entry values + if SSR_ACK feature is enabled + Set local RESTART_DONE flag to inverse of the remote RESTART_ACK + Send interrupt to remote system + Wait for interrupt and for remote RESTART_ACK to be equal to local + RESTART_DONE + Continue with normal negotiation sequence + +Interrupt Use Case +------------------ +For every interrupt triggered by a remote change, SMP2P will notify the client +of a change in state. In addition, if the SSR_ACK feature is enabled, the SSR +handshaking will also be handled. + + if SSR_ACK feature is enabled + if remote RESTART_DONE != local RESTART_ACK + Notify client of entry change (will be * -> 0 transition) + Toggle local RESTART_ACK + Send interrupt to remote system + else + Notify client of entry change as usual + else + Notify client of entry change as usual + +Debug +===== +The state values and names for all entries accessible by the Apps are +accessible through debugfs nodes for general debug purposes. + +Debugfs entries for triggering unit-tests are also exported. + +Internal logging will be performed using the IPC Logging module to enable +post-mortem analysis. + +Testing +======= +On-target unit testing will be done to verify internal functionality and the +GPIO/IRQ API's. + +Driver parameters +================= +One module parameter will be provided to change the verbosity of internal logging. + +Config options +============== +Configuration of interrupts will be done using Device Tree per the format in +Documentation/devicetree/bindings/arm/msm/smp2p.txt. By default, the testing +components will be enabled since it does not affect performance and has a +minimal impact on kernel size. However, customers can disable the testing +component for size optimization. + + CONFIG_MSM_SMP2P - enables SMP2P + CONFIG_MSM_SMP2P_TEST - enables unit test support + +Dependencies +=========== +Requires SMEM for creating the SMEM items. + +User Space utilities +==================== +No userspace utilities are planned. + +Known issues +============ +None. diff --git a/Documentation/arm/msm/remote_debug_drv.txt b/Documentation/arm/msm/remote_debug_drv.txt new file mode 100644 index 000000000000..13a35f43e86b --- /dev/null +++ b/Documentation/arm/msm/remote_debug_drv.txt @@ -0,0 +1,468 @@ +Introduction +============ + +The goal of this debug feature is to provide a reliable, responsive, +accurate and secure debug capability to developers interested in +debugging MSM subsystem processor images without the use of a hardware +debugger. + +The Debug Agent along with the Remote Debug Driver implements a shared +memory based transport mechanism that allows for a debugger (ex. GDB) +running on a host PC to communicate with a remote stub running on +peripheral subsystems such as the ADSP, MODEM etc. + +The diagram below depicts end to end the components involved to +support remote debugging: + + +: : +: HOST (PC) : MSM +: ,--------, : ,-------, +: | | : | Debug | ,--------, +: |Debugger|<--:-->| Agent | | Remote | +: | | : | App | +----->| Debug | +: `--------` : |-------| ,--------, | | Stub | +: : | Remote| | |<---+ `--------` +: : | Debug |<-->|--------| +: : | Driver| | |<---+ ,--------, +: : `-------` `--------` | | Remote | +: : LA Shared +----->| Debug | +: : Memory | Stub | +: : `--------` +: : Peripheral Subsystems +: : (ADSP, MODEM, ...) + + +Debugger: Debugger application running on the host PC that + communicates with the remote stub. + Examples: GDB, LLDB + +Debug Agent: Software that runs on the Linux Android platform + that provides connectivity from the MSM to the + host PC. This involves two portions: + 1) User mode Debug Agent application that discovers + processes running on the subsystems and creates + TCP/IP sockets for the host to connect to. In addition + to this, it creates an info (or meta) port that + users can connect to discover the various + processes and their corresponding debug ports. + +Remote Debug A character based driver that the Debug +Driver: Agent uses to transport the payload received from the + host to the debug stub running on the subsystem + processor over shared memory and vice versa. + +Shared Memory: Shared memory from the SMEM pool that is accessible + from the Applications Processor (AP) and the + subsystem processors. + +Remote Debug Privileged code that runs in the kernels of the +Stub: subsystem processors that receives debug commands + from the debugger running on the host and + acts on these commands. These commands include reading + and writing to registers and memory belonging to the + subsystem's address space, setting breakpoints, + single stepping etc. + +Hardware description +==================== + +The Remote Debug Driver interfaces with the Remote Debug stubs +running on the subsystem processors and does not drive or +manage any hardware resources. + +Software description +==================== + +The debugger and the remote stubs use Remote Serial Protocol (RSP) +to communicate with each other. This is widely used protocol by both +software and hardware debuggers. RSP is an ASCII based protocol +and used when it is not possible to run GDB server on the target under +debug. + +The Debug Agent application along with the Remote Debug Driver +is responsible for establishing a bi-directional connection from +the debugger application running on the host to the remote debug +stub running on a subsystem. The Debug Agent establishes connectivity +to the host PC via TCP/IP sockets. + +This feature uses ADB port forwarding to establish connectivity +between the debugger running on the host and the target under debug. + +Please note the Debug Agent does not expose HLOS memory to the +remote subsystem processors. + +Design +====== + +Here is the overall flow: + +1) When the Debug Agent application starts up, it opens up a shared memory +based transport channel to the various subsystem processor images. + +2) The Debug Agent application sends messages across to the remote stubs +to discover the various processes that are running on the subsystem and +creates debug sockets for each of them. + +3) Whenever a process running on a subsystem exits, the Debug Agent +is notified by the stub so that the debug port and other resources +can be reclaimed. + +4) The Debug Agent uses the services of the Remote Debug Driver to +transport payload from the host debugger to the remote stub and vice versa. + +5) Communication between the Remote Debug Driver and the Remote Debug stub +running on the subsystem processor is done over shared memory (see figure). +SMEM services are used to allocate the shared memory that will +be readable and writeable by the AP and the subsystem image under debug. + +A separate SMEM allocation takes place for each subsystem processor +involved in remote debugging. The remote stub running on each of the +subsystems allocates a SMEM buffer using a unique identifier so that both +the AP and subsystem get the same physical block of memory. It should be +noted that subsystem images can be restarted at any time. +However, when a subsystem comes back up, its stub uses the same unique +SMEM identifier to allocate the SMEM block. This would not result in a +new allocation rather the same block of memory in the first bootup instance +is provided back to the stub running on the subsystem. + +An 8KB chunk of shared memory is allocated and used for communication +per subsystem. For multi-process capable subsystems, 16KB chunk of shared +memory is allocated to allow for simultaneous debugging of more than one +process running on a single subsystem. + +The shared memory is used as a circular ring buffer in each direction. +Thus we have a bi-directional shared memory channel between the AP +and a subsystem. We call this SMQ. Each memory channel contains a header, +data and a control mechanism that is used to synchronize read and write +of data between the AP and the remote subsystem. + +Overall SMQ memory view: +: +: +------------------------------------------------+ +: | SMEM buffer | +: |-----------------------+------------------------| +: |Producer: LA | Producer: Remote | +: |Consumer: Remote | subsystem | +: | subsystem | Consumer: LA | +: | | | +: | Producer| Consumer| +: +-----------------------+------------------------+ +: | | +: | | +: | +--------------------------------------+ +: | | +: | | +: v v +: +--------------------------------------------------------------+ +: | Header | Data | Control | +: +-----------+---+---+---+-----+----+--+--+-----+---+--+--+-----+ +: | | b | b | b | | S |n |n | | S |n |n | | +: | Producer | l | l | l | | M |o |o | | M |o |o | | +: | Ver | o | o | o | | Q |d |d | | Q |d |d | | +: |-----------| c | c | c | ... | |e |e | ... | |e |e | ... | +: | | k | k | k | | O | | | | I | | | | +: | Consumer | | | | | u |0 |1 | | n |0 |1 | | +: | Ver | 0 | 1 | 2 | | t | | | | | | | | +: +-----------+---+---+---+-----+----+--+--+-----+---+--+--+-----+ +: | | +: + | +: | +: +------------------------+ +: | +: v +: +----+----+----+----+ +: | SMQ Nodes | +: |----|----|----|----| +: Node # | 0 | 1 | 2 | ...| +: |----|----|----|----| +: Starting Block Index # | 0 | 3 | 8 | ...| +: |----|----|----|----| +: # of blocks | 3 | 5 | 1 | ...| +: +----+----+----+----+ +: + +Header: Contains version numbers for software compatibility to ensure +that both producers and consumers on the AP and subsystems know how to +read from and write to the queue. +Both the producer and consumer versions are 1. +: +---------+-------------------+ +: | Size | Field | +: +---------+-------------------+ +: | 1 byte | Producer Version | +: +---------+-------------------+ +: | 1 byte | Consumer Version | +: +---------+-------------------+ + + +Data: The data portion contains multiple blocks [0..N] of a fixed size. +The block size SM_BLOCKSIZE is fixed to 128 bytes for header version #1. +Payload sent from the debug agent app is split (if necessary) and placed +in these blocks. The first data block is placed at the next 8 byte aligned +address after the header. + +The number of blocks for a given SMEM allocation is derived as follows: + Number of Blocks = ((Total Size - Alignment - Size of Header + - Size of SMQIn - Size of SMQOut)/(SM_BLOCKSIZE)) + +The producer maintains a private block map of each of these blocks to +determine which of these blocks in the queue is available and which are free. + +Control: +The control portion contains a list of nodes [0..N] where N is number +of available data blocks. Each node identifies the data +block indexes that contain a particular debug message to be transferred, +and the number of blocks it took to hold the contents of the message. + +Each node has the following structure: +: +---------+-------------------+ +: | Size | Field | +: +---------+-------------------+ +: | 2 bytes |Staring Block Index| +: +---------+-------------------+ +: | 2 bytes |Number of Blocks | +: +---------+-------------------+ + +The producer and the consumer update different parts of the control channel +(SMQOut / SMQIn) respectively. Each of these control data structures contains +information about the last node that was written / read, and the actual nodes +that were written/read. + +SMQOut Structure (R/W by producer, R by consumer): +: +---------+-------------------+ +: | Size | Field | +: +---------+-------------------+ +: | 4 bytes | Magic Init Number | +: +---------+-------------------+ +: | 4 bytes | Reset | +: +---------+-------------------+ +: | 4 bytes | Last Sent Index | +: +---------+-------------------+ +: | 4 bytes | Index Free Read | +: +---------+-------------------+ + +SMQIn Structure (R/W by consumer, R by producer): +: +---------+-------------------+ +: | Size | Field | +: +---------+-------------------+ +: | 4 bytes | Magic Init Number | +: +---------+-------------------+ +: | 4 bytes | Reset ACK | +: +---------+-------------------+ +: | 4 bytes | Last Read Index | +: +---------+-------------------+ +: | 4 bytes | Index Free Write | +: +---------+-------------------+ + +Magic Init Number: +Both SMQ Out and SMQ In initialize this field with a predefined magic +number so as to make sure that both the consumer and producer blocks +have fully initialized and have valid data in the shared memory control area. + Producer Magic #: 0xFF00FF01 + Consumer Magic #: 0xFF00FF02 + +SMQ Out's Last Sent Index and Index Free Read: + Only a producer can write to these indexes and they are updated whenever + there is new payload to be inserted into the SMQ in order to be sent to a + consumer. + + The number of blocks required for the SMQ allocation is determined as: + (payload size + SM_BLOCKSIZE - 1) / SM_BLOCKSIZE + + The private block map is searched for a large enough continuous set of blocks + and the user data is copied into the data blocks. + + The starting index of the free block(s) is updated in the SMQOut's Last Sent + Index. This update keeps track of which index was last written to and the + producer uses it to determine where the the next allocation could be done. + + Every allocation, a producer updates the Index Free Read from its + collaborating consumer's Index Free Write field (if they are unequal). + This index value indicates that the consumer has read all blocks associated + with allocation on the SMQ and that the producer can reuse these blocks for + subsquent allocations since this is a circular queue. + + At cold boot and restart, these indexes are initialized to zero and all + blocks are marked as available for allocation. + +SMQ In's Last Read Index and Index Free Write: + These indexes are written to only by a consumer and are updated whenever + there is new payload to be read from the SMQ. The Last Read Index keeps + track of which index was last read by the consumer and using this, it + determines where the next read should be done. + After completing a read, Last Read Index is incremented to the + next block index. A consumer updates Index Free Write to the starting + index of an allocation whenever it has completed processing the blocks. + This is an optimization that can be used to prevent an additional copy + of data from the queue into a client's data buffer and the data in the queue + itself can be used. + Once Index Free Write is updated, the collaborating producer (on the next + data allocation) reads the updated Index Free Write value and it then + updates its corresponding SMQ Out's Index Free Read and marks the blocks + associated with that index as available for allocation. At cold boot and + restart, these indexes are initialized to zero. + +SMQ Out Reset# and SMQ In Reset ACK #: + Since subsystems can restart at anytime, the data blocks and control channel + can be in an inconsistent state when a producer or consumer comes up. + We use Reset and Reset ACK to manage this. At cold boot, the producer + initializes the Reset# to a known number ex. 1. Every other reset that the + producer undergoes, the Reset#1 is simply incremented by 1. All the producer + indexes are reset. + When the producer notifies the consumer of data availability, the consumer + reads the producers Reset # and copies that into its SMQ In Reset ACK# + field when they differ. When that occurs, the consumer resets its + indexes to 0. + +6) Asynchronous notifications between a producer and consumer are +done using the SMP2P service which is interrupt based. + +Power Management +================ + +None + +SMP/multi-core +============== + +The driver uses completion to wake up the Debug Agent client threads. + +Security +======== + +From the perspective of the subsystem, the AP is untrusted. The remote +stubs consult the secure debug fuses to determine whether or not the +remote debugging will be enabled at the subsystem. + +If the hardware debug fuses indicate that debugging is disabled, the +remote stubs will not be functional on the subsystem. Writes to the +queue will only be done if the driver sees that the remote stub has been +initialized on the subsystem. + +Therefore even if any untrusted software running on the AP requests +the services of the Remote Debug Driver and inject RSP messages +into the shared memory buffer, these RSP messages will be discarded and +an appropriate error code will be sent up to the invoking application. + +Performance +=========== + +During operation, the Remote Debug Driver copies RSP messages +asynchronously sent from the host debugger to the remote stub and vice +versa. The debug messages are ASCII based and relatively short +(<25 bytes) and may once in a while go up to a maximum 700 bytes +depending on the command the user requested. Thus we do not +anticipate any major performance impact. Moreover, in a typical +functional debug scenario performance should not be a concern. + +Interface +========= + +The Remote Debug Driver is a character based device that manages +a piece of shared memory that is used as a bi-directional +single producer/consumer circular queue using a next fit allocator. +Every subsystem, has its own shared memory buffer that is managed +like a separate device. + +The driver distinguishes each subsystem processor's buffer by +registering a node with a different minor number. + +For each subsystem that is supported, the driver exposes a user space +interface through the following node: + - /dev/rdbg-<subsystem> + Ex. /dev/rdbg-adsp (for the ADSP subsystem) + +The standard open(), close(), read() and write() API set is +implemented. + +The open() syscall will fail if a subsystem is not present or supported +by the driver or a shared memory buffer cannot be allocated for the +AP - subsystem communication. It will also fail if the subsytem has +not initialized the queue on its side. Here are the error codes returned +in case a call to open() fails: +ENODEV - memory was not yet allocated for the device +EEXIST - device is already opened +ENOMEM - SMEM allocation failed +ECOMM - Subsytem queue is not yet setup +ENOMEM - Failure to initialize SMQ + +read() is a blocking call that will return with the number of bytes written +by the subsystem whenever the subsystem sends it some payload. Here are the +error codes returned in case a call to read() fails: +EINVAL - Invalid input +ENODEV - Device has not been opened yet +ERESTARTSYS - call to wait_for_completion_interruptible is interrupted +ENODATA - call to smq_receive failed + +write() attempts to send user mode payload out to the subsystem. It can fail +if the SMQ is full. The number of bytes written is returned back to the user. +Here are the error codes returned in case a call to write() fails: +EINVAL - Invalid input +ECOMM - SMQ send failed + +In the close() syscall, the control information state of the SMQ is +initialized to zero thereby preventing any further communication between +the AP and the subsystem. Here is the error code returned in case +a call to close() fails: +ENODEV - device wasn't opened/initialized + +The Remote Debug driver uses SMP2P for bi-directional AP to subsystem +notification. Notifications are sent to indicate that there are new +debug messages available for processing. Each subsystem that is +supported will need to add a device tree entry per the usage +specification of SMP2P driver. + +In case the remote stub becomes non operational or the security configuration +on the subsystem does not permit debugging, any messages put in the SMQ will +not be responded to. It is the responsibility of the Debug Agent app and the +host debugger application such as GDB to timeout and notify the user of the +non availability of remote debugging. + +Driver parameters +================= + +None + +Config options +============== + +The driver is configured with a device tree entry to map an SMP2P entry +to the device. The SMP2P entry name used is "rdbg". Please see +kernel\Documentation\arm\msm\msm_smp2p.txt for information about the +device tree entry required to configure SMP2P. + +The driver uses the SMEM allocation type SMEM_LC_DEBUGGER to allocate memory +for the queue that is used to share data with the subsystems. + +Dependencies +============ + +The Debug Agent driver requires services of SMEM to +allocate shared memory buffers. + +SMP2P is used as a bi-directional notification +mechanism between the AP and a subsystem processor. + +User space utilities +==================== + +This driver is meant to be used in conjunction with the user mode +Remote Debug Agent application. + +Other +===== + +None + +Known issues +============ +For targets with an external subsystem, we cannot use +shared memory for communication and would have to use the prevailing +transport mechanisms that exists between the AP and the external subsystem. + +This driver cannot be leveraged for such targets. + +To do +===== + +None diff --git a/Documentation/arm/msm/service_notifier.txt b/Documentation/arm/msm/service_notifier.txt new file mode 100644 index 000000000000..cfa64256d93a --- /dev/null +++ b/Documentation/arm/msm/service_notifier.txt @@ -0,0 +1,43 @@ +Introduction +============= + +The service notifier driver facilitates a mechanism for a client +to register for state notifications regarding a particular remote service. +A remote service here refers to a process providing certain services like audio, +the identifier for which is provided by the service locator. The process +domain will typically run on a remote processor within the same SoC. + +Software Description +===================== + +The driver provides the following two APIs: +* service_notif_register_notifier() - Register a notifier for a service + On success, it returns back a handle. It takes the following arguments: + service_path: Individual service identifier path for which a client + registers for notifications. + instance_id: Instance id specific to a subsystem. + current_state: Current state of service returned by the registration + process. + notifier block: notifier callback for service events. + +* service_notif_unregister_notifier() - Unregister a notifier for a service. + This takes the handle returned during registration and the notifier block + previously registered as the arguments. + +Types of notifications: +======================= + +A client can get either a SERVICE_DOWN notification or a SERVICE_UP +notification. A SERVICE_UP notification will be sent out when the SERVICE comes +up and is functional while a SERVICE_DOWN notification is sent after a +service ceases to exist. At the point a SERVICE_DOWN notification is sent out, +all the clients should assume that the service is already dead. + +Interaction with SSR +===================== +In general, it is recommended that clients register for either service +notifications using the service notifier or SSR notifications, but not both. +In case it is necessary to register for both, the client can expect to get +the SERVICE_DOWN notification before the SUBSYS_AFTER_SHUTDOWN notification. +However, the client may receive the SUBSYS_BEFORE_SHUTDOWN notification +either before or after the SERVICE_DOWN notification. diff --git a/Documentation/arm/msm/system_health_monitor.txt b/Documentation/arm/msm/system_health_monitor.txt new file mode 100644 index 000000000000..4e2e4c6c6281 --- /dev/null +++ b/Documentation/arm/msm/system_health_monitor.txt @@ -0,0 +1,213 @@ +Introduction +============ + +System Health Monitor (SHM) passively monitors the health of the +peripherals connected to the application processor. Software components +in the application processor that experience communication failure can +request the SHM to perform a system-wide health check. If any failures +are detected during the health-check, then a subsystem restart will be +triggered for the failed subsystem. + +Hardware description +==================== + +SHM is solely a software component and it interfaces with peripherals +through QMI communication. SHM does not control any hardware blocks and +it uses subsystem_restart to restart any peripheral. + +Software description +==================== + +SHM hosts a QMI service in the kernel that is connected to the Health +Monitor Agents (HMA) hosted in the peripherals. HMAs in the peripherals +are initialized along with other critical services in the peripherals and +hence the connection between SHM and HMAs are established during the early +stages of the peripheral boot-up procedure. Software components within the +application processor, either user-space or kernel-space, identify any +communication failure with the peripheral by a lack of response and report +that failure to SHM. SHM checks the health of the entire system through +HMAs that are connected to it. If all the HMAs respond in time, then the +failure report by the software component is ignored. If any HMAs do not +respond in time, then SHM will restart the concerned peripheral. Figure 1 +shows a high level design diagram and Figure 2 shows a flow diagram of the +design. + +Figure 1 - System Health Monitor Overview: + + +------------------------------------+ +----------------------+ + | Application Processor | | Peripheral 1 | + | +--------------+ | | +----------------+ | + | | Applications | | | | Health Monitor | | + | +------+-------+ | +------->| Agent 1 | | + | User-space | | | | +----------------+ | + +-------------------------|----------+ | +----------------------+ + | Kernel-space v | QMI . + | +---------+ +---------------+ | | . + | | Kernel |----->| System Health |<----+ . + | | Drivers | | Monitor | | | + | +---------+ +---------------+ | QMI +----------------------+ + | | | | Peripheral N | + | | | | +----------------+ | + | | | | | Health Monitor | | + | | +------->| Agent N | | + | | | +----------------+ | + +------------------------------------+ +----------------------+ + + +Figure 2 - System Health Monitor Message Flow with 2 peripherals: + + +-----------+ +-------+ +-------+ +-------+ + |Application| | SHM | | HMA 1 | | HMA 2 | + +-----+-----+ +-------+ +---+---+ +---+---+ + | | | | + | | | | + | check_system | | | + |------------------->| | | + | _health() | Report_ | | + | |---------------->| | + | | health_req(1) | | + | | | | + | | Report_ | | + | |---------------------------------->| + | +-+ health_req(2) | | + | |T| | | + | |i| | | + | |m| | | + | |e| Report_ | | + | |o|<---------------| | + | |u| health_resp(1) | | + | |t| | | + | +-+ | | + | | subsystem_ | | + | |---------------------------------->| + | | restart(2) | | + + + + + + +HMAs can be extended to monitor the health of individual software services +executing in their concerned peripherals. HMAs can restore the services +that are not responding to a responsive state. + +Design +====== + +The design goal of SHM is to: + * Restore the unresponsive peripheral to a responsive state. + * Restore the unresponsive software services in a peripheral to a + responsive state. + * Perform power-efficient monitoring of the system health. + +The alternate design discussion includes sending keepalive messages in +IPC protocols at Transport Layer. This approach requires rolling out the +protocol update in all the peripherals together and hence has considerable +coupling unless a suitable feature negotiation algorithm is implemented. +This approach also requires all the IPC protocols at transport layer to be +updated and hence replication of effort. There are multiple link-layer +protocols and adding keep-alive at the link-layer protocols does not solve +issues at the client layer which is solved by SHM. Restoring a peripheral +or a remote software service by an IPC protocol has not been an industry +standard practice. Industry standard IPC protocols only terminate the +connection if there is any communication failure and rely upon other +mechanisms to restore the system to full operation. + +Power Management +================ + +This driver ensures that the health monitor messages are sent only upon +request and hence does not wake up application processor or any peripheral +unnecessarily. + +SMP/multi-core +============== + +This driver uses standard kernel mutexes and wait queues to achieve any +required synchronization. + +Security +======== + +Denial of Service (DoS) attack by an application that keeps requesting +health checks at a high rate can be throttled by the SHM to minimize the +impact of the misbehaving application. + +Interface +========= + +Kernel-space APIs: +------------------ +/** + * kern_check_system_health() - Check the system health + * + * @return: 0 on success, standard Linux error codes on failure. + * + * This function is used by the kernel drivers to initiate the + * system health check. This function in turn trigger SHM to send + * QMI message to all the HMAs connected to it. + */ +int kern_check_system_health(void); + +User-space Interface: +--------------------- +This driver provides a devfs interface(/dev/system_health_monitor) to the +user-space. A wrapper API library will be provided to the user-space +applications in order to initiate the system health check. The API in turn +will interface with the driver through the sysfs interface provided by the +driver. + +/** + * check_system_health() - Check the system health + * + * @return: 0 on success, -1 on failure. + * + * This function is used by the user-space applications to initiate the + * system health check. This function in turn trigger SHM to send QMI + * message to all the HMAs connected to it. + */ +int check_system_health(void); + +The above mentioned interface function works by opening the sysfs +interface provided by SHM, perform an ioctl operation and then close the +sysfs interface. The concerned ioctl command(CHECK_SYS_HEALTH_IOCTL) does +not take any argument. This function performs the health check, handles the +response and timeout in an asynchronous manner. + +Driver parameters +================= + +The time duration for which the SHM has to wait before a response +arrives from HMAs can be configured using a module parameter. This +parameter will be used only for debugging purposes. The default SHM health +check timeout is 2s, which can be overwritten by the timeout provided by +HMA during the connection establishment. + +Config options +============== + +This driver is enabled through kernel config option +CONFIG_SYSTEM_HEALTH_MONITOR. + +Dependencies +============ + +This driver depends on the following kernel modules for its complete +functionality: + * Kernel QMI interface + * Subsystem Restart support + +User space utilities +==================== + +Any user-space or kernel-space modules that experience communication +failure with peripherals will interface with this driver. Some of the +modules include: + * RIL + * Location Manager + * Data Services + +Other +===== + +SHM provides a debug interface to enumerate some information regarding the +recent health checks. The debug information includes, but not limited to: +* application name that triggered the health check. +* time of the health check. +* status of the health check. diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 701d39d3171a..56d6d8b796db 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -109,7 +109,13 @@ Header notes: 1 - 4K 2 - 16K 3 - 64K - Bits 3-63: Reserved. + Bit 3: Kernel physical placement + 0 - 2MB aligned base should be as close as possible + to the base of DRAM, since memory below it is not + accessible via the linear mapping + 1 - 2MB aligned base may be anywhere in physical + memory + Bits 4-63: Reserved. - When image_size is zero, a bootloader should attempt to keep as much memory as possible free for use by the kernel immediately after the @@ -117,14 +123,14 @@ Header notes: depending on selected features, and is effectively unbound. The Image must be placed text_offset bytes from a 2MB aligned base -address near the start of usable system RAM and called there. Memory -below that base address is currently unusable by Linux, and therefore it -is strongly recommended that this location is the start of system RAM. -The region between the 2 MB aligned base address and the start of the -image has no special significance to the kernel, and may be used for -other purposes. +address anywhere in usable system RAM and called there. The region +between the 2 MB aligned base address and the start of the image has no +special significance to the kernel, and may be used for other purposes. At least image_size bytes from the start of the image must be free for use by the kernel. +NOTE: versions prior to v4.6 cannot make use of memory below the +physical offset of the Image so it is recommended that the Image be +placed as close as possible to the start of system RAM. Any memory described to the kernel (even that below the start of the image) which is not marked as reserved from the kernel (e.g., with a diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt new file mode 100644 index 000000000000..58b71ddf9b60 --- /dev/null +++ b/Documentation/arm64/silicon-errata.txt @@ -0,0 +1,58 @@ + Silicon Errata and Software Workarounds + ======================================= + +Author: Will Deacon <will.deacon@arm.com> +Date : 27 November 2015 + +It is an unfortunate fact of life that hardware is often produced with +so-called "errata", which can cause it to deviate from the architecture +under specific circumstances. For hardware produced by ARM, these +errata are broadly classified into the following categories: + + Category A: A critical error without a viable workaround. + Category B: A significant or critical error with an acceptable + workaround. + Category C: A minor error that is not expected to occur under normal + operation. + +For more information, consult one of the "Software Developers Errata +Notice" documents available on infocenter.arm.com (registration +required). + +As far as Linux is concerned, Category B errata may require some special +treatment in the operating system. For example, avoiding a particular +sequence of code, or configuring the processor in a particular way. A +less common situation may require similar actions in order to declassify +a Category A erratum into a Category C erratum. These are collectively +known as "software workarounds" and are only required in the minority of +cases (e.g. those cases that both require a non-secure workaround *and* +can be triggered by Linux). + +For software workarounds that may adversely impact systems unaffected by +the erratum in question, a Kconfig entry is added under "Kernel +Features" -> "ARM errata workarounds via the alternatives framework". +These are enabled by default and patched in at runtime when an affected +CPU is detected. For less-intrusive workarounds, a Kconfig option is not +available and the code is structured (preferably with a comment) in such +a way that the erratum will not be hit. + +This approach can make it slightly onerous to determine exactly which +errata are worked around in an arbitrary kernel source tree, so this +file acts as a registry of software workarounds in the Linux Kernel and +will be updated when new workarounds are committed and backported to +stable kernels. + +| Implementor | Component | Erratum ID | Kconfig | ++----------------+-----------------+-----------------+-------------------------+ +| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM | Cortex-A57 | #852523 | N/A | +| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +| | | | | +| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | diff --git a/Documentation/bif-framework.txt b/Documentation/bif-framework.txt new file mode 100644 index 000000000000..9831c800806d --- /dev/null +++ b/Documentation/bif-framework.txt @@ -0,0 +1,560 @@ +Introduction +============ + +BIF (Battery Interface) is a MIPI (Mobile Industry Processor Interface) +Alliance specification for a serial interface between a host device and a +battery pack. It provides a means to handle smart battery packs which can +communicate over BIF as well as low cost battery packs which provide no +serial communication interface. + +The BIF bus supports 1 master and up to 256 slaves. It supports data rates +up to 250 kbps. The master is in charge of initiating all bus +communications. Slaves may only respond asynchronously when they need to +signal the master that they have an interrupt pending and when the bus is +configured for interrupt mode. + +The BIF framework consists of a core into which BIF controller drivers +register. At runtime, consumers are notified of various events (e.g. battery +insertion and battery removal) via a notifier. Various framework functions are +available for consumers to read and write slave registers as well as to send +arbitrary BIF commands on the bus. + +Hardware description +==================== + +The BIF bus is a 1-wire wired-or interface. The bus signal is referred to as +the battery communication line (BCL). The BCL is pulled high by a resistor on +the host side and is driven low when the master or one of the slaves is +communicating. Additionally, there is a pull down resistor in the battery +pack which is used to identify whether or not the battery pack has BIF slaves. +Battery removal detection is achieved by comparing the analog voltage of the BCL +when idle to the host side reference voltage. If these voltages are within a +certain threshold, then a battery pack is not present. + +Slaves are addressed on the BIF bus using an 8-bit device address (DEV_ADR). +Notably, it is possible for no slaves to have defined DEV_ADR. In this case, +slave addressing is achieved via the always present unique ID (UID). The UID +of a slave is 80 bits long and guaranteed to be globally unique. A UID search +algorithm can be followed in order determine the UID of all slaves on the bus. + +BIF slaves come in two varieties: primary and secondary. A single primary +slave may be present on the battery pack and a single primary slave may be +present on the host. A battery pack primary slave has DEV_ADR=0x01. The +DEV_ADR of a host primary slave is set by the manufacturer. A given primary +slave contains a list of the UIDs of all secondary slaves in the same +subsystem. This provides a fast mechanism to determine the address of all +slaves without having to resort to the lengthy UID search algorithm. + +Each slave has a 64 kB address space. Part of this address space consists of +generic DDB L1 and L2 data structures at known addresses. This allows for +runtime discovery of supported battery properties and functions of a given +smart battery pack. + +System Diagram: + +-------------------------------+ +---------------------------------+ + | Host | | Smart Battery Pack | + | | | | + | Vbat-<+>-------<+>----------------------------+ | + | | | | | + | +--------------+ | | +--------------+ | | + | | Master BIF<+>-+---------<+>--BCL--<+>------+-<+>BIF Primary | | | + | | | | | | | | Slave | | | + | +--------------+ | | | | +--------------+ | | + | | | | | | | + | + - - - - - - -+ | | | | + - - - - - - -+ | | + | | Primary BIF<+>-+ | | +-<+>BIF Secondary| | | + | | Slave | | | | | | Slave | | | + | +- - - - - - - + | | | | +-- - - - - - -+ | | + | | | | | | | + | + - - - - - - -+ | | | | + - - - - - - -+ | | + | |Secondary BIF<+>-+ | | +-<+>BIF Secondary| | | + | |Slave | | | | | | Slave | | | + | +- - - - - - - + | | | | +-- - - - - - -+ | | + | / | | / | | + | Vref \ Rpu | | Rid \ ---- | + | ___ / | | / Battery -- | + | | \ | | \ Cell ---- | + | +-------+ | | | -- | + | | | | | | + | GND-<+>-------<+>------+---------------------+ | + | | | | + +-------------------------------+ +---------------------------------+ + +An overview of BIF is available at: +http://mipi.org/specifications/battery-interface + +Software description +==================== + +A given BIF hardware interface driver registers as a BIF controller in the +BIF framework during its probe function. The controller specifies a set of +callback functions which are used by the BIF framework to initiate bus +transactions (e.g. register read, register write, wait for slave interrupt) +and to configure the bus. The framework exposes a small API to controllers +which is used to notify the framework about asynchronous events such as +battery pack insertion/removal and slave interrupts. + +A given BIF consumer is linked to a BIF controller by specifying a property +in the consumer's device tree node which takes as its value the phandle of +the BIF controller's device tree node. + +A consumer driver calls a get function during its probe function with its +device pointer in order to get a handle to the BIF controller if it has probed. +If it hasn't, then ERR_PTR(-EPROBE_DEFER) is returned. The controller handle +can be used directly by the consumer to issue raw bus transactions if needed. +The controller handle can then be used to query which slaves are currently +present on the bus, if any. Handles to these slaves may be used by a consumer +driver in high level framework APIs such as register read and register write +which are slave oriented. All BIF framework API functions are synchronous, +blocking, and can sleep. + +Consumer drivers may also register a notifier function which is called when +certain bus activities occur such as battery pack insertion and removal. +Additionally, consumer drivers may register a notifier function which is called +when a specified slave interrupt fires. + +The framework maintains several linked-lists. One list contains all controllers +that have been registered. A second list contains all slaves that have been +seen since the system booted as well as a flag to indicate if they are currently +present or not. This scheme is used to avoid issues with slave handles existing +after a slave is removed and also so that function and object values do not have +to be searched when a slave is reinserted in the system since slaves are +globally unique and these features are read-only. Two further lists are +maintained inside slave device structures which contain BIF functions and +objects found in the slave. API functions are provided so that consumers can +find functions supported by slaves. + +Design +====== + +Design Goals: +One major goal of the BIF framework is to provide a uniform API for BIF +consumers to communicate with battery packs. This ensures that consumers are +unaffected by changes in the controller driver which actually interfaces with +the BCL at a hardware level. + +Another goal of the framework is to ensure the BIF bus can be shared between +multiple consumers in a simple and functionally correct way. Locking is used +inside of the framework to provide mutual exclusion on the bus. + +The framework also exposes features that almost all consumers will need, such +as BIF slave identification and BIF function enumeration within a given slave. + +The framework allows consumers to issue very specific bus commands which may +not be used within high level APIs. This provides maximum flexibility so +that consumers can make use of manufacturer defined bus commands which cannot be +handled in a generic fashion. + +Design Trade-offs: +The choice to not treat BIF like a traditional Linux bus was made because +there is nothing within BIF that naturally maps to a device on the bus for a +driver to manage. Slave devices would be a good candidate except that +consumers will not be managing slaves so much as functions exposed within +slaves. Bus matching could then instead be made at a BIF slave function +level. Unfortunately, the BIF specification allows for manufacturer specific +features to reside at any non-defined addresses. Additionally, consumers may +wish only to read and make policy decisions based on BIF non-volatile memory +(NVM) objects read out of memory. Thus, there are use-cases that require +consumers to utilize the bus without having a particular function to match to. + +Another trade-off was the choice to use custom interrupt handling functions +instead of the Linux interrupt framework. This choice was made because there is +no obvious way to handle IRQ chip registration given the dynamic nature of BIF +slaves (i.e. slaves may come and go at runtime if battery packs are swapped). + +Software layering: +BIF controller drivers register a set of callback functions with the BIF +framework which implement various BIF transaction primitives. These +callbacks ensure that tight timing constraints are met such as when receiving +a bus query response immediately after issuing a command. Such actions +cannot be carried out at the framework level as timing requirements are on +the order of 32 us when using the maximum data rate. + +The BIF framework provides easy access to standard BIF features such as +slave, functions, and interrupts. The framework also ensures mutual exclusion +between different BIF consumers. + +BIF consumer drivers make use of the API exposed by the framework in order +utilize functionality found on smart battery packs. One example of a +consumer driver is a temperature monitoring driver which reads the +temperature reported by the BIF temperature function on a BIF slave and +reports it to the Linux thermal framework. + +Power Management +================ + +The framework does not perform any special actions during system suspend and +resume. Controller drivers may choose to enter low power states during +suspend if they wish as long as it does not affect the logical state of the +bus. + +SMP/multi-core +============== + +Various linked lists are maintained inside of the framework which are +protected by mutexes. Mutex locks are also used during transactions at a bus +level in order to ensure mutual exclusion between consumers of the bus. + +Performance +=========== + +The BIF bus is inherently slow. Consumers should expect transactions to take +a long time to execute. Consumers are responsible for blocking suspend if +their transactions must be completed before the system enters suspend. + +Interface - BIF Consumer API +============================ + +BIF framework structs, enums, and functions used by BIF consumers are defined in +include/linux/bif/consumer.h + +Detailed descriptions of the BIF framework functions can be found in: +drivers/bif/bif-core.c + +Get/put handle for a BIF controller: +------------------------------------ + +struct bif_ctrl *bif_ctrl_get(struct device *consumer_dev); + +void bif_ctrl_put(struct bif_ctrl *ctrl); + +int bif_ctrl_count(void); + +struct bif_ctrl *bif_ctrl_get_by_id(unsigned int id); + +The function bif_ctrl_get() is intended to be the primary way to get a consumer +BIF controller handle. It relies upon the consumer device specifying a +"qcom,bif-ctrl" property in its device tree node which points to the phandle of +the BIF controller it wishes to use. + +A secondary mechanism is also provided for drivers without device tree support. +bif_ctrl_count() returns the number of BIF controllers currently registered. +bif_ctrl_get_by_id() returns a handle to the id'th controller enumerated in +registration order. + +Get/put handle for a BIF slave: +------------------------------- + +int bif_slave_match_count(struct bif_ctrl *ctrl, + const struct bif_match_criteria *match_criteria); + +struct bif_slave *bif_slave_match_get(struct bif_ctrl *ctrl, + unsigned int id, const struct bif_match_criteria *match_criteria); + +void bif_slave_put(struct bif_slave *slave); + +A consumer finds a slave attached to a given BIF controller by specifying a set +of matching criteria. The criteria can include such quantities as manufacturer +ID, product ID, function type or function version. It is possible that multiple +slaves will match the criteria. bif_slave_match_count() returns how many slaves +match the specified criteria. bif_slave_match_get() returns the id'th slave +which matches the criteria in an arbitrary, but fixed order (for a constant set +of slaves). Consumer drivers need to be able to handle the case of multiple +slaves matching the criteria. + +Additionally, if a battery pack is inserted or removed, then the output of +bif_slave_match_count() and bif_slave_match_get() could change. A consumer +driver can register to receive notification of battery pack insertion and +removal using the bif_ctrl_notifier_register() function listed below. + +Check if slave handle is still meaningful: +------------------------------------------ + +int bif_slave_is_present(struct bif_slave *slave); + +If a battery pack is removed, then the handles for its slaves will no longer be +meaningful. All transactions using a handle for a slave that isn't present will +fail. The function bif_slave_is_present() allows a consumer to determine if +a given slave is still physically present in the system. + +Get access to the controller handle present in a slave handle: +-------------------------------------------------------------- + +struct bif_ctrl *bif_get_ctrl_handle(struct bif_slave *slave); + +This function is useful if a consumer wishes to only store a slave handle but +also has need to call bus oriented BIF framework functions. + +Get version and register offset of a BIF function if it is present in a slave: +------------------------------------------------------------------------------ + +int bif_slave_find_function(struct bif_slave *slave, u8 function, u8 *version, + u16 *function_pointer); + +This function is used by consumers who wish to support given BIF functions +(e.g. temperature measurement, authentication, etc.) found inside of slaves. + +Receive notification upon battery insertion and removal: +-------------------------------------------------------- + +int bif_ctrl_notifier_register(struct bif_ctrl *ctrl, + struct notifier_block *nb); + +int bif_ctrl_notifier_unregister(struct bif_ctrl *ctrl, + struct notifier_block *nb); + +Read or write BIF slave registers: +---------------------------------- + +int bif_slave_read(struct bif_slave *slave, u16 addr, u8 *buf, int len); + +int bif_slave_write(struct bif_slave *slave, u16 addr, u8 *buf, int len); + + +BIF slave non-volatile memory manipulation: +------------------------------------------- + +int bif_slave_nvm_raw_read(struct bif_slave *slave, u16 offset, u8 *buf, + int len); + +int bif_slave_nvm_raw_write(struct bif_slave *slave, u16 offset, u8 *buf, + int len); + +Raw NVM writing may be needed in order to intialize the NVM BIF object list. +However, its use can be dangerous as it can overwrite existing objects in the +list and make the list unparsable. + +BIF object search in slave non-volatile memory: +----------------------------------------------- +int bif_object_match_count(struct bif_slave *slave, + const struct bif_obj_match_criteria *match_criteria); + +struct bif_object *bif_object_match_get(struct bif_slave *slave, + unsigned int id, const struct bif_obj_match_criteria *match_criteria); + +void bif_object_put(struct bif_object *object); + +bif_object_match_count() and bif_object_match_get() can be used together in +order to retrieve the set of BIF objects within a slave which match certain +criteria. bif_object_put() is used to free the memory allocated by +bif_object_match_get(). + +BIF object manipulation in slave non-volatile memory: +----------------------------------------------------- +int bif_object_write(struct bif_slave *slave, u8 type, u8 version, u16 + manufacturer_id, const u8 *data, int data_len); + +int bif_object_overwrite(struct bif_slave *slave, + struct bif_object *object, u8 type, u8 version, + u16 manufacturer_id, const u8 *data, int data_len); + +int bif_object_delete(struct bif_slave *slave, const struct bif_object *object); + +bif_object_write() can be used to write a new BIF data object into the NVM of +a given slave. The new object is added to the end of the NVM object list. +bif_object_overwrite() can be used to overwrite an existing BIF data object +in the NVM of a slave. The new object data must be the same size as the +existing object data. bif_object_delete() can be used to delete a object from +the NVM object list and shift all of the objects after it in order to fill the +deleted object's space. + +Get or set the BIF bus state or period: +--------------------------------------- + +int bif_ctrl_get_bus_state(struct bif_ctrl *ctrl); + +int bif_ctrl_set_bus_state(struct bif_ctrl *ctrl, enum bif_bus_state state); + +int bif_ctrl_get_bus_period(struct bif_ctrl *ctrl); + +int bif_ctrl_set_bus_period(struct bif_ctrl *ctrl, int period_ns); + +Bus states include: active for communication, active waiting for interrupt, +standby, and power down. The MIPI-BIF specification defines the allowed range +of bus periods as 2000 ns to 153000 ns. Individual controllers may further +restrict the range of allowed periods. When bif_ctrl_set_bus_period() is called +the first supported period that greater than or equal to the specified period +will be set. + +Measure battery pack resistance: +-------------------------------- + +int bif_ctrl_measure_rid(struct bif_ctrl *ctrl); + +This function returns an estimate of the battery pack resistance in ohms. If +no battery pack is connected, then the output of this function is undefined. + +Utilize BIF slave tasks and interrupts: +--------------------------------------- + +int bif_request_irq(struct bif_slave *slave, unsigned int task, + struct notifier_block *nb); + +int bif_free_irq(struct bif_slave *slave, unsigned int task, + struct notifier_block *nb); + +int bif_trigger_task(struct bif_slave *slave, unsigned int task); + +int bif_task_is_busy(struct bif_slave *slave, unsigned int task); + +int bif_enable_auto_task(struct bif_slave *slave, unsigned int task); + +int bif_disable_auto_task(struct bif_slave *slave, unsigned int task); + +A consumer can request a slave interrupt and specify a notifier to call when the +interrupt is triggered. Once the interrupt is requested the consumer will need +to call bif_trigger_task() in order to start the task associated with the +interrupt (both are identified by the same index). Polling for task completion +is also supported via the bif_task_is_busy() function. Auto task triggered can +be enabled and disabled for a given task using bif_enable_auto_task() and +bif_disable_auto_task() respectively. + +Raw BIF bus transactions: +------------------------- + +void bif_ctrl_bus_lock(struct bif_ctrl *ctrl); + +void bif_ctrl_bus_unlock(struct bif_ctrl *ctrl); + +int bif_ctrl_raw_transaction(struct bif_ctrl *ctrl, int transaction, u8 data); + +int bif_ctrl_raw_transaction_read(struct bif_ctrl *ctrl, int transaction, + u8 data, int *response); + +int bif_ctrl_raw_transaction_query(struct bif_ctrl *ctrl, int transaction, + u8 data, bool *query_response); + +int bif_slave_is_selected(struct bif_slave *slave); + +int bif_slave_select(struct bif_slave *slave); + +The function bif_ctrl_bus_lock() locks the BIF bus for exclusive use by the +consumer. No other transactions will be allowed on the bus including those +that would arise from battery insertion/removal or slave interrupt reception. +This lock is primarily intended to be used along with the raw transaction +functions. These functions allow a consumer to issue any BIF transaction +including manufacturer specific bus commands not handled by the BIF framework. + +While performing raw transactions, features normally performed transparently by +the core, such as device selection, are not available. The functions +bif_slave_select() and bif_slave_is_selected() can be used to fill in this gap +so that raw transactions are performed on the desired slave. + +Notify the BIF core that a battery has been inserted or removed: +---------------------------------------------------------------- + +int bif_ctrl_signal_battery_changed(struct bif_ctrl *ctrl); + +This function should only be called on systems where the BIF controller driver +is architecturally unable to detect battery insertion and removal on its own. + +Perform BIF object CRC using CRC-CCITT algorithm: +------------------------------------------------- + +u16 bif_crc_ccitt(const u8 *buffer, int len); + +Interface - BIF Controller API +============================== + +BIF framework structs and functions used by BIF controllers are defined in: +include/linux/bif/driver.h + +Ops found in struct bif_ctrl_ops: +--------------------------------- + +int (*bus_transaction) (struct bif_ctrl_dev *bdev, int transaction, u8 data); + +int (*bus_transaction_query) (struct bif_ctrl_dev *bdev, int transaction, + u8 data, bool *query_response); + +int (*bus_transaction_read) (struct bif_ctrl_dev *bdev, int transaction, + u8 data, int *response); + +int (*read_slave_registers) (struct bif_ctrl_dev *bdev, u16 addr, + u8 *data, int len); + +int (*write_slave_registers) (struct bif_ctrl_dev *bdev, u16 addr, + const u8 *data, int len); + +int (*get_bus_period) (struct bif_ctrl_dev *bdev); + +int (*set_bus_period) (struct bif_ctrl_dev *bdev, int period_ns); + +int (*get_battery_presence) (struct bif_ctrl_dev *bdev); + +int (*get_battery_rid) (struct bif_ctrl_dev *bdev); + +int (*get_bus_state) (struct bif_ctrl_dev *bdev); + +int (*set_bus_state) (struct bif_ctrl_dev *bdev, int state); + +A BIF controller driver registers a set of call back functions which instantiate +these ops. The BIF framework then calls these functions based on internal and +consumer needs. + +The ops bus_transaction(), bus_transaction_query(), and bus_transaction_read() +carry out the controller hardware specific actions to perform BIF transactions +on the BIF bus. These transactions result in no slave response, a pulse in +response, or a word in response respectively. The ops read_slave_registers() +and write_slave_registers() internally must perform all transactions necessary +to read and write to BIF slave registers. These ops exist so that burst reads +and writes can take place since these activities have very tight timing +constraints that the BIF core cannot handle. + +The ops get_bus_period() and set_bus_period() return the current bus clock base +period in nanoseconds and change the period to a new value respectively. The +ops get_bus_state() and set_bus_state() allow for monitoring and controlling the +bus state (i.e. active for communication, active waiting for interrupt, standby, +or power down). The op get_battery_presence() returns if any battery pack +(smart or low cost) is currently connected to the BCL. The op get_battery_rid() +returns a best estimate of the Rid battery pack pull down ID resistance in ohms +which can be used to determine if the battery pack is smart or low cost. + +Register/unregister a BIF controller: +------------------------------------- + +struct bif_ctrl_dev *bif_ctrl_register(struct bif_ctrl_desc *bif_desc, + struct device *dev, void *driver_data, struct device_node *of_node); + +void bif_ctrl_unregister(struct bif_ctrl_dev *bdev); + +Notify the BIF framework that a battery has been inserted or removed: +--------------------------------------------------------------------- + +int bif_ctrl_notify_battery_changed(struct bif_ctrl_dev *bdev); + +The BIF core will then call the get_battery_presence() op internally to +determine if the event is an insertion or removal. + +Notify the BIF framework that a slave interrupt has been received: +------------------------------------------------------------------ + +int bif_ctrl_notify_slave_irq(struct bif_ctrl_dev *bdev); + +Upon receiving this call, the BIF core interrogates each slave to determine +which slaves have pending interrupts. It then iterates through all interrupts +on those slaves clearing all pending interrupts and notifying any consumers +waiting for the interrupts. + +Get BIF controller private data: +-------------------------------- + +void *bdev_get_drvdata(struct bif_ctrl_dev *bdev); + +Config options +============== + +CONFIG_BIF - Enables BIF framework support. + +User space utilities +==================== + +No user space interface is provided in the BIF framework. Therefore, user +space will not be able to directly use it. + +To do +===== + +It is conceivable that the BIF framework should take some action during +system suspend and resume. However, it is not clear exactly what should be +done given that the BCL would still need to be active in order to detect +battery removal while suspended. + +sysfs nodes could be added which describe slaves as well as functions and +objects within the slaves. However these nodes would be read-only and would +really only be useful for descriptive as opposed to control purposes. + +The exact time at which slave searching, function enumeration, and object +loading takes place could be optimized in order to improve performance to +some degree. It could also be made configurable at a controller level if +needed. diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX index e840b47613f7..bc5148757edb 100644 --- a/Documentation/block/00-INDEX +++ b/Documentation/block/00-INDEX @@ -26,3 +26,9 @@ switching-sched.txt - Switching I/O schedulers at runtime writeback_cache_control.txt - Control of volatile write back caches +mmc-max-speed.txt + - eMMC layer speed simulation, related to /sys/block/mmcblk*/ + attributes: + max_read_speed + max_write_speed + cache_size diff --git a/Documentation/block/mmc-max-speed.txt b/Documentation/block/mmc-max-speed.txt new file mode 100644 index 000000000000..3f052b9fb999 --- /dev/null +++ b/Documentation/block/mmc-max-speed.txt @@ -0,0 +1,38 @@ +eMMC Block layer simulation speed controls in /sys/block/mmcblk*/ +=============================================== + +Turned on with CONFIG_MMC_SIMULATE_MAX_SPEED which enables MMC device speed +limiting. Used to test and simulate the behavior of the system when +confronted with a slow MMC. + +Enables max_read_speed, max_write_speed and cache_size attributes and module +default parameters to control the write or read maximum KB/second speed +behaviors. + +NB: There is room for improving the algorithm for aspects tied directly to +eMMC specific behavior. For instance, wear leveling and stalls from an +exhausted erase pool. We would expect that if there was a need to provide +similar speed simulation controls to other types of block devices, aspects of +their behavior are modelled separately (e.g. head seek times, heat assist, +shingling and rotational latency). + +/sys/block/mmcblk0/max_read_speed: + +Number of KB/second reads allowed to the block device. Used to test and +simulate the behavior of the system when confronted with a slow reading MMC. +Set to 0 or "off" to place no speed limit. + +/sys/block/mmcblk0/max_write_speed: + +Number of KB/second writes allowed to the block device. Used to test and +simulate the behavior of the system when confronted with a slow writing MMC. +Set to 0 or "off" to place no speed limit. + +/sys/block/mmcblk0/cache_size: + +Number of MB of high speed memory or high speed SLC cache expected on the +eMMC device being simulated. Used to help simulate the write-back behavior +more accurately. The assumption is the cache has no delay, but draws down +in the background to the MLC/TLC primary store at the max_write_speed rate. +Any write speed delays will show up when the cache is full, or when an I/O +request to flush is issued. diff --git a/Documentation/block/test-iosched.txt b/Documentation/block/test-iosched.txt new file mode 100644 index 000000000000..75d813418c00 --- /dev/null +++ b/Documentation/block/test-iosched.txt @@ -0,0 +1,39 @@ +Test IO scheduler +================== + +The test scheduler allows testing a block device by dispatching +specific requests according to the test case and declare PASS/FAIL +according to the requests completion error code. + +The test IO scheduler implements the no-op scheduler operations, and uses +them in order to dispatch the non-test requests when no test is running. +This will allow to keep a normal FS operation in parallel to the test +capability. +The test IO scheduler keeps two different queues, one for real-world requests +(inserted by the FS) and the other for the test requests. +The test IO scheduler chooses the queue for dispatch requests according to the +test state (IDLE/RUNNING). + +the test IO scheduler is compiled by default as a dynamic module and enabled +only if CONFIG_DEBUG_FS is defined. + +Each block device test utility that would like to use the test-iosched test +services, should register as a blk_dev_test_type and supply an init and exit +callbacks. Those callback are called upon selection (or removal) of the +test-iosched as the active scheduler. From that point the block device test +can start a test and supply its own callbacks for preparing, running, result +checking and cleanup of the test. + +Each test is exposed via debugfs and can be triggered by writing to +the debugfs file. In order to add a new test one should expose a new debugfs +file for the new test. + +Selecting IO schedulers +----------------------- +Refer to Documentation/block/switching-sched.txt for information on +selecting an io scheduler on a per-device basis. + + +May 10 2012, maya Erez <merez@codeaurora.org> + + diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroup-legacy/00-INDEX index 3f5a40f57d4a..3f5a40f57d4a 100644 --- a/Documentation/cgroups/00-INDEX +++ b/Documentation/cgroup-legacy/00-INDEX diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroup-legacy/blkio-controller.txt index 52fa9f353342..4ecc954a3063 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroup-legacy/blkio-controller.txt @@ -374,82 +374,3 @@ One can experience an overall throughput drop if you have created multiple groups and put applications in that group which are not driving enough IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle on individual groups and throughput should improve. - -Writeback -========= - -Page cache is dirtied through buffered writes and shared mmaps and -written asynchronously to the backing filesystem by the writeback -mechanism. Writeback sits between the memory and IO domains and -regulates the proportion of dirty memory by balancing dirtying and -write IOs. - -On traditional cgroup hierarchies, relationships between different -controllers cannot be established making it impossible for writeback -to operate accounting for cgroup resource restrictions and all -writeback IOs are attributed to the root cgroup. - -If both the blkio and memory controllers are used on the v2 hierarchy -and the filesystem supports cgroup writeback, writeback operations -correctly follow the resource restrictions imposed by both memory and -blkio controllers. - -Writeback examines both system-wide and per-cgroup dirty memory status -and enforces the more restrictive of the two. Also, writeback control -parameters which are absolute values - vm.dirty_bytes and -vm.dirty_background_bytes - are distributed across cgroups according -to their current writeback bandwidth. - -There's a peculiarity stemming from the discrepancy in ownership -granularity between memory controller and writeback. While memory -controller tracks ownership per page, writeback operates on inode -basis. cgroup writeback bridges the gap by tracking ownership by -inode but migrating ownership if too many foreign pages, pages which -don't match the current inode ownership, have been encountered while -writing back the inode. - -This is a conscious design choice as writeback operations are -inherently tied to inodes making strictly following page ownership -complicated and inefficient. The only use case which suffers from -this compromise is multiple cgroups concurrently dirtying disjoint -regions of the same inode, which is an unlikely use case and decided -to be unsupported. Note that as memory controller assigns page -ownership on the first use and doesn't update it until the page is -released, even if cgroup writeback strictly follows page ownership, -multiple cgroups dirtying overlapping areas wouldn't work as expected. -In general, write-sharing an inode across multiple cgroups is not well -supported. - -Filesystem support for cgroup writeback ---------------------------------------- - -A filesystem can make writeback IOs cgroup-aware by updating -address_space_operations->writepage[s]() to annotate bio's using the -following two functions. - -* wbc_init_bio(@wbc, @bio) - - Should be called for each bio carrying writeback data and associates - the bio with the inode's owner cgroup. Can be called anytime - between bio allocation and submission. - -* wbc_account_io(@wbc, @page, @bytes) - - Should be called for each data segment being written out. While - this function doesn't care exactly when it's called during the - writeback session, it's the easiest and most natural to call it as - data segments are added to a bio. - -With writeback bio's annotated, cgroup support can be enabled per -super_block by setting MS_CGROUPWB in ->s_flags. This allows for -selective disabling of cgroup writeback support which is helpful when -certain filesystem features, e.g. journaled data mode, are -incompatible. - -wbc_init_bio() binds the specified bio to its cgroup. Depending on -the configuration, the bio may be executed at a lower priority and if -the writeback session is holding shared resources, e.g. a journal -entry, may lead to priority inversion. There is no one easy solution -for the problem. Filesystems can try to work around specific problem -cases by skipping wbc_init_bio() or using bio_associate_blkcg() -directly. diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroup-legacy/cgroups.txt index c6256ae9885b..c6256ae9885b 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroup-legacy/cgroups.txt diff --git a/Documentation/cgroups/cpuacct.txt b/Documentation/cgroup-legacy/cpuacct.txt index 9d73cc0cadb9..9d73cc0cadb9 100644 --- a/Documentation/cgroups/cpuacct.txt +++ b/Documentation/cgroup-legacy/cpuacct.txt diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroup-legacy/cpusets.txt index fdf7dff3f607..fdf7dff3f607 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroup-legacy/cpusets.txt diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroup-legacy/devices.txt index 3c1095ca02ea..3c1095ca02ea 100644 --- a/Documentation/cgroups/devices.txt +++ b/Documentation/cgroup-legacy/devices.txt diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroup-legacy/freezer-subsystem.txt index e831cb2b8394..e831cb2b8394 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroup-legacy/freezer-subsystem.txt diff --git a/Documentation/cgroups/hugetlb.txt b/Documentation/cgroup-legacy/hugetlb.txt index 106245c3aecc..106245c3aecc 100644 --- a/Documentation/cgroups/hugetlb.txt +++ b/Documentation/cgroup-legacy/hugetlb.txt diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroup-legacy/memcg_test.txt index 8870b0212150..8870b0212150 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroup-legacy/memcg_test.txt diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroup-legacy/memory.txt index ff71e16cc752..ff71e16cc752 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroup-legacy/memory.txt diff --git a/Documentation/cgroups/net_cls.txt b/Documentation/cgroup-legacy/net_cls.txt index ec182346dea2..ec182346dea2 100644 --- a/Documentation/cgroups/net_cls.txt +++ b/Documentation/cgroup-legacy/net_cls.txt diff --git a/Documentation/cgroups/net_prio.txt b/Documentation/cgroup-legacy/net_prio.txt index a82cbd28ea8a..a82cbd28ea8a 100644 --- a/Documentation/cgroups/net_prio.txt +++ b/Documentation/cgroup-legacy/net_prio.txt diff --git a/Documentation/cgroups/pids.txt b/Documentation/cgroup-legacy/pids.txt index 1a078b5d281a..1a078b5d281a 100644 --- a/Documentation/cgroups/pids.txt +++ b/Documentation/cgroup-legacy/pids.txt diff --git a/Documentation/cgroup.txt b/Documentation/cgroup.txt new file mode 100644 index 000000000000..31d1f7bf12a1 --- /dev/null +++ b/Documentation/cgroup.txt @@ -0,0 +1,1293 @@ + +Control Group v2 + +October, 2015 Tejun Heo <tj@kernel.org> + +This is the authoritative documentation on the design, interface and +conventions of cgroup v2. It describes all userland-visible aspects +of cgroup including core and specific controller behaviors. All +future changes must be reflected in this document. Documentation for +v1 is available under Documentation/cgroup-legacy/. + +CONTENTS + +1. Introduction + 1-1. Terminology + 1-2. What is cgroup? +2. Basic Operations + 2-1. Mounting + 2-2. Organizing Processes + 2-3. [Un]populated Notification + 2-4. Controlling Controllers + 2-4-1. Enabling and Disabling + 2-4-2. Top-down Constraint + 2-4-3. No Internal Process Constraint + 2-5. Delegation + 2-5-1. Model of Delegation + 2-5-2. Delegation Containment + 2-6. Guidelines + 2-6-1. Organize Once and Control + 2-6-2. Avoid Name Collisions +3. Resource Distribution Models + 3-1. Weights + 3-2. Limits + 3-3. Protections + 3-4. Allocations +4. Interface Files + 4-1. Format + 4-2. Conventions + 4-3. Core Interface Files +5. Controllers + 5-1. CPU + 5-1-1. CPU Interface Files + 5-2. Memory + 5-2-1. Memory Interface Files + 5-2-2. Usage Guidelines + 5-2-3. Memory Ownership + 5-3. IO + 5-3-1. IO Interface Files + 5-3-2. Writeback +P. Information on Kernel Programming + P-1. Filesystem Support for Writeback +D. Deprecated v1 Core Features +R. Issues with v1 and Rationales for v2 + R-1. Multiple Hierarchies + R-2. Thread Granularity + R-3. Competition Between Inner Nodes and Threads + R-4. Other Interface Issues + R-5. Controller Issues and Remedies + R-5-1. Memory + + +1. Introduction + +1-1. Terminology + +"cgroup" stands for "control group" and is never capitalized. The +singular form is used to designate the whole feature and also as a +qualifier as in "cgroup controllers". When explicitly referring to +multiple individual control groups, the plural form "cgroups" is used. + + +1-2. What is cgroup? + +cgroup is a mechanism to organize processes hierarchically and +distribute system resources along the hierarchy in a controlled and +configurable manner. + +cgroup is largely composed of two parts - the core and controllers. +cgroup core is primarily responsible for hierarchically organizing +processes. A cgroup controller is usually responsible for +distributing a specific type of system resource along the hierarchy +although there are utility controllers which serve purposes other than +resource distribution. + +cgroups form a tree structure and every process in the system belongs +to one and only one cgroup. All threads of a process belong to the +same cgroup. On creation, all processes are put in the cgroup that +the parent process belongs to at the time. A process can be migrated +to another cgroup. Migration of a process doesn't affect already +existing descendant processes. + +Following certain structural constraints, controllers may be enabled or +disabled selectively on a cgroup. All controller behaviors are +hierarchical - if a controller is enabled on a cgroup, it affects all +processes which belong to the cgroups consisting the inclusive +sub-hierarchy of the cgroup. When a controller is enabled on a nested +cgroup, it always restricts the resource distribution further. The +restrictions set closer to the root in the hierarchy can not be +overridden from further away. + + +2. Basic Operations + +2-1. Mounting + +Unlike v1, cgroup v2 has only single hierarchy. The cgroup v2 +hierarchy can be mounted with the following mount command. + + # mount -t cgroup2 none $MOUNT_POINT + +cgroup2 filesystem has the magic number 0x63677270 ("cgrp"). All +controllers which support v2 and are not bound to a v1 hierarchy are +automatically bound to the v2 hierarchy and show up at the root. +Controllers which are not in active use in the v2 hierarchy can be +bound to other hierarchies. This allows mixing v2 hierarchy with the +legacy v1 multiple hierarchies in a fully backward compatible way. + +A controller can be moved across hierarchies only after the controller +is no longer referenced in its current hierarchy. Because per-cgroup +controller states are destroyed asynchronously and controllers may +have lingering references, a controller may not show up immediately on +the v2 hierarchy after the final umount of the previous hierarchy. +Similarly, a controller should be fully disabled to be moved out of +the unified hierarchy and it may take some time for the disabled +controller to become available for other hierarchies; furthermore, due +to inter-controller dependencies, other controllers may need to be +disabled too. + +While useful for development and manual configurations, moving +controllers dynamically between the v2 and other hierarchies is +strongly discouraged for production use. It is recommended to decide +the hierarchies and controller associations before starting using the +controllers after system boot. + + +2-2. Organizing Processes + +Initially, only the root cgroup exists to which all processes belong. +A child cgroup can be created by creating a sub-directory. + + # mkdir $CGROUP_NAME + +A given cgroup may have multiple child cgroups forming a tree +structure. Each cgroup has a read-writable interface file +"cgroup.procs". When read, it lists the PIDs of all processes which +belong to the cgroup one-per-line. The PIDs are not ordered and the +same PID may show up more than once if the process got moved to +another cgroup and then back or the PID got recycled while reading. + +A process can be migrated into a cgroup by writing its PID to the +target cgroup's "cgroup.procs" file. Only one process can be migrated +on a single write(2) call. If a process is composed of multiple +threads, writing the PID of any thread migrates all threads of the +process. + +When a process forks a child process, the new process is born into the +cgroup that the forking process belongs to at the time of the +operation. After exit, a process stays associated with the cgroup +that it belonged to at the time of exit until it's reaped; however, a +zombie process does not appear in "cgroup.procs" and thus can't be +moved to another cgroup. + +A cgroup which doesn't have any children or live processes can be +destroyed by removing the directory. Note that a cgroup which doesn't +have any children and is associated only with zombie processes is +considered empty and can be removed. + + # rmdir $CGROUP_NAME + +"/proc/$PID/cgroup" lists a process's cgroup membership. If legacy +cgroup is in use in the system, this file may contain multiple lines, +one for each hierarchy. The entry for cgroup v2 is always in the +format "0::$PATH". + + # cat /proc/842/cgroup + ... + 0::/test-cgroup/test-cgroup-nested + +If the process becomes a zombie and the cgroup it was associated with +is removed subsequently, " (deleted)" is appended to the path. + + # cat /proc/842/cgroup + ... + 0::/test-cgroup/test-cgroup-nested (deleted) + + +2-3. [Un]populated Notification + +Each non-root cgroup has a "cgroup.events" file which contains +"populated" field indicating whether the cgroup's sub-hierarchy has +live processes in it. Its value is 0 if there is no live process in +the cgroup and its descendants; otherwise, 1. poll and [id]notify +events are triggered when the value changes. This can be used, for +example, to start a clean-up operation after all processes of a given +sub-hierarchy have exited. The populated state updates and +notifications are recursive. Consider the following sub-hierarchy +where the numbers in the parentheses represent the numbers of processes +in each cgroup. + + A(4) - B(0) - C(1) + \ D(0) + +A, B and C's "populated" fields would be 1 while D's 0. After the one +process in C exits, B and C's "populated" fields would flip to "0" and +file modified events will be generated on the "cgroup.events" files of +both cgroups. + + +2-4. Controlling Controllers + +2-4-1. Enabling and Disabling + +Each cgroup has a "cgroup.controllers" file which lists all +controllers available for the cgroup to enable. + + # cat cgroup.controllers + cpu io memory + +No controller is enabled by default. Controllers can be enabled and +disabled by writing to the "cgroup.subtree_control" file. + + # echo "+cpu +memory -io" > cgroup.subtree_control + +Only controllers which are listed in "cgroup.controllers" can be +enabled. When multiple operations are specified as above, either they +all succeed or fail. If multiple operations on the same controller +are specified, the last one is effective. + +Enabling a controller in a cgroup indicates that the distribution of +the target resource across its immediate children will be controlled. +Consider the following sub-hierarchy. The enabled controllers are +listed in parentheses. + + A(cpu,memory) - B(memory) - C() + \ D() + +As A has "cpu" and "memory" enabled, A will control the distribution +of CPU cycles and memory to its children, in this case, B. As B has +"memory" enabled but not "CPU", C and D will compete freely on CPU +cycles but their division of memory available to B will be controlled. + +As a controller regulates the distribution of the target resource to +the cgroup's children, enabling it creates the controller's interface +files in the child cgroups. In the above example, enabling "cpu" on B +would create the "cpu." prefixed controller interface files in C and +D. Likewise, disabling "memory" from B would remove the "memory." +prefixed controller interface files from C and D. This means that the +controller interface files - anything which doesn't start with +"cgroup." are owned by the parent rather than the cgroup itself. + + +2-4-2. Top-down Constraint + +Resources are distributed top-down and a cgroup can further distribute +a resource only if the resource has been distributed to it from the +parent. This means that all non-root "cgroup.subtree_control" files +can only contain controllers which are enabled in the parent's +"cgroup.subtree_control" file. A controller can be enabled only if +the parent has the controller enabled and a controller can't be +disabled if one or more children have it enabled. + + +2-4-3. No Internal Process Constraint + +Non-root cgroups can only distribute resources to their children when +they don't have any processes of their own. In other words, only +cgroups which don't contain any processes can have controllers enabled +in their "cgroup.subtree_control" files. + +This guarantees that, when a controller is looking at the part of the +hierarchy which has it enabled, processes are always only on the +leaves. This rules out situations where child cgroups compete against +internal processes of the parent. + +The root cgroup is exempt from this restriction. Root contains +processes and anonymous resource consumption which can't be associated +with any other cgroups and requires special treatment from most +controllers. How resource consumption in the root cgroup is governed +is up to each controller. + +Note that the restriction doesn't get in the way if there is no +enabled controller in the cgroup's "cgroup.subtree_control". This is +important as otherwise it wouldn't be possible to create children of a +populated cgroup. To control resource distribution of a cgroup, the +cgroup must create children and transfer all its processes to the +children before enabling controllers in its "cgroup.subtree_control" +file. + + +2-5. Delegation + +2-5-1. Model of Delegation + +A cgroup can be delegated to a less privileged user by granting write +access of the directory and its "cgroup.procs" file to the user. Note +that resource control interface files in a given directory control the +distribution of the parent's resources and thus must not be delegated +along with the directory. + +Once delegated, the user can build sub-hierarchy under the directory, +organize processes as it sees fit and further distribute the resources +it received from the parent. The limits and other settings of all +resource controllers are hierarchical and regardless of what happens +in the delegated sub-hierarchy, nothing can escape the resource +restrictions imposed by the parent. + +Currently, cgroup doesn't impose any restrictions on the number of +cgroups in or nesting depth of a delegated sub-hierarchy; however, +this may be limited explicitly in the future. + + +2-5-2. Delegation Containment + +A delegated sub-hierarchy is contained in the sense that processes +can't be moved into or out of the sub-hierarchy by the delegatee. For +a process with a non-root euid to migrate a target process into a +cgroup by writing its PID to the "cgroup.procs" file, the following +conditions must be met. + +- The writer's euid must match either uid or suid of the target process. + +- The writer must have write access to the "cgroup.procs" file. + +- The writer must have write access to the "cgroup.procs" file of the + common ancestor of the source and destination cgroups. + +The above three constraints ensure that while a delegatee may migrate +processes around freely in the delegated sub-hierarchy it can't pull +in from or push out to outside the sub-hierarchy. + +For an example, let's assume cgroups C0 and C1 have been delegated to +user U0 who created C00, C01 under C0 and C10 under C1 as follows and +all processes under C0 and C1 belong to U0. + + ~~~~~~~~~~~~~ - C0 - C00 + ~ cgroup ~ \ C01 + ~ hierarchy ~ + ~~~~~~~~~~~~~ - C1 - C10 + +Let's also say U0 wants to write the PID of a process which is +currently in C10 into "C00/cgroup.procs". U0 has write access to the +file and uid match on the process; however, the common ancestor of the +source cgroup C10 and the destination cgroup C00 is above the points +of delegation and U0 would not have write access to its "cgroup.procs" +files and thus the write will be denied with -EACCES. + + +2-6. Guidelines + +2-6-1. Organize Once and Control + +Migrating a process across cgroups is a relatively expensive operation +and stateful resources such as memory are not moved together with the +process. This is an explicit design decision as there often exist +inherent trade-offs between migration and various hot paths in terms +of synchronization cost. + +As such, migrating processes across cgroups frequently as a means to +apply different resource restrictions is discouraged. A workload +should be assigned to a cgroup according to the system's logical and +resource structure once on start-up. Dynamic adjustments to resource +distribution can be made by changing controller configuration through +the interface files. + + +2-6-2. Avoid Name Collisions + +Interface files for a cgroup and its children cgroups occupy the same +directory and it is possible to create children cgroups which collide +with interface files. + +All cgroup core interface files are prefixed with "cgroup." and each +controller's interface files are prefixed with the controller name and +a dot. A controller's name is composed of lower case alphabets and +'_'s but never begins with an '_' so it can be used as the prefix +character for collision avoidance. Also, interface file names won't +start or end with terms which are often used in categorizing workloads +such as job, service, slice, unit or workload. + +cgroup doesn't do anything to prevent name collisions and it's the +user's responsibility to avoid them. + + +3. Resource Distribution Models + +cgroup controllers implement several resource distribution schemes +depending on the resource type and expected use cases. This section +describes major schemes in use along with their expected behaviors. + + +3-1. Weights + +A parent's resource is distributed by adding up the weights of all +active children and giving each the fraction matching the ratio of its +weight against the sum. As only children which can make use of the +resource at the moment participate in the distribution, this is +work-conserving. Due to the dynamic nature, this model is usually +used for stateless resources. + +All weights are in the range [1, 10000] with the default at 100. This +allows symmetric multiplicative biases in both directions at fine +enough granularity while staying in the intuitive range. + +As long as the weight is in range, all configuration combinations are +valid and there is no reason to reject configuration changes or +process migrations. + +"cpu.weight" proportionally distributes CPU cycles to active children +and is an example of this type. + + +3-2. Limits + +A child can only consume upto the configured amount of the resource. +Limits can be over-committed - the sum of the limits of children can +exceed the amount of resource available to the parent. + +Limits are in the range [0, max] and defaults to "max", which is noop. + +As limits can be over-committed, all configuration combinations are +valid and there is no reason to reject configuration changes or +process migrations. + +"io.max" limits the maximum BPS and/or IOPS that a cgroup can consume +on an IO device and is an example of this type. + + +3-3. Protections + +A cgroup is protected to be allocated upto the configured amount of +the resource if the usages of all its ancestors are under their +protected levels. Protections can be hard guarantees or best effort +soft boundaries. Protections can also be over-committed in which case +only upto the amount available to the parent is protected among +children. + +Protections are in the range [0, max] and defaults to 0, which is +noop. + +As protections can be over-committed, all configuration combinations +are valid and there is no reason to reject configuration changes or +process migrations. + +"memory.low" implements best-effort memory protection and is an +example of this type. + + +3-4. Allocations + +A cgroup is exclusively allocated a certain amount of a finite +resource. Allocations can't be over-committed - the sum of the +allocations of children can not exceed the amount of resource +available to the parent. + +Allocations are in the range [0, max] and defaults to 0, which is no +resource. + +As allocations can't be over-committed, some configuration +combinations are invalid and should be rejected. Also, if the +resource is mandatory for execution of processes, process migrations +may be rejected. + +"cpu.rt.max" hard-allocates realtime slices and is an example of this +type. + + +4. Interface Files + +4-1. Format + +All interface files should be in one of the following formats whenever +possible. + + New-line separated values + (when only one value can be written at once) + + VAL0\n + VAL1\n + ... + + Space separated values + (when read-only or multiple values can be written at once) + + VAL0 VAL1 ...\n + + Flat keyed + + KEY0 VAL0\n + KEY1 VAL1\n + ... + + Nested keyed + + KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01... + KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11... + ... + +For a writable file, the format for writing should generally match +reading; however, controllers may allow omitting later fields or +implement restricted shortcuts for most common use cases. + +For both flat and nested keyed files, only the values for a single key +can be written at a time. For nested keyed files, the sub key pairs +may be specified in any order and not all pairs have to be specified. + + +4-2. Conventions + +- Settings for a single feature should be contained in a single file. + +- The root cgroup should be exempt from resource control and thus + shouldn't have resource control interface files. Also, + informational files on the root cgroup which end up showing global + information available elsewhere shouldn't exist. + +- If a controller implements weight based resource distribution, its + interface file should be named "weight" and have the range [1, + 10000] with 100 as the default. The values are chosen to allow + enough and symmetric bias in both directions while keeping it + intuitive (the default is 100%). + +- If a controller implements an absolute resource guarantee and/or + limit, the interface files should be named "min" and "max" + respectively. If a controller implements best effort resource + guarantee and/or limit, the interface files should be named "low" + and "high" respectively. + + In the above four control files, the special token "max" should be + used to represent upward infinity for both reading and writing. + +- If a setting has a configurable default value and keyed specific + overrides, the default entry should be keyed with "default" and + appear as the first entry in the file. + + The default value can be updated by writing either "default $VAL" or + "$VAL". + + When writing to update a specific override, "default" can be used as + the value to indicate removal of the override. Override entries + with "default" as the value must not appear when read. + + For example, a setting which is keyed by major:minor device numbers + with integer values may look like the following. + + # cat cgroup-example-interface-file + default 150 + 8:0 300 + + The default value can be updated by + + # echo 125 > cgroup-example-interface-file + + or + + # echo "default 125" > cgroup-example-interface-file + + An override can be set by + + # echo "8:16 170" > cgroup-example-interface-file + + and cleared by + + # echo "8:0 default" > cgroup-example-interface-file + # cat cgroup-example-interface-file + default 125 + 8:16 170 + +- For events which are not very high frequency, an interface file + "events" should be created which lists event key value pairs. + Whenever a notifiable event happens, file modified event should be + generated on the file. + + +4-3. Core Interface Files + +All cgroup core files are prefixed with "cgroup." + + cgroup.procs + + A read-write new-line separated values file which exists on + all cgroups. + + When read, it lists the PIDs of all processes which belong to + the cgroup one-per-line. The PIDs are not ordered and the + same PID may show up more than once if the process got moved + to another cgroup and then back or the PID got recycled while + reading. + + A PID can be written to migrate the process associated with + the PID to the cgroup. The writer should match all of the + following conditions. + + - Its euid is either root or must match either uid or suid of + the target process. + + - It must have write access to the "cgroup.procs" file. + + - It must have write access to the "cgroup.procs" file of the + common ancestor of the source and destination cgroups. + + When delegating a sub-hierarchy, write access to this file + should be granted along with the containing directory. + + cgroup.controllers + + A read-only space separated values file which exists on all + cgroups. + + It shows space separated list of all controllers available to + the cgroup. The controllers are not ordered. + + cgroup.subtree_control + + A read-write space separated values file which exists on all + cgroups. Starts out empty. + + When read, it shows space separated list of the controllers + which are enabled to control resource distribution from the + cgroup to its children. + + Space separated list of controllers prefixed with '+' or '-' + can be written to enable or disable controllers. A controller + name prefixed with '+' enables the controller and '-' + disables. If a controller appears more than once on the list, + the last one is effective. When multiple enable and disable + operations are specified, either all succeed or all fail. + + cgroup.events + + A read-only flat-keyed file which exists on non-root cgroups. + The following entries are defined. Unless specified + otherwise, a value change in this file generates a file + modified event. + + populated + + 1 if the cgroup or its descendants contains any live + processes; otherwise, 0. + + +5. Controllers + +5-1. CPU + +[NOTE: The interface for the cpu controller hasn't been merged yet] + +The "cpu" controllers regulates distribution of CPU cycles. This +controller implements weight and absolute bandwidth limit models for +normal scheduling policy and absolute bandwidth allocation model for +realtime scheduling policy. + + +5-1-1. CPU Interface Files + +All time durations are in microseconds. + + cpu.stat + + A read-only flat-keyed file which exists on non-root cgroups. + + It reports the following six stats. + + usage_usec + user_usec + system_usec + nr_periods + nr_throttled + throttled_usec + + cpu.weight + + A read-write single value file which exists on non-root + cgroups. The default is "100". + + The weight in the range [1, 10000]. + + cpu.max + + A read-write two value file which exists on non-root cgroups. + The default is "max 100000". + + The maximum bandwidth limit. It's in the following format. + + $MAX $PERIOD + + which indicates that the group may consume upto $MAX in each + $PERIOD duration. "max" for $MAX indicates no limit. If only + one number is written, $MAX is updated. + + cpu.rt.max + + [NOTE: The semantics of this file is still under discussion and the + interface hasn't been merged yet] + + A read-write two value file which exists on all cgroups. + The default is "0 100000". + + The maximum realtime runtime allocation. Over-committing + configurations are disallowed and process migrations are + rejected if not enough bandwidth is available. It's in the + following format. + + $MAX $PERIOD + + which indicates that the group may consume upto $MAX in each + $PERIOD duration. If only one number is written, $MAX is + updated. + + +5-2. Memory + +The "memory" controller regulates distribution of memory. Memory is +stateful and implements both limit and protection models. Due to the +intertwining between memory usage and reclaim pressure and the +stateful nature of memory, the distribution model is relatively +complex. + +While not completely water-tight, all major memory usages by a given +cgroup are tracked so that the total memory consumption can be +accounted and controlled to a reasonable extent. Currently, the +following types of memory usages are tracked. + +- Userland memory - page cache and anonymous memory. + +- Kernel data structures such as dentries and inodes. + +- TCP socket buffers. + +The above list may expand in the future for better coverage. + + +5-2-1. Memory Interface Files + +All memory amounts are in bytes. If a value which is not aligned to +PAGE_SIZE is written, the value may be rounded up to the closest +PAGE_SIZE multiple when read back. + + memory.current + + A read-only single value file which exists on non-root + cgroups. + + The total amount of memory currently being used by the cgroup + and its descendants. + + memory.low + + A read-write single value file which exists on non-root + cgroups. The default is "0". + + Best-effort memory protection. If the memory usages of a + cgroup and all its ancestors are below their low boundaries, + the cgroup's memory won't be reclaimed unless memory can be + reclaimed from unprotected cgroups. + + Putting more memory than generally available under this + protection is discouraged. + + memory.high + + A read-write single value file which exists on non-root + cgroups. The default is "max". + + Memory usage throttle limit. This is the main mechanism to + control memory usage of a cgroup. If a cgroup's usage goes + over the high boundary, the processes of the cgroup are + throttled and put under heavy reclaim pressure. + + Going over the high limit never invokes the OOM killer and + under extreme conditions the limit may be breached. + + memory.max + + A read-write single value file which exists on non-root + cgroups. The default is "max". + + Memory usage hard limit. This is the final protection + mechanism. If a cgroup's memory usage reaches this limit and + can't be reduced, the OOM killer is invoked in the cgroup. + Under certain circumstances, the usage may go over the limit + temporarily. + + This is the ultimate protection mechanism. As long as the + high limit is used and monitored properly, this limit's + utility is limited to providing the final safety net. + + memory.events + + A read-only flat-keyed file which exists on non-root cgroups. + The following entries are defined. Unless specified + otherwise, a value change in this file generates a file + modified event. + + low + + The number of times the cgroup is reclaimed due to + high memory pressure even though its usage is under + the low boundary. This usually indicates that the low + boundary is over-committed. + + high + + The number of times processes of the cgroup are + throttled and routed to perform direct memory reclaim + because the high memory boundary was exceeded. For a + cgroup whose memory usage is capped by the high limit + rather than global memory pressure, this event's + occurrences are expected. + + max + + The number of times the cgroup's memory usage was + about to go over the max boundary. If direct reclaim + fails to bring it down, the OOM killer is invoked. + + oom + + The number of times the OOM killer has been invoked in + the cgroup. This may not exactly match the number of + processes killed but should generally be close. + + +5-2-2. General Usage + +"memory.high" is the main mechanism to control memory usage. +Over-committing on high limit (sum of high limits > available memory) +and letting global memory pressure to distribute memory according to +usage is a viable strategy. + +Because breach of the high limit doesn't trigger the OOM killer but +throttles the offending cgroup, a management agent has ample +opportunities to monitor and take appropriate actions such as granting +more memory or terminating the workload. + +Determining whether a cgroup has enough memory is not trivial as +memory usage doesn't indicate whether the workload can benefit from +more memory. For example, a workload which writes data received from +network to a file can use all available memory but can also operate as +performant with a small amount of memory. A measure of memory +pressure - how much the workload is being impacted due to lack of +memory - is necessary to determine whether a workload needs more +memory; unfortunately, memory pressure monitoring mechanism isn't +implemented yet. + + +5-2-3. Memory Ownership + +A memory area is charged to the cgroup which instantiated it and stays +charged to the cgroup until the area is released. Migrating a process +to a different cgroup doesn't move the memory usages that it +instantiated while in the previous cgroup to the new cgroup. + +A memory area may be used by processes belonging to different cgroups. +To which cgroup the area will be charged is in-deterministic; however, +over time, the memory area is likely to end up in a cgroup which has +enough memory allowance to avoid high reclaim pressure. + +If a cgroup sweeps a considerable amount of memory which is expected +to be accessed repeatedly by other cgroups, it may make sense to use +POSIX_FADV_DONTNEED to relinquish the ownership of memory areas +belonging to the affected files to ensure correct memory ownership. + + +5-3. IO + +The "io" controller regulates the distribution of IO resources. This +controller implements both weight based and absolute bandwidth or IOPS +limit distribution; however, weight based distribution is available +only if cfq-iosched is in use and neither scheme is available for +blk-mq devices. + + +5-3-1. IO Interface Files + + io.stat + + A read-only nested-keyed file which exists on non-root + cgroups. + + Lines are keyed by $MAJ:$MIN device numbers and not ordered. + The following nested keys are defined. + + rbytes Bytes read + wbytes Bytes written + rios Number of read IOs + wios Number of write IOs + + An example read output follows. + + 8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 + 8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 + + io.weight + + A read-write flat-keyed file which exists on non-root cgroups. + The default is "default 100". + + The first line is the default weight applied to devices + without specific override. The rest are overrides keyed by + $MAJ:$MIN device numbers and not ordered. The weights are in + the range [1, 10000] and specifies the relative amount IO time + the cgroup can use in relation to its siblings. + + The default weight can be updated by writing either "default + $WEIGHT" or simply "$WEIGHT". Overrides can be set by writing + "$MAJ:$MIN $WEIGHT" and unset by writing "$MAJ:$MIN default". + + An example read output follows. + + default 100 + 8:16 200 + 8:0 50 + + io.max + + A read-write nested-keyed file which exists on non-root + cgroups. + + BPS and IOPS based IO limit. Lines are keyed by $MAJ:$MIN + device numbers and not ordered. The following nested keys are + defined. + + rbps Max read bytes per second + wbps Max write bytes per second + riops Max read IO operations per second + wiops Max write IO operations per second + + When writing, any number of nested key-value pairs can be + specified in any order. "max" can be specified as the value + to remove a specific limit. If the same key is specified + multiple times, the outcome is undefined. + + BPS and IOPS are measured in each IO direction and IOs are + delayed if limit is reached. Temporary bursts are allowed. + + Setting read limit at 2M BPS and write at 120 IOPS for 8:16. + + echo "8:16 rbps=2097152 wiops=120" > io.max + + Reading returns the following. + + 8:16 rbps=2097152 wbps=max riops=max wiops=120 + + Write IOPS limit can be removed by writing the following. + + echo "8:16 wiops=max" > io.max + + Reading now returns the following. + + 8:16 rbps=2097152 wbps=max riops=max wiops=max + + +5-3-2. Writeback + +Page cache is dirtied through buffered writes and shared mmaps and +written asynchronously to the backing filesystem by the writeback +mechanism. Writeback sits between the memory and IO domains and +regulates the proportion of dirty memory by balancing dirtying and +write IOs. + +The io controller, in conjunction with the memory controller, +implements control of page cache writeback IOs. The memory controller +defines the memory domain that dirty memory ratio is calculated and +maintained for and the io controller defines the io domain which +writes out dirty pages for the memory domain. Both system-wide and +per-cgroup dirty memory states are examined and the more restrictive +of the two is enforced. + +cgroup writeback requires explicit support from the underlying +filesystem. Currently, cgroup writeback is implemented on ext2, ext4 +and btrfs. On other filesystems, all writeback IOs are attributed to +the root cgroup. + +There are inherent differences in memory and writeback management +which affects how cgroup ownership is tracked. Memory is tracked per +page while writeback per inode. For the purpose of writeback, an +inode is assigned to a cgroup and all IO requests to write dirty pages +from the inode are attributed to that cgroup. + +As cgroup ownership for memory is tracked per page, there can be pages +which are associated with different cgroups than the one the inode is +associated with. These are called foreign pages. The writeback +constantly keeps track of foreign pages and, if a particular foreign +cgroup becomes the majority over a certain period of time, switches +the ownership of the inode to that cgroup. + +While this model is enough for most use cases where a given inode is +mostly dirtied by a single cgroup even when the main writing cgroup +changes over time, use cases where multiple cgroups write to a single +inode simultaneously are not supported well. In such circumstances, a +significant portion of IOs are likely to be attributed incorrectly. +As memory controller assigns page ownership on the first use and +doesn't update it until the page is released, even if writeback +strictly follows page ownership, multiple cgroups dirtying overlapping +areas wouldn't work as expected. It's recommended to avoid such usage +patterns. + +The sysctl knobs which affect writeback behavior are applied to cgroup +writeback as follows. + + vm.dirty_background_ratio + vm.dirty_ratio + + These ratios apply the same to cgroup writeback with the + amount of available memory capped by limits imposed by the + memory controller and system-wide clean memory. + + vm.dirty_background_bytes + vm.dirty_bytes + + For cgroup writeback, this is calculated into ratio against + total available memory and applied the same way as + vm.dirty[_background]_ratio. + + +P. Information on Kernel Programming + +This section contains kernel programming information in the areas +where interacting with cgroup is necessary. cgroup core and +controllers are not covered. + + +P-1. Filesystem Support for Writeback + +A filesystem can support cgroup writeback by updating +address_space_operations->writepage[s]() to annotate bio's using the +following two functions. + + wbc_init_bio(@wbc, @bio) + + Should be called for each bio carrying writeback data and + associates the bio with the inode's owner cgroup. Can be + called anytime between bio allocation and submission. + + wbc_account_io(@wbc, @page, @bytes) + + Should be called for each data segment being written out. + While this function doesn't care exactly when it's called + during the writeback session, it's the easiest and most + natural to call it as data segments are added to a bio. + +With writeback bio's annotated, cgroup support can be enabled per +super_block by setting SB_I_CGROUPWB in ->s_iflags. This allows for +selective disabling of cgroup writeback support which is helpful when +certain filesystem features, e.g. journaled data mode, are +incompatible. + +wbc_init_bio() binds the specified bio to its cgroup. Depending on +the configuration, the bio may be executed at a lower priority and if +the writeback session is holding shared resources, e.g. a journal +entry, may lead to priority inversion. There is no one easy solution +for the problem. Filesystems can try to work around specific problem +cases by skipping wbc_init_bio() or using bio_associate_blkcg() +directly. + + +D. Deprecated v1 Core Features + +- Multiple hierarchies including named ones are not supported. + +- All mount options and remounting are not supported. + +- The "tasks" file is removed and "cgroup.procs" is not sorted. + +- "cgroup.clone_children" is removed. + +- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file + at the root instead. + + +R. Issues with v1 and Rationales for v2 + +R-1. Multiple Hierarchies + +cgroup v1 allowed an arbitrary number of hierarchies and each +hierarchy could host any number of controllers. While this seemed to +provide a high level of flexibility, it wasn't useful in practice. + +For example, as there is only one instance of each controller, utility +type controllers such as freezer which can be useful in all +hierarchies could only be used in one. The issue is exacerbated by +the fact that controllers couldn't be moved to another hierarchy once +hierarchies were populated. Another issue was that all controllers +bound to a hierarchy were forced to have exactly the same view of the +hierarchy. It wasn't possible to vary the granularity depending on +the specific controller. + +In practice, these issues heavily limited which controllers could be +put on the same hierarchy and most configurations resorted to putting +each controller on its own hierarchy. Only closely related ones, such +as the cpu and cpuacct controllers, made sense to be put on the same +hierarchy. This often meant that userland ended up managing multiple +similar hierarchies repeating the same steps on each hierarchy +whenever a hierarchy management operation was necessary. + +Furthermore, support for multiple hierarchies came at a steep cost. +It greatly complicated cgroup core implementation but more importantly +the support for multiple hierarchies restricted how cgroup could be +used in general and what controllers was able to do. + +There was no limit on how many hierarchies there might be, which meant +that a thread's cgroup membership couldn't be described in finite +length. The key might contain any number of entries and was unlimited +in length, which made it highly awkward to manipulate and led to +addition of controllers which existed only to identify membership, +which in turn exacerbated the original problem of proliferating number +of hierarchies. + +Also, as a controller couldn't have any expectation regarding the +topologies of hierarchies other controllers might be on, each +controller had to assume that all other controllers were attached to +completely orthogonal hierarchies. This made it impossible, or at +least very cumbersome, for controllers to cooperate with each other. + +In most use cases, putting controllers on hierarchies which are +completely orthogonal to each other isn't necessary. What usually is +called for is the ability to have differing levels of granularity +depending on the specific controller. In other words, hierarchy may +be collapsed from leaf towards root when viewed from specific +controllers. For example, a given configuration might not care about +how memory is distributed beyond a certain level while still wanting +to control how CPU cycles are distributed. + + +R-2. Thread Granularity + +cgroup v1 allowed threads of a process to belong to different cgroups. +This didn't make sense for some controllers and those controllers +ended up implementing different ways to ignore such situations but +much more importantly it blurred the line between API exposed to +individual applications and system management interface. + +Generally, in-process knowledge is available only to the process +itself; thus, unlike service-level organization of processes, +categorizing threads of a process requires active participation from +the application which owns the target process. + +cgroup v1 had an ambiguously defined delegation model which got abused +in combination with thread granularity. cgroups were delegated to +individual applications so that they can create and manage their own +sub-hierarchies and control resource distributions along them. This +effectively raised cgroup to the status of a syscall-like API exposed +to lay programs. + +First of all, cgroup has a fundamentally inadequate interface to be +exposed this way. For a process to access its own knobs, it has to +extract the path on the target hierarchy from /proc/self/cgroup, +construct the path by appending the name of the knob to the path, open +and then read and/or write to it. This is not only extremely clunky +and unusual but also inherently racy. There is no conventional way to +define transaction across the required steps and nothing can guarantee +that the process would actually be operating on its own sub-hierarchy. + +cgroup controllers implemented a number of knobs which would never be +accepted as public APIs because they were just adding control knobs to +system-management pseudo filesystem. cgroup ended up with interface +knobs which were not properly abstracted or refined and directly +revealed kernel internal details. These knobs got exposed to +individual applications through the ill-defined delegation mechanism +effectively abusing cgroup as a shortcut to implementing public APIs +without going through the required scrutiny. + +This was painful for both userland and kernel. Userland ended up with +misbehaving and poorly abstracted interfaces and kernel exposing and +locked into constructs inadvertently. + + +R-3. Competition Between Inner Nodes and Threads + +cgroup v1 allowed threads to be in any cgroups which created an +interesting problem where threads belonging to a parent cgroup and its +children cgroups competed for resources. This was nasty as two +different types of entities competed and there was no obvious way to +settle it. Different controllers did different things. + +The cpu controller considered threads and cgroups as equivalents and +mapped nice levels to cgroup weights. This worked for some cases but +fell flat when children wanted to be allocated specific ratios of CPU +cycles and the number of internal threads fluctuated - the ratios +constantly changed as the number of competing entities fluctuated. +There also were other issues. The mapping from nice level to weight +wasn't obvious or universal, and there were various other knobs which +simply weren't available for threads. + +The io controller implicitly created a hidden leaf node for each +cgroup to host the threads. The hidden leaf had its own copies of all +the knobs with "leaf_" prefixed. While this allowed equivalent +control over internal threads, it was with serious drawbacks. It +always added an extra layer of nesting which wouldn't be necessary +otherwise, made the interface messy and significantly complicated the +implementation. + +The memory controller didn't have a way to control what happened +between internal tasks and child cgroups and the behavior was not +clearly defined. There were attempts to add ad-hoc behaviors and +knobs to tailor the behavior to specific workloads which would have +led to problems extremely difficult to resolve in the long term. + +Multiple controllers struggled with internal tasks and came up with +different ways to deal with it; unfortunately, all the approaches were +severely flawed and, furthermore, the widely different behaviors +made cgroup as a whole highly inconsistent. + +This clearly is a problem which needs to be addressed from cgroup core +in a uniform way. + + +R-4. Other Interface Issues + +cgroup v1 grew without oversight and developed a large number of +idiosyncrasies and inconsistencies. One issue on the cgroup core side +was how an empty cgroup was notified - a userland helper binary was +forked and executed for each event. The event delivery wasn't +recursive or delegatable. The limitations of the mechanism also led +to in-kernel event delivery filtering mechanism further complicating +the interface. + +Controller interfaces were problematic too. An extreme example is +controllers completely ignoring hierarchical organization and treating +all cgroups as if they were all located directly under the root +cgroup. Some controllers exposed a large amount of inconsistent +implementation details to userland. + +There also was no consistency across controllers. When a new cgroup +was created, some controllers defaulted to not imposing extra +restrictions while others disallowed any resource usage until +explicitly configured. Configuration knobs for the same type of +control used widely differing naming schemes and formats. Statistics +and information knobs were named arbitrarily and used different +formats and units even in the same controller. + +cgroup v2 establishes common conventions where appropriate and updates +controllers so that they expose minimal and consistent interfaces. + + +R-5. Controller Issues and Remedies + +R-5-1. Memory + +The original lower boundary, the soft limit, is defined as a limit +that is per default unset. As a result, the set of cgroups that +global reclaim prefers is opt-in, rather than opt-out. The costs for +optimizing these mostly negative lookups are so high that the +implementation, despite its enormous size, does not even provide the +basic desirable behavior. First off, the soft limit has no +hierarchical meaning. All configured groups are organized in a global +rbtree and treated like equal peers, regardless where they are located +in the hierarchy. This makes subtree delegation impossible. Second, +the soft limit reclaim pass is so aggressive that it not just +introduces high allocation latencies into the system, but also impacts +system performance due to overreclaim, to the point where the feature +becomes self-defeating. + +The memory.low boundary on the other hand is a top-down allocated +reserve. A cgroup enjoys reclaim protection when it and all its +ancestors are below their low boundaries, which makes delegation of +subtrees possible. Secondly, new cgroups have no reserve per default +and in the common case most cgroups are eligible for the preferred +reclaim pass. This allows the new low boundary to be efficiently +implemented with just a minor addition to the generic reclaim code, +without the need for out-of-band data structures and reclaim passes. +Because the generic reclaim code considers all cgroups except for the +ones running low in the preferred first reclaim pass, overreclaim of +individual groups is eliminated as well, resulting in much better +overall workload performance. + +The original high boundary, the hard limit, is defined as a strict +limit that can not budge, even if the OOM killer has to be called. +But this generally goes against the goal of making the most out of the +available memory. The memory consumption of workloads varies during +runtime, and that requires users to overcommit. But doing that with a +strict upper limit requires either a fairly accurate prediction of the +working set size or adding slack to the limit. Since working set size +estimation is hard and error prone, and getting it wrong results in +OOM kills, most users tend to err on the side of a looser limit and +end up wasting precious resources. + +The memory.high boundary on the other hand can be set much more +conservatively. When hit, it throttles allocations by forcing them +into direct reclaim to work off the excess, but it never invokes the +OOM killer. As a result, a high boundary that is chosen too +aggressively will not terminate the processes, but instead it will +lead to gradual performance degradation. The user can monitor this +and make corrections until the minimal memory footprint that still +gives acceptable performance is found. + +In extreme cases, with many concurrent allocations and a complete +breakdown of reclaim progress within the group, the high boundary can +be exceeded. But even then it's mostly better to satisfy the +allocation from the slack available in other groups or the rest of the +system than killing the group. Otherwise, memory.max is there to +limit this type of spillover and ultimately contain buggy or even +malicious applications. diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt deleted file mode 100644 index 781b1d475bcf..000000000000 --- a/Documentation/cgroups/unified-hierarchy.txt +++ /dev/null @@ -1,647 +0,0 @@ - -Cgroup unified hierarchy - -April, 2014 Tejun Heo <tj@kernel.org> - -This document describes the changes made by unified hierarchy and -their rationales. It will eventually be merged into the main cgroup -documentation. - -CONTENTS - -1. Background -2. Basic Operation - 2-1. Mounting - 2-2. cgroup.subtree_control - 2-3. cgroup.controllers -3. Structural Constraints - 3-1. Top-down - 3-2. No internal tasks -4. Delegation - 4-1. Model of delegation - 4-2. Common ancestor rule -5. Other Changes - 5-1. [Un]populated Notification - 5-2. Other Core Changes - 5-3. Controller File Conventions - 5-3-1. Format - 5-3-2. Control Knobs - 5-4. Per-Controller Changes - 5-4-1. io - 5-4-2. cpuset - 5-4-3. memory -6. Planned Changes - 6-1. CAP for resource control - - -1. Background - -cgroup allows an arbitrary number of hierarchies and each hierarchy -can host any number of controllers. While this seems to provide a -high level of flexibility, it isn't quite useful in practice. - -For example, as there is only one instance of each controller, utility -type controllers such as freezer which can be useful in all -hierarchies can only be used in one. The issue is exacerbated by the -fact that controllers can't be moved around once hierarchies are -populated. Another issue is that all controllers bound to a hierarchy -are forced to have exactly the same view of the hierarchy. It isn't -possible to vary the granularity depending on the specific controller. - -In practice, these issues heavily limit which controllers can be put -on the same hierarchy and most configurations resort to putting each -controller on its own hierarchy. Only closely related ones, such as -the cpu and cpuacct controllers, make sense to put on the same -hierarchy. This often means that userland ends up managing multiple -similar hierarchies repeating the same steps on each hierarchy -whenever a hierarchy management operation is necessary. - -Unfortunately, support for multiple hierarchies comes at a steep cost. -Internal implementation in cgroup core proper is dazzlingly -complicated but more importantly the support for multiple hierarchies -restricts how cgroup is used in general and what controllers can do. - -There's no limit on how many hierarchies there may be, which means -that a task's cgroup membership can't be described in finite length. -The key may contain any varying number of entries and is unlimited in -length, which makes it highly awkward to handle and leads to addition -of controllers which exist only to identify membership, which in turn -exacerbates the original problem. - -Also, as a controller can't have any expectation regarding what shape -of hierarchies other controllers would be on, each controller has to -assume that all other controllers are operating on completely -orthogonal hierarchies. This makes it impossible, or at least very -cumbersome, for controllers to cooperate with each other. - -In most use cases, putting controllers on hierarchies which are -completely orthogonal to each other isn't necessary. What usually is -called for is the ability to have differing levels of granularity -depending on the specific controller. In other words, hierarchy may -be collapsed from leaf towards root when viewed from specific -controllers. For example, a given configuration might not care about -how memory is distributed beyond a certain level while still wanting -to control how CPU cycles are distributed. - -Unified hierarchy is the next version of cgroup interface. It aims to -address the aforementioned issues by having more structure while -retaining enough flexibility for most use cases. Various other -general and controller-specific interface issues are also addressed in -the process. - - -2. Basic Operation - -2-1. Mounting - -Currently, unified hierarchy can be mounted with the following mount -command. Note that this is still under development and scheduled to -change soon. - - mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT - -All controllers which support the unified hierarchy and are not bound -to other hierarchies are automatically bound to unified hierarchy and -show up at the root of it. Controllers which are enabled only in the -root of unified hierarchy can be bound to other hierarchies. This -allows mixing unified hierarchy with the traditional multiple -hierarchies in a fully backward compatible way. - -A controller can be moved across hierarchies only after the controller -is no longer referenced in its current hierarchy. Because per-cgroup -controller states are destroyed asynchronously and controllers may -have lingering references, a controller may not show up immediately on -the unified hierarchy after the final umount of the previous -hierarchy. Similarly, a controller should be fully disabled to be -moved out of the unified hierarchy and it may take some time for the -disabled controller to become available for other hierarchies; -furthermore, due to dependencies among controllers, other controllers -may need to be disabled too. - -While useful for development and manual configurations, dynamically -moving controllers between the unified and other hierarchies is -strongly discouraged for production use. It is recommended to decide -the hierarchies and controller associations before starting using the -controllers. - - -2-2. cgroup.subtree_control - -All cgroups on unified hierarchy have a "cgroup.subtree_control" file -which governs which controllers are enabled on the children of the -cgroup. Let's assume a hierarchy like the following. - - root - A - B - C - \ D - -root's "cgroup.subtree_control" file determines which controllers are -enabled on A. A's on B. B's on C and D. This coincides with the -fact that controllers on the immediate sub-level are used to -distribute the resources of the parent. In fact, it's natural to -assume that resource control knobs of a child belong to its parent. -Enabling a controller in a "cgroup.subtree_control" file declares that -distribution of the respective resources of the cgroup will be -controlled. Note that this means that controller enable states are -shared among siblings. - -When read, the file contains a space-separated list of currently -enabled controllers. A write to the file should contain a -space-separated list of controllers with '+' or '-' prefixed (without -the quotes). Controllers prefixed with '+' are enabled and '-' -disabled. If a controller is listed multiple times, the last entry -wins. The specific operations are executed atomically - either all -succeed or fail. - - -2-3. cgroup.controllers - -Read-only "cgroup.controllers" file contains a space-separated list of -controllers which can be enabled in the cgroup's -"cgroup.subtree_control" file. - -In the root cgroup, this lists controllers which are not bound to -other hierarchies and the content changes as controllers are bound to -and unbound from other hierarchies. - -In non-root cgroups, the content of this file equals that of the -parent's "cgroup.subtree_control" file as only controllers enabled -from the parent can be used in its children. - - -3. Structural Constraints - -3-1. Top-down - -As it doesn't make sense to nest control of an uncontrolled resource, -all non-root "cgroup.subtree_control" files can only contain -controllers which are enabled in the parent's "cgroup.subtree_control" -file. A controller can be enabled only if the parent has the -controller enabled and a controller can't be disabled if one or more -children have it enabled. - - -3-2. No internal tasks - -One long-standing issue that cgroup faces is the competition between -tasks belonging to the parent cgroup and its children cgroups. This -is inherently nasty as two different types of entities compete and -there is no agreed-upon obvious way to handle it. Different -controllers are doing different things. - -The cpu controller considers tasks and cgroups as equivalents and maps -nice levels to cgroup weights. This works for some cases but falls -flat when children should be allocated specific ratios of CPU cycles -and the number of internal tasks fluctuates - the ratios constantly -change as the number of competing entities fluctuates. There also are -other issues. The mapping from nice level to weight isn't obvious or -universal, and there are various other knobs which simply aren't -available for tasks. - -The io controller implicitly creates a hidden leaf node for each -cgroup to host the tasks. The hidden leaf has its own copies of all -the knobs with "leaf_" prefixed. While this allows equivalent control -over internal tasks, it's with serious drawbacks. It always adds an -extra layer of nesting which may not be necessary, makes the interface -messy and significantly complicates the implementation. - -The memory controller currently doesn't have a way to control what -happens between internal tasks and child cgroups and the behavior is -not clearly defined. There have been attempts to add ad-hoc behaviors -and knobs to tailor the behavior to specific workloads. Continuing -this direction will lead to problems which will be extremely difficult -to resolve in the long term. - -Multiple controllers struggle with internal tasks and came up with -different ways to deal with it; unfortunately, all the approaches in -use now are severely flawed and, furthermore, the widely different -behaviors make cgroup as whole highly inconsistent. - -It is clear that this is something which needs to be addressed from -cgroup core proper in a uniform way so that controllers don't need to -worry about it and cgroup as a whole shows a consistent and logical -behavior. To achieve that, unified hierarchy enforces the following -structural constraint: - - Except for the root, only cgroups which don't contain any task may - have controllers enabled in their "cgroup.subtree_control" files. - -Combined with other properties, this guarantees that, when a -controller is looking at the part of the hierarchy which has it -enabled, tasks are always only on the leaves. This rules out -situations where child cgroups compete against internal tasks of the -parent. - -There are two things to note. Firstly, the root cgroup is exempt from -the restriction. Root contains tasks and anonymous resource -consumption which can't be associated with any other cgroup and -requires special treatment from most controllers. How resource -consumption in the root cgroup is governed is up to each controller. - -Secondly, the restriction doesn't take effect if there is no enabled -controller in the cgroup's "cgroup.subtree_control" file. This is -important as otherwise it wouldn't be possible to create children of a -populated cgroup. To control resource distribution of a cgroup, the -cgroup must create children and transfer all its tasks to the children -before enabling controllers in its "cgroup.subtree_control" file. - - -4. Delegation - -4-1. Model of delegation - -A cgroup can be delegated to a less privileged user by granting write -access of the directory and its "cgroup.procs" file to the user. Note -that the resource control knobs in a given directory concern the -resources of the parent and thus must not be delegated along with the -directory. - -Once delegated, the user can build sub-hierarchy under the directory, -organize processes as it sees fit and further distribute the resources -it got from the parent. The limits and other settings of all resource -controllers are hierarchical and regardless of what happens in the -delegated sub-hierarchy, nothing can escape the resource restrictions -imposed by the parent. - -Currently, cgroup doesn't impose any restrictions on the number of -cgroups in or nesting depth of a delegated sub-hierarchy; however, -this may in the future be limited explicitly. - - -4-2. Common ancestor rule - -On the unified hierarchy, to write to a "cgroup.procs" file, in -addition to the usual write permission to the file and uid match, the -writer must also have write access to the "cgroup.procs" file of the -common ancestor of the source and destination cgroups. This prevents -delegatees from smuggling processes across disjoint sub-hierarchies. - -Let's say cgroups C0 and C1 have been delegated to user U0 who created -C00, C01 under C0 and C10 under C1 as follows. - - ~~~~~~~~~~~~~ - C0 - C00 - ~ cgroup ~ \ C01 - ~ hierarchy ~ - ~~~~~~~~~~~~~ - C1 - C10 - -C0 and C1 are separate entities in terms of resource distribution -regardless of their relative positions in the hierarchy. The -resources the processes under C0 are entitled to are controlled by -C0's ancestors and may be completely different from C1. It's clear -that the intention of delegating C0 to U0 is allowing U0 to organize -the processes under C0 and further control the distribution of C0's -resources. - -On traditional hierarchies, if a task has write access to "tasks" or -"cgroup.procs" file of a cgroup and its uid agrees with the target, it -can move the target to the cgroup. In the above example, U0 will not -only be able to move processes in each sub-hierarchy but also across -the two sub-hierarchies, effectively allowing it to violate the -organizational and resource restrictions implied by the hierarchical -structure above C0 and C1. - -On the unified hierarchy, let's say U0 wants to write the pid of a -process which has a matching uid and is currently in C10 into -"C00/cgroup.procs". U0 obviously has write access to the file and -migration permission on the process; however, the common ancestor of -the source cgroup C10 and the destination cgroup C00 is above the -points of delegation and U0 would not have write access to its -"cgroup.procs" and thus be denied with -EACCES. - - -5. Other Changes - -5-1. [Un]populated Notification - -cgroup users often need a way to determine when a cgroup's -subhierarchy becomes empty so that it can be cleaned up. cgroup -currently provides release_agent for it; unfortunately, this mechanism -is riddled with issues. - -- It delivers events by forking and execing a userland binary - specified as the release_agent. This is a long deprecated method of - notification delivery. It's extremely heavy, slow and cumbersome to - integrate with larger infrastructure. - -- There is single monitoring point at the root. There's no way to - delegate management of a subtree. - -- The event isn't recursive. It triggers when a cgroup doesn't have - any tasks or child cgroups. Events for internal nodes trigger only - after all children are removed. This again makes it impossible to - delegate management of a subtree. - -- Events are filtered from the kernel side. A "notify_on_release" - file is used to subscribe to or suppress release events. This is - unnecessarily complicated and probably done this way because event - delivery itself was expensive. - -Unified hierarchy implements "populated" field in "cgroup.events" -interface file which can be used to monitor whether the cgroup's -subhierarchy has tasks in it or not. Its value is 0 if there is no -task in the cgroup and its descendants; otherwise, 1. poll and -[id]notify events are triggered when the value changes. - -This is significantly lighter and simpler and trivially allows -delegating management of subhierarchy - subhierarchy monitoring can -block further propagation simply by putting itself or another process -in the subhierarchy and monitor events that it's interested in from -there without interfering with monitoring higher in the tree. - -In unified hierarchy, the release_agent mechanism is no longer -supported and the interface files "release_agent" and -"notify_on_release" do not exist. - - -5-2. Other Core Changes - -- None of the mount options is allowed. - -- remount is disallowed. - -- rename(2) is disallowed. - -- The "tasks" file is removed. Everything should at process - granularity. Use the "cgroup.procs" file instead. - -- The "cgroup.procs" file is not sorted. pids will be unique unless - they got recycled in-between reads. - -- The "cgroup.clone_children" file is removed. - -- /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged - to before exiting. If the cgroup is removed before the zombie is - reaped, " (deleted)" is appeneded to the path. - - -5-3. Controller File Conventions - -5-3-1. Format - -In general, all controller files should be in one of the following -formats whenever possible. - -- Values only files - - VAL0 VAL1...\n - -- Flat keyed files - - KEY0 VAL0\n - KEY1 VAL1\n - ... - -- Nested keyed files - - KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01... - KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11... - ... - -For a writeable file, the format for writing should generally match -reading; however, controllers may allow omitting later fields or -implement restricted shortcuts for most common use cases. - -For both flat and nested keyed files, only the values for a single key -can be written at a time. For nested keyed files, the sub key pairs -may be specified in any order and not all pairs have to be specified. - - -5-3-2. Control Knobs - -- Settings for a single feature should generally be implemented in a - single file. - -- In general, the root cgroup should be exempt from resource control - and thus shouldn't have resource control knobs. - -- If a controller implements ratio based resource distribution, the - control knob should be named "weight" and have the range [1, 10000] - and 100 should be the default value. The values are chosen to allow - enough and symmetric bias in both directions while keeping it - intuitive (the default is 100%). - -- If a controller implements an absolute resource guarantee and/or - limit, the control knobs should be named "min" and "max" - respectively. If a controller implements best effort resource - gurantee and/or limit, the control knobs should be named "low" and - "high" respectively. - - In the above four control files, the special token "max" should be - used to represent upward infinity for both reading and writing. - -- If a setting has configurable default value and specific overrides, - the default settings should be keyed with "default" and appear as - the first entry in the file. Specific entries can use "default" as - its value to indicate inheritance of the default value. - -- For events which are not very high frequency, an interface file - "events" should be created which lists event key value pairs. - Whenever a notifiable event happens, file modified event should be - generated on the file. - - -5-4. Per-Controller Changes - -5-4-1. io - -- blkio is renamed to io. The interface is overhauled anyway. The - new name is more in line with the other two major controllers, cpu - and memory, and better suited given that it may be used for cgroup - writeback without involving block layer. - -- Everything including stat is always hierarchical making separate - recursive stat files pointless and, as no internal node can have - tasks, leaf weights are meaningless. The operation model is - simplified and the interface is overhauled accordingly. - - io.stat - - The stat file. The reported stats are from the point where - bio's are issued to request_queue. The stats are counted - independent of which policies are enabled. Each line in the - file follows the following format. More fields may later be - added at the end. - - $MAJ:$MIN rbytes=$RBYTES wbytes=$WBYTES rios=$RIOS wrios=$WIOS - - io.weight - - The weight setting, currently only available and effective if - cfq-iosched is in use for the target device. The weight is - between 1 and 10000 and defaults to 100. The first line - always contains the default weight in the following format to - use when per-device setting is missing. - - default $WEIGHT - - Subsequent lines list per-device weights of the following - format. - - $MAJ:$MIN $WEIGHT - - Writing "$WEIGHT" or "default $WEIGHT" changes the default - setting. Writing "$MAJ:$MIN $WEIGHT" sets per-device weight - while "$MAJ:$MIN default" clears it. - - This file is available only on non-root cgroups. - - io.max - - The maximum bandwidth and/or iops setting, only available if - blk-throttle is enabled. The file is of the following format. - - $MAJ:$MIN rbps=$RBPS wbps=$WBPS riops=$RIOPS wiops=$WIOPS - - ${R|W}BPS are read/write bytes per second and ${R|W}IOPS are - read/write IOs per second. "max" indicates no limit. Writing - to the file follows the same format but the individual - settings may be omitted or specified in any order. - - This file is available only on non-root cgroups. - - -5-4-2. cpuset - -- Tasks are kept in empty cpusets after hotplug and take on the masks - of the nearest non-empty ancestor, instead of being moved to it. - -- A task can be moved into an empty cpuset, and again it takes on the - masks of the nearest non-empty ancestor. - - -5-4-3. memory - -- use_hierarchy is on by default and the cgroup file for the flag is - not created. - -- The original lower boundary, the soft limit, is defined as a limit - that is per default unset. As a result, the set of cgroups that - global reclaim prefers is opt-in, rather than opt-out. The costs - for optimizing these mostly negative lookups are so high that the - implementation, despite its enormous size, does not even provide the - basic desirable behavior. First off, the soft limit has no - hierarchical meaning. All configured groups are organized in a - global rbtree and treated like equal peers, regardless where they - are located in the hierarchy. This makes subtree delegation - impossible. Second, the soft limit reclaim pass is so aggressive - that it not just introduces high allocation latencies into the - system, but also impacts system performance due to overreclaim, to - the point where the feature becomes self-defeating. - - The memory.low boundary on the other hand is a top-down allocated - reserve. A cgroup enjoys reclaim protection when it and all its - ancestors are below their low boundaries, which makes delegation of - subtrees possible. Secondly, new cgroups have no reserve per - default and in the common case most cgroups are eligible for the - preferred reclaim pass. This allows the new low boundary to be - efficiently implemented with just a minor addition to the generic - reclaim code, without the need for out-of-band data structures and - reclaim passes. Because the generic reclaim code considers all - cgroups except for the ones running low in the preferred first - reclaim pass, overreclaim of individual groups is eliminated as - well, resulting in much better overall workload performance. - -- The original high boundary, the hard limit, is defined as a strict - limit that can not budge, even if the OOM killer has to be called. - But this generally goes against the goal of making the most out of - the available memory. The memory consumption of workloads varies - during runtime, and that requires users to overcommit. But doing - that with a strict upper limit requires either a fairly accurate - prediction of the working set size or adding slack to the limit. - Since working set size estimation is hard and error prone, and - getting it wrong results in OOM kills, most users tend to err on the - side of a looser limit and end up wasting precious resources. - - The memory.high boundary on the other hand can be set much more - conservatively. When hit, it throttles allocations by forcing them - into direct reclaim to work off the excess, but it never invokes the - OOM killer. As a result, a high boundary that is chosen too - aggressively will not terminate the processes, but instead it will - lead to gradual performance degradation. The user can monitor this - and make corrections until the minimal memory footprint that still - gives acceptable performance is found. - - In extreme cases, with many concurrent allocations and a complete - breakdown of reclaim progress within the group, the high boundary - can be exceeded. But even then it's mostly better to satisfy the - allocation from the slack available in other groups or the rest of - the system than killing the group. Otherwise, memory.max is there - to limit this type of spillover and ultimately contain buggy or even - malicious applications. - -- The original control file names are unwieldy and inconsistent in - many different ways. For example, the upper boundary hit count is - exported in the memory.failcnt file, but an OOM event count has to - be manually counted by listening to memory.oom_control events, and - lower boundary / soft limit events have to be counted by first - setting a threshold for that value and then counting those events. - Also, usage and limit files encode their units in the filename. - That makes the filenames very long, even though this is not - information that a user needs to be reminded of every time they type - out those names. - - To address these naming issues, as well as to signal clearly that - the new interface carries a new configuration model, the naming - conventions in it necessarily differ from the old interface. - -- The original limit files indicate the state of an unset limit with a - Very High Number, and a configured limit can be unset by echoing -1 - into those files. But that very high number is implementation and - architecture dependent and not very descriptive. And while -1 can - be understood as an underflow into the highest possible value, -2 or - -10M etc. do not work, so it's not consistent. - - memory.low, memory.high, and memory.max will use the string "max" to - indicate and set the highest possible value. - -6. Planned Changes - -6-1. CAP for resource control - -Unified hierarchy will require one of the capabilities(7), which is -yet to be decided, for all resource control related knobs. Process -organization operations - creation of sub-cgroups and migration of -processes in sub-hierarchies may be delegated by changing the -ownership and/or permissions on the cgroup directory and -"cgroup.procs" interface file; however, all operations which affect -resource control - writes to a "cgroup.subtree_control" file or any -controller-specific knobs - will require an explicit CAP privilege. - -This, in part, is to prevent the cgroup interface from being -inadvertently promoted to programmable API used by non-privileged -binaries. cgroup exposes various aspects of the system in ways which -aren't properly abstracted for direct consumption by regular programs. -This is an administration interface much closer to sysctl knobs than -system calls. Even the basic access model, being filesystem path -based, isn't suitable for direct consumption. There's no way to -access "my cgroup" in a race-free way or make multiple operations -atomic against migration to another cgroup. - -Another aspect is that, for better or for worse, the cgroup interface -goes through far less scrutiny than regular interfaces for -unprivileged userland. The upside is that cgroup is able to expose -useful features which may not be suitable for general consumption in a -reasonable time frame. It provides a relatively short path between -internal details and userland-visible interface. Of course, this -shortcut comes with high risk. We go through what we go through for -general kernel APIs for good reasons. It may end up leaking internal -details in a way which can exert significant pain by locking the -kernel into a contract that can't be maintained in a reasonable -manner. - -Also, due to the specific nature, cgroup and its controllers don't -tend to attract attention from a wide scope of developers. cgroup's -short history is already fraught with severely mis-designed -interfaces, unnecessary commitments to and exposing of internal -details, broken and dangerous implementations of various features. - -Keeping cgroup as an administration interface is both advantageous for -its role and imperative given its nature. Some of the cgroup features -may make sense for unprivileged access. If deemed justified, those -must be further abstracted and implemented as a different interface, -be it a system call or process-private filesystem, and survive through -the scrutiny that any interface for general consumption is required to -go through. - -Requiring CAP is not a complete solution but should serve as a -significant deterrent against spraying cgroup usages in non-privileged -programs. diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index c15aa75f5227..472122fda585 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -28,6 +28,7 @@ Contents: 2.3 Userspace 2.4 Ondemand 2.5 Conservative +2.6 Interactive 3. The Governor Interface in the CPUfreq Core @@ -218,6 +219,134 @@ a decision on when to decrease the frequency while running in any speed. Load for frequency increase is still evaluated every sampling rate. +2.6 Interactive +--------------- + +The CPUfreq governor "interactive" is designed for latency-sensitive, +interactive workloads. This governor sets the CPU speed depending on +usage, similar to "ondemand" and "conservative" governors, but with a +different set of configurable behaviors. + +The tuneable values for this governor are: + +target_loads: CPU load values used to adjust speed to influence the +current CPU load toward that value. In general, the lower the target +load, the more often the governor will raise CPU speeds to bring load +below the target. The format is a single target load, optionally +followed by pairs of CPU speeds and CPU loads to target at or above +those speeds. Colons can be used between the speeds and associated +target loads for readability. For example: + + 85 1000000:90 1700000:99 + +targets CPU load 85% below speed 1GHz, 90% at or above 1GHz, until +1.7GHz and above, at which load 99% is targeted. If speeds are +specified these must appear in ascending order. Higher target load +values are typically specified for higher speeds, that is, target load +values also usually appear in an ascending order. The default is +target load 90% for all speeds. + +min_sample_time: The minimum amount of time to spend at the current +frequency before ramping down. Default is 80000 uS. + +hispeed_freq: An intermediate "hi speed" at which to initially ramp +when CPU load hits the value specified in go_hispeed_load. If load +stays high for the amount of time specified in above_hispeed_delay, +then speed may be bumped higher. Default is the maximum speed +allowed by the policy at governor initialization time. + +go_hispeed_load: The CPU load at which to ramp to hispeed_freq. +Default is 99%. + +above_hispeed_delay: When speed is at or above hispeed_freq, wait for +this long before raising speed in response to continued high load. +The format is a single delay value, optionally followed by pairs of +CPU speeds and the delay to use at or above those speeds. Colons can +be used between the speeds and associated delays for readability. For +example: + + 80000 1300000:200000 1500000:40000 + +uses delay 80000 uS until CPU speed 1.3 GHz, at which speed delay +200000 uS is used until speed 1.5 GHz, at which speed (and above) +delay 40000 uS is used. If speeds are specified these must appear in +ascending order. Default is 20000 uS. + +timer_rate: Sample rate for reevaluating CPU load when the CPU is not +idle. A deferrable timer is used, such that the CPU will not be woken +from idle to service this timer until something else needs to run. +(The maximum time to allow deferring this timer when not running at +minimum speed is configurable via timer_slack.) Default is 20000 uS. + +timer_slack: Maximum additional time to defer handling the governor +sampling timer beyond timer_rate when running at speeds above the +minimum. For platforms that consume additional power at idle when +CPUs are running at speeds greater than minimum, this places an upper +bound on how long the timer will be deferred prior to re-evaluating +load and dropping speed. For example, if timer_rate is 20000uS and +timer_slack is 10000uS then timers will be deferred for up to 30msec +when not at lowest speed. A value of -1 means defer timers +indefinitely at all speeds. Default is 80000 uS. + +boost: If non-zero, immediately boost speed of all CPUs to at least +hispeed_freq until zero is written to this attribute. If zero, allow +CPU speeds to drop below hispeed_freq according to load as usual. +Default is zero. + +boostpulse: On each write, immediately boost speed of all CPUs to +hispeed_freq for at least the period of time specified by +boostpulse_duration, after which speeds are allowed to drop below +hispeed_freq according to load as usual. + +boostpulse_duration: Length of time to hold CPU speed at hispeed_freq +on a write to boostpulse, before allowing speed to drop according to +load as usual. Default is 80000 uS. + +align_windows: If non-zero, align governor timer window to fire at +multiples of number of jiffies timer_rate converts to. + +use_sched_load: If non-zero, query scheduler for CPU busy time, +instead of collecting it directly in governor. This would allow +scheduler to adjust the busy time of each CPU to account for known +information such as migration. If non-zero, this also implies governor +sampling windows are aligned across CPUs, with same timer_rate, +regardless what align_windows is set to. Default is zero. + +use_migration_notif: If non-zero, schedule hrtimer to fire in 1ms +to reevaluate frequency of notified CPU, unless the hrtimer is already +pending. If zero, ignore scheduler notification. Default is zero. + +max_freq_hysteresis: Each time freq evaluation chooses policy->max, +next max_freq_hysteresis is considered as hysteresis period. During +this period, frequency target will not drop below hispeed_freq, no +matter how light actual workload is. If CPU load of any sampling +window exceeds go_hispeed_load during this period, governor will +directly increase frequency back to policy->max. Default is 0 uS. + +ignore_hispeed_on_notif: If non-zero, do not apply hispeed related +logic if frequency evaluation is triggered by scheduler notification. +This includes ignoring go_hispeed_load, hispeed_freq in frequency +selection, and ignoring above_hispeed_delay that prevents frequency +ramp up. For evaluation triggered by timer, hispeed logic is still +always applied. ignore_hispeed_on_notif has no effect if +use_migration_notif is set to zero. Default is zero. + +fast_ramp_down: If non-zero, do not apply min_sample_time if +frequency evaluation is triggered by scheduler notification. For +evaluation triggered by timer, min_sample_time is still always +enforced. fast_ramp_down has no effect if use_migration_notif is +set to zero. Default is zero. + +enable_prediction: If non-zero, two frequencies will be calculated +during each sampling period: one based on busy time in previous sampling +period (f_prev), and the other based on prediction provided by scheduler +(f_pred). Max of both will be selected as final frequency. Hispeed +related logic, including both frequency selection and delay is ignored +if enable_prediction is set. If only f_pred but not f_prev picked +policy->max, max_freq_hysteresis period is not started/extended. +use_sched_load must be turned on before enabling this feature. +Default is zero. + 3. The Governor Interface in the CPUfreq Core ============================================= diff --git a/Documentation/crypto/msm/msm_ice_driver.txt b/Documentation/crypto/msm/msm_ice_driver.txt new file mode 100644 index 000000000000..ddb81766b134 --- /dev/null +++ b/Documentation/crypto/msm/msm_ice_driver.txt @@ -0,0 +1,235 @@ +Introduction: +============= +Storage encryption has been one of the most required feature from security +point of view. QTI based storage encryption solution uses general purpose +crypto engine. While this kind of solution provide a decent amount of +performance, it falls short as storage speed is improving significantly +continuously. To overcome performance degradation, newer chips are going to +have Inline Crypto Engine (ICE) embedded into storage device. ICE is supposed +to meet the line speed of storage devices. + +Hardware Description +==================== +ICE is a HW block that is embedded into storage device such as UFS/eMMC. By +default, ICE works in bypass mode i.e. ICE HW does not perform any crypto +operation on data to be processed by storage device. If required, ICE can be +configured to perform crypto operation in one direction (i.e. either encryption +or decryption) or in both direction(both encryption & decryption). + +When a switch between the operation modes(plain to crypto or crypto to plain) +is desired for a particular partition, SW must complete all transactions for +that particular partition before switching the crypto mode i.e. no crypto, one +direction crypto or both direction crypto operation. Requests for other +partitions are not impacted due to crypto mode switch. + +ICE HW currently supports AES128/256 bit ECB & XTS mode encryption algorithms. + +Keys for crypto operations are loaded from SW. Keys are stored in a lookup +table(LUT) located inside ICE HW. Maximum of 32 keys can be loaded in ICE key +LUT. A Key inside the LUT can be referred using a key index. + +SW Description +============== +ICE HW has catagorized ICE registers in 2 groups: those which can be accessed by +only secure side i.e. TZ and those which can be accessed by non-secure side such +as HLOS as well. This requires that ICE driver to be split in two pieces: one +running from TZ space and another from HLOS space. + +ICE driver from TZ would configure keys as requested by HLOS side. + +ICE driver on HLOS side is responsible for initialization of ICE HW. + +SW Architecture Diagram +======================= +Following are all the components involved in the ICE driver for control path: + ++++++++++++++++++++++++++++++++++++++++++ ++ App layer + ++++++++++++++++++++++++++++++++++++++++++ ++ System layer + ++ ++++++++ +++++++ + ++ + VOLD + + PFM + + ++ ++++++++ +++++++ + ++ || || + ++ || || + ++ \/ \/ + ++ ++++++++++++++ + ++ + LibQSEECom + + ++ ++++++++++++++ + ++++++++++++++++++++++++++++++++++++++++++ ++ Kernel + +++++++++++++++++ ++ + + KMS + ++ +++++++ +++++++++++ +++++++++++ + +++++++++++++++++ ++ + ICE + + Storage + + QSEECom + + + ICE Driver + ++++++++++++++++++++++++++++++++++++++++++ <===> +++++++++++++++++ + || || + || || + \/ \/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ Storage Device + ++ ++++++++++++++ + ++ + ICE HW + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Use Cases: +---------- +a) Device bootup +ICE HW is detected during bootup time and corresponding probe function is +called. ICE driver parses its data from device tree node. ICE HW and storage +HW are tightly coupled. Storage device probing is dependent upon ICE device +probing. ICE driver configures all the required registers to put the ICE HW +in bypass mode. + +b) Configuring keys +Currently, there are couple of use cases to configure the keys. + +1) Full Disk Encryption(FDE) +System layer(VOLD) at invocation of apps layer would call libqseecom to create +the encryption key. Libqseecom calls qseecom driver to communicate with KMS +module on the secure side i.e. TZ. KMS would call ICE driver on the TZ side to +create and set the keys in ICE HW. At the end of transaction, VOLD would have +key index of key LUT where encryption key is present. + +2) Per File Encryption (PFE) +Per File Manager(PFM) calls QSEECom api to create the key. PFM has a peer comp- +onent(PFT) at kernel layer which gets the corresponding key index from PFM. + +Following are all the components involved in the ICE driver for data path: + ++++++++++++++++++++++++++++++++++++++++++ ++ App layer + ++++++++++++++++++++++++++++++++++++++++++ ++ VFS + ++---------------------------------------+ ++ File System (EXT4) + ++---------------------------------------+ ++ Block Layer + ++ --------------------------------------+ ++ +++++++ + ++ dm-req-crypt => + PFT + + ++ +++++++ + ++ + ++---------------------------------------+ ++ +++++++++++ +++++++ + ++ + Storage + + ICE + + ++++++++++++++++++++++++++++++++++++++++++ ++ || + ++ || (Storage Req with + ++ \/ ICE parameters ) + ++++++++++++++++++++++++++++++++++++++++++ ++ Storage Device + ++ ++++++++++++++ + ++ + ICE HW + + ++++++++++++++++++++++++++++++++++++++++++ + +c) Data transaction +Once the crypto key has been configured, VOLD/PFM creates device mapping for +data partition. As part of device mapping VOLD passes key index, crypto +algorithm, mode and key length to dm layer. In case of PFE, keys are provided +by PFT as and when request is processed by dm-req-crypt. When any application +needs to read/write data, it would go through DM layer which would add crypto +information, provided by VOLD/PFT, to Request. For each Request, Storage driver +would ask ICE driver to configure crypto part of request. ICE driver extracts +crypto data from Request structure and provide it to storage driver which would +finally dispatch request to storage device. + +d) Error Handling +Due to issue # 1 mentioned in "Known Issues", ICE driver does not register for +any interrupt. However, it enables sources of interrupt for ICE HW. After each +data transaction, Storage driver receives transaction completion event. As part +of event handling, storage driver calls ICE driver to check if any of ICE +interrupt status is set. If yes, storage driver returns error to upper layer. + +Error handling would be changed in future chips. + +Interfaces +========== +ICE driver exposes interfaces for storage driver to : +1. Get the global instance of ICE driver +2. Get the implemented interfaces of the particular ice instance +3. Initialize the ICE HW +4. Reset the ICE HW +5. Resume/Suspend the ICE HW +6. Get the Crypto configuration for the data request for storage +7. Check if current data transaction has generated any interrupt + +Driver Parameters +================= +This driver is built and statically linked into the kernel; therefore, +there are no module parameters supported by this driver. + +There are no kernel command line parameters supported by this driver. + +Power Management +================ +ICE driver does not do power management on its own as it is part of storage +hardware. Whenever storage driver receives request for power collapse/suspend +resume, it would call ICE driver which exposes APIs for Storage HW. ICE HW +during power collapse or reset, wipes crypto configuration data. When ICE +driver receives request to resume, it would ask ICE driver on TZ side to +restore the configuration. ICE driver does not do anything as part of power +collapse or suspend event. + +Interface: +========== +ICE driver exposes following APIs for storage driver to use: + +int (*init)(struct platform_device *, void *, ice_success_cb, ice_error_cb); + -- This function is invoked by storage controller during initialization of + storage controller. Storage controller would provide success and error call + backs which would be invoked asynchronously once ICE HW init is done. + +int (*reset)(struct platform_device *); + -- ICE HW reset as part of storage controller reset. When storage controller + received reset command, it would call reset on ICE HW. As of now, ICE HW + does not need to do anything as part of reset. + +int (*resume)(struct platform_device *); + -- ICE HW while going to reset, wipes all crypto keys and other data from ICE + HW. ICE driver would reconfigure those data as part of resume operation. + +int (*suspend)(struct platform_device *); + -- This API would be called by storage driver when storage device is going to + suspend mode. As of today, ICE driver does not do anything to handle suspend. + +int (*config)(struct platform_device *, struct request* , struct ice_data_setting*); + -- Storage driver would call this interface to get all crypto data required to + perform crypto operation. + +int (*status)(struct platform_device *); + -- Storage driver would call this interface to check if previous data transfer + generated any error. + +Config options +============== +This driver is enabled by the kernel config option CONFIG_CRYPTO_DEV_MSM_ICE. + +Dependencies +============ +ICE driver depends upon corresponding ICE driver on TZ side to function +appropriately. + +Known Issues +============ +1. ICE HW emits 0s even if it has generated an interrupt +This issue has significant impact on how ICE interrupts are handled. Currently, +ICE driver does not register for any of the ICE interrupts but enables the +sources of interrupt. Once storage driver asks to check the status of interrupt, +it reads and clears the clear status and provide read status to storage driver. +This mechanism though not optimal but prevents filesystem curruption. +This issue has been fixed in newer chips. + +2. ICE HW wipes all crypto data during power collapse +This issue necessiate that ICE driver on TZ side store the crypto material +which is not required in the case of general purpose crypto engine. +This issue has been fixed in newer chips. + +Further Improvements +==================== +Currently, Due to PFE use case, ICE driver is dependent upon dm-req-crypt to +provide the keys as part of request structure. This couples ICE driver with +dm-req-crypt based solution. It is under discussion to expose an IOCTL based +and registeration based interface APIs from ICE driver. ICE driver would use +these two interfaces to find out if any key exists for current request. If +yes, choose the right key index received from IOCTL or registeration based +APIs. If not, dont set any crypto parameter in the request. diff --git a/Documentation/crypto/msm/qce.txt b/Documentation/crypto/msm/qce.txt new file mode 100644 index 000000000000..18435d170e19 --- /dev/null +++ b/Documentation/crypto/msm/qce.txt @@ -0,0 +1,228 @@ +Introduction: +============= + +The Qualcomm crypto engine (qce) driver is a module that +provides common services for accessing the Qualcomm crypto device. +Currently, the two main clients of qce are +-qcrypto driver (module provided for accessing CE HW by kernel space apps) +-qcedev driver (module provided for accessing CE HW by user space apps) + + +The crypto engine (qce) driver is a client to the DMA driver for the Qualcomm +DMA device - Application Data Mover (ADM). ADM is used to provide the DMA +transfer capability between Qualcomm crypto device hardware and DDR memory +for crypto operations. + + Figure 1. + --------- + + Linux kernel + (ex:IPSec)<--*Qualcomm crypto driver----+ + (qcrypto) | + (for kernel space app) | + | + +-->| + | + | *qce <----> Qualcomm + | driver ADM driver <---> ADM HW + +-->| | | + | | | + | | | + | | | + Linux kernel | | | + misc device <--- *QCEDEV Driver-------+ | | + interface (qcedev) (Reg interface) (DMA interface) + (for user space app) \ / + \ / + \ / + \ / + \ / + \ / + \ / + Qualcomm crypto CE3 HW + + + The entities marked with (*) in the Figure 1, are the software components of + the Linux Qualcomm crypto modules. + +=============== +IMPORTANT NOTE: +=============== +(1) The CE hardware can be accessed either from user space OR kernel space, + at one time. Both user space and kernel space clients cannot access the + qce driver (and the CE hardware) at the same time. + - If your device has user space apps that needs to access the crypto + hardware, make sure to have the qcrypto module disabled/unloaded. + This will result in the kernel space apps to use the registered + software implementation of the crypto algorithms. + - If your device has kernel space apps that needs to access the + crypto hardware, make sure to have qcedev module disabled/unloaded + and implement your user space application to use the software + implemenation (ex: openssl/crypto) of the crypto algorithms. + +(2) If your device has Playready(Windows Media DRM) application enabled and + uses the qcedev module to access the crypto hardware accelarator, + please be informed that for performance reasons, the CE hardware will need + to be dedicated to playready application. Any other user space application + should be implemented to use the software implemenation (ex: openssl/crypto) + of the crypto algorithms. + + +Hardware description: +===================== + +Qualcomm Crypto HW device family provides a series of algorithms implemented +in the device hardware. + +Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES +algorithms, and concurrent operations of hashing, and ciphering. + +In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides +fast AES algorithms. + +In addition to those functions provided by Crypto 3 HW, Crypto 3E provides +HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as +defined by the 3GPP forum. + + +Software description +==================== + +The crypto device is defined as a platform device. The driver is +independent of the platform. The driver supports multiple instances of +crypto HW. +All the platform specific parameters are defined in the board init +file, eg. arch/arm/mach-msm/board-msm7x30.c for MSM7x30. + +The qce driver provide the common services of HW crypto +access to the two drivers as listed above (qcedev, qcrypto. It sets up +the crypto HW device for the operation, then it requests ADM driver for +the DMA of the crypto operation. + +Two ADM channels and two command lists (one command list for each +channel) are involved in an operation. + +The setting up of the command lists and the procedure of the operation +of the crypto device are described in the following sections. + +The command list for the first DMA channel is set up as follows: + + 1st command of the list is for the DMA transfer from DDR memory to the + crypto device to input data to crypto device. The dst crci of the command + is set for crci-in for this crypto device. + + 2nd command is for the DMA tansfer is from crypto device to DDR memory for + the authentication result. The src crci is set as crci-hash-done of the + crypto device. If authentication is not required in the operation, + the 2nd command is not used. + +The command list for the second DMA channel is set up as follows: + + One command to DMA data from crypto device to DDR memory for encryption or + decryption output from crypto device. + +To accomplish ciphering and authentication concurrent operations, the driver +performs the following steps: + (a). set up HW crypto device + (b). hit the crypto go register. + (c). issue the DMA command of first channel to the ADM driver, + (d). issue the DMA command of 2nd channel to the ADM driver. + +SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish +hash operation (or any authentication only algorithm), 2nd DMA channel is +not required. Only steps (a) to (c) are performed. + +At the completion of the DMA operation (for (c) and (d)) ADM driver +invokes the callback registered to the DMA driver. This signifies the end of +the DMA operation(s). The driver reads the status and other information from +the CE hardware register and then invokes the callback to the qce driver client. +This signal the completion and the results of the DMA along with the status of +the CE hardware to the qce driver client. This completes a crypto operation. + +In the qce driver initialization, memory for the two command lists, descriptor +lists for each crypto device are allocated out of coherent memory, using Linux +DMA API. The driver pre-configures most of the two ADM command lists +in the initialization. During each crypto operation, minimal set up is required. +src_dscr or/and dst_dscr descriptor list of the ADM command are populated +from the information obtained from the corresponding data structure. eg: for +AEAD request, the following data structure provides the information: + + struct aead_request *req + ...... + req->assoc + req->src + req->dst + +The DMA address of a scatter list will be retrieved and set up in the +descriptor list of an ADM command. + +Power Management +================ + none + + +Interface: +========== + +The interface is defined in kernel/drivers/crypto/msm/inc/qce.h + +The clients qcrypto, qcedev drivers are the clients using +the interfaces. + +The following services are provided by the qce driver - + + qce_open(), qce_close(), qce_ablk_cipher_req(), + qce_hw_support(), qce_process_sha_req() + + qce_open() is the first request from the client, ex. Qualcomm crypto + driver (qcedev, qcrypto), to open a crypto engine. It is normally + called at the probe function of the client for a device. During the + probe, + - ADM command list structure will be set up + - Crypto device will be initialized. + - Resource associated with the crypto engine is retrieved by doing + platform_get_resource() or platform_get_resource_byname(). + + The resources for a device are + - crci-in, crci-out, crci-hash-done + - two DMA channel IDs, one for encryption and decryption input, one for + output. + - base address of the HW crypto device. + + qce_close() is the last request from the client. Normally, it is + called from the remove function of the client. + + qce_hw_support() allows the client to query what is supported + by the crypto engine hardware. + + qce_ablk_cipher_req() provides ciphering service to the client. + qce_process_sha_req() provide hashing service to the client. + qce_aead_req() provide aead service to the client. + +Module parameters: +================== + +The following module parameters are defined in the board init file. +-CE hardware nase register address +-Data mover channel used for transfer to/from CE hardware +These parameters differ in each platform. + + +Dependencies: +============= + +Existing DMA driver. +The transfers are DMA'ed between the crypto hardware and DDR memory via the +data mover, ADM. The data transfers are set up to use the existing dma driver. + +User space utilities: +===================== + n/a + +Known issues: +============= + n/a + +To do: +====== + n/a diff --git a/Documentation/crypto/msm/qce40.txt b/Documentation/crypto/msm/qce40.txt new file mode 100644 index 000000000000..e99f7d7ef6cf --- /dev/null +++ b/Documentation/crypto/msm/qce40.txt @@ -0,0 +1,241 @@ +Introduction: +============= + +The Qualcomm crypto engine (qce40) driver is a module that +provides common services for accessing the Qualcomm crypto device. +Currently, the two main clients of qce40 are +-qcrypto driver (module provided for accessing CE HW by kernel space apps) +-qcedev driver (module provided for accessing CE HW by user space apps) +This module provides the same interface to the clients as does qce.c and is +based off qce.c. Following are the updates from qce.c +- Add support for AES XTS mode +- Add support for CMAC mode +- Add support for AES CCM mode +- Add support for SHA1/SHA256 HMAC +- Read HASH/MAC information directly from CE hardware registers instead of + using datamover. + +The crypto engine (qce40) module is a client to the DMA driver for the Qualcomm +DMA device - Application Data Mover (ADM). ADM is used to provide the DMA +transfer capability between Qualcomm crypto device hardware and DDR memory +for crypto operations. + + Figure 1. + --------- + + Linux kernel + (ex:IPSec)<--*Qualcomm crypto driver----+ + (qcrypto) | + (for kernel space app) | + | + +-->| + | + | *qce40 <----> Qualcomm + | driver ADM driver <---> ADM HW + +-->| | | + | | | + | | | + | | | + Linux kernel | | | + misc device <--- *QCEDEV Driver-------+ | | + interface (qcedev) (Reg interface) (DMA interface) + (for user space app) \ / + \ / + \ / + \ / + \ / + \ / + \ / + Qualcomm crypto CE3 HW + + + The entities marked with (*) in the Figure 1, are the software components of + the Linux Qualcomm crypto modules. + +=============== +IMPORTANT NOTE: +=============== +(1) The CE hardware can be accessed either from user space OR kernel space, + at one time. Both user space and kernel space clients cannot access the + qce driver (and the CE hardware) at the same time. + - If your device has user space apps that needs to access the crypto + hardware, make sure to have the qcrypto module disabled/unloaded. + This will result in the kernel space apps to use the registered + software implementation of the crypto algorithms. + - If your device has kernel space apps that needs to access the + crypto hardware, make sure to have qcedev module disabled/unloaded + and implement your user space application to use the software + implemenation (ex: openssl/crypto) of the crypto algorithms. + +(2) If your device has Playready(Windows Media DRM) application enabled and + uses the qcedev module to access the crypto hardware accelarator, + please be informed that for performance reasons, the CE hardware will need + to be dedicated to playready application. Any other user space application + should be implemented to use the software implemenation (ex: openssl/crypto) + of the crypto algorithms. + + +Hardware description: +===================== + +Qualcomm Crypto HW device family provides a series of algorithms implemented +in the device hardware. + +Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES +algorithms, and concurrent operations of hashing and ciphering. + +In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides +fast AES algorithms. + +In addition to those functions provided by Crypto 3 HW, Crypto 3E provides +HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as +defined by the 3GPP forum. + + +Software description +==================== + +The crypto device is defined as a platform device. The driver is +independent of the platform. The driver supports multiple instances of +crypto HW. +All the platform specific parameters are defined in the board init +file, eg. arch/arm/mach-msm/board-msm8960.c for MSM8960. + +The qce40 driver provide the common services of HW crypto +access to the two drivers as listed above (qcedev, qcrypto. It sets up +the crypto HW device for the operation, then it requests ADM driver for +the DMA of the crypto operation. + +Two ADM channels and two command lists (one command list for each +channel) are involved in an operation. + +The setting up of the command lists and the procedure of the operation +of the crypto device are described in the following sections. + +The command lists contains a single command. For the first DMA channel it +is set up as follows: + + The command is for the DMA transfer from DDR memory to the + crypto device to input data to crypto device. The dst crci of the command + is set for crci-in for this crypto device. + +The command list for the second DMA channel is set up as follows: + + One command to DMA data from crypto device to DDR memory for encryption or + decryption output from crypto device. + +To accomplish ciphering and authentication concurrent operations, the driver +performs the following steps: + (a). set up HW crypto device + (b). hit the crypto go register. + (c). issue the DMA command of first channel to the ADM driver, + (d). issue the DMA command of 2nd channel to the ADM driver. + +SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish +hash operation (or any authentication only algorithm), 2nd DMA channel is +not required. Only steps (a) to (c) are performed. + +At the completion of the DMA operation (for (c) and (d)) ADM driver +invokes the callback registered to the DMA driver. This signifies the end of +the DMA operation(s). The driver reads the status and other information from +the CE hardware register. For HASH functions (SHA1/SHA256, HMAC, CMAC and +CCM) were the MAC/HASH information is read off hardware registers. + +[ NOTE: This is different from what is done in the qce module that support +CE3.x hardware. In CE4.0 there is not CRCI_HASH and hence we cannot rely +on the data mover to populate the HMAC/SHA information. This information +is acquired fromte h ahrdware by reading directly from some registers that +hold this information ] + +The driver than nvokes the callback to the qce driver client. +This signal the completion and the results of the DMA along with the status of +the CE hardware to the qce40 driver client. This completes a crypto operation. + +In the qce40 driver initialization, memory for the two command lists, descriptor +lists for each crypto device are allocated out of coherent memory, using Linux +DMA API. The driver pre-configures most of the two ADM command lists +in the initialization. During each crypto operation, minimal set up is required. +src_dscr or/and dst_dscr descriptor list of the ADM command are populated +from the information obtained from the corresponding data structure. eg: for +AEAD request, the following data structure provides the information: + + struct aead_request *req + ...... + req->assoc + req->src + req->dst + +The DMA address of a scatter list will be retrieved and set up in the +descriptor list of an ADM command. + +Power Management +================ + none + + +Interface: +========== + +The interface is defined in kernel/drivers/crypto/msm/inc/qce.h + +The clients qcrypto, qcedev drivers are the clients using +the interfaces. + +The following services are provided by the qce driver - + + qce_open(), qce_close(), qce_ablk_cipher_req(), + qce_hw_support(), qce_process_sha_req() + + qce_open() is the first request from the client, ex. Qualcomm crypto + driver (qcedev, qcrypto), to open a crypto engine. It is normally + called at the probe function of the client for a device. During the + probe, + - ADM command list structure will be set up + - Crypto device will be initialized. + - Resource associated with the crypto engine is retrieved by doing + platform_get_resource() or platform_get_resource_byname(). + + The resources for a device are + - crci-in, crci-out, crci-hash-done + - two DMA channel IDs, one for encryption and decryption input, one for + output. + - base address of the HW crypto device. + + qce_close() is the last request from the client. Normally, it is + called from the remove function of the client. + + qce_hw_support() allows the client to query what is supported + by the crypto engine hardware. + + qce_ablk_cipher_req() provides ciphering service to the client. + qce_process_sha_req() provides hashing service to the client. + qce_aead_req() provides aead service to the client. + + +Module parameters: +================== + +The following module parameters are defined in the board init file. +-CE hardware base register address +-Data mover channel used for transfer to/from CE hardware +These parameters differ in each platform. + + +Dependencies: +============= + +Existing DMA driver. +The transfers are DMA'ed between the crypto hardware and DDR memory via the +data mover, ADM. The data transfers are set up to use the existing dma driver. + +User space utilities: +===================== + n/a + +Known issues: +============= + n/a + +To do: +====== + n/a diff --git a/Documentation/crypto/msm/qcedev.txt b/Documentation/crypto/msm/qcedev.txt new file mode 100644 index 000000000000..fde69bbed7c0 --- /dev/null +++ b/Documentation/crypto/msm/qcedev.txt @@ -0,0 +1,232 @@ +Introduction: +============= + +This driver provides IOCTLS for user space application to access crypto +engine hardware for the qcedev crypto services. The driver supports the +following crypto algorithms +- AES-128, AES-256 (ECB, CBC and CTR mode) +- AES-192, (ECB, CBC and CTR mode) + (support exists on platform supporting CE 3.x hardware) +- SHA1/SHA256 +- AES-128, AES-256 (XTS), AES CMAC, SHA1/SHA256 HMAC + (support exists on platform supporting CE 4.x hardware) + +Hardware description: +===================== +Crypto 3E provides cipher and hash algorithms as defined in the +3GPP forum specifications. + + +Software description +==================== + +The driver is a Linux platform device driver. For an msm target, +there can be multiple crypto devices assigned for QCEDEV. + +The driver is a misc device driver as well. +The following operations are registered in the driver, +-qcedev_ioctl() +-qcedev_open() +-qcedev_release() + +The following IOCTLS are available to the user space application(s)- + + Cipher IOCTLs: + -------------- + QCEDEV_IOCTL_ENC_REQ is for encrypting data. + QCEDEV_IOCTL_DEC_REQ is for decrypting data. + + Hashing/HMAC IOCTLs + ------------------- + + QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request. + QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac. + QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request. + QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data + packet of known size. + QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC + algorithm) for data packet of known size. + +The requests are synchronous. The driver will put the process to +sleep, waiting for the completion of the requests using wait_for_completion(). + +Since the requests are coming out of user space application, before giving +the requests to the low level qce driver, the ioctl requests and the +associated input/output buffer will have to be safe checked, and copied +to/from kernel space. + +The extra copying of requests/buffer can affect the performance. The issue +with copying the data buffer is resolved by having the client use PMEM +allocated buffers. + +NOTE: Using memory allocated via PMEM is supported only for in place + operations where source and destination buffers point to the same + location. Support for different source and destination buffers + is not supported currently. + Furthermore, when using PMEM, and in AES CTR mode, when issuing an + encryption or decryption request, a non-zero byteoffset is not + supported. + +The design of the driver is to allow multiple open, and multiple requests +to be issued from application(s). Therefore, the driver will internally queue +the requests, and serialize the requests to the low level qce (or qce40) driver. + +On an IOCTL request from an application, if there is no outstanding +request, a the driver will issue a "qce" request, otherwise, +the request is queued in the driver queue. The process is suspended +waiting for completion. + +On completion of a request by the low level qce driver, the internal +tasklet (done_tasklet) is scheduled. The sole purpose of done_tasklet is +to call the completion of the current active request (complete()), and +issue more requests to the qce, if any. +When the process wakes up from wait_for_completion(), it will collect the +return code, and return the ioctl. + +A spin lock is used to protect the critical section of internal queue to +be accessed from multiple tasks, SMP, and completion callback +from qce. + +The driver maintains a set of statistics using debug fs. The files are +in /debug/qcedev/stats1, /debug/qcedev/stats2, /debug/qcedev/stats3; +one for each instance of device. Reading the file associated with +a device will retrieve the driver statistics for that device. +Any write to the file will clear the statistics. + + +Power Management +================ +n/a + + +Interface: +========== + +Linux user space applications will need to open a handle +(file desrciptor) to the qcedev device. This is achieved by doing +the following to retrieve a file desrciptor to the device. + + fd = open("/dev/qce", O_RDWR); + .. + ioctl(fd, ...); + +Once a valid fd is retrieved, user can call the following ioctls with +the fd as the first parameter and a pointer to an appropriate data +structure, qcedev_cipher_op_req or qcedev_sha_op_req (depending on +cipher/hash functionality) as the second parameter. + +The following IOCTLS are available to the user space application(s)- + + Cipher IOCTLs: + -------------- + QCEDEV_IOCTL_ENC_REQ is for encrypting data. + QCEDEV_IOCTL_DEC_REQ is for decrypting data. + + The caller of the IOCTL passes a pointer to the structure shown + below, as the second parameter. + + struct qcedev_cipher_op_req { + int use_pmem; + union{ + struct qcedev_pmem_info pmem; + struct qcedev_vbuf_info vbuf; + }; + uint32_t entries; + uint32_t data_len; + uint8_t in_place_op; + uint8_t enckey[QCEDEV_MAX_KEY_SIZE]; + uint32_t encklen; + uint8_t iv[QCEDEV_MAX_IV_SIZE]; + uint32_t ivlen; + uint32_t byteoffset; + enum qcedev_cipher_alg_enum alg; + enum qcedev_cipher_mode_enum mode; + enum qcedev_oper_enum op; + }; + + Hashing/HMAC IOCTLs + ------------------- + + QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request. + QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac. + QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request. + QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data + packet of known size. + QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC + algorithm) for data packet of known size. + + The caller of the IOCTL passes a pointer to the structure shown + below, as the second parameter. + + struct qcedev_sha_op_req { + struct buf_info data[QCEDEV_MAX_BUFFERS]; + uint32_t entries; + uint32_t data_len; + uint8_t digest[QCEDEV_MAX_SHA_DIGEST]; + uint32_t diglen; + uint8_t *authkey; + uint32_t authklen; + enum qcedev_sha_alg_enum alg; + struct qcedev_sha_ctxt ctxt; + }; + +The IOCTLs and associated request data structures are defined in + kernel/drivers/crypto/msm/inc/qcedev.h.. + + +Module parameters: +================== + +The following module parameters are defined in the board init file. +-CE hardware nase register address +-Data mover channel used for transfer to/from CE hardware +These parameters differ in each platform. + + + +Dependencies: +============= +qce driver. Please see Documentation/arm/msm/qce.txt. + + +User space utilities: +===================== + +none + +Known issues: +============= + +none. + + +To do: +====== + Enhance Cipher functionality: + (1) Add support for handling > 32KB for ciphering functionality when + - operation is not an "in place" operation (source != destination). + (when using PMEM allocated memory) + +Limitations: +============ + (1) In case of cipher functionality, Driver does not support + a combination of different memory sources for source/destination. + In other words, memory pointed to by src and dst, + must BOTH (src/dst) be "pmem" or BOTH(src/dst) be "vbuf". + + (2) In case of hash functionality, driver does not support handling data + buffers allocated via PMEM. + + (3) Do not load this driver if your device already has kernel space apps + that need to access the crypto hardware. + Make sure to have qcedev module disabled/unloaded and implement your user + space application to use the software implemenation (ex: openssl/crypto) + of the crypto algorithms. + (NOTE: Please refer to details on the limitations listed in qce.txt) + + (4) If your device has Playready (Windows Media DRM) application enabled + and uses the qcedev module to access the crypto hardware accelarator, + please be informed that for performance reasons, the CE hardware will + need to be dedicated to playready application. Any other user space + application should be implemented to use the software implemenation + (ex: openssl/crypto) of the crypto algorithms. diff --git a/Documentation/crypto/msm/qcrypto.txt b/Documentation/crypto/msm/qcrypto.txt new file mode 100644 index 000000000000..81aa1941e157 --- /dev/null +++ b/Documentation/crypto/msm/qcrypto.txt @@ -0,0 +1,144 @@ +Introduction: +============= + +Qualcomm Crypto (qcrypto) driver is a Linux crypto driver which interfaces +with the Linux kernel crypto API layer to provide the HW crypto functions. +This driver is accessed by kernel space apps via the kernel crypto API layer. +At present there is no means for user space apps to access this module. + +Hardware description: +===================== + +Qualcomm Crypto HW device family provides a series of algorithms implemented +in the device. + +Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES +algorithms, and concurrent operations of hashing, and ciphering. + +In addition to those functions provided by Crypto 2 HW, Crypto 3 provides fast +AES algorithms. + +In addition to those functions provided by Crypto 3 HW, Crypto 3E provides +HMAC-SHA1 hashing algorithm. + +In addition to those functions provided by Crypto 3 HW, Crypto 4.0 provides +HMAC-SHA1/SHA256, AES CBC-MAC hashing algorithm and AES XTS/CCM cipher +algorithms. + + +Software description +==================== + +The module init function (_qcrypto_init()), does a platform_register(), +to register the driver. As the result, the driver probe function, +_qcrypto_probe(), will be invoked for each registered device. + +In the probe function, driver opens the low level CE (qce_open), and +registers the supported algorithms to the kernel crypto API layer. +Currently, qcrypto supports the following algorithms. + + ablkcipher - + cbc(aes),ecb(aes),ctr(aes) + ahash - + sha1, sha256 + aead - + authenc(hmac(sha1),cbc(aes)) + + The hmac(sha1), hmac(sha256, authenc(hmac(sha1),cbc(aes)), ccm(aes) + and xts(aes) algorithms are registered for some platforms that + support these in the CE hardware + +The HW device can support various algorithms. However, the most important +algorithms to gain the performance using a HW crypto accelerator are +AEAD, and ABLKCIPHER. + +AEAD stands for "authentication encryption with association data". +ABLKCIPHER stands of "asynchronous block cipher". + +The AEAD structure is described in the following header file + LINUX/opensource/kernel/include/crypto/aead.h + +The design of the driver is to allow multiple requests +issued from kernel client SW (eg IPSec). +Therefore, the driver will have to internally queue the requests, and +serialize the requests to the low level qce driver. + +When a request is received from the client, if there is no outstanding +request, a qce (or qce40) request is issued, otherwise, the request is +queued in the driver queue. + +On completion of a request, the qce (or qce40) invokes the registered +callback from the qcrypto. The internal tasklet (done_tasklet) is scheduled +in this callback function. The sole purpose of done_tasklet is +to call the completion of the current active request, and +issue more requests to the qce (or qce40), if any exists. + +A spin lock is used to protect the critical section of internal queue to +be accessed from multiple tasks, SMP, and completion callback +from qce. + +The driver maintains a set of statistics using debug fs. The files are +in /debug/qcrypto/stats1, /debug/qcrypto/stats2, /debug/qcrypto/stats3; +one for each instance of device. Reading the file associated with +a device will retrieve the driver statistics for that device. +Any write to the file will clear the statistics. + +Test vectors for authenc(hmac(sha1),cbc(aes)) algorithm are +developed offline, and imported to crypto/testmgr.c, and crypto/testmgr.h. + + +Power Management +================ + none + + +Interface: +========== +The kernel interface is defined in + LINUX/opensource/kernel/include/linux/crypto.h. + + +Module parameters: +================== + +All the platform specific parameters are defined in the board init +file, eg. arch/arm/mach-msm/board-mssm7x30.c for msm7x30. + +Dependencies: +============= +qce driver. + + +User space utilities: +===================== + n/a + +Known issues: +============= + n/a + +To do: +====== + Add Hashing algorithms. + + +Limitations: +=============== +(1) Each packet transfer size (for cipher and hash) is limited to maximum of + 32KB. This is a limitation in the crypto engine hardware. Client will + have to break packets larger than 32KB into multiple requests of smaller + size data packets. + +(2) Do not load this driver if your device has user space apps that needs to + access the crypto hardware. Please make sure to have the qcrypto module + disabled/unloaded. + Not having the driver loaded, will result in the kernel space apps to use + the registered software implementation of the crypto algorithms. + +(3) If your device has Playready application enabled and uses the qcedev module + to access the crypto hardware accelarator, please be informed that for + performance reasons, the CE hardware will need to be dedicated to playready + application. Any other user space or kernel application should be implemented + to use the software implemenation of the crypto algorithms. + + (NOTE: Please refer to details on the limitations listed in qce/40.txt) diff --git a/Documentation/device-mapper/boot.txt b/Documentation/device-mapper/boot.txt new file mode 100644 index 000000000000..adcaad5e5e32 --- /dev/null +++ b/Documentation/device-mapper/boot.txt @@ -0,0 +1,42 @@ +Boot time creation of mapped devices +=================================== + +It is possible to configure a device mapper device to act as the root +device for your system in two ways. + +The first is to build an initial ramdisk which boots to a minimal +userspace which configures the device, then pivot_root(8) in to it. + +For simple device mapper configurations, it is possible to boot directly +using the following kernel command line: + +dm="<name> <uuid> <ro>,table line 1,...,table line n" + +name = the name to associate with the device + after boot, udev, if used, will use that name to label + the device node. +uuid = may be 'none' or the UUID desired for the device. +ro = may be "ro" or "rw". If "ro", the device and device table will be + marked read-only. + +Each table line may be as normal when using the dmsetup tool except for +two variations: +1. Any use of commas will be interpreted as a newline +2. Quotation marks cannot be escaped and cannot be used without + terminating the dm= argument. + +Unless renamed by udev, the device node created will be dm-0 as the +first minor number for the device-mapper is used during early creation. + +Example +======= + +- Booting to a linear array made up of user-mode linux block devices: + + dm="lroot none 0, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \ + root=/dev/dm-0 + +Will boot to a rw dm-linear target of 8192 sectors split across two +block devices identified by their major:minor numbers. After boot, udev +will rename this target to /dev/mapper/lroot (depending on the rules). +No uuid was assigned. diff --git a/Documentation/device-mapper/verity.txt b/Documentation/device-mapper/verity.txt index e15bc1a0fb98..89fd8f9a259f 100644 --- a/Documentation/device-mapper/verity.txt +++ b/Documentation/device-mapper/verity.txt @@ -18,11 +18,11 @@ Construction Parameters 0 is the original format used in the Chromium OS. The salt is appended when hashing, digests are stored continuously and - the rest of the block is padded with zeros. + the rest of the block is padded with zeroes. 1 is the current format that should be used for new devices. The salt is prepended when hashing and each digest is - padded with zeros to the power of two. + padded with zeroes to the power of two. <dev> This is the device containing data, the integrity of which needs to be @@ -79,6 +79,37 @@ restart_on_corruption not compatible with ignore_corruption and requires user space support to avoid restart loops. +ignore_zero_blocks + Do not verify blocks that are expected to contain zeroes and always return + zeroes instead. This may be useful if the partition contains unused blocks + that are not guaranteed to contain zeroes. + +use_fec_from_device <fec_dev> + Use forward error correction (FEC) to recover from corruption if hash + verification fails. Use encoding data from the specified device. This + may be the same device where data and hash blocks reside, in which case + fec_start must be outside data and hash areas. + + If the encoding data covers additional metadata, it must be accessible + on the hash device after the hash blocks. + + Note: block sizes for data and hash devices must match. Also, if the + verity <dev> is encrypted the <fec_dev> should be too. + +fec_roots <num> + Number of generator roots. This equals to the number of parity bytes in + the encoding data. For example, in RS(M, N) encoding, the number of roots + is M-N. + +fec_blocks <num> + The number of encoding data blocks on the FEC device. The block size for + the FEC device is <data_block_size>. + +fec_start <offset> + This is the offset, in <data_block_size> blocks, from the start of the + FEC device to the beginning of the encoding data. + + Theory of operation =================== @@ -98,6 +129,11 @@ per-block basis. This allows for a lightweight hash computation on first read into the page cache. Block hashes are stored linearly, aligned to the nearest block size. +If forward error correction (FEC) support is enabled any recovery of +corrupted data will be verified using the cryptographic hash of the +corresponding data. This is why combining error correction with +integrity checking is essential. + Hash Tree --------- diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt new file mode 100644 index 000000000000..a9594f026506 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cache.txt @@ -0,0 +1,195 @@ +========================================== +ARM processors cache binding description +========================================== + +Device tree bindings for ARM processor caches adhere to the cache bindings +described in [3], in section 3.8 for multi-level and shared caches. +On ARM based systems most of the cache properties related to cache +geometry are probeable in HW, hence, unless otherwise stated, the properties +defined in ePAPR for multi-level and shared caches are to be considered +optional by default. + +On ARM, caches are either architected (directly controlled by the processor +through coprocessor instructions and tightly coupled with the processor +implementation) or unarchitected (controlled through a memory mapped +interface, implemented as a stand-alone IP external to the processor +implementation). + +This document provides the device tree bindings for ARM architected caches. + +- ARM architected cache node + + Description: must be a direct child of the cpu node. A system + can contain multiple architected cache nodes per cpu node, + linked through the next-level-cache phandle. The + next-level-cache property in the cpu node points to + the first level of architected cache for the CPU. + The next-level-cache property in architected cache nodes + points to the respective next level of caching in the + hierarchy. An architected cache node with an empty or + missing next-level-cache property represents the last + architected cache level for the CPU. + On ARM v7 and v8 architectures, the order in which cache + nodes are linked through the next-level-cache phandle must + follow the ordering specified in the processors CLIDR (v7) + and CLIDR_EL1 (v8) registers, as described in [1][2], + implying that a cache node pointed at by a + next-level-cache phandle must correspond to a level + defined in CLIDR (v7) and CLIDR_EL1 (v8) greater than the + one the cache node containing the next-level-cache + phandle corresponds to. + + Since on ARM most of the cache properties are probeable in HW the + properties described in [3] - section 3.8 multi-level and shared + caches - shall be considered optional, with the following properties + updates, specific for the ARM architected cache node. + + - compatible + Usage: Required + Value type: <string> + Definition: value shall be "arm,arch-cache". + + - interrupts + Usage: Optional + Value type: See definition + Definition: standard device tree property [3] that defines + the interrupt line associated with the cache. + The property can be accompanied by an + interrupt-names property, as described in [4]. + + - power-domain + Usage: Optional + Value type: phandle + Definition: A phandle and power domain specifier as defined by + bindings of power controller specified by the + phandle [5]. + + - qcom,dump-size + Usage: Optional + Value type: <integer> + Definition: The memory size needed to contain a copy of the + cache data and associated tag ram. + size = nways * nsets * (bytes per cache line + + bytes tag ram per line) + +Example(dual-cluster big.LITTLE system 32-bit) + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + next-level-cache = <&L1_0>; + + L1_0: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_0>; + }; + + L2_0: l2-cache { + compatible = "arm,arch-cache"; + }; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + next-level-cache = <&L1_1>; + + L1_1: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_0>; + }; + }; + + cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x2>; + next-level-cache = <&L1_2>; + + L1_2: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_0>; + }; + }; + + cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x3>; + next-level-cache = <&L1_3>; + + L1_3: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_0>; + }; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + next-level-cache = <&L1_4>; + + L1_4: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_1>; + }; + + L2_1: l2-cache { + compatible = "arm,arch-cache"; + }; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + next-level-cache = <&L1_5>; + + L1_5: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_1>; + }; + }; + + cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + next-level-cache = <&L1_6>; + + L1_6: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_1>; + }; + }; + + cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + next-level-cache = <&L1_7>; + + L1_7: l1-cache { + compatible = "arm,arch-cache"; + next-level-cache = <&L2_1>; + }; + }; + }; + +[1] ARMv7-AR Reference Manual + http://infocenter.arm.com/help/index.jsp +[2] ARMv8-A Reference Manual + http://infocenter.arm.com/help/index.jsp +[3] ePAPR standard + https://www.power.org/documentation/epapr-version-1-1/ +[4] Kernel documentation - resource property bindings + Documentation/devicetree/bindings/resource-names.txt +[5] Kernel documentation - power domain bindings + Documentation/devicetree/bindings/power/power_domain.txt diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index 62938eb9697f..45d052ad0ada 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -19,6 +19,7 @@ its hardware characteristcs. - "arm,coresight-etm3x", "arm,primecell"; - "arm,coresight-etm4x", "arm,primecell"; - "qcom,coresight-replicator1x", "arm,primecell"; + - "arm,coresight-stm", "arm,primecell"; * reg: physical base address and length of the register set(s) of the component. @@ -36,15 +37,30 @@ its hardware characteristcs. layout using the generic DT graph presentation found in "bindings/graph.txt". + * coresight-name: unique descriptive name of the component. + * Required properties for devices that don't show up on the AMBA bus, such as non-configurable replicators: - * compatible: Currently supported value is (note the absence of the + * compatible: Currently supported values are (note the absence of the AMBA markee): - "arm,coresight-replicator" + - "qcom,coresight-csr" + - "arm,coresight-cti" + - "qcom,coresight-tpda" + - "qcom,coresight-tpdm" + - "qcom,coresight-remote-etm" + - "qcom,coresight-qpdi" + - "qcom,coresight-hwevent" + - "qcom,coresight-dummy" * port or ports: same as above. + * coresight-name: unique descriptive name of the component. + +* Optional properties for all components: + * reg-names: names corresponding to each reg property value. + * Optional properties for ETM/PTMs: * arm,cp14: must be present if the system accesses ETM/PTM management @@ -58,6 +74,55 @@ its hardware characteristcs. * arm,buffer-size: size of contiguous buffer space for TMC ETR (embedded trace router) + * arm,default-sink: represents the default compile time CoreSight sink + + * coresight-ctis: represents flush and reset CTIs for TMC buffer + + * qcom,force-reg-dump: enables TMC reg dump support + + * arm,sg-enable : indicates whether scatter gather feature is enabled + by default for TMC ETR configuration. + +* Required property for TPDAs: + + * qcom,tpda-atid: must be present. Specifies the ATID for TPDA. + +* Optional properties for TPDAs: + + * qcom,bc-elem-size: specifies the BC element size supported by each + monitor connected to the aggregator on each port. Should be specified + in pairs (port, bc element size). + + * qcom,tc-elem-size: specifies the TC element size supported by each + monitor connected to the aggregator on each port. Should be specified + in pairs (port, tc element size). + + * qcom,dsb-elem-size: specifies the DSB element size supported by each + monitor connected to the aggregator on each port. Should be specified + in pairs (port, dsb element size). + + * qcom,cmb-elem-size: specifies the CMB element size supported by each + monitor connected to the aggregator on each port. Should be specified + in pairs (port, cmb element size). + +* Optional properties for TPDM: + + * qcom,clk-enable: specifies whether additional clock bit needs to be + set for M4M TPDM. + + * qcom,msr-fix-req: boolean, indicating if MSRs need to be programmed + after enabling the subunit. + +* Required property for Remote ETMs: + + * qcom,inst-id: must be present. QMI instance id for remote ETMs. + +* Optional properties for QPDI: + + * qcom,pmic-carddetect-gpio: indicates the hotplug capabilities of the + qpdi driver + + * qcom,skip-ldo: set to skip LDO management. Example: @@ -174,6 +239,42 @@ Example: }; }; + tpda_mss: tpda@7043000 { + compatible = "qcom,coresight-tpda"; + reg = <0x7043000 0x1000>; + reg-names = "tpda-base"; + + coresight-name = "coresight-tpda-mss"; + + qcom,tpda-atid = <67>; + qcom,dsb-elem-size = <0 32>; + qcom,cmb-elem-size = <0 32>; + + clocks = <&clock_gcc clk_qdss_clk>, + <&clock_gcc clk_qdss_a_clk>; + clock-names = "core_clk", "core_a_clk"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + tpda_mss_out_funnel_in1: endpoint { + remote-endpoint = + <&funnel_in1_in_tpda_mss>; + }; + }; + port@1 { + reg = <0>; + tpda_mss_in_tpdm_mss: endpoint { + slave-mode; + remote-endpoint = + <&tpdm_mss_out_tpda_mss>; + }; + }; + }; + }; + 3. Sources ptm@2201c000 { compatible = "arm,coresight-etm3x", "arm,primecell"; @@ -202,3 +303,55 @@ Example: }; }; }; + + stm: stm@6002000 { + compatible = "arm,coresight-stm", "arm,primecell"; + arm,primecell-periphid = <0x0003b962>; + + reg = <0x6002000 0x1000>, + <0x16280000 0x180000>; + reg-names = "stm-base", "stm-data-base"; + + coresight-name = "coresight-stm"; + + clocks = <&clock_gcc clk_qdss_clk>, + <&clock_gcc clk_qdss_a_clk>; + clock-names = "apb_pclk", "core_a_clk"; + + port{ + stm_out_funnel_in0: endpoint { + remote-endpoint = <&funnel_in0_in_stm>; + }; + }; + }; + + tpdm_mss: tpdm@7042000 { + compatible = "qcom,coresight-tpdm"; + reg = <0x7042000 0x1000>; + reg-names = "tpdm-base"; + + coresight-name = "coresight-tpdm-mss"; + + clocks = <&clock_gcc clk_qdss_clk>, + <&clock_gcc clk_qdss_a_clk>; + clock-names = "core_clk", "core_a_clk"; + + port{ + tpdm_mss_out_tpda_mss: endpoint { + remote-endpoint = <&tpda_mss_in_tpdm_mss>; + }; + }; + }; + +4. CTIs + cti0: cti@6010000 { + compatible = "arm,coresight-cti"; + reg = <0x6010000 0x1000>; + reg-names = "cti-base"; + + coresight-name = "coresight-cti0"; + + clocks = <&clock_gcc clk_qdss_clk>, + <&clock_gcc clk_qdss_a_clk>; + clock-names = "core_clk", "core_a_clk"; + }; diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 3a07a87fef20..9a9c045dbf6a 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -212,6 +212,20 @@ nodes to be present and contain the properties described below. property identifying a 64-bit zero-initialised memory location. + - efficiency + Usage: optional. + Value type: <u32> + Definition: + # Specifies the CPU efficiency. The CPU efficiency is + a unit less number and it is intended to show relative + performance of CPUs when normalized for clock frequency + (instructions per cycle performance). + + The efficiency of a CPU can vary across SoCs depending + on the cache size, bus interconnect frequencies etc. + This value overrides the default efficiency value + defined for the corresponding CPU architecture. + - qcom,saw Usage: required for systems that have an "enable-method" property value of "qcom,kpss-acc-v1" or @@ -226,6 +240,13 @@ nodes to be present and contain the properties described below. Value type: <phandle> Definition: Specifies the ACC[2] node associated with this CPU. + - qcom,lmh-dcvs: + Usage: optional and only defined for those SoC's that support + LMH DCVS hardware block + Value type: <phandle> + Definition: Specifies the LMH device that is associated with + with this CPU. + - cpu-idle-states Usage: Optional Value type: <prop-encoded-array> diff --git a/Documentation/devicetree/bindings/arm/msm/acc.txt b/Documentation/devicetree/bindings/arm/msm/acc.txt new file mode 100644 index 000000000000..ae2d7253b363 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/acc.txt @@ -0,0 +1,19 @@ +Application Processor Sub-system (APSS) Application Clock Controller (ACC) + +The ACC provides clock, power domain, and reset control to a CPU. There is one ACC +register region per CPU within the APSS remapped region as well as an alias register +region that remaps accesses to the ACC associated with the CPU accessing the region. + +Required properties: +- compatible: Must be "qcom,arm-cortex-acc" +- reg: The first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + +Example: + + clock-controller@b088000 { + compatible = "qcom,arm-cortex-acc"; + reg = <0x0b088000 0x1000>, + <0x0b008000 0x1000>; + } diff --git a/Documentation/devicetree/bindings/arm/msm/acpuclock/clock-a7.txt b/Documentation/devicetree/bindings/arm/msm/acpuclock/clock-a7.txt new file mode 100644 index 000000000000..2da075b081ab --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/acpuclock/clock-a7.txt @@ -0,0 +1,45 @@ +* Qualcomm Application CPU clock driver + +clock-a7 is the driver for the Root Clock Generator (rcg) hw which controls +the cpu rate. RCGs support selecting one of several clock inputs, as well as +a configurable divider. This hw is different than normal rcgs in that it may +optionally have a register which encodes the maximum rate supported by hw. + +Required properties: +- compatible: "qcom,clock-a7-8226", "qcom,clock-a7-9630", + "qcom,clock-a53-8916", "qcom,clock-a7-vpipa", + "qcom,clock-a7-9640", "qcom,clock-a7-californium" + "qcom,clock-a7-9640", "qcom,clock-a7-mdm9607" +- reg: pairs of physical address and region size +- reg-names: "rcg-base" is expected +- clock-names: list of names of clock inputs +- qcom,speedX-bin-vZ: + A table of CPU frequency (Hz) to regulator voltage (uV) mapping. + Format: <freq uV> + This represents the max frequency possible for each possible + power configuration for a CPU that's binned as speed bin X, + speed bin revision Z. Speed bin values can be between [0-7] + and the version can be between [0-3]. + +- cpu-vdd-supply: regulator phandle for cpu power domain. + +Optional properties: +- reg-names: "efuse", "efuse1" +- qcom,safe-freq: Frequency in HZ + When switching rates from A to B, the mux div clock will + instead switch from A -> safe_freq -> B. +- qcom,enable-opp: This will allow to register the cpu clock with OPP + framework. + +Example: + qcom,acpuclk@f9011050 { + compatible = "qcom,clock-a7-8226"; + reg = <0xf9011050 0x8>; + reg-names = "rcg_base"; + cpu-vdd-supply = <&apc_vreg_corner>; + + clock-names = "clk-4", "clk-5"; + qcom,speed0-bin-v0 = + <384000000 1150000>, + <600000000 1200000>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/bam_dmux.txt b/Documentation/devicetree/bindings/arm/msm/bam_dmux.txt new file mode 100644 index 000000000000..ef40b72cacf1 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/bam_dmux.txt @@ -0,0 +1,28 @@ +Qualcomm Technologies, Inc. BAM Data Multiplexer Driver + +Required properties: +- compatible : should be "qcom,bam_dmux" +- reg : the location and size of the BAM hardware +- interrupts : the BAM hardware to apps processor interrupt line + +Optional properties: +-qcom,satellite-mode: the hardware needs to be configured in satellite mode +-qcom,rx-ring-size: the size of the receive ring buffer pool, default is 32 +-qcom,max-rx-mtu: the maximum receive MTU that can be negotiated, in bytes. + Default is 2048. Other possible values are 4096, 8192, and 16384. +-qcom,no-cpu-affinity: boolean value indicating that workqueue CPU affinity + is not required. +-qcom,fast-shutdown: boolean value to support fast shutdown time. + +Example: + + qcom,bam_dmux@fc834000 { + compatible = "qcom,bam_dmux"; + reg = <0xfc834000 0x7000>; + interrupts = <0 29 1>; + qcom,satellite-mode; + qcom,rx-ring-size = <64>; + qcom,max-rx-mtu = <8192>; + qcom,no-cpu-affinity; + qcom,fast-shutdown; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/bcl.txt b/Documentation/devicetree/bindings/arm/msm/bcl.txt new file mode 100644 index 000000000000..710c70a57840 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/bcl.txt @@ -0,0 +1,225 @@ +* Battery Current Limit + +This Battery Current Limit(BCL) device, provides an interface to detect and notify +interested applications when the SOC is drawing current in excess of the limits +specified. +The BCL driver has another operation mode, where it monitors the battery +current and voltage via ADC TM hardware called BTM. The newer devices support +a BTM hardware configuration, which can measure the battery current and voltage. +This ADC hardware is capable of sampling the sensor every 1 msec and interrupts +the BCL driver, which in turn mitigates the CPU frequency based on the +current load thresholds. The BCL drivers operation mode is decided based +on the parameters given in the device tree. In this BTM operation mode, BCL +driver provides sysfs entries to configure the thresholds, ADC polling +timer interval and other operational parameters. + +The device tree parameters for bcl are: + +Required parameters: +- compatible: Must be "qcom,bcl" + +Optional parameters: +- qcom,bcl-enable : If this property is defined, BCL functionality will + be enabled from boot. The mode of operation, will be based + on the properties defined in the device tree. +- qcom,ibat-vadc = <&vadc_phandle>: A phandle to the VADC device. The BTM mode + of operation requires this property to be defined if and only + if qcom,ibat-threshold-adc_tm and qcom,ibat-monitor are defined. + Error in any of these properties will disable BTM mode of operation + and will fall back to the available current monitor mode. +- qcom,ibat-threshold-adc_tm = <&vadc_tm_phandle>: A phandle to the ADC TM + device. BCL registers with the hardware monitor for this TM + device to be able to set thresholds and get threshold + notifications. The BTM mode of operation requires this property + to be defined if and only if qcom,ibat-vadc and qcom,ibat-monitor + are defined. Error in any of these properties will disable BTM + mode of operation and will fall back to the available current + monitor mode. +- qcom,bcl-framework-interface: If this property is defined, then the BCL uses + the BCL framework for monitoring battery voltage and current. + When this property is defined, the 'qcom,high-threshold-uamp', + 'qcom,low-threshold-uamp', 'qcom,vph-high-threshold-uv', + 'qcom,vph-low-threshold-uv' and 'qcom,thermal-handle' properties + should be defined in the 'qcom,ibat-monitor' node. +- qcom,bcl-hotplug-list = <hotplug-phandle-list>: List of phandles to the cores + that are to be hotplugged, when battery current limit condition + is reached. +- qcom,bcl-soc-hotplug-list: List of phandles to the cores that are to be hotplugged, + when battery SOC limit condition is reached. +- qcom,bcl-freq-control-list: This optional property takes list of phandles to the + cores that are to be frequency mitigated when BCL condition is + reached. When this property is defined, 'qcom,mitigation-freq-khz' + and 'qcom,thermal-handle' should be defined in the + 'qcom,ibat-monitor' node. +- qcom,bcl-no-bms: This is an optional node for BCL IAVAIL monitor mode. + If this property is defined, BCL IAVAIL monitor gets rbat value + from power supply battery module instead of bms module. + +Optional nodes: +- qcom,ibat-monitor: This optional node defines all the parameters for the + battery current monitoring. The BTM mode of operation requires + all the below properties to be defined with valid values. Also, + this node should be defined if and only if qcom,ibat-vadc and + qcom,ibat-threshold-adc_tm are defined. Error in any of these + properties will disable BTM mode of operation and will fall + back to the available current monitor mode. + * qcom,high-threshold-uamp: The battery current, in microampere, after + which the BCL driver should cap the maximum frequency. + * qcom,low-threshold-uamp: The battery current, in microampere, below + which the BCL driver should clear the CPU frequency mitigation. + * qcom,mitigation-freq-khz: This optional property defines the maximum + frequency value the BCL driver should mitigate the CPUS's with. + This property is valid only if 'qcom,bcl-freq-control-list' is + defined in bcl parent node. This frequency shouldn't be less than + the minimum frequency request that the kernel thermal monitor + driver places during vdd restriction. + * qcom,ibat-channel: The ADC hardware's Ibat channel number. + * qcom,uv-to-ua-numerator: The conversion parameter required for converting + the voltage measure from ADC hardware to current value. + * qcom,uv-to-ua-denominator: The conversion parameter required for + converting the voltage measure from ADC hardware to current. + The microvolt to microampere (or vice-versa) conversion uses + the below conversion formulae. + ua = (uv * uv-to-ua-numerator) / uv-to-ua-denominator + * qcom,adc-interval-usec: The polling interval, in microseconds, for the ADC + hardware. + * qcom,vph-channel: The ADC hardware's Vph channel number. + * qcom,vph-high-threshold-uv: The battery voltage threshold above which the + BCL driver clears the previously applied mitigation, disables + the battery current monitoring, and starts monitoring for low + battery voltage. + * qcom,vph-low-threshold-uv: The battery voltage threshold below which the + BCL driver starts monitoring the battery current thresholds and + mitigates the CPU on the event of high load. + * qcom,thermal-handle = <&phandle_to_vdd_apps>: phandle to the "qcom,msm_thermal" + vdd restriction property, "qcom,vdd-apps-rstr". This phandle is + used by BCL driver to get the minimum frequency request that the + thermal driver places during vdd restriction. This frequency + value will be the lowest max frequency value the BCL driver can + request. This property is valid only if 'qcom,bcl-freq-control-list' + is defined in bcl parent node. + * qcom,soc-low-threshold: The battery SOC percentage threshold below which + mitigation needs to be applied. + + +Example: + qcom,bcl { + compatible = "qcom,bcl"; + qcom,ibat-vadc = <&pma8084_vadc>; + qcom,ibat-threshold-adc_tm = <&pma8084_adc_tm>; + qcom,bcl-no-bms; + qcom,ibat-monitor { + qcom,high-threshold-uamp = <1500>; + qcom,low-threshold-uamp = <500>; + qcom,mitigation-freq-khz = <1958400>; + qcom,ibat-channel = <0x15>; + qcom,adc-interval-usec = <3900>; + qcom,uv-to-ua-numerator = <2>; + qcom,uv-to-ua-denominator = <1>; + qcom,vph-channel = <0x07>; + qcom,vph-high-threshold-uv = <3700000>; + qcom,vph-low-threshold-uv = <3500000>; + qcom,thermal-handle = <&msm_thermal_freq>; + }; + }; +For Using BCL peripheral interface: + qcom,bcl { + compatible = "qcom,bcl"; + qcom,bcl-framework-interface; + qcom,bcl-freq-mit-list = <&CPU4 &CPU5 &CPU6 &CPU7>; + qcom,bcl-hotplug-list = <&CPU5 &CPU6 &CPU7>; + qcom,bcl-soc-hotplug-list = <&CPU4 &CPU5 &CPU6 &CPU7>; + qcom,ibat-monitor { + qcom,high-threshold-uamp = <1500>; + qcom,low-threshold-uamp = <500>; + qcom,mitigation-freq-khz = <1958400>; + qcom,vph-high-threshold-uv = <3700000>; + qcom,vph-low-threshold-uv = <3500000>; + qcom,thermal-handle = <&msm_thermal_freq>; + }; + }; + +=============================================================================== +BCL PMIC Peripheral driver: +=============================================================================== +In newer targets from MSM8994, the PMIC has BCL monitoring capabilities +in the hardware. The PMIC exposes this BCL monitoring peripheral as a PMIC +peripheral. The BCL peripheral driver interacts with the PMIC peripheral using +the SPMI driver interfaces. The details and the configuration for the BCL +peripheral can be inputted using the device tree. + +The units of the Vbat and Ibat values returned and read depends on the scaling +factor that is given as input for BCL peripheral driver through device tree. The +scaling factors should be configured to handle Vbat in micro-volt and Ibat in +micro-amps. + +Required Parameters: +- compatible: must be either + 1. 'qcom,msm-bcl' for bcl peripheral without LMH DCVSh + interface + 2. 'qcom,msm-bcl-lmh' for bcl peripheral with LMH DCVSh interface. +- reg: <a b> where 'a' is the starting register address of the PMIC + peripheral and 'b' is the size of the peripheral address space. + If the BCL inhibit current derating feature is enabled, this must also + contain the PON spare registers as well. Example: <a b c d> where + c is the first PON spare register that will be written and d is the + size of the registers space needed to be written. Certain version + of PMIC, can send interrupt to LMH hardware driver directly. In that + case the shadow peripheral address space should be mentioned along + with the bcl peripherals address. +- reg-names: a list of names of the registers corresponding to the reg + property. The fuel gauge peripheral should be "fg_user_adc", the + PON spare should be "pon_spare", and the bcl-lmh shadow peripheral + should be "fg_lmh". +-interrupts: <a b c> Where 'a' is the SLAVE ID of the PMIC, 'b' is + the peripheral ID and 'c' is the interrupt number in PMIC. +- interrupt-names: user defined names for the interrupts. These + interrupt names will be used by the drivers to identify the + interrupts, instead of specifying the ID's. +- qcom,ibat-polling-delay-ms: Software polling interval for monitoring ibat + low threshold. +- qcom,vbat-polling-delay-ms: Software polling interval for monitoring vbat + high threshold. + +Optional parameters for peripheral with LMH DCVSh interface: +- qcom,vbat-scaling-factor: The scaling factor to be used for converting + the raw vbat ADC value to milli-volt. +- qcom,vbat-gain-numerator: The numerator of the vbat gain correction factor. +- qcom,vbat-gain-denominator: The denominator of the vbat gain correction + factor. +- qcom,ibat-scaling-factor: The scaling factor to be used for converting + the raw ibat ADC value to micro-amps. +- qcom, ibat-gain-numerator: The numerator of the ibat gain correction factor. +- qcom, ibat-gain-denominator: The denominator of the ibat gain correction + factor. +- qcom, ibat-offset-numerator: The numerator of the ibat offset correction + factor. +- qcom, ibat-offset-denominator: The denominator of the ibat offset + correction factor. + +Optional Parameters: +- qcom,inhibit-derating-ua: The amount that the bcl current high trip threshold + should be lowered by when the bcl peripheral is operating in a + dead time. + + bcl@4200 { + compatible = "qcom,msm-bcl"; + reg = <0x4200 0xFF 0x88e 0x2>; + reg-names = "fg_user_adc", "pon_spare"; + interrupts = <0x2 0x42 0x0>, + <0x2 0x42 0x1>; + interrupt-names = "bcl-high-ibat-int", + "bcl-low-vbat-int"; + qcom,vbat-scaling-factor = <39>; + qcom,vbat-gain-numerator = <1>; + qcom,vbat-gain-denominator = <32>; + qcom,vbat-polling-delay-ms = <50>; + qcom,ibat-scaling-factor = <39>; + qcom,ibat-gain-numerator = <1>; + qcom,ibat-gain-denominator = <32>; + qcom,ibat-offset-numerator = <12>; + qcom,ibat-offset-denominator = <10>; + qcom,ibat-polling-delay-ms = <50>; + }; + + diff --git a/Documentation/devicetree/bindings/arm/msm/clock-controller-dummy.txt b/Documentation/devicetree/bindings/arm/msm/clock-controller-dummy.txt new file mode 100644 index 000000000000..c6db837fa137 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/clock-controller-dummy.txt @@ -0,0 +1,22 @@ +Qualcomm MSM Dummy Clock controller + +Qualcomm MSM Dummy Clock controller devices provide a dummy clock for driver +development during pre-silicon stage. The driver will always return a dummy +clock that has no effect on hardware. + +Required properties: +- compatible: Must be "qcom,dummycc" +- #clock_cells: Must be <1>. This will allow the common clock device + tree framework to recognize _this_ device node as a + clock provider. +Optional properties: +- #reset-cells: Must be <1>. This will allow the common reset device + tree framework to recognize _this_ device node as a + reset controller provider. + +Example: + clock_rpm: qcom,rpmcc { + compatible = "qcom,dummycc"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/clock-controller.txt b/Documentation/devicetree/bindings/arm/msm/clock-controller.txt new file mode 100644 index 000000000000..17250cceea4c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/clock-controller.txt @@ -0,0 +1,135 @@ +Qualcomm MSM Clock controller + +Qualcomm MSM Clock controller devices contain PLLs, root clock generators +and other clocking hardware blocks that provide stable, low power clocking to +hardware blocks on Qualcomm SOCs. The clock controller device node lists the +power supplies needed to be scaled using the vdd_*-supply property. + +Minor differences between hardware revisions are handled in code by re-using +the compatible string to indicate the revision. + +Required properties: +- compatible: Must be one of following, + "qcom,gcc-8916" + "qcom,gcc-8936" + "qcom,gcc-8909" + "qcom,gcc-8992" + "qcom,gcc-8994" + "qcom,gcc-8994v2" + "qcom,gcc-8952" + "qcom,gcc-spm-8952" + "qcom,gcc-fsm9010" + "qcom,gcc-8996" + "qcom,gcc-8996-v2" + "qcom,gcc-8996-v3" + "qcom,gcc-8937" + "qcom,gcc-spm-8937" + "qcom,gcc-titanium" + "qcom,rpmcc-8994" + "qcom,rpmcc-8992" + "qcom,rpmcc-8916" + "qcom,rpmcc-8936" + "qcom,rpmcc-8909" + "qcom,cc-debug-8916" + "qcom,cc-debug-8936" + "qcom,cc-debug-8909" + "qcom,cc-debug-8992" + "qcom,cc-debug-8994" + "qcom,cc-debug-8952" + "qcom,cc-debug-titanium" + "qcom,cc-debug-fsm9010" + "qcom,cc-debug-8996" + "qcom,cc-debug-8996-v2" + "qcom,cc-debug-8996-v3" + "qcom,cc-debug-8937" + "qcom,gcc-mdss-8936" + "qcom,gcc-mdss-8909" + "qcom,gcc-mdss-8916" + "qcom,gcc-mdss-8952" + "qcom,gcc-mdss-8937" + "qcom,gcc-mdss-titanium" + "qcom,mmsscc-8994v2" + "qcom,mmsscc-8994" + "qcom,mmsscc-8992" + "qcom,mmsscc-8996" + "qcom,mmsscc-8996-v2" + "qcom,mmsscc-8996-v3" + "qcom,mmsscc-8996-pro" + "qcom,gpucc-8996" + "qcom,gpucc-8996-v2" + "qcom,gpucc-8996-v3" + "qcom,gpucc-8996-v3.0" + "qcom,gpucc-8996-pro" + "qcom,gcc-gfx-titanium" + "qcom,gcc-californium" + "qcom,cc-debug-californium" + "qcom,gcc-mdm9607" + "qcom,cc-debug-mdm9607" + "qcom,gcc-8998" + "qcom,gcc-8998-v2" + "qcom,gcc-hamster" + "qcom,cc-debug-8998" + "qcom,gpucc-8998" + "qcom,gfxcc-8998" + "qcom,gpucc-8998-v2" + "qcom,gfxcc-8998-v2" + "qcom,gpucc-hamster" + "qcom,gfxcc-hamster" + "qcom,mmsscc-8998" + "qcom,mmsscc-8998-v2" + "qcom,mmsscc-hamster" + +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. Currently, + there is one expected base: "cc_base". Optional + reg-names are "apcs_base", "meas", "mmss_base", + "lpass_base", "apcs_c0_base", "apcs_c1_base", + "apcs_cci_base", "efuse". + +Optional properties: +- vdd_dig-supply: The digital logic rail supply. +- <pll>_dig-supply: Some PLLs might have separate digital supply on some + targets. These properties will be provided on those + targets for specific PLLs. +- <pll>_analog-supply: Some PLLs might have separate analog supply on some + targets. These properties will be provided on those + targets for specific PLLs. +- vdd_gpu_mx-supply: MX rail supply for the GPU core. +- #clock_cells: If this device will also be providing controllable + clocks, the clock_cells property needs to be specified. + This will allow the common clock device tree framework + to recognize _this_ device node as a clock provider. +- qcom,<clk>-corner-<vers>: List of frequency voltage pairs that the clock can + operate at. Drivers can use the OPP library API to + operate on the list of OPPs registered using these + values. +- qcom,<clk>-speedbinX: A table of frequency (Hz) to voltage (corner) mapping + that represents the max frequency possible for each + supported voltage level for the clock. + 'X' is the speed bin into which the device falls into - + a bin will have unique frequency-voltage relationships. + The value 'X' is read from efuse registers, and the right + table is picked from multiple possible tables. +- qcom,<clock-name>-opp-handle: phandle references to the devices for which OPP + table is filled with the clock frequency and voltage + values. +- qcom,<clock-name>-opp-store-vcorner: phandle references to the devices for + which OPP table is filled with the clock frequency + and voltage corner/level. + +Example: + clock_rpm: qcom,rpmcc@fc4000000 { + compatible = "qcom,rpmcc-8974"; + reg = <0xfc400000 0x4000>; + reg-names = "cc_base"; + #clock-cells = <1>; + }; + + clock_gcc: qcom,gcc@fc400000 { + compatible = "qcom,gcc-8974"; + reg = <0xfc400000 0x4000>; + reg-names = "cc_base"; + vdd_dig-supply = <&pm8841_s2_corner>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/clock-cpu-8996.txt b/Documentation/devicetree/bindings/arm/msm/clock-cpu-8996.txt new file mode 100644 index 000000000000..f3c6cc747710 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/clock-cpu-8996.txt @@ -0,0 +1,78 @@ +Qualcomm MSM 8996 CPU clock tree + +clock-cpu-8996 is a device that represents the MSM 8996 CPU subsystem +clock tree. It lists the various power supplies that need to be scaled when +the clocks are scaled and also other HW specific parameters like fmax tables, +PLL FMAXes etc. + +Required properties: +- compatible: Must be either "qcom,cpu-clock-8996" or + "qcom,cpu-clock-8996-v3" or "qcom,cpu-clock-8996-pro" +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. Expected + bases are: + "pwrcl_pll", "perfcl_pll", "cbf_pll", "pwrcl_mux", + "perfcl_mux", "cbf_mux", "efuse"; +- vdd-perfcl-supply: The regulator powering the power cluster +- vdd-pwrcl-supply: The regulator powering the perf cluster +- vdd-cbf-supply: The regulator powering the CBF interconnect +- vdd-dig-supply: The regulator powering the cluster PLLs +- qcom,pwrcl-speedbinY-vZ: + A table of CPU frequency (Hz) to voltage (corner) + mapping that represents the max frequency possible + for each supported voltage level for the power cluster. + 'Y' is the speed bin into which the device falls into - + a bin will have unique frequency-voltage relationships. + 'Z' is the characterization version, implying that + characterization (deciding what speed bin a device + falls into) methods and/or encoding may change. The + values 'Y' and 'Z' are read from efuse registers, and + the right table is picked from multiple possible tables. +- qcom,perfcl-speedbinY-vZ: + Similar to the qcom,pwrcl-speedbinY-vZ property above, + except this frequency to voltage table is applied to the + clock for the perf cluster. +- qcom,cbf-speedbinY-vZ: + Similar to the qcom,perfcl-speedbinY-vZ property above, + except this frequency to voltage table is applied to the + clock for the CBF. +- cbf-dev: The CBF cache device to which the OPP table for the + CBF clock domain will be added. +Example: + clock_cpu: qcom,cpu-clock-8996@ { + compatible = "qcom,cpu-clock-8996"; + reg = <0x06400000 0x1000>, + <0x06480000 0x1000>, + <0x09A20000 0x1000>, + <0x06400000 0x1000>, + <0x06480000 0x1000>, + <0x09A11000 0x1000>, + <0x00070130 0x8>; + reg-names = "pwrcl_pll", "perfcl_pll", "cbf_pll", "pwrcl_mux", "perfcl_mux", "cbf_mux", "efuse"; + vdd-pwrcl-supply = <&apc_vreg_corner>; + vdd-perfcl-supply = <&apc_vreg_corner>; + vdd-cbf-supply = <&apc_vreg_corner>; + vdd-dig-supply = <&pm8994_s1_corner_ao>; + qcom,pwrcl-speedbin0-v0 = + < 0 0 >, + < 300000000 1 >, + < 345600000 2 >, + < 422400000 3 >, + < 1459200000 18 >; + qcom,perfcl-speedbin0-v0 = + < 0 0 >, + < 300000000 1 >, + < 345600000 2 >, + < 422400000 3 >, + < 1593600000 18 >; + qcom,cbf-speedbin0-v0 = + < 0 0 >, + < 300000000 1 >, + < 384000000 3 >, + < 1036800000 18 >; + clock-names = "xo_ao", "aux_clk"; + clocks = <&clock_gcc clk_cxo_clk_src_ao>, + <&clock_gcc clk_gpll0_out_main>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/clock-cpu-rcgwr.txt b/Documentation/devicetree/bindings/arm/msm/clock-cpu-rcgwr.txt new file mode 100644 index 000000000000..514f994b4982 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/clock-cpu-rcgwr.txt @@ -0,0 +1,42 @@ +Qualcomm CPU clock Ramp Controller + +The root clock generator could have the ramp controller in built. +Ramp control will allow programming the sequence ID for pulse swallowing, +enable sequence and for linking sequence IDs. + +This will use the cpu clock device node. + +Required properties: +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. Expected + bases are: + "rcgwr-cX-base" (X: 0 or 1 based on the number of + clusters) +- qcom,num-clusters: Number of clusters which support RCGwR. + +Optional Properties: +- qcom,lmh-sid-cX: List of LMH SID offset and value to be programmed for + each cluster (X: 0 or 1) +- qcom,link-sid-cX: List of Link SID offset and value to be programmed for + each cluster (X: 0 or 1) +- qcom,dfs-sid-cX: List of DFS SID offset and value to be programmed for + each cluster (X: 0 or 1) +- qcom,ramp-dis-cX: Boolean property to disable ramp down for each cluster + (X: 0 or 1) + +Example: + clock_cpu: qcom,cpu-clock@b016000 { + compatible = "qcom,cpu-clock"; + qcom,num-clusters = <2>; + qcom,lmh-sid-c0 = < 0x30 0x077706db>, + < 0x34 0x05550249>, + < 0x38 0x00000111>; + qcom,lmh-sid-c1 = < 0x30 0x077706db>, + < 0x34 0x05550249>, + < 0x38 0x00000111>; + reg = <0xb114000 0x68>, + <0xb014000 0x68>; + reg-names = "rcgwr-c0-base", "rcgwr-c1-base"; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/core_sleep_status.txt b/Documentation/devicetree/bindings/arm/msm/core_sleep_status.txt new file mode 100644 index 000000000000..56fa470eddfe --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/core_sleep_status.txt @@ -0,0 +1,49 @@ +* MSM Sleep status + +MSM Sleep status device is used to check the power collapsed status of a +offlined core. The core that initiates the hotplug would wait on the +sleep status device before CPU_DEAD notifications are sent out. Some hardware +devices require that the offlined core is power collapsed before turning off +the resources that are used by the offlined core. + +The required properties of core sleep status node are: +- compatible: qcom,cpu-sleep-status + +The required properties of sleep status node are: +- reg: physical address of the sleep status register for the cpus +- qcom,cpu-sleep-status-mask - The bit mask within the status register that + indicates the Core's sleep state. + +Example: + qcom,cpu-sleep-status { + compatible = "qcom,cpu-sleep-status"; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo"; + + qcom,sleep-status = <&cpu0_slp_sts>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "qcom,kryo"; + + qcom,sleep-status = <&cpu1_slp_sts>; + }; + }; + + cpu0_slp_sts: cpu-sleep-status@9981058 { + reg = <0x9981058 0x100>; + qcom,sleep-status-mask = <0xc00000>; + }; + + cpu1_slp_sts: cpu-sleep-status@9991058 { + reg = <0x9991058 0x100>; + qcom,sleep-status-mask = <0xc00000>; + } diff --git a/Documentation/devicetree/bindings/arm/msm/glink_config_qos.txt b/Documentation/devicetree/bindings/arm/msm/glink_config_qos.txt new file mode 100644 index 000000000000..d9c8a007a8fe --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_config_qos.txt @@ -0,0 +1,22 @@ +Qualcomm Technologies, Inc. G-link QoS Configuration + +Required properties: +-compatible : should be "qcom,glink-qos-config" +-qcom,flow-info : A table of MTU transmission time specific for a power state. + The total number of entries in the table should be equal to the + number of supported flows. +-qcom,mtu-size : The MTU size for which the qos elements are configured. +-qcom,tput-stats-cycle: The number of allowable cycles for a packet to be + transmitted without its priority being re-evaluated. + +Example: + + qcom,glink-qos-config-adsp { + compatible = "qcom,glink-qos-config"; + qcom,flow-info = <0x80 0x0>, + <0x70 0x1>, + <0x60 0x2>, + <0x50 0x3>; + qcom,mtu-size = <0x800>; + qcom,tput-stats-cycle = <0xa>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glink_mailbox_xprt.txt b/Documentation/devicetree/bindings/arm/msm/glink_mailbox_xprt.txt new file mode 100644 index 000000000000..acf98c4aa6a0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_mailbox_xprt.txt @@ -0,0 +1,35 @@ +Qualcomm Technologies, Inc. G-link Mailbox Transport + +Required properties: +-compatible : should be "qcom,glink-mailbox-xprt" +-reg : the mailbox register to store the location of the fifo + the mailbox register to store the size of the fifo + the irq register base address for triggering interrupts + the register to enable sending interrupts + the register to reset the rx irq line +-reg-names : "mbox-loc-addr" - string to identify the mailbox location reg + "mbox-loc-size" - string to identify the mailbox size reg + "irq-reg-base" - string to identify the irq register region + "irq-rx-reset" - string to identify the rx irq reset register +-qcom,irq-mask : the bitmask to trigger an interrupt +-interrupts : the receiving interrupt line +-label : the name of the subsystem this link connects to +-qcom,tx-ring-size: size of the transmit ring buffer in bytes +-qcom,rx-ring-size: size of the receive ring buffer in bytes + +Example: + + qcom,glink-mailbox-xprt-spss@1d05008 { + compatible = "qcom,glink-mailbox-xprt"; + reg = <0x1d05008 0x8>, + <0x1d05010 0x4>, + <0x1d06004 0x4>, + <0x1d06020 0x4>; + reg-names = "mbox-loc-addr", "mbox-loc-size", "irq-reg-base", + "irq-rx-reset"; + qcom,irq-mask = <0x1000>; + interrupts = <0 25 4>; + label = "spss"; + qcom,tx-ring-size = <0x400>; + qcom,rx-ring-size = <0x400>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glink_rpm_native_xprt.txt b/Documentation/devicetree/bindings/arm/msm/glink_rpm_native_xprt.txt new file mode 100644 index 000000000000..2da6f2a19126 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_rpm_native_xprt.txt @@ -0,0 +1,21 @@ +Qualcomm Technologies, Inc. G-link RPM Native Transport + +Required properties: +-compatible : should be "qcom,glink-rpm-native-xprt" +-reg : the location and size of RPM message RAM + the irq register base address for triggering interrupts +-reg-names : "msgram" - string to identify the RPM message RAM region + "irq-reg-base" - string to identify the irq register region +-qcom,irq-mask : the bitmark to trigger an interrupt +-interrupts : the receiving interrupt line + +Example: + + qcom,glink-rpm-native-xprt@68000 { + compatible = "qcom,glink-rpm-native-xprt"; + reg = <0x68000 0x8000>, + <0xfa006008 0x4>; + reg-names = "msgram", "irq-reg-base"; + qcom,irq-mask = <0x1000>; + interrupts = <0 25 1>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glink_smem_native_xprt.txt b/Documentation/devicetree/bindings/arm/msm/glink_smem_native_xprt.txt new file mode 100644 index 000000000000..f68c8e4a4554 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_smem_native_xprt.txt @@ -0,0 +1,54 @@ +Qualcomm Technologies, Inc. G-link SMEM Native Transport + +Required properties: +-compatible : should be "qcom,glink-smem-native-xprt" +-reg : the location and size of shared memory + the irq register base address for triggering interrupts +-reg-names : "smem" - string to identify the shared memory region + "irq-reg-base" - string to identify the irq register region +-qcom,irq-mask : the bitmark to trigger an interrupt +-interrupts : the receiving interrupt line +-label : the name of the subsystem this link connects to + +Optional properties: +-qcom,qos-config: Reference to the qos configuration elements.It depends on + ramp-time. +-qcom,ramp-time: Worst case time in microseconds to transition to this power + state. Power states are numbered by array index position. + +Example: + + qcom,glink-smem-native-xprt-modem@fa00000 { + compatible = "qcom,glink-smem-native-xprt"; + reg = <0xfa00000 0x200000>, + <0xfa006008 0x4>; + reg-names = "smem", "irq-reg-base"; + qcom,irq-mask = <0x1000>; + interrupts = <0 25 1>; + label = "mpss"; + }; + + qcom,glink-smem-native-xprt-adsp@fa00000 { + compatible = "qcom,glink-smem-native-xprt"; + reg = <0xfa00000 0x200000>, + <0xfa006008 0x4>; + reg-names = "smem", "irq-reg-base"; + qcom,irq-mask = <0x1000>; + interrupts = <0 25 1>; + label = "lpass"; + qcom,qos-config = <&glink_qos_adsp>; + qcom,ramp-time = <0x10>, + <0x20>, + <0x30>, + <0x40>; + }; + + glink_qos_adsp: qcom,glink-qos-config-adsp { + compatible = "qcom,glink-qos-config"; + qcom,flow-info = <0x80 0x0>, + <0x70 0x1>, + <0x60 0x2>, + <0x50 0x3>; + qcom,mtu-size = <0x800>; + qcom,tput-stats-cycle = <0xa>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glink_spi_xprt.txt b/Documentation/devicetree/bindings/arm/msm/glink_spi_xprt.txt new file mode 100644 index 000000000000..0a78eb6b91fd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_spi_xprt.txt @@ -0,0 +1,44 @@ +Qualcomm Technologies, Inc. G-link SPI Transport + +Required properties: +-compatible : should be "qcom,glink-spi-xprt". +-label : the name of the subsystem this link connects to. + +Optional properties: +-qcom,remote-fifo-config: Reference to the FIFO configuratio in the remote + processor. +-qcom,qos-config: Reference to the qos configuration elements.It depends on + ramp-time. +-qcom,ramp-time: Worst case time in microseconds to transition to this power + state. Power states are numbered by array index position. + +Example: + + glink_spi_xprt_wdsp: qcom,glink-spi-xprt-wdsp { + compatible = "qcom,glink-spi-xprt"; + label = "wdsp"; + qcom,remote-fifo-config = <&glink_fifo_wdsp>; + qcom,qos-config = <&glink_qos_wdsp>; + qcom,ramp-time = <0x10>, + <0x20>, + <0x30>, + <0x40>; + }; + + glink_fifo_wdsp: qcom,glink-fifo-config-wdsp { + compatible = "qcom,glink-fifo-config"; + qcom,out-read-idx-reg = <0x12000>; + qcom,out-write-idx-reg = <0x12004>; + qcom,in-read-idx-reg = <0x1200C>; + qcom,in-write-idx-reg = <0x12010>; + }; + + glink_qos_wdsp: qcom,glink-qos-config-wdsp { + compatible = "qcom,glink-qos-config"; + qcom,flow-info = <0x80 0x0>, + <0x70 0x1>, + <0x60 0x2>, + <0x50 0x3>; + qcom,mtu-size = <0x800>; + qcom,tput-stats-cycle = <0xa>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glink_ssr.txt b/Documentation/devicetree/bindings/arm/msm/glink_ssr.txt new file mode 100644 index 000000000000..5a0ac7ce63a4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glink_ssr.txt @@ -0,0 +1,36 @@ +Qualcomm Technologies, Inc. G-Link SSR + +[Root level node] +Required properties: +-compatible : should be "qcom,glink_ssr" +-label : The name of this subsystem. +-qcom,edge : The name of the edge to this subsystem. +-qcom,notify-edges : Reference to other subsystems to notify when this + subsystem goes down. + +Optional properties: +-qcom,xprt : The name of the transport on which to notify this subystem. + +Example: + + glink_mpss: qcom,glink-ssr-modem { + compatible = "qcom,glink_ssr"; + label = "modem"; + qcom,edge = "mpss"; + qcom,notify-edges = <&glink_adsp>, <&glink_wcnss>; + qcom,xprt = "smem"; + }; + + glink_adsp: qcom,glink-ssr-adsp { + compatible = "qcom,glink_ssr"; + label = "adsp"; + qcom,edge = "adsp"; + qcom,notify-edges = <&glink_mpss>, <&glink_wcnss>; + }; + + glink_wcnss: qcom,glink-ssr-wcnss { + compatible = "qcom,glink_ssr"; + label = "wcnss"; + qcom,edge = "wcnss"; + qcom,notify-edges = <&glink_mpss>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/glinkpkt.txt b/Documentation/devicetree/bindings/arm/msm/glinkpkt.txt new file mode 100644 index 000000000000..b5c660c808e0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/glinkpkt.txt @@ -0,0 +1,40 @@ +Qualcomm Technologies, Inc. G-Link Packet Driver (glinkpkt) + +[Root level node] +Required properties: +-compatible : should be "qcom,glinkpkt" + +[Second level nodes] +qcom,glinkpkt-channel-names +Required properties: +-qcom,glinkpkt-transport : the glinkpkt transport layer +-qcom,glinkpkt-edge : the remote subsystem name +-qcom,glinkpkt-ch-name : the glink channel name +-qcom,glinkpkt-dev-name : the glinkpkt device name + +Example: + + qcom,glink_pkt { + compatible = "qcom,glinkpkt"; + + qcom,glinkpkt-at-mdm0 { + qcom,glinkpkt-transport = "smd_trans"; + qcom,glinkpkt-edge = "mpss"; + qcom,glinkpkt-ch-name = "DS"; + qcom,glinkpkt-dev-name = "at_mdm0"; + }; + + qcom,glinkpkt-loopback-cntl { + qcom,glinkpkt-transport = "lloop"; + qcom,glinkpkt-edge = "local"; + qcom,glinkpkt-ch-name = "LOCAL_LOOPBACK_CLNT"; + qcom,glinkpkt-dev-name = "glink_pkt_loopback_ctrl"; + }; + + qcom,glinkpkt-loopback-data { + qcom,glinkpkt-transport = "lloop"; + qcom,glinkpkt-edge = "local"; + qcom,glinkpkt-ch-name = "glink_pkt_lloop_CLNT"; + qcom,glinkpkt-dev-name = "glink_pkt_loopback"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/heap-sharing.txt b/Documentation/devicetree/bindings/arm/msm/heap-sharing.txt new file mode 100644 index 000000000000..359223128b9b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/heap-sharing.txt @@ -0,0 +1,44 @@ +* Memory Share Driver (MEMSHARE) + +The Memshare driver implements a Kernel QMI service on the +LA-APSS, which is responsible for providing contiguous physical +memory to MPSS for use cases when the modem requires additional +memory (e.g. GPS). + +Required properties for Memshare + +-Root Node- + +- compatible: Must be "qcom,memshare" + +Required properties for child nodes: + +- compatible: Must be "qcom,memshare-peripheral" + +- qcom,peripheral-size: Indicates the size (in bytes) required for that child. + +- qcom,client-id: Indicates the client id of the child node. + +- label: Indicates the peripheral information for the node. Should be one of + the following: + - modem /* Represent Modem Peripheral */ + - adsp /* Represent ADSP Peripheral */ + - wcnss /* Represent WCNSS Peripheral */ + +Optional properties for child nodes: + +- qcom,allocate-boot-time: Indicates whether clients needs boot time memory allocation. + +Example: + +qcom,memshare { + compatible = "qcom,memshare"; + + qcom,client_1 { + compatible = "qcom,memshare-peripheral"; + qcom,peripheral-size = <0x200000>; + qcom,client-id = <0>; + qcom,allocate-boot-time; + label = "modem"; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/imem.txt b/Documentation/devicetree/bindings/arm/msm/imem.txt new file mode 100644 index 000000000000..2989fbfe7972 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/imem.txt @@ -0,0 +1,124 @@ +Qualcomm IMEM + +IMEM is fast on-chip memory used for various debug features and dma transactions. + +Required properties + +-compatible: "qcom,msm-imem" +-reg: start address and size of imem memory + +If any children nodes exist the following properties are required: +-#address-cells: should be 1 +-#size-cells: should be 1 +-ranges: A triplet that includes the child address, parent address, & + length. The child address is assumed to be 0. + +Child nodes: +------------ + +Peripheral Image Loader (pil): +------------------------------ +Required properties: +-compatible: "qcom,msm-imem-pil" +-reg: start address and size of PIL region in imem + +Bootloader Stats: +----------------- +Required properties: +-compatible: "qcom,msm-imem-boot_stats" +-reg: start address and size of boot_stats region in imem + +Cache error reporting: +----------------- +Required properties: +-compatible: "qcom,msm-imem-cache_erp" +-reg: start address and size of cache_erp region in imem + +Memory Dump: +------------ +Required properties: +-compatible: "qcom,msm-imem-mem_dump_table" +-reg: start address and size of mem_dump_table region in imem + +Restart Reason: +--------------- +Required properties: +-compatible: "qcom,msm-imem-restart_reason +-reg: start address and size of restart_reason region in imem + +Download Mode Type: +------------------- +Required properties: +-compatible: "qcom,msm-imem-dload-type" +-reg: start address and size of dload type region in imem + +Download Mode: +-------------- +Required properties: +-compatible: "qcom,msm-imem-download_mode" +-reg: start address and size of download_mode region in imem + +Emergency Download Mode: +------------------------ +-compatible: "qcom,msm-imem-emergency_download_mode" +-reg: start address and size of emergency_download_mode region in imem + +Kaslr Offset: +------------------------ +-compatible: "qcom,msm-imem-kaslr_offset" +-reg: start address and size of kaslr_offset region in imem + +USB Diag Cookies: +----------------- +Memory region used to store USB PID and serial numbers to be used by +bootloader in download mode. + +Required properties: +-compatible: "qcom,msm-imem-diag-dload" +-reg: start address and size of USB Diag download mode region in imem + +Example: + + qcom,msm-imem { + compatible = "qcom,msm-imem"; + reg = <0xdeadbeef 0x1000>; /* < start_address size > */ + ranges = <0x0 0xdeadbeef 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + download_mode@0 { + compatible = "qcom,msm-imem-download_mode"; + reg = <0x0 8>; + }; + + restart_reason@65c { + compatible = "qcom,msm-imem-restart_reason"; + reg = <0x65c 4>; + }; + + imem_cache_erp: cache_erp@6a4 { + compatible = "qcom,msm-imem-cache_erp"; + reg = <0x6a4 4>; + }; + + boot_stats@6b0 { + compatible = "qcom,msm-imem-boot_stats"; + reg = <0x6b0 32>; + }; + + kaslr_offset@6d0 { + compatible = "qcom,msm-imem-kaslr_offset"; + reg = <0x6d0 12>; + }; + + + pil@94c { + compatible = "qcom,msm-imem-pil"; + reg = <0x94c 200>; + }; + + emergency_download_mode@fe0 { + compatible = "qcom,msm-imem-emergency_download_mode"; + reg = <0xfe0 12>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/ipc-spinlock.txt b/Documentation/devicetree/bindings/arm/msm/ipc-spinlock.txt new file mode 100644 index 000000000000..24dbb4b83d99 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/ipc-spinlock.txt @@ -0,0 +1,27 @@ +Qualcomm Interprocessor Communication Spinlock + +--Dedicated Hardware Implementation-- +Required properties: +- compatible : should be "qcom,ipc-spinlock-sfpb" +- reg : the location and size of the spinlock hardware +- qcom,num-locks : the number of locks supported + +Example: + + qcom,ipc-spinlock@fd484000 { + compatible = "qcom,ipc-spinlock-sfpb"; + reg = <0xfd484000 0x1000>; + qcom,num-locks = <32>; + }; + +--LDREX Implementation-- +Required properties: +- compatible : should be "qcom,ipc-spinlock-ldrex" +- reg : the location and size of the shared lock memory + +Example: + + qcom,ipc-spinlock@fa00000 { + compatible = "qcom,ipc-spinlock-ldrex"; + reg = <0xfa00000 0x200000>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/jtag-fuse.txt b/Documentation/devicetree/bindings/arm/msm/jtag-fuse.txt new file mode 100644 index 000000000000..ed2ac0226eab --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/jtag-fuse.txt @@ -0,0 +1,23 @@ +* JTAG-FUSE + +The jtag-fuse entry specifies the memory mapped addresses for the fuse +registers. The jtag-fuse driver uses these to provide api(s) that can be used +by jtag save and restore driver(s) to query whether the Hardware they manage +is functionally disabled or not and take corresponding steps. + +Required Properties: +compatible: component name used for driver matching, should be one of the + following: + "qcom,jtag-fuse" for jtag fuse device + "qcom,jtag-fuse-v2" for jtag fuse v2 device + "qcom,jtag-fuse-v3" for jtag fuse v3 device + "qcom,jtag-fuse-v4" for jtag fuse v4 device +reg: physical base address and length of the register set +reg-names: should be "fuse-base" + +Example: + jtag_fuse: jtagfuse@fc4be024 { + compatible = "qcom,jtag-fuse"; + reg = <0xfc4be024 0x8>; + reg-names = "fuse-base"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/jtag-mm.txt b/Documentation/devicetree/bindings/arm/msm/jtag-mm.txt new file mode 100644 index 000000000000..68b972f8c7cc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/jtag-mm.txt @@ -0,0 +1,31 @@ +* JTAG-MM + +The jtag-mm entry specifies the memory mapped addresses for the debug and ETM +registers. The jtag-mm driver uses these to save and restore the registers +using memory mapped access during power collapse so as to retain their state +accross power collapse. This is necessary in case cp14 access to the registers +is not permitted. + +Required Properties: +compatible: component name used for driver matching, should be: + "qcom,jtag-mm" - for jtag-mm device + "qcom,jtagv8-mm" - for jtagv8-mm device supporting ARMv8 targets +reg: physical base address and length of the register set +reg-names: should be "etm-base" for etm register set and "debug-base" for debug + register set. +qcom,coresight-jtagmm-cpu : specifies phandle for the cpu associated with the + jtag-mm device +qcom,si-enable : boolean, indicating etm save and restore is supported via + system instructions +qcom,save-restore-disable : boolean, to disable etm save and restore + functionality + +Example: +jtag_mm: jtagmm@fc332000 { + compatible = "qcom,jtag-mm"; + reg = <0xfc332000 0x1000>, + <0xfc333000 0x1000>; + reg-names = "etm-base","debug-base"; + + qcom,coresight-jtagmm-cpu = <&CPU0>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/l2cache-pmu.txt b/Documentation/devicetree/bindings/arm/msm/l2cache-pmu.txt new file mode 100644 index 000000000000..905b70989733 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/l2cache-pmu.txt @@ -0,0 +1,20 @@ +L2 cache performance monitor unit + +L2 cache controllers have a performance monitor unit to measure +events such as cache hits and misses. There is one L2 cache PMU +for each cluster of CPUs. + +Required properties: + +- compatible : should be "qcom,qcom-l2cache-pmu" +- interrupts : 1 interrupt for each cluster. +- qcom,cpu-affinity: specifies the id of the first CPU in the cluster. + +Example: + + l2cache-pmu { + compatible = "qcom,qcom-l2cache-pmu"; + interrupts = <0 0 1>, <0 8 1>; + qcom,cpu-affinity = <0>, <2> + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/l2ccc.txt b/Documentation/devicetree/bindings/arm/msm/l2ccc.txt new file mode 100644 index 000000000000..74d5f84c8c9c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/l2ccc.txt @@ -0,0 +1,20 @@ +L2 Cache Clock Controller + +The L2 Cache Clock Controller provides clock, power domain, and +reset control to a L2-cache for a cluster. There is L2CCC register +region per CPU Cluster. + +Required properties: +- compatible: Can be one of: + "qcom,8916-l2ccc" + "qcom,titanium-l2ccc" + "qcom,8937-l2ccc" +- reg: This specifies the base address and size of + the register region. + +Example: + + clock-controller@f900f000 { + compatible = "qcom,8916-l2ccc""; + reg = <0xf900f000 0x1000>; + } diff --git a/Documentation/devicetree/bindings/arm/msm/limits_lmh.txt b/Documentation/devicetree/bindings/arm/msm/limits_lmh.txt new file mode 100644 index 000000000000..4d279a55ac10 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/limits_lmh.txt @@ -0,0 +1,46 @@ +Limits Management Hardware Driver +================================ +LMH driver provides API to interact with the LMH hardware. All the calls to +the LMH hardware are routed via secure space. + +The device tree parameters for LMH driver are: + +Device/Asic specific properties: +- reg : Base address of the LMH Lite hardware's interrupt status register + and its size in bytes. 'reg' parameter is required if + 'qcom,lmh-trim-err-offset' is set. +- qcom,lmh-trim-err-offset : This property defines the bit in the LMH + interrupt status register, which shows whether there is a + trim error in LMH hardware. +- vdd-apss-supply : This property should hold the phandle of APSS regulator. + When defined, the M4M DPM will be notified for the APSS + voltage change. +- qcom,lmh-odcm-disable-threshold-mA : This property holds the APSS rail + current threshold below which the ODCM will be disabled. + This property requires the "vdd-apss-supply" property + defined. + +Required parameters: +- compatible: Must be either "qcom,lmh" or "qcom,lmh_v1". + The driver based on the compatible string will decide + the default profile. +- interrupts: LMH Lite hardware interrupt details. + +Example: + +qcom,lmh { + compatible = "qcom,lmh"; + interrupts = <0 332 4>; + reg = <0xF9117000 0x4>; + qcom,lmh-trim-err-offset = <18>; + vdd-apss-supply = <&pm8994_s11>; + qcom,lmh-odcm-disable-threshold-mA = <850>; +}; + +Or for asics that don't have trim err and don't require the voltage change +update for DPM. + +qcom,lmh { + compatible = "qcom,lmh_v1"; + interrupts = <0 332 4>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/lmh-dcvs.txt b/Documentation/devicetree/bindings/arm/msm/lmh-dcvs.txt new file mode 100644 index 000000000000..6337065c0d2b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/lmh-dcvs.txt @@ -0,0 +1,32 @@ +Limits Management Hardware - DCVS + +The LMH-DCVS block is a hardware IP for every CPU cluster, to handle quick +changes in thermal limits. The hardware responds to thermal variation amongst +the CPUs in the cluster by requesting limits on the clock frequency and +voltage on the OSM hardware. + +The LMH DCVS driver exports a virtual sensor that can be used to set the +thermal limits on the hardware. The thermal zone is not capable of reading out +a temperature. + +Properties: + +- compatible: + Usage: required + Value type: <string> + Definition: shall be "qcom,msm-hw-limits" +- interrupts: + Usage: required + Value type: <interrupt_type interrupt_number interrupt_trigger_type> + Definition: Should specify interrupt information about the debug + interrupt generated by the LMH DCVSh hardware. LMH + DCVSh hardware will generate this interrupt whenever + it makes a new cpu DCVS decision. + +Example: + + lmh_dcvs0: qcom,limits-dcvs@0 { + compatible = "qcom,msm-hw-limits"; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/lpm-levels.txt b/Documentation/devicetree/bindings/arm/msm/lpm-levels.txt new file mode 100644 index 000000000000..ae476d07466e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/lpm-levels.txt @@ -0,0 +1,324 @@ +* Low Power Management Levels + +The application processor in MSM can do a variety of C-States for low power +management. The LPM module performs the System low power modes based on +the latency/residency information of the individual CPUs and clusters. + +LPM-levels defines a hierarchy of low power modes that a cluster and +clusters/cpus within that cluster can enter. The bottom hierarchy level +represents the low power modes that a CPU can enter. The CPU low power nodes +are associated with a cluster that defines the low power modes that a cluster +can enter. For system involving a hierarchy of clusters, the cluster low power +modes can be contained within another cluster. + +[Top Level Node] +Required properties: + +- compatible: "qcom,lpm-levels" + +[Node bindings for qcom,pm-cluster] + Required properties: + - reg - The numeric cluster id + - label: Identifies the cluster name. The name will be + used when reporting the stats for each low power mode. + - qcom,spm-device-names: List of SPM device names which control the + low power modes for this driver. The lpm driver uses the device name + to obtain a handle to the SPM driver that controls the cluster's low + power mode. This is only required if "qcom,use-psci" is not defined. + - qcom,default-level: The default low power level that a cluster is + programmed. The SPM of the corresponding device is configured at this + low power mode by default. + - qcom,cpu: List of CPU phandles to identify the CPUs associated with + this cluster. This property is required if and only if the cluster + node contains a qcom,pm-cpu node. + + qcom,pm-cluster contains qcom,pm-cluster-level nodes which identify + the various low power modes that the cluster can enter. The + qcom,pm-cluster node should also include another cluster node or a cpu + node that defines their respective low power modes. + +[Node bindings for qcom,pm-cluster-level] + Required properties: + - reg: The numeric cluster level id + - label: Name to identify the low power mode in stats + module. + - qcom,spm-<device-name>-mode: For each SPM device defined in + qcom,spm-devices-names, a corresponding entry identifying the low + power mode is expected. For example, the qcom,pm-cluster node contains + a SPM device by name "l2" then the cluster level should contain a + qcom,spm-l2-mode. When a cluster level is chosen ,the SPM device is + programmed with its + corresponding low power mode. The accepted values for this property + are: + - "active" + - "wfi" + - "retention" + - "gdhs" + - "pc" + - "fpc" + - qcom,min-child-idx: The minimum level that a child CPU should be in + before this level can be chosen. This property is required for all + non-default level. + - qcom,latency-us: The latency in handling the interrupt if this level + was chosen, in uSec + - qcom,ss-power: The steady state power expelled when the processor is + in this level in mWatts + - qcom,energy-overhead: The energy used up in entering and exiting + this level in mWatts.uSec + - qcom,time-overhead: The time spent in entering and exiting this + level in uS + Optional properties: + - qcom,notify-rpm: When set, the driver flushes the RPM sleep set and + configures the virtual MPM driver in prepration for a RPM assisted + sleep. + - qcom,last-level - When set, the cluster level is applied only when + there is 1 online core. + - qcom,disable-dynamic-int-routing: When set disables the dynamic + routing of rpm-smd and mpm interrupts to next wake up core. + - qcom,use-psci: This boolean property allows the LPM modules to + terminate in PSCI to configure SPM for low power modes. + - qcom,psci-mode-shift: The property is used to determine with bit + location of the cluster mode in the composite state ID used to define + cluster low power modes in PSCI v1.0. Required only if qcom,use-psci + is defined at the lpm-levels root node. + - qcom,psci-mode-mask: The property is used to determine with bit + mask of the cluster mode in the composite state ID used to define + cluster low power modes in PSCI v1.0. Required only if qcom,use-psci + is defined at the lpm-levels root node. + - qcom,psci-mode: ID to be passed into the PSCI firmware. Required + only if qcom,use-psci is defined at the lpm-levels root node. + - qcom,is-reset: This boolean property will tell whether + cluster level need power management notifications to be sent out + or not for the drivers to prepare for cluster collapse. + - qcom,hyp-psci: This property is used to determine if the cpu + enters the low power mode within hypervisor. + - qcom,reset-level: This property is used to determine in this + low power mode only control logic power collapse happens or memory + logic power collapse aswell happens or retention state. + The accepted values for this property are: + "LPM_RESET_LVL_NONE" - No power collapse + "LPM_RESET_LVL_RET" - Retention state + "LPM_RESET_LVL_GDHS" - Only control logic power collapse (GDHS) + "LPM_RESET_LVL_PC" - Control logic and memory logic + power collapse (PC) + +[Node bindings for qcom,pm-cpu] +qcom,pm-cpu contains the low power modes that a cpu could enter. Currently it +doesn't have any required properties and is a container for +qcom,pm-cpu-levels. + +[Node bindings for qcom,pm-cpu-levels] + Required properties: + - reg: The numeric cpu level id + - qcom,spm-cpu-mode: The sleep mode of the processor, values for the + property are: + "wfi" - Wait for Interrupt + "retention" - Retention + "standalone_pc" - Standalone power collapse + "pc" - Power Collapse + - qcom,latency-us: The latency in handling the interrupt if this level + was chosen, in uSec + - qcom,ss-power: The steady state power expelled when the processor is + in this level in mWatts + - qcom,energy-overhead: The energy used up in entering and exiting + this level in mWatts.uSec + - qcom,time-overhead: The time spent in entering and exiting this + level in uS + - qcom,use-broadcast-timer: Indicates that the timer gets reset during + power collapse and the cpu relies on Broadcast timer for scheduled + wakeups. Required only for states where the CPUs internal timer state + is lost. + + Optional properties: + - qcom,psci-mode-shift: Same as cluster level fields. + - qcom,psci-mode-mask: Same as cluster level fields. + - qcom,psci-cpu-mode: ID to be passed into PSCI firmware. + - qcom,jtag-save-restore: A boolean specifying jtag registers save and restore + required are not. + - qcom,is-reset: This boolean property maps to "power state" bit in PSCI + state_id configuration. This property will tell whether CPU get reset for + a particular LPM or not. This property will also be used to notify the + drivers in case of cpu reset. + +[Example dts] + +qcom,lpm-levels { + #address-cells = <1>; + #size-cells = <0>; + compatible = "qcom,lpm-levels"; + + qcom,pm-cluster@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + label = "system"; + qcom,spm-device-names = "cci"; + qcom,default-level = <0>; + + qcom,pm-cluster-level@0{ + reg = <0>; + label = "system-cci-retention"; + qcom,spm-cci-mode = "retention"; + qcom,latency-us = <100>; + qcom,ss-power = <1000>; + qcom,energy-overhead = <300000>; + qcom,time-overhead = <100>; + }; + + qcom,pm-cluster-level@2{ + reg = <1>; + label = "system-cci-pc"; + qcom,spm-cci-mode = "pc"; + qcom,latency-us = <30000>; + qcom,ss-power = <83>; + qcom,energy-overhead = <2274420>; + qcom,time-overhead = <6605>; + qcom,min-child-idx = <1>; + qcom,notify-rpm; + }; + + qcom,pm-cluster@0{ + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + label = "a53"; + qcom,spm-device-names = "l2"; + qcom,default-level=<0>; + qcom,cpu = <&CPU0 &CPU1 &CPU2 &CPU3>; + + qcom,pm-cluster-level@0{ + reg = <0>; + label = "a53-l2-retention"; + qcom,spm-l2-mode = "retention"; + qcom,latency-us = <100>; + qcom,ss-power = <1000>; + qcom,energy-overhead = <300000>; + qcom,time-overhead = <100>; + }; + + qcom,pm-cluster-level@1{ + reg = <1>; + label = "a53-l2-pc"; + qcom,spm-l2-mode = "pc"; + qcom,latency-us = <30000>; + qcom,ss-power = <83>; + qcom,energy-overhead = <2274420>; + qcom,time-overhead = <6605>; + qcom,min-child-idx = <3>; + }; + + qcom,pm-cpu { + #address-cells = <1>; + #size-cells = <0>; + qcom,pm-cpu-level@0 { + reg = <0>; + qcom,spm-cpu-mode = "wfi"; + qcom,latency-us = <1>; + qcom,ss-power = <715>; + qcom,energy-overhead = <17700>; + qcom,time-overhead = <2>; + }; + + qcom,pm-cpu-level@1 { + reg = <1>; + qcom,spm-cpu-mode = "retention"; + qcom,latency-us = <35>; + qcom,ss-power = <542>; + qcom,energy-overhead = <34920>; + qcom,time-overhead = <40>; + }; + + qcom,pm-cpu-level@2 { + reg = <2>; + qcom,spm-cpu-mode = "standalone_pc"; + qcom,latency-us = <300>; + qcom,ss-power = <476>; + qcom,energy-overhead = <225300>; + qcom,time-overhead = <350>; + }; + + qcom,pm-cpu-level@3 { + reg = <3>; + qcom,spm-cpu-mode = "pc"; + qcom,latency-us = <500>; + qcom,ss-power = <163>; + qcom,energy-overhead = <577736>; + qcom,time-overhead = <1000>; + }; + }; + }; + + qcom,pm-cluster@1{ + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + label = "a57"; + qcom,spm-device-names = "l2"; + qcom,default-level=<0>; + qcom,cpu = <&CPU4 &CPU5 &CPU6 &CPU7>; + + qcom,pm-cluster-level@0{ + reg = <0>; + label = "a57-l2-retention"; + qcom,spm-l2-mode = "retention"; + qcom,latency-us = <100>; + qcom,ss-power = <1000>; + qcom,energy-overhead = <300000>; + qcom,time-overhead = <100>; + }; + + qcom,pm-cluster-level@2{ + reg = <1>; + label = "a57-l2-pc"; + qcom,spm-l2-mode = "pc"; + qcom,latency-us = <30000>; + qcom,ss-power = <83>; + qcom,energy-overhead = <2274420>; + qcom,time-overhead = <6605>; + qcom,min-child-idx = <3>; + }; + + qcom,pm-cpu { + #address-cells = <1>; + #size-cells = <0>; + qcom,pm-cpu-level@0 { + reg = <0>; + qcom,spm-cpu-mode = "wfi"; + qcom,latency-us = <1>; + qcom,ss-power = <715>; + qcom,energy-overhead = <17700>; + qcom,time-overhead = <2>; + }; + + qcom,pm-cpu-level@1 { + reg = <1>; + qcom,spm-cpu-mode = "retention"; + qcom,latency-us = <35>; + qcom,ss-power = <542>; + qcom,energy-overhead = <34920>; + qcom,time-overhead = <40>; + }; + + qcom,pm-cpu-level@2 { + reg = <2>; + qcom,spm-cpu-mode = "standalone_pc"; + qcom,latency-us = <300>; + qcom,ss-power = <476>; + qcom,energy-overhead = <225300>; + qcom,time-overhead = <350>; + }; + + qcom,pm-cpu-level@3 { + reg = <3>; + qcom,spm-cpu-mode = "pc"; + qcom,latency-us = <500>; + qcom,ss-power = <163>; + qcom,energy-overhead = <577736>; + qcom,time-overhead = <1000>; + }; + }; + }; + }; + + +}; diff --git a/Documentation/devicetree/bindings/arm/msm/mdm-modem.txt b/Documentation/devicetree/bindings/arm/msm/mdm-modem.txt new file mode 100644 index 000000000000..6ddc72576e88 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/mdm-modem.txt @@ -0,0 +1,148 @@ +Attached MDM Modem Devices + +External modems are devices that are attached to the msm and controlled by gpios. +There is also a data channel between the msm and the external modem that sometimes needs +to be reset. + +Required Properties: +- compatible: The bus devices need to be compatible with + "qcom,mdm2-modem", "qcom,ext-mdm9x25", "qcom,ext-mdm9x35", "qcom, ext-mdm9x45", + "qcom,ext-mdm9x55". + +Required named gpio properties: +- qcom,mdm2ap-errfatal-gpio: gpio for the external modem to indicate to the apps processor + of an error fatal condition on the modem. +- qcom,ap2mdm-errfatal-gpio: gpio for the apps processor to indicate to the external modem + of an error fatal condition on the apps processor. +- qcom,mdm2ap-status-gpio: gpio to indicate to the apps processor when there is a watchdog + bite on the external modem. +- qcom,ap2mdm-status-gpio: gpio for the apps processor to indicate to the modem that an apps + processor watchdog bite has occurred. +- qcom,ap2mdm-soft-reset-gpio: gpio for the apps processor to use to soft-reset the external + modem. If the flags parameter has a value of 0x1 then the gpio is active LOW. + +Required Interrupts: +- "err_fatal_irq": Interrupt generated on the apps processor when the error fatal gpio is pulled + high by the external modem. +- "status_irq": Interrupt generated on the apps processor when the mdm2ap-status gpio falls low + on the external modem. This usually indicates a watchdog bite on the modem. +- "plbrdy_irq": Interrupt generated on the aps processor when the mdm2ap-pblrdy gpio is pulled + either high or low by the external modem. This is an indication that the modem + has rebooted. +- "mdm2ap_vddmin_irq": Interrupt generated on the apps processor when the external modem goes + into vddmin power state. + +Optional named gpio properties: +- qcom,mdm2ap-pblrdy-gpio: gpio used by some external modems to indicate when the modem has + booted into the PBL bootloader. +- qcom,ap2mdm-wakeup-gpio: gpio used by the apps processor to wake the external modem + out of a low power state. +- qcom,ap2mdm-chnl-rdy-gpio: gpio used by the apps processor to inform the external modem + that data link is ready. +- qcom,mdm2ap-wakeup-gpio: gpio from the external modem to the apps processor to wake it + out of a low power state. +- qcom,ap2mdm-vddmin-gpio: gpio to indicate to the external modem when the apps processor + is about to enter vddmin power state. +- qcom,mdm2ap-vddmin-gpio: gpio used by the external modem to inform the apps processor + when it is about to enter vddmin power state. +- qcom,ap2mdm-kpdpwr-gpio: gpio used to simulate a power button press on the external + modem. Some modems use this as part of their initial power-up sequence. + If the "flags" parameter has a value of 0x1 then it is active LOW. +- qcom,ap2mdm-pmic-pwr-en-gpio: Some modems need this gpio for the apps processor to enable + the pmic on the external modem. +- qcom,use-usb-port-gpio: some modems use this gpio to switch a port connection from uart to usb. + This is used during firmware upgrade of some modems. +- qcom,mdm-link-detect-gpio: some modems may support two interfaces. This gpio + indicates whether only one or both links can be used. + +Optional driver parameters: +- qcom,ramdump-delay-ms: time in milliseconds to wait before starting to collect ramdumps. + This interval is the time to wait after an error on the external modem is + signaled to the apps processor before starting to collect ramdumps. Its + value depends on the type of external modem (e.g. MDM vs QSC), and how + error fatal handing is done on the modem. + The default value is 2 seconds (2000 milliseconds) as specified by the + mdm9x15 software developer. Consultation with the developer of the modem + software is required to determine this value for that modem. +- qcom,ps-hold-delay-ms: minimum delay in milliseconds between consecutive PS_HOLD toggles. + SGLTE targets that use a QSC1215 modem require a minimum delay between consecutive + toggling of the PS_HOLD pmic input. For one target it is 500 milliseconds but it + may vary depending on the target and how the external modem is connected. The value + is specified by the hardware designers. +- qcom,early-power-on: boolean flag to indicate if to power on the modem when the device is probed. +- qcom,sfr-query: boolean flag to indicate if to query the modem for a reset reason. +- qcom,no-powerdown-after-ramdumps: boolean flag to indicate if to power down the modem after ramdumps. +- qcom,no-a2m-errfatal-on-ssr: boolean to tell driver not to raise ap2mdm errfatal during SSR. +- qcom,no-reset-on-first-powerup: boolean to tell driver not to reset the modem when first + powering up the modem. +- qcom,ramdump-timeout-ms: ramdump timeout interval in milliseconds. + This interval is the time to wait for collection of the external modem's ramdump + to complete. It's value depends on the speed of the data connection between the + external modem and the apps processor on the platform. If the connection is a + UART port then this delay needs to be longer in order to avoid premature timeout + of the ramdump collection. + The default value is 2 minutes (120000 milliseconds) which is based on the + measured time it takes over a UART connection. It is reduced when the data + connection is an HSIC port. The value is usually tuned empirically for a + particular target. +- qcom,image-upgrade-supported: boolean flag to indicate if software upgrade is supported. +- qcom,support-shutdown: boolean flag to indicate if graceful shutdown is supported. +- qcom,vddmin-drive-strength: drive strength in milliamps of the ap2mdm-vddmin gpio. + The ap2mdm_vddmin gpio is controlled by the RPM processor. It is pulled low + to indicate to the external modem that the apps processor has entered vddmin + state, and high to indicate the reverse. Its parameters are passed to the RPM + software from the HLOS because the RPM software has to way of saving this type + of configuration when an external modem is attached. + The value of the drive strength is specified by the hardware designers. A value + of 8 milliamps is typical. + This property is ignored if the property "qcom,ap2mdm-vddmin-gpio" is + not set. +- qcom,vddmin-modes: a string indicating the "modes" requested for the ap2mdm-vddmin gpio. + This value is passed to RPM and is used by the RPM module to determine the + gpio mux function. The only currently supported modes string is "normal" and + corresponds to the value 0x03 that is passed to RPM. +- qcom,restart-group: List of subsystems that will need to restart together. +- qcom,mdm-dual-link: Boolean indicates whether both links can used for + communication. +- qcom,ssctl-instance-id: Instance id used by the subsystem to connect with the SSCTL service. +- qcom,sysmon-id: platform device id that sysmon is probed with for the subsystem. +- qcom,pil-force-shutdown: Boolean. If set, the SSR framework will not trigger graceful shutdown + on behalf of the subsystem driver. + +Example: + mdm0: qcom,mdm0 { + compatible = "qcom,mdm2-modem"; + cell-index = <0>; + #address-cells = <0>; + interrupt-parent = <&mdm0>; + interrupts = <0 1 2 3>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xffffffff>; + interrupt-map = + <0 &msmgpio 82 0x3 + 1 &msmgpio 46 0x3 + 2 &msmgpio 80 0x3 + 3 &msmgpio 27 0x3>; + interrupt-names = + "err_fatal_irq", + "status_irq", + "plbrdy_irq", + "mdm2ap_vddmin_irq"; + + qcom,mdm2ap-errfatal-gpio = <&msmgpio 82 0x00>; + qcom,ap2mdm-errfatal-gpio = <&msmgpio 106 0x00>; + qcom,mdm2ap-status-gpio = <&msmgpio 46 0x00>; + qcom,ap2mdm-status-gpio = <&msmgpio 105 0x00>; + qcom,ap2mdm-soft-reset-gpio = <&msmgpio 24 0x00>; + qcom,mdm2ap-pblrdy-gpio = <&msmgpio 80 0x00>; + qcom,ap2mdm-wakeup-gpio = <&msmgpio 104 0x00>; + qcom,ap2mdm-vddmin-gpio = <&msmgpio 108 0x00>; + qcom,mdm2ap-vddmin-gpio = <&msmgpio 27 0x00>; + + qcom,ramdump-delay-ms = <2000>; + qcom,ramdump-timeout-ms = <120000>; + qcom,vddmin-modes = "normal"; + qcom,vddmin-drive-strength = <8>; + qcom,ssctl-instance-id = <10>; + qcom,sysmon-id = <20>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/mpm.txt b/Documentation/devicetree/bindings/arm/msm/mpm.txt new file mode 100644 index 000000000000..c3535cb65400 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/mpm.txt @@ -0,0 +1,77 @@ +* MSM Sleep Power Manager (mpm-v2) + +The MPM acts a sleep power manager to shutdown the clock source and put the +device into a retention mode to save power. The MPM is also responsible for +waking up and bringing up the resources from sleep. The MPM driver configures +interrupts monitored by the MPM hardware before entering sleep through a +RPM interface. + +The required nodes for the MPM driver are: + +- compatible: "qcom, mpm-v2" +- reg: Specifies the base physical address(s) and the size of the MPM + registers. The MPM driver access two memory regions for confifure the + virtual MPM driver on the RPM. The first region is the memory space + shared with the virtual MPM driver. The second region is the address + to the register that triggers a interrupt to the RPM. +- reg-names: "vmpm" - string to identify the shared memory space region + "ipc" - string to identify the register that triggers a interrupt +- clocks: clock identifers used by clock driver while looking up mpm clocks. +- clock-names: name of the clock used by mpm driver. +- qcom,ipc-bit-offset: The bit to set in the ipc register that triggers a interrupt + to the RPM +- qcom,gic-parent: phandle to the gic interrupt controller +- qcom,gic-map: Provides a mapping of how a GIC interrupt is connect to a MPM. The + mapping is presented in tuples. Each tuple represents a MPM pin and + which GIC interrupt is routed to it. Since MPM monitors interrupts + only during system wide low power mode, system interrupts originating + from other processors can be ignored and assigned an MPM pin mapping + of 0xff. +- qcom,gpio-parent: phandle to the GPIO interrupt controller +- qcom,gpio-map: Provides a mapping of how a GPIO interrupt is connect to a MPM. The + mapping is presented in tuples. Each tuple represents a MPM pin and + which GIC interrupt is routed to it. Since MPM monitors interrupts + only during system wide low power mode, system interrupts originating + from other processors can be ignored and assigned an MPM pin mapping + of 0xff. + +Optional Properties: + +- qcom,num-mpm-irqs : Specifies the number of mpm interrupts supported on a + target. If the property isn't present, 64 interrupts are + considered for the target by default. + +Example: + qcom,mpm@fc4281d0 { + compatible = "qcom,mpm-v2"; + reg = <0xfc4281d0 0x1000>, /* MSM_RPM_MPM_BASE 4K*/ + <0xfa006000 0x1000>; /* MSM_APCS_GCC_BASE 4K*/ + reg-names = "vmpm", "ipc" + interrupts = <0 171 1>; + clocks = <&clock_rpm clk_xo_lpm_clk>; + clock-names = "xo"; + + qcom,ipc-bit-offset = <0>; + + qcom,gic-parent = <&intc>; + qcom,gic-map = <25 132>, + <27 111>, + <0xff 48>, + <0xff 51>, + <0xff 52>, + <0xff 53>, + <0xff 54>, + <0xff 55>; + + qcom,gpio-parent = <&msmgpio>; + qcom,gpio-map = <1 46>, + <2 150>, + <4 103>, + <5 104>, + <6 105>, + <7 106>, + <8 107>, + <53 37>, + <54 24>, + <55 14>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/mpm_counter.txt b/Documentation/devicetree/bindings/arm/msm/mpm_counter.txt new file mode 100644 index 000000000000..ab0d3a0a48a1 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/mpm_counter.txt @@ -0,0 +1,18 @@ +* MSM MPM sleep counter (mpm-v2) + +The MPM provides a timetick that starts when the device is powered up and +is not reset by any of the boot loaders or the HLOS. The MPM timetick counter +driver provides an api to get this value. + +The required nodes for the MPM timetick counter driver are: + +- compatible: "qcom,mpm2-sleep-counter" +- reg: Specifies the physical address of the timetick count register. +- clock-frequency: the physical counter frequency. + +Example: + qcom,mpm2-sleep-counter@4a3000 { + compatible = "qcom,mpm2-sleep-counter"; + reg = <0x4a3000 0x1000>; + clock-frequency = <32768>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm-cpufreq.txt b/Documentation/devicetree/bindings/arm/msm/msm-cpufreq.txt new file mode 100644 index 000000000000..1b2b5948da0b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm-cpufreq.txt @@ -0,0 +1,48 @@ +Qualcomm MSM CPUfreq device + +msm-cpufreq is a device that represents the list of usable CPU frequencies +and provides a device handle for the CPUfreq driver to get the CPU and cache +clocks. + +Required properties: +- compatible: Must be "qcom,msm-cpufreq" +- qcom,cpufreq-table, or qcom,cpufreq-table-<X>: + A list of usable CPU frequencies (KHz). + Use "qcom,cpufreq-table" if all CPUs in the system + should share same list of frequencies. + Use "qcom,cpufreq-table-<cpuid>" to describe + different CPU freq tables for different CPUs. + The table should be listed only for the first CPU + if multiple CPUs are synchronous. + +Optional properties: +- clock-names: When DT based binding of clock is available, this + provides a list of CPU subsystem clocks. + "cpuX_clk" for every CPU that's present. + "l2_clk" when an async cache/CCI is present. + +Optional properties: +- qcom,governor-per-policy: This property denotes that governor tunables + should be associated with each cpufreq policy + group instead of being global. + +Example: + qcom,msm-cpufreq@0 { + regs = <0 4> + compatible = "qcom,msm-cpufreq"; + qcom,cpufreq-table = + < 300000 >, + < 422400 >, + < 652800 >, + < 729600 >, + < 883200 >, + < 960000 >, + < 1036800 >, + < 1190400 >, + < 1267200 >, + < 1497600 >, + < 1574400 >, + < 1728000 >, + < 1958400 >, + < 2265600 >; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm-spm.txt b/Documentation/devicetree/bindings/arm/msm/msm-spm.txt new file mode 100644 index 000000000000..194059c39c68 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm-spm.txt @@ -0,0 +1,169 @@ +* MSM Subsystem Power Manager (spm-v2) + +S4 generation of MSMs have SPM hardware blocks to control the Application +Processor Sub-System power. These SPM blocks run individual state machine +to determine what the core (L2 or Krait/Scorpion) would do when the WFI +instruction is executed by the core. The SAW hardware block handles SPM and +AVS functionality for the cores. + +The devicetree representation of the SPM block should be: + +Required properties + +- compatible: "qcom,spm-v2" +- reg: The physical address and the size of the SPM's memory mapped registers +- qcom,cpu: phandle for the CPU that the SPM block is attached to. This field +is required on only for SPMs that control the CPU. This field is not required +for SPMs that control L2/CCI/L3 +- qcom,saw2-ver-reg: The location of the version register +- qcom,name: The name with which a SPM device is identified by the power +management code. + +---------------------------------------------------- +Non-PSCI targets should follow the rules shown below +---------------------------------------------------- +Required properties for only Non-PSCI targets: + +- qcom,saw2-cfg: SAW2 configuration register +- qcom,saw2-spm-ctl: The SPM control register +- qcom,saw2-spm-dly: Provides the values for the SPM delay command in the SPM + sequence + +Optional properties for only Non-PSCI targets +- reg-names: Register names for the physical address required if spm device + has more than one physical addressed to be mapped. Allowed register + names are: "saw-base", "q2s", "hw-flush", "slpreq" +- qcom,saw2-avs-ctl: The AVS control register +- qcom,saw2-avs-hysterisis: The AVS hysterisis register to delay the AVS + controller requests +- qcom,vctl-timeout-us: The timeout value in us to wait for voltage to change + after sending the voltage command to the PMIC +- qcom,saw2-avs-limit: The AVS limit register +- qcom,saw2-avs-dly: The AVS delay register is used to specify the delay values + between AVS controller requests +- qcom,saw2-pmic-data0..7: Specify the pmic data value and the associated FTS + index to send the PMIC data to +- qcom,vctl-port: The PVC (PMIC Virtual Channel) port used for changing + voltage +- qcom,phase-port: The PVC port used for changing the number of phases +- qcom,pfm-port: The PVC port used for enabling PWM/PFM modes +- qcom,cpu-vctl-mask: Mask of cpus, whose voltage the spm device can control. + Depricated: Replaced with cpu-vctl-list when cpu phandles are available. +- qcom,cpu-vctl-list: List of cpu node phandles, whose voltage the spm device + can control. +- qcom,use-qchannel-for-pc: Boolean property to specify if qchannel should be + ignored when entering power collapse. If this property is set qchannel + will not be ignored in power collapse. +- qcom,supports-rpm-hs: Indicates that this SPM instance allow handshake with +RPM processor when executing the sleep command in the SPM sequence. Supported +only on SAW2 v3.0 and above. +- qcom,use-spm-clock-gating: This boolean property is used to indicate that + the SPM needs to be used for clock gating. Using the SPM for clock + gating would result in auto clock gating being disabled. Use this on + targets that do not support or do not use auto clock gating. +- qcom,use-qchannel-for-wfi: This boolean property is used to indicate + that the SPM gets triggerd by the qchannel and not by means of + wfi. So a wfe could trigger a spm for clock gating as well. +- modes: Lists all the available low power modes for the device + +Second level properties for modes + +Required properties (if modes node is available) +- qcom,label: Specifies the mode name such as: + qcom,saw2-spm-cmd-wfi: WFI mode + qcom,saw2-spm-cmd-ret: Retention mode + qcom,saw2-spm-cmd-spc: Standalone PC mode + qcom,saw2-spm-cmd-pc: Power Collapse mode + qcom,saw2-spm-cmd-gdhs: GDHS mode +- qcom,sequence: Specifies sequence for the low power mode +Optional properties +- qcom,pc_mode: Specifies pc_mode bit should be set in the SPM control register +- qcom,ret_mode: Specifies ret_mode bit should be set in the SPM control register +- qcom,spm_en: Specifies spm_en bit should be set in the SPM control register +- qcom,isar: Specifies isar bit should be set in the SPM control register + Specify this property only if SPM should retain its start address at + the end of the program. +- qcom,slp_cmd_mode: Specifies slp_cmd_mode bit should be set in SPM control register. + Adding this property results in SPM handshaking with RPM. Please remove + the RPM handshake command from the sleep sequence, replace that with + Sleep without RPM handshake command. +- qcom,event_sync: Specifies event_sync byte should be set in SPM control + register. + +---------------------------------------------------- +PSCI targets should follow the rules shown below +---------------------------------------------------- +Optional properties for only PSCI targets: + +- qcom,saw2-avs-ctl: The AVS control register +- qcom,saw2-avs-hysterisis: The AVS hysterisis register to delay the AVS + controller requests +- qcom,vctl-timeout-us: The timeout value in us to wait for voltage to change + after sending the voltage command to the PMIC +- qcom,saw2-avs-limit: The AVS limit register +- qcom,saw2-avs-dly: The AVS delay register is used to specify the delay values + between AVS controller requests +- qcom,vctl-port: The PVC (PMIC Virtual Channel) port used for changing + voltage +- qcom,phase-port: The PVC port used for changing the number of phases +- qcom,pfm-port: The PVC port used for enabling PWM/PFM modes +- qcom,cpu-vctl-list: List of cpu node phandles, whose voltage the spm device + can control. + + +Example 1: + qcom,spm@f9089000 { + compatible = "qcom,spm-v2"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xf9089000 0x1000>; + qcom,cpu = <&CPU0>; + qcom,saw2-ver-reg = <0xfd0>; + qcom,saw2-cfg = <0x1b>; + qcom,saw2-avs-ctl = <0>; + qcom,saw2-avs-hysteresis = <0>; + qcom,saw2-avs-limit = <0>; + qcom,saw2-avs-dly= <0>; + qcom,saw2-spm-dly= <0x20000400>; + qcom,saw2-spm-ctl = <0x1>; + qcom,cpu-vctl-list = <&CPU0 &CPU1 &CPU2 &CPU3>; + qcom,mode0 { + qcom,label = "qcom,saw2-spm-cmd-wfi"; + qcom,sequence = [03 0b 0f]; + qcom,spm_en; + }; + + qcom,mode1 { + qcom,label = "qcom,saw2-spm-cmd-spc"; + qcom,sequence = [00 20 50 80 60 70 10 92 + a0 b0 03 68 70 3b 92 a0 b0 + 82 2b 50 10 30 02 22 30 0f]; + qcom,spm_en; + qcom,pc_mode; + }; + + qcom,mode2 { + qcom,label = "qcom,saw2-spm-cmd-pc"; + qcom,sequence = [00 20 10 92 a0 b0 07 3b 92 + a0 b0 82 10 30 02 22 30 0f]; + qcom,spm_en; + qcom,pc_mode; + }; + }; + +Example 2: + qcom,spm@9A10000 { + compatible = "qcom,spm-v2"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x9A10000 0x1000>; + qcom,name = "system-cbf"; /* CBF SAW */ + qcom,saw2-ver-reg = <0xFD0>; + qcom,cpu-vctl-list = <&CPU0 &CPU1 &CPU2 &CPU3>; + qcom,vctl-timeout-us = <50>; + qcom,vctl-port = <0x0>; + qcom,phase-port = <0x1>; + qcom,saw2-avs-ctl = <0x1100>; + qcom,pfm-port = <0x2>; +}; + diff --git a/Documentation/devicetree/bindings/arm/msm/msm.txt b/Documentation/devicetree/bindings/arm/msm/msm.txt new file mode 100644 index 000000000000..02bf809740c3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm.txt @@ -0,0 +1,322 @@ +* Qualcomm Technologies, Inc. MSM + +MSM uses a combination of DTS and DTSI files to describe the hardware on various +SoCs and boards. Typically, a SoC-specific DTSI file describes the devices +present on a given SoC, and a board-specific DTSI file describes the devices +external to the SoC, although some targets may follow a more simplified +approach. Additionally, the SoC-specific DTSI files may further consist of a +base chip-specific file and a version-specific DTSI file, to facilitate reuse +of device definitions among multiple revisions of the same SoC. + +Required properties: +- compatible: Every device present on the MSM SoC shall have a 'qcom,' prefix + in its compatible string + +Example: +restart@fc4ab000 { + compatible = "qcom,pshold"; + reg = <0xfc4ab000 0x4>; +}; + + +* Compatible strings: + +SoCs: + +- APQ8016 + compatible = "qcom,apq8016" + +- APQ8026 + compatible = "qcom,apq8026" + +- APQ8074 + compatible = "qcom,apq8074" + +- APQ8084 + compatible = "qcom,apq8084" + +- APQ8094 + compatible = "qcom,apq8094" + +- APQ8096 + compatible = "qcom,apq8096" + +- APQ8937 + compatible = "qcom,apq8037" + +- APQTITANIUM + compatible = "qcom,apqtitanium" + +- APQ8998 + compatible = "qcom,apq8998" + +- MDM9630 + compatible = "qcom,mdm9630" + +- MSM8226 + compatible = "qcom,msm8226" + +- MSM8610 + compatible = "qcom,msm8610" + +- MSM8909 + compatible = "qcom,msm8909" + +- MSM8916 + compatible = "qcom,msm8916" + +- MSMGOLD + compatible = "qcom,msmgold" + +- MSM8936 + compatible = "qcom,msm8936" + +- MSM8960 + compatible = "qcom,msm8960" + +- MSM8992 + compatible = "qcom,msm8992" + +- MSM8994 + compatible = "qcom,msm8994" + +- MSM8996 + compatible = "qcom,msm8996" + +- MSM8998 + compatible = "qcom,msm8998" + +- MSMHAMSTER + compatible = "qcom,msmhamster" + +- SDM658 + compatible = "qcom,sdm658" + +- SDM660 + compatible = "qcom,sdm660" + +- SDA658 + compatible = "qcom,sda658" + +- SDA660 + compatible = "qcom,sda660" + +- SDM630 + compatible = "qcom,sdm630" + +- SDA630 + compatible = "qcom,sda630" + +- MSM8952 + compatible = "qcom,msm8952" + +- APQ8052 + compatible = "qcom,apq8052" + +- MSMTITANIUM + compatible = "qcom,msmtitanium" + +- MSM8937 + compatible = "qcom,msm8937" + +- MDM9640 + compatible = "qcom,mdm9640" + +- MDMCALIFORNIUM + compatible = "qcom,mdmcalifornium" + +- VPIPA + compatible = "qcom,msmvpipa" + +- MDM9607 + compatible = "qcom,mdm9607" + +Generic board variants: + +- CDP device: + compatible = "qcom,cdp" + +- MTP device: + compatible = "qcom,mtp" + +- FLUID device: + compatible = "qcom,fluid" + +- LIQUID device: + compatible = "qcom,liquid" + +- Dragonboard device: + compatible = "qcom,dragonboard" + +- SBC device: + compatible = "qcom,sbc" + +- SURF device: + compatible = "qcom,surf" + +- QRD device: + compatible = "qcom,qrd" + +- ADP device: + compatible = "qcom,adp" + +- Simulator device: + compatible = "qcom,sim" + +- RUMI device: + compatible = "qcom,rumi" + + + +Boards (SoC type + board variant): + +compatible = "qcom,apq8016" +compatible = "qcom,apq8026-cdp" +compatible = "qcom,apq8026-mtp" +compatible = "qcom,apq8026-xpm" +compatible = "qcom,apq8074-cdp" +compatible = "qcom,apq8074-dragonboard" +compatible = "qcom,apq8074-liquid" +compatible = "qcom,apq8084-cdp" +compatible = "qcom,apq8084-liquid" +compatible = "qcom,apq8084-mtp" +compatible = "qcom,apq8084-sbc" +compatible = "qcom,apq8094-cdp" +compatible = "qcom,apq8094-fluid" +compatible = "qcom,apq8094-liquid" +compatible = "qcom,apq8094-mtp" +compatible = "qcom,apq8094-dragonboard" +compatible = "qcom,apq8096-cdp" +compatible = "qcom,apq8096-mtp" +compatible = "qcom,apq8096-dragonboard" +compatible = "qcom,apq8096-sbc" +compatible = "qcom,apq8096-liquid" +compatible = "qcom,apq8037-cdp" +compatible = "qcom,apq8037-mtp" +compatible = "qcom,apqtitanium-cdp" +compatible = "qcom,apqtitanium-mtp" +compatible = "qcom,apq8998-cdp" +compatible = "qcom,apq8998-mtp" +compatible = "qcom,apq8998-qrd" +compatible = "qcom,mdm9630-cdp" +compatible = "qcom,mdm9630-mtp" +compatible = "qcom,mdm9630-sim" +compatible = "qcom,msm8226-cdp" +compatible = "qcom,msm8226-fluid" +compatible = "qcom,msm8226-mtp" +compatible = "qcom,msm8226-qrd" +compatible = "qcom,msm8226-sim" +compatible = "qcom,msm8610-cdp" +compatible = "qcom,msm8610-mtp" +compatible = "qcom,msm8610-qrd" +compatible = "qcom,msm8610-rumi" +compatible = "qcom,msm8610-sim" +compatible = "qcom,msm8660-surf" +compatible = "qcom,msm8909-cdp" +compatible = "qcom,msm8909-mtp" +compatible = "qcom,msm8909-qrd" +compatible = "qcom,msm8909-rumi" +compatible = "qcom,msm8909-sim" +compatible = "qcom,msm8916-cdp" +compatible = "qcom,msm8916-mtp" +compatible = "qcom,msm8916-qrd-skuh" +compatible = "qcom,msm8916-qrd-skuhf" +compatible = "qcom,msm8916-qrd-skui" +compatible = "qcom,msm8916-qrd-skuic" +compatible = "qcom,msm8916-qrd-skuid" +compatible = "qcom,msm8916-qrd-skut1" +compatible = "qcom,msm8916-rumi" +compatible = "qcom,msm8916-sim" +compatible = "qcom,msmgold-rumi" +compatible = "qcom,msm8926-cdp" +compatible = "qcom,msm8926-mtp" +compatible = "qcom,msm8926-qrd" +compatible = "qcom,msm8936-cdp" +compatible = "qcom,msm8936-mtp" +compatible = "qcom,msm8939-cdp" +compatible = "qcom,msm8939-mtp" +compatible = "qcom,msm8939-qrd-skuk" +compatible = "qcom,msm8939-qrd-skul" +compatible = "qcom,msm8939-rumi" +compatible = "qcom,msm8939-sim" +compatible = "qcom,msm8960-cdp" +compatible = "qcom,msm8974-cdp" +compatible = "qcom,msm8974-fluid" +compatible = "qcom,msm8974-liquid" +compatible = "qcom,msm8974-mtp" +compatible = "qcom,msm8974-rumi" +compatible = "qcom,msm8974-sim" +compatible = "qcom,msm8992-cdp" +compatible = "qcom,msm8992-mtp" +compatible = "qcom,msm8992-rumi" +compatible = "qcom,msm8992-sim" +compatible = "qcom,msm8994-cdp" +compatible = "qcom,msm8994-fluid" +compatible = "qcom,msm8994-liquid" +compatible = "qcom,msm8994-mtp" +compatible = "qcom,msm8994-rumi" +compatible = "qcom,msm8994-sim" +compatible = "qcom,msm8996-rumi" +compatible = "qcom,msm8996-sim" +compatible = "qcom,msm8996-cdp" +compatible = "qcom,msm8996-dtp" +compatible = "qcom,msm8996-fluid" +compatible = "qcom,msm8996-liquid" +compatible = "qcom,msm8996-mtp" +compatible = "qcom,msm8996-adp" +compatible = "qcom,msm8998-sim" +compatible = "qcom,msm8998-rumi" +compatible = "qcom,msm8998-cdp" +compatible = "qcom,msm8998-mtp" +compatible = "qcom,msm8998-qrd" +compatible = "qcom,msmhamster-rumi" +compatible = "qcom,msmhamster-cdp" +compatible = "qcom,msmhamster-mtp" +compatible = "qcom,sdm658-cdp" +compatible = "qcom,sdm658-mtp" +compatible = "qcom,sdm658-qrd" +compatible = "qcom,sdm660-sim" +compatible = "qcom,sdm660-rumi" +compatible = "qcom,sdm660-cdp" +compatible = "qcom,sdm660-mtp" +compatible = "qcom,sdm660-qrd" +compatible = "qcom,sda658-mtp" +compatible = "qcom,sda658-cdp" +compatible = "qcom,sda660-mtp" +compatible = "qcom,sda660-cdp" +compatible = "qcom,sdm630-rumi" +compatible = "qcom,sdm630-mtp" +compatible = "qcom,sdm630-cdp" +compatible = "qcom,sda630-mtp" +compatible = "qcom,sda630-cdp" +compatible = "qcom,sdm630-qrd" +compatible = "qcom,msm8952-rumi" +compatible = "qcom,msm8952-sim" +compatible = "qcom,msm8952-qrd" +compatible = "qcom,msm8952-qrd-skum" +compatible = "qcom,msm8952-cdp" +compatible = "qcom,msm8952-mtp" +compatible = "qcom,apq8052-cdp" +compatible = "qcom,apq8052-mtp" +compatible = "qcom,msm8937-rumi" +compatible = "qcom,msm8937-cdp" +compatible = "qcom,msm8937-mtp" +compatible = "qcom,msm8937-qrd" +compatible = "qcom,msm8937-pmi8950-qrd-sku1" +compatible = "qcom,msm8937-pmi8937-qrd-sku2" +compatible = "qcom,msmtitanium-rumi" +compatible = "qcom,msmtitanium-sim" +compatible = "qcom,msmtitanium-cdp" +compatible = "qcom,msmtitanium-mtp" +compatible = "qcom,mdm9640-cdp" +compatible = "qcom,mdm9640-mtp" +compatible = "qcom,mdm9640-rumi" +compatible = "qcom,mdm9640-sim" +compatible = "qcom,msmvpipa-sim" +compatible = "qcom,mdm9607-rumi" +compatible = "qcom,mdm9607-cdp" +compatible = "qcom,mdm9607-mtp" +compatible = "qcom,mdmcalifornium-rumi" +compatible = "qcom,mdmcalifornium-sim" +compatible = "qcom,mdmcalifornium-cdp" +compatible = "qcom,mdmcalifornium-mtp" diff --git a/Documentation/devicetree/bindings/arm/msm/msm_bus.txt b/Documentation/devicetree/bindings/arm/msm/msm_bus.txt new file mode 100644 index 000000000000..117907b00033 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_bus.txt @@ -0,0 +1,258 @@ +MSM Bus Devices + +The bus devices (fabrics/NoCs) are the interconnects between various +components on chipsets. These devices form the backbone of the chip +topology. Entire topology of the chipset is built using the +device-tree data of these bus devices. + +To add the bus devices following properties are required: + +compatible: The bus devices need to be compatible with + msm-bus-fabric +cell-id: A 32 bit integer unique per bus per chipset. The IDs + for buses are in multiples of 1024. +label: Bus name +qcom,fabclk-dual: Dual set (active/sleep) bus clock name +qcom,fabclk-active: Active set bus clock name +qcom,nfab: An integer property which specifies the total number + of buses on the chipset. + +The following properties are optional as a bus might not support +these features: + +qcom,ntieredslaves: Number of tiered slaves on the bus. +qcom,qos-freq: QoS frequency (In KHz) +qcom,hw-sel: A string which decides whether QoS data + should be sent to RPM, set using BIMC or NoCs. + It can be set to "RPM", "NoC" or "BIMC". +qcom,qos-baseoffset: Base address offset of QoS registers from the bus device + base address. +qcom,qos-delta: Address delta between QoS registers of different masters. +qcom,rpm-en: A boolean flag indicating whether RPM transactions are + supported for nodes of the bus. +qcom,ahb: A boolean flag indicating whether the bus is ahb type. +qcom,virt: A boolean property indicating this is a virtual bus. +reg: Register space of the bus device. Not required in case + the bus is virtual. +qom,nr-lim-thresh The threshold below which to apply throttling of non + real time masters. +qcom,eff-fact The DDR effeciency factor to be assumed. This only + comes into play for buses that connect to the DDR. + + +The following properties are optional as collecting data via coresight might +not be supported for every bus. The documentation for coresight properties +can be found in: +Documentation/devicetree/bindings/coresight/coresight.txt + +coreisght-id Unique integer identifier for the bus. +coresight-name Unique descriptive name of the bus. +coresight-nr-inports Number of input ports on the bus. +coresight-outports List of output port numbers on the bus. +coresight-child-list List of phandles pointing to the children of this + component. +coresight-child-ports List of input port numbers of the children. + + +Any interconnect on the bus is represented as a child node. +A child node can be of type: master, slave or a gateway. +A gateway is an interconnect between buses and can be of both +master and slave type. + +The following properties are available to characterize a child node. +The properties can be chosen depending on the type of child node. + +cell-id: For a master the ID is between 0 - 512 + For a slave the ID is between 512 - 1024 +label: Name of the master/slave/gateway +qcom,masterp: Hardware master port number(s) +qcom,tier: The tier to which a master/slave belongs. + Note that tiering might not be supported on + all architectures. +qcom,hw-sel: A string which decides whether QoS data should be sent + to RPM, set using BIMC or NoCs. + It can be set to "RPM", "NoC" or "BIMC". +qcom,mode: Used for masters on NoC/BIMC. Indicates which of the + four modes (Fixed/Limiter/Bypass/Regulator) the master + belongs to. +qcom,perm-mode: Permissible mode switches. Indicates which of the four + modes are supported of the master node. Generally, + modes are set at boot-up and not switched at run-time. +qcom,qport: QoS port number. This can be different from the + master-port number. +qcom,ws: Window size (in Hz), used for NoC/BIMC masters to + calculate saturation values. +qcom,mas-hw-id: A unique hardware ID agreed upon by processors across + the system. This ID is assigned to every master. It can + be used to send master specific data from + Apps/Modem/LPASS to RPM. +qcom,slv-hw-id: A unique hardware ID agreed upon by processors across + the system. This ID is assigned to every slave. It can + be used to send slave specific data from +qcom,slaveclk-dual: Dual set (active/sleep) slave clock name +qcom,slaveclk-active: Active set slave clock name + Apps/Modem/LPASS to RPM. +qcom,gateway: Flag indicating whether a particular node is a gateway. +qcom,slavep: Hardware slave port number(s). +qcom,buswidth: Width of the interconnect between a node and the bus. + (In Bytes). +qcom,prio-rd: Read priority for a BIMC bus master (Can be 0/1/2) +qcom,prio-wr: Write priority for a BIMC bus master (Can be 0/1/2) +qcom,prio0: Priority low signal for a NoC bus master + (Can be 0/1/2). +qcom,prio1: Priority high signal for a NoC bus master + (Can be 0/1/2) +qcom,dual-conf: Indicates whether a BIMC/NoC master can be configured + in multiple modes at run-time. (Boolean) +qcom,mode-thresh: Threshold mode for a BIMC/NoC master. Beyond a certain + threshold frequency, a threshold mode can be used. + (Can be Fixed/Limiter/Bypass/Regulator) +qcom,bimc,bw: Bandwidth limit for a BIMC master using dual modes. + This bandwidth is used to calculate Grant count and + other parameters used in Limiter and Regular mode. + for static BKE configuration. It is defined in KBytes/s. +qcom,bimc,gp: Grant Period for configuring a master in limiter + mode. This is an integer value in nano-seconds. +qcom,bimc,thmp: Medium threshold percentage for BIMC masters. + This percentage is used to calculate medium threshold + value for BIMC Masters in Limiter mode for static + configuration. This can be any integer value between + 1 and 100. +qcom,thresh: Beyond this threshold frequency, the mode usage is + switched from mode specified by property qcom,mode + to the one specified by qcom,mode-thresh. These thresholds + can be setup in increasing order of thresholds, so the + requested IB is evaluated at each threshold level before + making the decision to switch QoS modes and applying the + corresponding qcom,bimc,bw limitig bw as needed. + This is specified in KBytes/s. +qcom,rt-mas: Indicates if a master node is a realtime master with + hard deadlines. +qcom,nr-lim: Indicates that this is non-real time master which can + be throttled in case of concurrent scenarios. +qcom,floor-bw: Represents the floor bandwidth below which this master + cannot be throttled. This floor bandwidth is specified in + KBytes/s. +qcom,ff: The fudge factor used by clients when voting for + bandwidth from the node. + + + +Example: + + + msm-mmss-noc@fc478000 { + compatible = "msm-bus-fabric"; + reg = <0xfc478000 0x00004000>; + cell-id = <2048>; + label = "msm_mmss_noc"; + qcom,fabclk-dual = "bus_clk"; + qcom,fabclk-active = "bus_a_clk"; + qcom,ntieredslaves = <0>; + qcom,qos-freq = <4800>; + qcom,hw-sel = "NoC"; + qcom,rpm-en; + qcom,nfab = <6>; + + mas-gfx3d { + cell-id = <26>; + label = "mas-gfx3d"; + qcom,masterp = <2 3>; + qcom,tier = <2>; + qcom,hw-sel = "NoC"; + qcom,perm-mode = "Bypass"; + qcom,mode = "Bypass"; + qcom,ws = <10000>; + qcom,qport = <2 3>; + qcom,mas-hw-id = <6>; + }; + + mas-jpeg { + cell-id = <62>; + label = "mas-jpeg"; + qcom,masterp = <4>; + qcom,tier = <2>; + qcom,hw-sel = "NoC"; + qcom,perm-mode = "Bypass"; + qcom,mode = "Bypass"; + qcom,qport = <0>; + qcom,ws = <10000>; + qcom,mas-hw-id = <7>; + }; + }; + + msm-bimc@0xfc380000 { + compatible = "msm-bus-fabric"; + reg = <0xfc380000 0x0006A000>; + cell-id = <0>; + label = "msm_bimc"; + qcom,fabclk-dual = "mem_clk"; + qcom,fabclk-active = "mem_a_clk"; + qcom,ntieredslaves = <0>; + qcom,qos-freq = <19200>; + qcom,hw-sel = "BIMC"; + qcom,rpm-en; + + coresight-id = <55>; + coresight-name = "coresight-bimc"; + coresight-nr-inports = <0>; + coresight-outports = <0>; + coresight-child-list = <&funnel_in1>; + coresight-child-ports = <3>; + + mas-ampss-m0 { + cell-id = <1>; + label = "mas-ampss-m0"; + qcom,masterp = <0>; + qcom,tier = <2>; + qcom,hw-sel = "BIMC"; + qcom,mode = "Limiter"; + qcom,qport = <0>; + qcom,ws = <10000>; + qcom,mas-hw-id = <0>; + qcom,prio-rd = <0>; + qcom,prio-wr = <0>; + qcom,mode-thresh = "Fixed"; + qcom,thresh = <2000000>; + qcom,dual-conf; + qcom,bimc,bw = <300000>; + qcom,bimc,gp = <5>; + qcom,bimc,thmp = <50>; + }; + }; + + + + +The bus scaling driver also provides the ability to configure +bus performance parameters across the entire chip-set. +Various clients use MSM scaling APIs to request bandwidth +between multiple master-slave pairs. The bus driver then finds +the optimal path between the master and the slave, and aggregates +the bandwidth and clock requests for all master-slave pairs on +that path, and programs hardware accordingly. + +The device-tree data required for bus-scaling can be embedded within +the clients' device nodes. The clients can register with the bus driver +using the following properties: + +- qcom,msm-bus,name: String representing the client-name +- qcom,msm-bus,num-cases: Total number of usecases +- qcom,msm-bus,active-only: Boolean context flag for requests in active or + dual (active & sleep) contex +- qcom,msm-bus,num-paths: Total number of master-slave pairs +- qcom,msm-bus,vectors-KBps: Arrays of unsigned integers representing: + master-id, slave-id, arbitrated bandwidth + in KBps, instantaneous bandwidth in KBps + +Example: + + qcom,msm-bus,name = "client-name"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,active-only; + qcom,msm-bus,num-paths = <2>; + qcom,msm-bus,vectors = + <22 512 0 0>, <26 512 0 0>, + <22 512 320000 3200000>, <26 512 3200000 3200000>, + <22 512 160000 1600000>, <26 512 1600000 1600000>; + diff --git a/Documentation/devicetree/bindings/arm/msm/msm_bus_adhoc.txt b/Documentation/devicetree/bindings/arm/msm/msm_bus_adhoc.txt new file mode 100644 index 000000000000..e0c2a9f01448 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_bus_adhoc.txt @@ -0,0 +1,231 @@ +MSM Bus Devices for adhoc bus topologies + +Buses are the interconnects between various devices. The devices are +connected in different topologies. The bus scaling driver accepts +bandwidth requests from clients and ensures that the bandwidth requests +can be met between the source and destination for that client. +In order to accept and honor bandwidth requests the bus scaling driver +needs to know about the bus topology. +This device tree binding represents the bus devices in the SOC, their +connections to other bus devices and the resources associated with each +node. The bus scaling driver uses this device tree to setup the bus +topology in order to apply client bandwidth requests. + +The mandatory properties for bus driver are: + +compatible: "qcom,msm-bus-device" + +The register space associated with the bus devices are represented with +the following optional properties: +reg: Register space for a bus device. +reg-name: Name of the register space for the bus device. + +The child nodes represent the devices on the bus. + +The following properties are mandatory for a child node + +cell-id: The unique device id of the child node. + For a master the ID is between 0 - 512 + For a slave the ID is between 512 - 1024 + For internal nodes the range is > 10000 + The range of ids for the different types of child + devices are chosen for convenience, the only + requirement is that the id's be unique among the + child devices. +label: Unique name of the device. + +The following are optional properties for child nodes: + + +qcom,fab-dev: Optional boolean parameter that states if the device + is a fabric device or not. + Typically these optional properties are used for + devices that represent fabric devices. +qcom,bypass-qos-prg: Optional debug parameter to avoid programming the QoS + HW registers for a given fabric device. + Typically these optional properties are used for + devices that represent fabric devices. +qcom,base-name: Parameter that specifies the physical base address for + accessing registers associated with the child device. + Typically these optional properties are used for + devices that represent fabric devices. +qcom,base-offset: Parameter that gives the offset from the base address to access + the QoS registers. + Typically these optional properties are used for + devices that represent fabric devices. +qcom,qos-off: Parameter that represents the delta between QoS register address + space for different devices. + Typically these optional properties are used for + devices that represent fabric devices. +qcom,agg-scheme: Parameter that represents the aggregation scheme to be used for the + node. This parameter defaults to LEGACY scheme. The valid options + are LEGACY/SCHEME_1. +qcom,util-fact: Parameter that represents the DDR utilization factor to be used in + LEGACY scheme. It is represented as actual util-factor * 100. +qcom,vrail-comp: Parameter that represents the voltage rail compensation to push + the bus to the next level if needed in LEGACY and SCHEME 1 aggregation + schemes. It is represented as actual vrail-comp * 100. +qcom,util-levels: Array of tuples that represent a bandwidth threshold and util factor + to be used uptil the given threshold. +qcom,bus-type: Parameter that represents the bus type such as BIMC or NOC. + Typically these optional properties are used for + devices that represent fabric devices. +bus-gdsc-supply: Optional fabric device parameter that is a reference to the dual + context GDSC supply that is needed before clock operations. +bus-a-gdsc-supply: Optional fabric device parameter that is a reference to an active + only context GDSC supply that is needed before clock operations. +bus-qos-gdsc-supply: Optional node or fabric device parameter that is a reference to a GDSC + supply that is needed before use of the clock needed to program + QoS registers. +node-gdsc-supply: Optional node device parameter that is a reference to a GDSC supply + that is needed before node-clock operations. +qcom,enable-only-clk: Optional property that is represents if the clock doesn't support + the clk_set_rate API and should only be enabled/disabled. +qcom,setrate-only-clk: Optional property that is indicates that bus driver should only + set a rate on a clock handle and not call the enable/disable + clock API. +clock-names: Optional property that represents the clock name associated + with the device "bus_clk", "bus_a_clk"; +clocks: Property pair that represents the clock controller and the clock + id. This in combimination with the clock-name is used to obtain + the handle for the clock associated with this device. +qcom,virt-dev: Parameter used for devices that represent virtual devices. Virtual + devices aren't real devices on the SOC but are used to aggregate + resources in some special cases. +qcom,qport: The offset index into the masters QoS register space. +qcom,num-ports: The number of ports that the device has. +qcom,ap-owned: Property that states if the device is "owned" by the Apps processor. + If true then the AP will program the QoS registers for the device + else it is done by RPM. +qcom,connections: An array of phandles that represent the devices this device is connected to.; +qcom,bus-dev: Phandle that represents the fabric device that this child node belongs to. +qcom,qos-mode: QoS mode to be programmed for this device, only applicable for AP owned resource. +qcom,prio-rd: Read priority for a BIMC bus master (Can be 0/1/2) +qcom,prio-wr: Write priority for a BIMC bus master (Can be 0/1/2) +qcom,prio0: Priority low signal for a NoC bus master + (Can be 0/1/2). +qcom,reg-prio1: Regulator mode Priority high signal for a NoC bus master if the master port is in + regulator QoS mode +qcom,reg-prio0: Regulator Priority low signal for a NoC bus master if the master port is in + regulator Qos mode. + (Can be 0/1/2). +qcom,prio1: Priority high signal for a NoC bus master +qcom,bw_buffer: Optional parameter in KBytes used to specify a buffer value that should be added to + the voted bandwidth value to figure out the limiting bandwidth for a master port. +qcom,buswidth: The buswidth at the device, default is 8 bytes. +qcom,mas-rpm-id: For non-AP owned device this is the RPM id for devices that are bus masters. + This is the id that is used when sending a message to RPM for this device. +qcom,slv-rpm-id: For non-AP owned device this is the RPM id for devices that are bus slaves. + This is the id that is used when sending a message to RPM for this device. +qcom,blacklist: An array of phandles that represent devices that this device + cannot connect to either directly or via any number of + intermediate nodes. +qcom,agg-ports: The number of aggregation ports on the bus. + +The following properties are optional as collecting data via coresight might +and are present on child nodes that represent NOC devices. The documentation +for coresight properties can be found in: +Documentation/devicetree/bindings/coresight/coresight.txt + +coreisght-id Unique integer identifier for the bus. +coresight-name Unique descriptive name of the bus. +coresight-nr-inports Number of input ports on the bus. +coresight-outports List of output port numbers on the bus. +coresight-child-list List of phandles pointing to the children of this + component. +coresight-child-ports List of input port numbers of the children. + +The following sub-nodes are optional paramters: + +qcom,node-qos-clks: Optional node listing all the clocks and regulators required for programming of + QoS registers. Usually these are associated with fabric nodes. + clock-names: An array of clock names for QoS programming, + clocks: An array of clock phandles corresponding to the clock names listed above. + clock-name-gdsc: + An optional property listing the regulator associated with a given clock name. + +Example: + +&ad_hoc_bus { + compatible = "msm-bus-device"; + reg = <0x580000 0x62000>; + reg-names = "snoc-base"; + + fab_snoc: fab-snoc { + cell-id = <1024>; + label = "fab-snoc"; + qcom,fab-dev; + qcom,bypass-qos-prg; + qcom,agg-scheme = <SCHEME_1>; + qcom,util-levels = <450000 133>, + <750000 154>; + qcom,base-name = "snoc-base"; + qcom,base-offset = <0x7000>; + qcom,qos-off = <0x1000>; + qcom,bus-type = <1>; + clock-names = "bus_clk", "bus_a_clk"; + clocks = <&clock_rpm clk_snoc_msmbus_clk>, + <&clock_rpm clk_snoc_msmbus_a_clk>; + qcom,node-qos-clks { + clock-names = "q0-clk", "q1-clk"; + clocks = <&clock_gcc clk_q0_clk>, + <&clock_gcc clk_q1_clk>; + q0-clk-supply = <&gdsc_q0_clk>; + }; + }; + + mm_int_bimc: mm-int-bimc { + cell-id = <10003>; + label = "mm-int-bimc"; + qcom,util-fact = <154>; + qcom,vrail-comp = <100>; + qcom,ap-owned; + qcom,connections = <&snoc_bimc_1_mas>; + qcom,bus-dev = <&fab_snoc>; + qcom,buswidth = <16>; + }; + + snoc_int_0: snoc-int-0 { + cell-id = <10004>; + label = "snoc-int-0"; + qcom,connections = <&slv_qdss_stm &slv_imem &snoc_pnoc_mas>; + qcom,bus-dev = <&fab_snoc>; + qcom,mas-rpm-id = <99>; + qcom,slv-rpm-id = <130>; + qcom,buswidth = <8>; + }; +}; + + +The bus scaling driver also provides the ability to configure +bus performance parameters across the entire chip-set. +Various clients use MSM scaling APIs to request bandwidth +between multiple master-slave pairs. The bus driver then finds +the optimal path between the master and the slave, and aggregates +the bandwidth and clock requests for all master-slave pairs on +that path, and programs hardware accordingly. + +The device-tree data required for bus-scaling can be embedded within +the clients' device nodes. The clients can register with the bus driver +using the following properties: + +- qcom,msm-bus,name: String representing the client-name +- qcom,msm-bus,num-cases: Total number of usecases +- qcom,msm-bus,active-only: Boolean context flag for requests in active or + dual (active & sleep) contex +- qcom,msm-bus,num-paths: Total number of master-slave pairs +- qcom,msm-bus,vectors-KBps: Arrays of unsigned integers representing: + master-id, slave-id, arbitrated bandwidth + in KBps, instantaneous bandwidth in KBps + +Example: + + qcom,msm-bus,name = "client-name"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,active-only; + qcom,msm-bus,num-paths = <2>; + qcom,msm-bus,vectors = + <22 512 0 0>, <26 512 0 0>, + <22 512 320000 3200000>, <26 512 3200000 3200000>, + <22 512 160000 1600000>, <26 512 1600000 1600000>; + diff --git a/Documentation/devicetree/bindings/arm/msm/msm_bus_rules.txt b/Documentation/devicetree/bindings/arm/msm/msm_bus_rules.txt new file mode 100644 index 000000000000..b68284c8970d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_bus_rules.txt @@ -0,0 +1,62 @@ +MSM Bus static bandwidth rules for adhoc bus topologies + +Buses are the interconnects between various devices. The devices are +connected in different topologies. The static bandwidth rules allow +setting up SOC specific rules to monitor certain bandwidth requests +at different bus nodes. When the conditions of the rule are met +the bus driver will be given a list of actions to be take on specific +bus master ports (throttle on/off, what bandwidth to throttle to etc). + +The mandatory properties for bus driver are: + +compatible: "qcom,msm-bus-static-bw-rules" + +The static_rules node can have numerous rules for the different bandwidth voting +conditions to be monitored. The mandatory properties for the rules are + +- qcom,src-nodes: An array of phandles denoting the source nodes + whose bandwidth votes need to be monitored. +- qcom,src-field: This field represents the voted field of the + source node to be monitored. Possible values + are FLD_IB/FLD_AB/FLD_CLK +- qcom,src-op: The operand to be used when evaluating a node's + bandwidth vote with a threshold.Possible values + are OP_LE/OP_LT/OP_GT/OP_GE. +- qcom,thresh: The threshold in Kbytes/s to be used in vote + evaluation. +- qcom,mode: The QoS mode to be applied when this rule's + criterion are satisfied. Possible values are + THROTTLE_ON/THROTTLE_OFF +- qcom,dest-node: An array of phandles representing the nodes to + which the QoS mode is to be applied. + +The optional properties for the rule node are: +- qcom,dest-bw: The destination bandwidth value in Kbytes/s to + be used toward the QoS mode for the destination + node. + +Example: + static-rules { + compatible = "qcom,msm-bus-static-bw-rules"; + #address-cells = <1>; + #size-cells = <0>; + + rule@0 { + qcom,src-nodes = <&mas_apss>; + qcom,src-field = <FLD_IB>; + qcom,src-op = <OP_LE>; + qcom,thresh = <1599078>; + qcom,mode = <THROTTLE_ON>; + qcom,dest-node = <&mas_apss>; + qcom,dest-bw = <1599078>; + }; + + rule@1 { + qcom,src-nodes = <&mas_apss>; + qcom,src-field = <FLD_IB>; + qcom,src-op = <OP_GT>; + qcom,thresh = <1599078>; + qcom,mode = <THROTTLE_OFF>; + qcom,dest-node = <&mas_apss>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_core.txt b/Documentation/devicetree/bindings/arm/msm/msm_core.txt new file mode 100644 index 000000000000..f3859157a26f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_core.txt @@ -0,0 +1,71 @@ +MSM Core Energy Aware driver + +The Energy Aware driver provides per core power and temperature +information to the scheduler for it to make more power efficient +scheduling decision. + +The required properties for the Energy-aware driver are: + +- compatible: "qcom,apss-core-ea" +- reg: Physical address mapped to this device + +Required nodes: +- ea@X: Parent node that has the sensor mapping for each cpu. + This node's phandle is provided within cpu node + to invoke/probe energy-aware only for available cpus. + There should be one such node present for each cpu. + +Optional properties: +- qcom,low-hyst-temp: Degrees C below which the power numbers + need to be recomputed for the cores and reset + the threshold. If this is not present, the default + value is 10C. +- qcom,high-hyst-temp: Degrees C above which the power numbers + need to be recomputed for the cores and reset + the threshold. If this property is not present, + the default value is 5C. +- qcom,polling-interval: Interval for which the power numbers + need to be recomputed for the cores if there + is no change in threshold. If this property is not + present, the power is recalculated only on + temperature threshold notifications. +-qcom,throttling-temp: Temperature threshold for cpu frequency mitigation. + The value should be set same as the threshold temperature + in thermal module - 5 C, such that there is a bandwidth to + control the cores before frequency mitigation happens. + +[Second level nodes] +Require properties to define per core characteristics: +- sensor: Sensor phandle to map a particular sensor to the core. + If this property is not present, then the core is assumed + to be at 40C for all the power estimations. No sensor + threshold is set. This phandle's compatible property is + "qcom,sensor-information". This driver relies on the + sensor-type and scaling-factor information provided in this + phandle. + +Example + +qcom,msm-core@0xfc4b0000 { + compatible = "qcom,apss-core-ea"; + reg = <0xfc4b0000 0x1000>; + qcom,low-hyst-temp = <10>; + qcom,high-hyst-temp = <5>; + qcom,polling-interval = <50>; + + ea0: ea0 { + sensor = <&sensor_information0>; + }; + + ea1: ea1 { + sensor = <&sensor_information1>; + }; + +}; + +CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x0>; + qcom,ea = <&ea0>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_gladiator_hang_detect.txt b/Documentation/devicetree/bindings/arm/msm/msm_gladiator_hang_detect.txt new file mode 100644 index 000000000000..1935a092f857 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_gladiator_hang_detect.txt @@ -0,0 +1,40 @@ +Gladiator Hang Detection provides sysfs entries for configuring +thresholds and enable on ACE_port, IO_port, M1_port, M2_port, +and PCIO_port + +If gladiator is hung for threshold time (value * 5ns) and no +heart beat event from gladiator port to gladiator hang monitor +detection, gladiator hang interrupt would be generated to reset +the SOC to collect all cores context. + +Gladiator hang detection can be enabled on different ports. + +Writing 1 into ace_enabled sysfs entry, enables gladiator hang +detection on ACE port +Writing 1 into io_enabled sysfs entry, enables gladiator hang +detection on IO port +Writing 1 into ace_enabled sysfs entry, enables gladiator hang +detection on M1 port +Writing 1 into ace_enabled sysfs entry, enables gladiator hang +detection on M2 port +Writing 1 into pcio_enabled sysfs entry, enables gladiator hang +detection on PCIO port + +Required properties: +- compatible : "qcom,gladiator-hang-detect" +- qcom, threshold-arr: + Array of APCS_COMMON_GLADIATOR_HANG_THRESHOLD_n register + address +- qcom, config-reg: + APCS_COMMON_GLADIATOR_HANG_CONFIG register address + +Optional properties: + +Example: + For msm8998: + qcom,ghd { + compatible = "qcom,gladiator-hang-detect"; + qcom,threshold-arr = <0x179d141c 0x179d1420 + 0x179d1424 0x179d1428 0x179d1420 0x179d1430>; + qcom,config-reg = <0x179d1434>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_hang_detect.txt b/Documentation/devicetree/bindings/arm/msm/msm_hang_detect.txt new file mode 100644 index 000000000000..1700d588fd46 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_hang_detect.txt @@ -0,0 +1,55 @@ +* Qualcomm MSM Core Hang Detection + +Core Hang Detection provides the three sysfs entries for configuring +threshold, PMU event mux select and to enable hang detection. + +If core is hung for threshold time (value X 10ns) and no +heart beat event from pmu to core hang monitor detection, core hang +interrupt would be generated to reset the SOC via secure watchdog +to collect all cores context. + +PMU event mux select can be programmed to one of the supported +events, for example- +1) Load Instruction executed, +2) Store Instructions executed +3) Instruction architecturally executed and etc. + +Writing 1 into enable sysfs entry, enables core hang detection and +if there is no selected PMU mux event for 10ns core hang counter +gets incremented. Once counter reaches the programmed threshold value, +core hang interrupts generated to reset the SOC. + + +The device tree parameters for the core hang detection are: + +Required properties: + +- compatible : "qcom,core-hang-detect" +- label: unique name used to created sysfs entry +- qcom,threshold-arr : + Array of APCS_ALIAS*_CORE_HANG_THRESHOLD register address + for each core. +- qcom,config-arr : + Array of APCS_ALIAS*_CORE_HANG_CONFIG register address + for each core. + +Optional properties: + +Example: + For msm8937: + qcom,chd { + compatible = "qcom,core-hang-detect"; + qcom,threshold-arr = <0xB088094 0xB098094 0xB0A8094 + 0xB0B8094 0xB188094 0xB198094 0xB1A8094 0xB1B8094>; + qcom,config-arr = <0xB08809C 0xB09809C 0xB0A809C + 0xB0B809C 0xB18809C 0xB19809C 0xB1A809C 0xB1B809C>; + }; + + For msmtitanium: + qcom,chd { + compatible = "qcom,core-hang-detect"; + qcom,threshold-arr = <0xB1880B0 0xB1980B0 0xB1A80B0 + 0xB1B80B0 0xB0880B0 0xB0980B0 0xB0A80B0 0xB0B80B0>; + qcom,config-arr = <0xB1880B8 0xB1980B8 0xB1A80B8 + 0xB1B80B8 0xB0880B8 0xB0980B8 0xB0A80B8 0xB0B80B8>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ion.txt b/Documentation/devicetree/bindings/arm/msm/msm_ion.txt new file mode 100644 index 000000000000..6527675e258d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ion.txt @@ -0,0 +1,72 @@ +ION Memory Manager (ION) + +ION is a memory manager that allows for sharing of buffers between different +processes and between user space and kernel space. ION manages different +memory spaces by separating the memory spaces into "heaps". Depending on the +type of heap ION must reserve memory using the msm specific memory reservation +bindings (see Documentation/devicetree/bindings/arm/msm/memory-reserve.txt). + +Required properties for Ion + +- compatible: "qcom,msm-ion" + + +All child nodes of a qcom,msm-ion node are interpreted as Ion heap +configurations. + +Required properties for Ion heaps + +- reg: The ID of the ION heap. +- qcom,ion-heap-type: The heap type to use for this heap. Should be one of + the following: + - "SYSTEM" + - "SYSTEM_CONTIG" + - "CARVEOUT" + - "CHUNK" + - "CP" + - "DMA" + - "SECURE_DMA" + +Optional properties for Ion heaps + +- compatible: "qcom,msm-ion-reserve" This is required if memory is to be reserved + as specified by qcom,memory-reservation-size below. +- qcom,heap-align: Alignment of start of the memory in the heap. +- qcom,heap-adjacent: ID of heap this heap needs to be adjacent to. +- qcom,memory-reservation-size: size of reserved memory for the ION heap. +- qcom,memory-reservation-type: type of memory to be reserved +(see memory-reserve.txt for information about memory reservations) +- qcom,default-prefetch-size: Base value to be used for prefetching + optimizations. Ignored if the heap does not support prefetching. + Will set to a reasonable default value (e.g. the maximum heap size) + if this option is not set. + +Example: + qcom,ion { + compatible = "qcom,msm-ion"; + #address-cells = <1>; + #size-cells = <0>; + + qcom,ion-heap@25 { + reg = <25>; + qcom,ion-heap-type = "SYSTEM"; + }; + + qcom,ion-heap@8 { /* CP_MM HEAP */ + compatible = "qcom,msm-ion-reserve"; + reg = <8>; + qcom,heap-align = <0x1000>; + linux,contiguous-region = <&secure_mem>; + qcom,ion-heap-type = "SECURE_DMA"; + }; + + qcom,ion-heap@29 { /* FIRMWARE HEAP */ + compatible = "qcom,msm-ion-reserve"; + reg = <29>; + qcom,heap-align = <0x20000>; + qcom,heap-adjacent = <8>; + qcom,memory-reservation-type = "EBI1"; /* reserve EBI memory */ + qcom,memory-reservation-size = <0xA00000>; + qcom,ion-heap-type = "CARVEOUT"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ipc_router.txt b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router.txt new file mode 100644 index 000000000000..086f55ffa8fa --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router.txt @@ -0,0 +1,16 @@ +Qualcomm IPC Router + +Required properties: +-compatible: should be "qcom,ipc_router" +-qcom,node-id: unique ID to identify the node in network + +Optional properties: +-qcom,default-peripheral: String property to indicate the default peripheral + to communicate + +Example: + qcom,ipc_router { + compatible = "qcom,ipc_router"; + qcom,node-id = <1>; + qcom,default-peripheral = "modem"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_glink_xprt.txt b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_glink_xprt.txt new file mode 100644 index 000000000000..9e1d230432cf --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_glink_xprt.txt @@ -0,0 +1,42 @@ +Qualcomm Technologies, Inc. IPC Router G-Link Transport + +Required properties: +-compatible: should be "qcom,ipc_router_glink_xprt" +-qcom,ch-name: the G-Link channel name used by the G-Link transport +-qcom,xprt-remote: string that defines the edge of the transport +-qcom,glink-xprt: string that describes the underlying physical transport +-qcom,xprt-linkid: unique integer to identify the tier to which the link + belongs to in the network and is used to avoid the + routing loops while forwarding the broadcast messages +-qcom,xprt-version: unique version ID used by G-Link transport header + +Optional properties: +-qcom,fragmented-data: Boolean property to indicate that G-Link transport + supports fragmented data +-qcom,pil-label: string that defines remote subsystem name understood + by pil. Absence of this property indicates that + subsystem loading through pil voting is disabled for + that subsystem. + +Example: + qcom,ipc_router_modem_xprt { + compatible = "qcom,ipc_router_glink_xprt"; + qcom,ch-name = "IPCRTR"; + qcom,xprt-remote = "mpss"; + qcom,glink-xprt = "smem"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <1>; + qcom,fragmented-data; + qcom,pil-label = "modem"; + }; + + qcom,ipc_router_q6_xprt { + compatible = "qcom,ipc_router_glink_xprt"; + qcom,ch-name = "IPCRTR"; + qcom,xprt-remote = "lpass"; + qcom,glink-xprt = "smem"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <1>; + qcom,fragmented-data; + qcom,pil-label = "adsp"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_hsic_xprt.txt b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_hsic_xprt.txt new file mode 100644 index 000000000000..21cffdc262f8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_hsic_xprt.txt @@ -0,0 +1,19 @@ +Qualcomm IPC Router HSIC Transport + +Required properties: +-compatible: should be "qcom,ipc_router_hsic_xprt" +-qcom,ch-name: the HSIC channel name used by the HSIC transport +-qcom,xprt-remote: string that defines the edge of the transport (PIL Name) +-qcom,xprt-linkid: unique integer to identify the tier to which the link + belongs to in the network and is used to avoid the + routing loops while forwarding the broadcast messages +-qcom,xprt-version: unique version ID used by HSIC transport header + +Example: + qcom,ipc_router_external_modem_xprt { + compatible = "qcom,ipc_router_hsic_xprt"; + qcom,ch-name = "ipc_bridge"; + qcom,xprt-remote = "external-modem"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <3>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_mhi_xprt.txt b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_mhi_xprt.txt new file mode 100644 index 000000000000..de5ab2c37967 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_mhi_xprt.txt @@ -0,0 +1,21 @@ +Qualcomm Technologies, Inc. IPC Router MHI Transport + +Required properties: +-compatible: should be "qcom,ipc_router_mhi_xprt" +-qcom,out-chan-id: MHI Channel ID for the transmit path +-qcom,in-chan-id: MHI Channel ID for the receive path +-qcom,xprt-remote: string that defines the edge of the transport (PIL Name) +-qcom,xprt-linkid: unique integer to identify the tier to which the link + belongs to in the network and is used to avoid the + routing loops while forwarding the broadcast messages +-qcom,xprt-version: unique version ID used by MHI transport header + +Example: + qcom,ipc_router_external_modem_xprt2 { + compatible = "qcom,ipc_router_mhi_xprt"; + qcom,out-chan-id = <34>; + qcom,in-chan-id = <35>; + qcom,xprt-remote = "external-modem"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <3>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_smd_xprt.txt b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_smd_xprt.txt new file mode 100644 index 000000000000..f90d01af24bc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_ipc_router_smd_xprt.txt @@ -0,0 +1,34 @@ +Qualcomm IPC Router SMD Transport + +Required properties: +-compatible: should be "qcom,ipc_router_smd_xprt" +-qcom,ch-name: the SMD channel name used by the SMD transport +-qcom,xprt-remote: string that defines the edge of the transport (PIL Name) +-qcom,xprt-linkid: unique integer to identify the tier to which the link + belongs to in the network and is used to avoid the + routing loops while forwarding the broadcast messages +-qcom,xprt-version: unique version ID used by SMD transport header + +Optional properties: +-qcom,fragmented-data: Indicate the SMD transport supports fragmented data +-qcom,disable-pil-loading: Disable PIL Loading of the remote subsystem + +Example: + qcom,ipc_router_modem_xprt { + compatible = "qcom,ipc_router_smd_xprt"; + qcom,ch-name = "IPCRTR"; + qcom,xprt-remote = "modem"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <1>; + qcom,fragmented-data; + qcom,disable-pil-loading; + }; + + qcom,ipc_router_q6_xprt { + compatible = "qcom,ipc_router_smd_xprt"; + qcom,ch-name = "IPCRTR"; + qcom,xprt-remote = "adsp"; + qcom,xprt-linkid = <1>; + qcom,xprt-version = <1>; + qcom,fragmented-data; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_pacman.txt b/Documentation/devicetree/bindings/arm/msm/msm_pacman.txt new file mode 100644 index 000000000000..c8804ad750c2 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_pacman.txt @@ -0,0 +1,22 @@ +* msm-pacman - The MSM Peripheral Access Control Manager + +Required Properties: + + - compatible: "qcom,msm-pacman" + +Aliases: + + An alias is required to properly map the i2c/SPI bus driver to a Qualcomm + Universal Peripheral (QUP) ID. The alias is of the form 'qup<n>', where + <n> is an integer specifying the QUP ID. + +Example: + + aliases { + i2c2 = &i2c_2; + qup2 = &ic2_2; + }; + + qcom,msm-pacman { + compatible = "qcom,msm-pacman"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_rtb.txt b/Documentation/devicetree/bindings/arm/msm/msm_rtb.txt new file mode 100644 index 000000000000..ae61ebf771e4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_rtb.txt @@ -0,0 +1,22 @@ +Register Trace Buffer (RTB) + +The RTB is used to log discrete events in the system in an uncached buffer that +can be post processed from RAM dumps. The RTB must reserve memory using +the msm specific memory reservation bindings (see +Documentation/devicetree/bindings/arm/msm/memory-reserve.txt). + +Required properties + +- compatible: "qcom,msm-rtb" +- qcom,rtb-size: size of the RTB buffer in bytes + +Optional properties: + +- linux,contiguous-region: phandle reference to a CMA region + +Example: + + qcom,msm-rtb { + compatible = "qcom,msm-rtb"; + qcom,rtb-size = <0x100000>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_thermal.txt b/Documentation/devicetree/bindings/arm/msm/msm_thermal.txt new file mode 100644 index 000000000000..c2bc68a57bc7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_thermal.txt @@ -0,0 +1,444 @@ +MSM thermal driver (MSM_THERMAL) + +MSM_THERMAL is a kernel platform driver which regulates thermal conditions +on the device during kernel boot. The goal of MSM_THERMAL is to prevent the +temperature of the system from exceeding a thermal limit at which it cannot +operate. Examples are CPU junction thermal limit, or POP memory thermal limit. +The MSM_THERMAL driver polls the TSENS sensor hardware during boot, and +reduces the maximum CPU frequency allowed in steps, to limit power/thermal +output when a threshold temperature is crossed. It restores the maximum CPU +frequency allowed in the same stepwise fashion when the threshold temperature +(with hysteresis gap) is cleared. + +The devicetree representation of the MSM_THERMAL block should be: + +Required properties + +- compatible: "qcom,msm-thermal" +- qcom,sensor-id: The id of the TSENS sensor polled for temperature. + Typically the sensor closest to CPU0. +- qcom,poll-ms: Sampling interval to read sensor, in ms. + +Optional properties + +- reg: Physical address for uio mapping +- qcom,limit-temp: Threshold temperature to start stepping CPU down, in degC. +- qcom,temp-hysteresis: Degrees C below threshold temperature to step CPU up. +- qcom,freq-step: Number of frequency steps to take on each CPU mitigation. +- qcom,core-limit-temp: Threshold temperature to start shutting down cores + in degC +- qcom,core-temp-hysteresis: Degrees C below which the cores will be brought + online in sequence. +- qcom,hotplug-temp: Threshold temperature to start shutting down cores + in degC. This will be used when polling based + core control is disabled. The difference between hotplug-temp + and core-limit-temp is that core-limit-temp is used during + early boot prior to thermal_sys being available for hotplug. +- qcom,hotplug-temp-hysteresis: Degrees C below which thermal will not force the + cores to be offlined. Cores can be brought online if needed. +- qcom,freq-mitigation-temp: Threshold temperature to mitigate + the CPU max frequency in degC. This will be + used when polling based frequency control is disabled. + The difference between freq-mitigation-temp + and limit-temp is that limit-temp is used during + early boot prior to thermal_sys being available for registering + temperature thresholds. Also, this emergency frequency + mitigation is a single step frequency mitigation to a predefined value + as opposed to the step by step frequency mitigation during boot-up. +- qcom,freq-mitigation-temp-hysteresis: Degrees C below which thermal will not mitigate the + cpu max frequency. +- qcom,freq-mitigation-value: The frequency value (in kHz) to which the thermal + should mitigate the CPU, when the freq-mitigation-temp + threshold is reached. +- qcom,vdd-restriction-temp: When temperature is below this threshold, will + enable vdd restriction which will set higher voltage on + key voltage rails, in degC. +- qcom,vdd-restriction-temp-hysteresis: When temperature is above this threshold + will disable vdd restriction on key rails, in degC. +- qcom,pmic-sw-mode-temp: Threshold temperature to disable auto mode on the + rail, in degC. If this property exists, + qcom,pmic-sw-mode-temp-hysteresis and + qcom,pmic-sw-mode-regs need to exist, otherwise return error. +- qcom,pmic-sw-mode-temp-hysteresis: Degree below threshold temperature to + enable auto mode on the rail, in degC. If this property exists, + qcom,pmic-sw-mode-temp and qcom,pmic-sw-mode-regs need to + exist, otherwise return error. +- qcom,pmic-sw-mode-regs: Array of the regulator names that will want to + disable/enable automode based on the threshold. If this + property exists, qcom,pmic-sw-mode-temp and + qcom,pmic-sw-mode-temp-hysteresis need to exist, otherwise + return error. Also, if this property is defined, will have to + define <consumer_supply_name>-supply = <&phandle_of_regulator> +- <consumer_supply_name>-supply = <&phandle_of_regulator>: consumer_supply_name + is the name that's defined in thermal driver. + phandle_of_regulator is defined by reuglator device tree. +- qcom,online-hotplug-core: This property should be defined in targets where + KTM should online cores, which are hotplugged due to + thermal condition. +- qcom,synchronous-cluster-map: This property specifies an array of cluster-ID, + number of cpus in that cluster and their corresponding cpu + phandles. This property should be defined in targets where + the kernel topology module is not present. + In the older kernel version, where the kernel topology module is + not available, KTM gets the mapping information from this property. +- qcom,disable-vdd-mx: If this property is defined, the feature VDD MX + restriction will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-vdd-rstr: If this property is defined, the feature VDD + restriction will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-sensor-info: If this property is defined, the feature sensor + alias info will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-ocr: If this property is defined, the feature optimum current + request will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-psm: If this property is defined, the feature PMIC software + mode will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-gfx-phase-ctrl: If this property is defined, the feature graphics + phase control will be disabled. All other properties + corresponding to this feature will be ignored. +- qcom,disable-cx-phase-ctrl: If this property is defined, the feature + cx phase control will be disabled. All other properties + corresponding to this feature will be ignored. +- clock-names: The list of clocks needed for thermal module. Must be + - "osm" for LMH DCVS +- clocks: The phandle to the clocks. +- qcom,cxip-lm-enable: If this optional property is defined with a non zero value, + it enables CXIP_LM hardware feature. If value is zero, + it disables CXIP_LM hardware feature. +Optional child nodes +- qcom,pmic-opt-curr-temp: Threshold temperature for requesting optimum current (request + dual phase) for rails with PMIC, in degC. If this property exists, + then the properties, qcom,pmic-opt-curr-temp-hysteresis and + qcom,pmic-opt-curr-regs should also be defined to enable this + feature. +- qcom,pmic-opt-curr-temp-hysteresis: Degree below the threshold to disable the optimum + current request for a rail, in degC. If this property exists, + then the properties, qcom,pmic-opt-curr-temp and + qcom,pmic-opt-curr-regs should also be defined to enable + this feature. +- qcom,pmic-opt-curr-regs: Name of the rails for which the optimum current should be + requested. If this property exists, then the properties, + qcom,pmic-opt-curr-temp and qcom,pmic-opt-curr-temp-hysteresis + should also be defined to enable this feature. +- qcom,pmic-opt-curr-sensor-id: Sensor, which needs to be monitored for requesting OCR + when qcom,pmic-opt-curr-temp threshold is reached. + It is an optional property, if it is configured, msm_thermal will + monitor only this sensor, otherwise it will monitor all TSENS for + this feature. If this property exists, then the properties, + qcom,pmic-opt-curr-temp, qcom,pmic-opt-curr-temp-hysteresis and + qcom,pmic-opt-curr-regs should also be defined to enable this feature. +- qcom,<vdd restriction child node name>: Define the name of the child node. + If this property exisits, qcom,vdd-rstr-reg, qcom,levels + need to exist. qcom,min-level is optional if qcom,freq-req + exists, otherwise it's required. +- qcom,vdd-rstr-reg: Name of the rail +- qcom,levels: Array of the level values. Unit is corner voltage for voltage request + or kHz for frequency request. +- qcom,min-level: Request this level as minimum level when disabling voltage + restriction. Unit is corner voltage for voltage request. + This will not be required if qcom,freq-req exists. +- qcom,freq-req: Flag to determine if we should restrict frequency on this rail + instead of voltage. +- qcom,max-freq-level: Request this frequency as scaling maximum level when + enabling vdd restriction feature for a rail. This is + an optional property which is only applicable to the rail + with "qcom,freq-req" property set. +- qcom,cx-phase-hot-crit-temp: Threshold temperature for sending the 'HOT_CRITICAL' + temperature band to RPM, in degC. This will aid RPM + in deciding the number of phases required for CX rail. + If this property exists, then the property, + qcom,cx-phase-hot-crit-temp-hyst should also be defined to + enable this feature. +- qcom,cx-phase-hot-crit-temp-hyst: Degree below the threshold to send the 'WARM' + temperature band to RPM, in degC. This will aid RPM + in deciding the number of phases required for CX. + If this property exists, then the property, + qcom,cx-phase-hot-crit-temp should also be defined to enable + this feature. +- qcom,cx-phase-resource-key: The key name to be used for sending the CX + temperature band message to RPM. This property should + be defined along with the other properties required for + CX phase selection feature. +- qcom,gfx-phase-hot-crit-temp: Threshold temperature for sending the 'HOT_CRITICAL' + temperature band to RPM, in degC. This will aid RPM in + deciding the number of phases required for GFX rail. + If this property exists, then the properties, + qcom,gfx-phase-hot-crit-temp-hyst and qcom,gfx-sensor-id + should also be defined to enable this feature. +- qcom,gfx-phase-hot-crit-temp-hyst: Degree below the threshold to clear the 'HOT_CRITICAL' + band and send the 'WARM' temperature band to RPM, in degC. + This will aid RPM in deciding the number of phases required + for GFX rail. If this property exists, then the properties, + qcom,gfx-phase-hot-crit-temp and qcom,gfx-sensor-id + should also be defined to enable this feature. +- qcom,gfx-phase-warm-temp: Threshold temperature for sending the 'WARM' temperature + band to RPM, in degC. This will aid RPM in deciding the + number of phases required for GFX rail. If this property + exists, then the properties, qcom,gfx-sensor-id and + qcom,gfx-phase-warm-temp-hyst should also be defined to + enable this feature. +- qcom,gfx-phase-warm-temp-hyst: Degree below the threshold to clear the 'WARM' + band and send the 'NORMAL' temperature band to RPM, in degC. + This will aid RPM in deciding the number of phases required + for GFX rail. If this property exists, then the property, + qcom,gfx-sensor-id and qcom,gfx-phase-warm-temp should also + be defined to enable this feature. +-qcom,gfx-sensor-id: The ID of the TSENS sensor, which is closest to graphics + processor, monitoring the GPU temperature. If this property + exists, then the property, qcom,gfx-phase-hot-crit-temp and + qcom,gfx-phase-hot-crit-temp-hyst or/and qcom,gfx-phase-warm-temp + and qcom,gfx-phase-warm-temp-hyst should also be defined to + enable this feature. +- qcom,gfx-phase-resource-key: The key name to be used for sending the GFX temperature + band message to RPM. This property should be defined along + with the other properties required for GFX phase selection + feature. +- qcom,rpm-phase-resource-type: The RPM resource type name to be used for sending + temperature bands for CX and GFX phase selection. This + property should be defined along with the other properties + required for CX and GFX phase selection feature. +- qcom,rpm-phase-resource-id: The RPM resource ID to be used for sending temperature + bands for CX and GFX phase selection. This property should + be defined along with the other properties required for CX + and GFX phase selection feature. +- qcom,mx-restriction-temp: Threshold temperature below which the module votes for + higher data retention voltage of MX and CX supply. If and only if this + property exists, then the property qcom,mx-restriction-temp-hysteresis, + qcom,mx-retention-min should also be present. Also, if this + property is defined, will have to define vdd-mx-supply = + <&phandle_of_regulator> +- qcom,mx-restriction-temp-hysteresis: Degree above the threshold to remove MX and CX vote. + If this property exists, then the property qcom,mx-restriction-temp, + qcom,mx-retention-min should also be present.Also, if this + property is defined, will have to define vdd-mx-supply = + <&phandle_of_regulator> +- qcom,mx-retention-min: Minimum data retention voltage to be applied to MX rail if + the low threshold is crossed. If this property exists, then the + property qcom,mx-restriction-temp and + qcom,mx-restriction-temp-hysteresis should also be present. + Also, if this property is defined, will have to define + vdd-mx-supply = <&phandle_of_regulator> +- qcom,cx-retention-min: Minimum data retention voltage to be applied to CX rail if the low + threshold is crossed. If this property exists, then the property + qcom,mx-restriction-temp and qcom,mx-restriction-temp-hysteresis + should also be present. Also, if this property is defined, will + have to define vdd-cx-supply = <&phandle_of_regulator>. +- qcom,mx-restriction-sensor_id: sensor id, which needs to be monitored for requesting MX/CX + retention voltage. If this optional property is defined, msm_thermal + will monitor only this sensor, otherwise by default it will monitor + all TSENS for this feature. If this property exists, then the properties, + qcom,mx-restriction-temp, qcom,mx-restriction-temp-hysteresis and + qcom,mx-retention-min should also be defined to enable this feature. +- qcom,therm-reset-temp: Degree above which the KTM will initiate a secure watchdog reset. + When this property is defined, KTM will monitor all the tsens from + boot time and will initiate a secure watchdog reset if any of the + tsens temperature reaches this threshold. This reset helps in + generating more informative crash dumps opposed to the crash dump + generated by the hardware reset. + +Example: + + qcom,msm-thermal { + compatible = "qcom,msm-thermal"; + reg = <0x70000 0x1000>; + qcom,sensor-id = <0>; + qcom,poll-ms = <250>; + qcom,limit-temp = <60>; + qcom,temp-hysteresis = <10>; + qcom,freq-step = <2>; + qcom,therm-reset-temp = <115>; + qcom,core-limit-temp = <90>; + qcom,core-temp-hysteresis = <10>; + qcom,hotplug-temp = <110>; + qcom,hotplug-temp-hysteresis = <20>; + qcom,freq-mitigation-temp = <110>; + qcom,freq-mitigation-temp-hysteresis = <20>; + qcom,freq-mitigation-value = <960000>; + qcom,rpm-phase-resource-type = "misc"; + qcom,rpm-phase-resource-id = <0>; + qcom,cx-phase-resource-key = "tmpc"; + qcom,cx-phase-hot-crit-temp = <75>; + qcom,cx-phase-hot-crit-temp-hyst = <15>; + qcom,gfx-phase-warm-temp = <60>; + qcom,gfx-phase-warm-temp-hyst = <10>; + qcom,gfx-phase-hot-crit-temp = <85>; + qcom,gfx-phase-hot-crit-temp-hyst = <15>; + qcom,gfx-sensor-id = <4>; + qcom,gfx-phase-resource-key = "tmpg"; + qcom,pmic-sw-mode-temp = <90>; + qcom,pmic-sw-mode-temp-hysteresis = <80>; + qcom,pmic-sw-mode-regs = "vdd-dig"; + qcom,vdd-restriction-temp = <5>; + qcom,vdd-restriction-temp-hysteresis = <10>; + vdd-dig-supply=<&pm8841_s2_floor_corner> + qcom,mx-restriction-temp = <5>; + qcom,mx-restriction-temp-hysteresis = <10>; + qcom,mx-retention-min = <710000>; + qcom,mx-restriction-sensor_id = <2>; + vdd-mx-supply = <&pma8084_s1>; + qcom,cx-retention-min = <RPM_SMD_REGULATOR_LEVEL_RETENTION_PLUS>; + vdd-cx-supply = <&pmd9635_s5_level>; + qcom,online-hotplug-core; + qcom,synchronous-cluster-map = <0 2 &CPU0 &CPU1>, + <1 2 &CPU2 &CPU3>; + /* <cluster-ID, number of cores in cluster, cpu phandles>. + ** In the above case, the cluster with ID 0 & 1 has 2 cores + ** and their phandles are mentioned. + */ + + qcom,vdd-dig-rstr{ + qcom,vdd-rstr-reg = "vdd-dig"; + qcom,levels = <5 7 7>; /* Nominal, Super Turbo, Super Turbo */ + qcom,min-level = <1>; /* No Request */ + }; + + qcom,vdd-apps-rstr{ + qcom,vdd-rstr-reg = "vdd-apps"; + qcom,levels = <1881600 1958400 2265600>; + qcom,freq-req; + qcom,max-freq-level = <1958400>; + }; + }; + + + +The sensor information node is an optional node that holds information +about thermal sensors on a target. The information includes sensor type, +sensor name, sensor alias and sensor scaling factor. The parent node +name is qcom,sensor-information. It has a list of optional child +nodes, each representing a sensor. The child node is named as +qcom,sensor-information-<id>. The id takes values sequentially +from 0 to N-1 where N is the number of sensors. This id doesn't +relate to zone id or sensor id. + +The devicetree representation of sensor information node should be: + +1.0 Required properties: + +- compatible: "qcom,sensor-information" + +1.1 Optional nodes: + +qcom,sensor-information-<id> + +The below properties belong to the child node qcom,sensor-information-<id>. +Following are the required and optional properties of a child node. + +1.1.a Required properties: + +- qcom,sensor-type: Type of a sensor. A sensor can be of type tsens, + alarm or adc. + tsens: Sensors that are on MSM die. + alarm: Sensors that are on PMIC die. + adc: Sensors that are usually thermistors + placed out of the die. +- qcom,sensor-name: Name of a sensor as defined by low level sensor driver. + +1.1.b Optional properties: + +- qcom,alias-name: Alias name for a sensor. The alias name corresponds + to a device such as gpu/pop-mem whose temperature + is relative to the sensor temperature defined in the + child node. This node can not be used for providing + alias name for cpu devices. Thermal driver assigns the + cpu device alias, based on the sensor defined in the + cpu mitigation profile. +- qcom,scaling-factor: The unit that needs to be multiplied to the + sensor temperature to get temperature unit in + degree centigrade. If this property is not + present, a default scaling factor of 1 is assigned + to a sensor. + +Example: + + qcom,sensor-information { + compatible = "qcom,sensor-information"; + sensor_information0: qcom,sensor-information-0 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor0"; + }; + + sensor_information1: qcom,sensor-information-1 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor1"; + }; + + sensor_information2: qcom,sensor-information-2 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor2"; + }; + + sensor_information3: qcom,sensor-information-3 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor3"; + }; + + sensor_information4: qcom,sensor-information-4 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor4"; + }; + + sensor_information5: qcom,sensor-information-5 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor5"; + }; + + sensor_information6: qcom,sensor-information-6 { + qcom,sensor-type = "tsens"; + qcom,sensor-name = "tsens_tz_sensor6"; + qcom,alias-name = "cpu7"; + } + + sensor_information7: qcom,sensor-information-7 { + qcom,sensor-type = "alarm"; + qcom,sensor-name = "pm8994_tz"; + qcom,scaling-factor = <1000>; + }; + + }; + +=============================================================================== +Mitigation Profile: +=============================================================================== +Thermal driver allows users to specify various mitigation profiles and +associate a profile to a device. The device should have a phandle, to associate +itself with a mitigation profile, using a "qcom,limits-info" property. +This profile can specify whether to mitigate the device during various +limiting conditions. + +Required Node: +- qcom,limit_info-#: This is a mitigation profile node. A profile should + normally have a sensor(s) to monitor and a list + of properties enabling or disabling a mitigation. + +Required properties: + +- qcom,temperature-sensor: Array of phandle(s) to the temperature sensor(s) that + need(s) to be used for monitoring the device associated + with this mitigation profile. Right now the first + sensor will be used for KTM CPU monitoring. Alias + name of multiple sensors monitoring a same device will + be differentiated by appending an index like, "cpu0_0" + and "cpu0_1". A single sensor monitoring multiple + devices will have an alias name like "cpu0-cpu1-cpu2". + +Optional properties: + +- qcom,boot-frequency-mitigate: Enable thermal frequency mitigation + during boot. +- qcom,emergency-frequency-mitigate: Enable emergency frequency mitigation. +- qcom,hotplug-mitigation-enable: Enable hotplug mitigation. This enables + hotplug mitigation both during boot and emergency + condition. + +Example: + mitigation_profile7: qcom,limit_info-7 { + qcom,temperature-sensor = + <&sensor_information6 &sensor_information8>; + qcom,boot-frequency-mitigate; + qcom,emergency-frequency-mitigate; + qcom,hotplug-mitigation-enable; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_tspp.txt b/Documentation/devicetree/bindings/arm/msm/msm_tspp.txt new file mode 100644 index 000000000000..ee8f06e01957 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_tspp.txt @@ -0,0 +1,93 @@ +TSPP Driver + +For information on the TSPP driver, please refer to the TSPP driver +documentation: Documentation/arm/msm/tspp.txt. + +The devicetree representation of the TSPP block should be: + +Required properties: + +- compatible: "qcom,msm_tspp" +- reg: physical memory base addresses and sizes for the following: + TSIF0, TSIF1, TSPP and TSPP_BAM. +- reg-names: names of the memory regions. +- interrupts: represents IRQ numbers for the following: + TSIF_TSPP_IRQ, TSIF0_IRQ, TSIF1_IRQ, TSIF_BAM_IRQ. +- interrupt-names: TSPP, TSIF and BAM interrupt names. +- pinctrl-names: the names of the pinctrl states that are used by the driver to + configure the TLMM pins. The allowed states are: + disabled - both tsif inputs are not used + tsif0-mode1 - only tsif0 is active in mode 1 (no sync signal) + tsif0-mode2 - only tsif0 is used in mode 2 (with sync signal) + tsif1-mode1 - only tsif1 is active in mode 1 (no sync signal) + tsif1-mode2 - only tsif1 is used in mode 2 (with sync signal) + dual-tsif-mode1 - both tsif0 and tsif1 are active, in mode 1 + dual-tsif-mode1 - both tsif0 and tsif1 are active, in mode 2 +- pinctrl-#: a list of pinctrl phandles for the different pinctrl states. Refer + to "Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt" for + the pinctrl handles definitions. Each pinctrl-# corresponds to the + respective state name that appears under pinctrl-state list. + Note that when switching from one state to another, any pins in + the old state which do not appear in the new state are automatically + disabled by the pinctrl framework. + +Optional properties: + +- vdd_cx-supply: Reference to the regulator that supplies the CX rail. + Some hardware platforms (e.g. 8974-v2) require the voltage of the rail + supplying power to the TSIF hardware block to be elevated before + enabling the TSIF clocks. +- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + the below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + +Example (for 8974 platform, avaialble at msm8974.dtsi): + + tspp: msm_tspp@f99d8000 { + compatible = "qcom,msm_tspp"; + reg = <0xf99d8000 0x1000>, /* MSM_TSIF0_PHYS */ + <0xf99d9000 0x1000>, /* MSM_TSIF1_PHYS */ + <0xf99da000 0x1000>, /* MSM_TSPP_PHYS */ + <0xf99c4000 0x14000>; /* MSM_TSPP_BAM_PHYS */ + reg-names = "MSM_TSIF0_PHYS", + "MSM_TSIF1_PHYS", + "MSM_TSPP_PHYS", + "MSM_TSPP_BAM_PHYS"; + interrupts = <0 153 0>, /* TSIF_TSPP_IRQ */ + <0 151 0>, /* TSIF0_IRQ */ + <0 152 0>, /* TSIF1_IRQ */ + <0 154 0>; /* TSIF_BAM_IRQ */ + interrupt-names = "TSIF_TSPP_IRQ", + "TSIF0_IRQ", + "TSIF1_IRQ", + "TSIF_BAM_IRQ"; + + pinctrl-names = "disabled", + "tsif0-mode1", "tsif0-mode2", + "tsif1-mode1", "tsif1-mode2", + "dual-tsif-mode1", "dual-tsif-mode2"; + + pinctrl-0 = <>; /* disabled */ + pinctrl-1 = <&tsif0_signals_active>; /* tsif0-mode1 */ + pinctrl-2 = <&tsif0_signals_active + &tsif0_sync_active>; /* tsif0-mode2 */ + pinctrl-3 = <&tsif1_signals_active>; /* tsif1-mode1 */ + pinctrl-4 = <&tsif1_signals_active + &tsif1_sync_active>; /* tsif1-mode2 */ + pinctrl-5 = <&tsif0_signals_active + &tsif1_signals_active>; /* dual-tsif-mode1 */ + pinctrl-6 = <&tsif0_signals_active + &tsif0_sync_active + &tsif1_signals_active + &tsif1_sync_active>; /* dual-tsif-mode2 */ + + qcom,msm-bus,name = "tsif"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <82 512 0 0>, /* No vote */ + <82 512 12288 24576>; /* Max. bandwidth, 2xTSIF, each max of 96Mbps */ + }; diff --git a/Documentation/devicetree/bindings/arm/msm/msm_watchdog.txt b/Documentation/devicetree/bindings/arm/msm/msm_watchdog.txt new file mode 100644 index 000000000000..296e5dd0e383 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/msm_watchdog.txt @@ -0,0 +1,50 @@ +* Qualcomm MSM Watchdog + +Watchdog timer is configured with a bark and a bite time. +if the watchdog is not "pet" at regular intervals, the system +is assumed to have become non responsive and needs to be reset. +A warning in the form of a bark timeout leads to a bark interrupt +and a kernel panic. if the watchdog timer is still not reset, +a bite timeout occurs, which is an interrupt in the secure mode, +which leads to a reset of the SOC via the secure watchdog. The +driver needs the petting time, and the bark timeout to be programmed +into the watchdog, as well as the bark and bite irqs. + +The device tree parameters for the watchdog are: + +Required properties: + +- compatible : "qcom,msm-watchdog" +- reg : offset and length of the register set for the watchdog block. +- reg-names : names corresponding to each reg property value. + "wdt-base" - physical base address of watchdog timer registers + "wdt-absent-base" - physical base address of watchdog absent register +- interrupts : should contain bark and bite irq numbers +- qcom,pet-time : Non zero time interval at which watchdog should be pet in ms. +- qcom,bark-time : Non zero timeout value for a watchdog bark in ms. +- qcom,userspace-watchdog : + (boolean) Allow enabling the userspace-watchdog feature. This feature + requires userspace to pet the watchdog every qcom,pet-time interval + in addition to the existing kernel-level checks. + This feature is supported through device sysfs files. + + +Optional properties: + +- qcom,ipi-ping : (boolean) send keep alive ping to other cpus if present +- qcom,wakeup-enable : (boolean) enable non secure watchdog to freeze / unfreeze + automatically across suspend / resume path. +- qcom,scandump-size : size of scan dump memory region + +Example: + + qcom,wdt@f9017000 { + compatible = "qcom,msm-watchdog"; + reg = <0xf9017000 0x1000>; + reg-names = "wdt-base"; + interrupts = <0 3 0>, <0 4 0>; + qcom,bark-time = <11000>; + qcom,pet-time = <10000>; + qcom,ipi-ping; + qcom,wakeup-enable; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/pm_snoc_client.txt b/Documentation/devicetree/bindings/arm/msm/pm_snoc_client.txt new file mode 100644 index 000000000000..4f7111fd5933 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/pm_snoc_client.txt @@ -0,0 +1,35 @@ +* MSM PM SNOC client + +MSM PM SNOC client device is used to setup a bus request for 100 Mhz for the +SNOC bus when the Apps cores are active. This bus request helps mitigate the +exit latency from power collapse in cases where there aren't any active bus +requests for SNOC. + +This device is dependent on the pm-8x60 device, which configures the low power +mode of respective cores. + +The required properties of this device are: + +- compatible: qcom,pm-snoc-client +- qcom,msm-bus,name: String representing the client-name +- qcom,msm-bus,num-cases: Total number of usecases +- qcom,msm-bus,active-only: Boolean context flag for requests in active or + dual (active & sleep) contex +- qcom,msm-bus,num-paths: Total number of master-slave pairs +- qcom,msm-bus,vectors-KBps: Arrays of unsigned integers representing: + master-id, slave-id, arbitrated bandwidth + in KBps, instantaneous bandwidth in KBps + + +Example: + qcom,pm-snoc-client { + compatible = "qcom,pm-snoc-client"; + qcom,msm-bus,name = "ocimem_snoc"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,active-only; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors = + <22 512 0 0>, + <22 512 320000 3200000>; + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt index 1333db9acfee..382a574a5c55 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt @@ -21,10 +21,17 @@ PROPERTIES the register region. An optional second element specifies the base address and size of the alias register region. +- clock-output-names: + Usage: optional + Value type: <string> + Definition: Name of the output clock. Typically acpuX_aux where X is a + CPU number starting at 0. + Example: clock-controller@2088000 { compatible = "qcom,kpss-acc-v2"; reg = <0x02088000 0x1000>, <0x02008000 0x1000>; + clock-output-names = "acpu0_aux"; }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt new file mode 100644 index 000000000000..d1e12f16a28c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-gcc.txt @@ -0,0 +1,28 @@ +Krait Processor Sub-system (KPSS) Global Clock Controller (GCC) + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: should be one of: + "qcom,kpss-gcc" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: base address and size of the register region + +- clock-output-names: + Usage: required + Value type: <string> + Definition: Name of the output clock. Typically acpu_l2_aux indicating + an L2 cache auxiliary clock. + +Example: + + l2cc: clock-controller@2011000 { + compatible = "qcom,kpss-gcc"; + reg = <0x2011000 0x1000>; + clock-output-names = "acpu_l2_aux"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,osm.txt b/Documentation/devicetree/bindings/arm/msm/qcom,osm.txt new file mode 100644 index 000000000000..38c9fe749abb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,osm.txt @@ -0,0 +1,493 @@ +Qualcomm Technologies, Inc. OSM Bindings + +Operating State Manager (OSM) is a hardware engine used by some Qualcomm +Technologies, Inc. (QTI) SoCs to manage frequency and voltage scaling +in hardware. OSM is capable of controlling frequency and voltage requests +for multiple clusters via the existence of multiple OSM domains. + +Properties: +- compatible + Usage: required + Value type: <string> + Definition: must be "qcom,cpu-clock-osm-msm8998-v1", + "qcom,cpu-clock-osm-msm8998-v2", + "qcom,clk-cpu-osm" or + "qcom,clk-cpu-osm-sdm630". + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of the OSM controller, + cluster PLL management, and APCS common register regions. + Optionally, the address of the efuse registers used to + determine the pwrcl or perfcl speed-bins and/or the ACD + register space to initialize prior to enabling OSM. + +- reg-names + Usage: required + Value type: <stringlist> + Definition: Address names. Must be "osm", "pwrcl_pll", "perfcl_pll", + "apcs_common", and "debug". Optionally, "pwrcl_efuse", + "perfcl_efuse", "pwrcl_acd", or "perfcl_acd". + Must be specified in the same order as the corresponding + addresses are specified in the reg property. + +- vdd-pwrcl-supply + Usage: required + Value type: <phandle> + Definition: phandle of the underlying regulator device that manages + the voltage supply of the Power cluster. + +- vdd-perfcl-supply + Usage: required + Value type: <phandle> + Definition: phandle of the underlying regulator device that manages + the voltage supply of the Performance cluster. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: OSM interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. this list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. + "pwrcl-irq" and "perfcl-irq" must be specified. + +- qcom,pwrcl-speedbinX-v0 + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the frequency in Hertz, frequency, + PLL override data, ACC level, and virtual corner used + by the OSM hardware for each supported DCVS setpoint + of the Power cluster. + +- qcom,perfcl-speedbinX-v0 + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the frequency in Hertz, frequency, + PLL override data, ACC level and virtual corner used + by the OSM hardware for each supported DCVS setpoint + of the Performance cluster. + +- qcom,osm-no-tz + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that there is no programming + of the OSM hardware performed by the secure world. + +- qcom,osm-pll-setup + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the PLL setup sequence + must be executed for each clock domain managed by the OSM + controller. + +- qcom,up-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the DCVS up timer value in nanoseconds + for each of the two clusters managed by the OSM controller. + +- qcom,down-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the DCVS down timer value in nanoseconds + for each of the two clusters managed by the OSM controller. + +- qcom,pc-override-index + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the OSM performance index to be used + when each cluster enters certain low power modes. + +- qcom,set-ret-inactive + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if domains in retention must + be treated as inactive. + +- qcom,enable-llm-freq-vote + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if Limits hardware frequency + votes must be honored by OSM. + +- qcom,llm-freq-up-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the LLM frequency up timer value in + nanoseconds for each of the two clusters managed by the + OSM controller. + +- qcom,llm-freq-down-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the LLM frequency down timer value in + nanoseconds for each of the two clusters managed by the + OSM controller. + +- qcom,enable-llm-volt-vote + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if Limits hardware voltage + votes must be honored by OSM. + +- qcom,llm-volt-up-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the LLM voltage up timer value in + nanoseconds for each of the two clusters managed by the + OSM controller. + +- qcom,llm-volt-down-timer + Usage: optional + Value type: <prop-encoded-array> + Definition: Array which defines the LLM voltage down timer value in + nanoseconds for each of the two clusters managed by the + OSM controller. + +- qcom,cc-reads + Usage: optional + Value type: <integer> + Definition: Defines the number of times the cycle counters must be + read to determine the performance level of each clock + domain. + +- qcom,l-val-base + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the L_VAL + control register for each of the two clusters managed + by the OSM controller. + +- qcom,apcs-itm-present + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the ITM + control register for each of the two clusters managed + by the OSM controller. + +- qcom,apcs-pll-user-ctl + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the PLL + user control register for each of the two clusters managed + by the OSM controller. + +- qcom,apcs-cfg-rcgr + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the RCGR + configuration register for each of the two clusters managed + by the OSM controller. + +- qcom,apcs-cmd-rcgr + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the RCGR + command register for each of the two clusters managed + by the OSM controller. + +- qcom,apm-threshold-voltage + Usage: required + Value type: <u32> + Definition: Specifies the APM threshold voltage in microvolts. If the + VDD_APCC supply voltage is above or at this level, then the + APM is switched to use VDD_APCC. If VDD_APCC is below + this level, then the APM is switched to use VDD_MX. + +- qcom,apm-mode-ctl + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the APM + control register for each of the two clusters managed + by the OSM controller. + +- qcom,apm-ctrl-status + Usage: required + Value type: <prop-encoded-array> + Definition: Array which defines the register addresses of the APM + controller status register for each of the two clusters + managed by the OSM controller. + +- qcom,llm-sw-overr + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of tuples which defines the three non-zero LLM SW + override values to write to the OSM controller for each + of the two clusters. Each tuple must contain three elements. + +- qcom,acdtd-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the values to program to the ACD + Tunable-Length Delay register for the power and performance + clusters. + +- qcom,acdcr-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the values for the ACD control register + for the power and performance clusters. + +- qcom,acdsscr-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the values for the ACD Soft Start Control + register for the power and performance clusters. + +- qcom,acdextint0-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the initial values for the ACD + external interface configuration register for the power + and performance clusters. + +- qcom,acdextint1-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the final values for the ACD + external interface configuration register for the power + and performance clusters. + +- qcom,acdautoxfer-val + Usage: required if pwrcl_acd or perfcl_acd registers are specified + Value type: <prop-encoded-array> + Definition: Array which defines the values for the ACD auto transfer + control register for the power and performance clusters. + +- qcom,pwrcl-apcs-mem-acc-cfg + Usage: required if qcom,osm-no-tz is specified + Value type: <prop-encoded-array> + Definition: Array which defines the addresses of the mem-acc + configuration registers for the Power cluster. + The array must contain exactly three elements. + +- qcom,perfcl-apcs-mem-acc-cfg + Usage: required if qcom,osm-no-tz is specified + Value type: <prop-encoded-array> + Definition: Array which defines the addresses of the mem-acc + configuration registers for the Performance cluster. + The array must contain exactly three elements. + +- qcom,pwrcl-apcs-mem-acc-val + Usage: required if qcom,osm-no-tz is specified + Value type: <prop-encoded-array> + Definition: List of integer tuples which define the mem-acc values + for each performance mode of the Power cluster. Each tuple + is of length 3 corresponding to the mem-acc values per + performance mode with a total of 4 tuples corresponding + to each supported performance mode. + +- qcom,pwrcl-apcs-mem-acc-threshold-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the highest MEM ACC threshold voltage in + microvolts for the Power cluster. This voltage is + used to determine which MEM ACC setting is used for the + highest frequencies. If specified, the voltage must match + the MEM ACC threshold voltage specified for the + corresponding CPRh device. + +- qcom,perfcl-apcs-mem-acc-val + Usage: required if qcom,osm-no-tz is specified + Value type: <prop-encoded-array> + Definition: List of integer tuples which define the mem-acc values + for each performance mode of the Performance cluster. + Each tuple is of length 3 corresponding to the mem-acc + values per performance mode with a total of 4 tuples + corresponding to each supported performance mode. + +- qcom,perfcl-apcs-mem-acc-threshold-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the highest MEM ACC threshold voltage in + microvolts for the Performance cluster. This voltage is + used to determine which MEM ACC setting is used for the + highest frequencies. If specified, the voltage must match + the MEM ACC threshold voltage specified for the + corresponding CPRh device. + +- qcom,red-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the reduction FSM + should be enabled. + +- qcom,boost-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the boost FSM should + be enabled. + +- qcom,safe-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the safe FSM should + be enabled. + +- qcom,ps-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the PS FSM should be + enabled. + +- qcom,droop-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the droop FSM should + be enabled. +- qcom,wfx-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the WFX FSM should + be enabled. + +- qcom,pc-fsm-en + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates if the PC/RET FSM should + be enabled. + +- clock-names + Usage: required + Value type: <string> + Definition: Must be "aux_clk". + +- clocks + Usage: required + Value type: <phandle> + Definition: Phandle to the aux clock device. + +Example: + + clock_cpu: qcom,cpu-clock-8998@179c0000 { + compatible = "qcom,cpu-clock-osm-msm8998-v1"; + reg = <0x179C0000 0x4000>, + <0x17916000 0x1000>, + <0x17816000 0x1000>, + <0x179D1000 0x1000>, + <0x1791101c 0x8>; + reg-names = "osm", "pwrcl_pll", "perfcl_pll", + "apcs_common", "debug"; + + vdd-pwrcl-supply = <&apc0_pwrcl_vreg>; + vdd-perfcl-supply = <&apc1_perfcl_vreg>; + + interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "pwrcl-irq", "perfcl-irq"; + + qcom,pwrcl-speedbin0-v0 = + < 300000000 0x0004000f 0x031e001e 0x1 1 >, + < 345600000 0x05040012 0x04200020 0x1 2 >, + < 422400000 0x05040016 0x04200020 0x1 3 >, + < 499200000 0x0504001a 0x05200020 0x1 4 >, + < 576000000 0x0504001e 0x06200020 0x1 5 >, + < 633600000 0x04040021 0x07200020 0x1 6 >, + < 710400000 0x04040025 0x07200020 0x1 7 >, + < 806400000 0x0404002a 0x08220022 0x2 8 >, + < 883200000 0x0404002e 0x09250025 0x2 9 >, + < 960000000 0x04040032 0x0a280028 0x2 10 >, + < 1036800000 0x04040036 0x0b2b002b 0x3 11 >, + < 1113600000 0x0404003a 0x0c2e002e 0x3 12 >, + < 1190400000 0x0404003e 0x0c320032 0x3 13 >, + < 1248000000 0x04040041 0x0d340034 0x3 14 >, + < 1324800000 0x04040045 0x0e370037 0x3 15 >, + < 1401600000 0x04040049 0x0f3a003a 0x3 16 >, + < 1478400000 0x0404004d 0x103e003e 0x3 17 >, + < 1574400000 0x04040052 0x10420042 0x4 18 >, + < 1651200000 0x04040056 0x11450045 0x4 19 >, + < 1728000000 0x0404005a 0x12480048 0x4 20>, + < 1804800000 0x0404005e 0x134b004b 0x4 21 >, + < 1881600000 0x04040062 0x144e004e 0x4 22 >; + + qcom,perfcl-speedbin0-v0 = + < 300000000 0x0004000f 0x03200020 0x1 1 >, + < 345600000 0x05040012 0x04200020 0x1 2 >, + < 422400000 0x05040016 0x04200020 0x1 3 >, + < 480000000 0x05040019 0x05200020 0x1 4 >, + < 556800000 0x0504001d 0x06200020 0x1 5 >, + < 633600000 0x04040021 0x07200020 0x1 6 >, + < 710400000 0x04040025 0x07200020 0x1 7 >, + < 787200000 0x04040029 0x08210021 0x1 8 >, + < 844800000 0x0404002c 0x09240024 0x2 9 >, + < 902400000 0x0404002f 0x09260026 0x2 10 >, + < 979200000 0x04040033 0x0a290029 0x2 11 >, + < 1056000000 0x04040037 0x0b2c002c 0x2 12 >, + < 1171200000 0x0404003d 0x0c300030 0x3 13 >, + < 1248000000 0x04040041 0x0d340034 0x3 14 >, + < 1324800000 0x04040045 0x0e370037 0x3 15 >, + < 1401600000 0x04040049 0x0f3b003b 0x3 16 >, + < 1478400000 0x0404004d 0x0f3e003e 0x3 17 >, + < 1536000000 0x04040050 0x10400040 0x3 18 >, + < 1632000000 0x04040055 0x11440044 0x4 19 >, + < 1708800000 0x04040059 0x12480048 0x4 20 >, + < 1785600000 0x0404005d 0x134a004a 0x4 21 >, + < 1862400000 0x04040061 0x134e004e 0x4 22 >, + < 1939200000 0x04040065 0x14510051 0x4 23 >, + < 2016000000 0x04040069 0x15540054 0x4 24 >, + < 2092800000 0x0404006d 0x16570057 0x4 25 >; + + qcom,osm-no-tz; + qcom,osm-pll-setup; + + qcom,up-timer = + <1000 1000>; + qcom,down-timer = + <1000 1000>; + qcom,pc-override-index = + <0 0>; + qcom,set-ret-inactive; + qcom,enable-llm-freq-vote; + qcom,llm-freq-up-timer = + <1000 1000>; + qcom,llm-freq-down-timer = + <1000 1000>; + qcom,enable-llm-volt-vote; + qcom,llm-volt-up-timer = + <1000 1000>; + qcom,llm-volt-down-timer = + <1000 1000>; + qcom,cc-reads = <10>; + + qcom,l-val-base = + <0x17916004 0x17816004>; + qcom,apcs-itm-present = + <0x179d143c 0x179d143c>; + qcom,apcs-pll-user-ctl = + <0x1791600c 0x1781600c>; + qcom,apcs-cfg-rcgr = + <0x17911054 0x17811054>; + qcom,apcs-cmd-rcgr = + <0x17911050 0x17811050>; + qcom,apm-mode-ctl = + <0x179d0004 0x179d0010>; + qcom,apm-ctrl-status = + <0x179d000c 0x179d0018>; + + qcom,apm-threshold-voltage = <832000>; + + qcom,pwrcl-apcs-mem-acc-cfg = + <0x179d1360 0x179d1364 0x179d1364>; + qcom,perfcl-apcs-mem-acc-cfg = + <0x179d1368 0x179d136C 0x179d1370>; + qcom,pwrcl-apcs-mem-acc-val = + <0x00000000 0x10000000 0x10000000>, + <0x00000000 0x10000000 0x10000000>, + <0x00000000 0x00000000 0x00000000>, + <0x00000000 0x00000001 0x00000001>; + qcom,perfcl-apcs-mem-acc-val = + <0x00000000 0x00000000 0x10000000>, + <0x00000000 0x00000000 0x10000000>, + <0x00000000 0x00000000 0x00000000>, + <0x00000000 0x00000000 0x00000001>; + + clock-names = "aux_clk"; + clocks = <&clock_gcc clk_gpll0_ao>; + #clock-cells = <1>; + }; +} diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt index ae4afc6dcfe0..1505fb8e131a 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -2,31 +2,22 @@ SPM AVS Wrapper 2 (SAW2) The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable -power-controller that transitions a piece of hardware (like a processor or +micro-controller that transitions a piece of hardware (like a processor or subsystem) into and out of low power modes via a direct connection to the PMIC. It can also be wired up to interact with other processors in the system, notifying them when a low power state is entered or exited. -Multiple revisions of the SAW hardware are supported using these Device Nodes. -SAW2 revisions differ in the register offset and configuration data. Also, the -same revision of the SAW in different SoCs may have different configuration -data due the the differences in hardware capabilities. Hence the SoC name, the -version of the SAW hardware in that SoC and the distinction between cpu (big -or Little) or cache, may be needed to uniquely identify the SAW register -configuration and initialization data. The compatible string is used to -indicate this parameter. - PROPERTIES - compatible: Usage: required Value type: <string> - Definition: Must have - "qcom,saw2" - A more specific value could be one of: - "qcom,apq8064-saw2-v1.1-cpu" - "qcom,msm8974-saw2-v2.1-cpu" - "qcom,apq8084-saw2-v2.1-cpu" + Definition: shall contain "qcom,saw2". A more specific value should be + one of: + "qcom,saw2-v1" + "qcom,saw2-v1.1" + "qcom,saw2-v2" + "qcom,saw2-v2.1" - reg: Usage: required @@ -35,23 +26,10 @@ PROPERTIES the register region. An optional second element specifies the base address and size of the alias register region. -- regulator: - Usage: optional - Value type: boolean - Definition: Indicates that this SPM device acts as a regulator device - device for the core (CPU or Cache) the SPM is attached - to. -Example 1: +Example: - power-controller@2099000 { + regulator@2099000 { compatible = "qcom,saw2"; reg = <0x02099000 0x1000>, <0x02009000 0x1000>; - regulator; - }; - -Example 2: - saw0: power-controller@f9089000 { - compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2"; - reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/arm/msm/qsee_ipc_irq_bridge.txt b/Documentation/devicetree/bindings/arm/msm/qsee_ipc_irq_bridge.txt new file mode 100644 index 000000000000..442ad52b4bf6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qsee_ipc_irq_bridge.txt @@ -0,0 +1,30 @@ +Qualcomm Technologies, Inc. Secure Execution Environment IPC Interrupt Bridge + +[Root level node] +Required properties: +-compatible : should be "qcom,qsee-ipc-irq-bridge"; + +[Second level nodes] +qcom,qsee-ipc-irq-subsystem +Required properties: +-qcom,dev-name: the bridge device name +-interrupt: IPC interrupt line from remote subsystem to QSEE +-label : The name of this subsystem. + +Required properties if interrupt type is IRQ_TYPE_LEVEL_HIGH[4]: +-qcom,rx-irq-clr : the register to clear the level triggered rx interrupt +-qcom,rx-irq-clr-mask : the bitmask to clear the rx interrupt + +Example: + + qcom,qsee_ipc_irq_bridge { + compatible = "qcom,qsee-ipc-irq-bridge"; + + qcom,qsee-ipc-irq-spss { + qcom,rx-irq-clr = <0x1d08008 0x4>; + qcom,rx-irq-clr-mask = <0x2>; + qcom,dev-name = "qsee_ipc_irq_spss"; + interrupts = <0 349 4>; + label = "spss"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/rdbg-smp2p.txt b/Documentation/devicetree/bindings/arm/msm/rdbg-smp2p.txt new file mode 100644 index 000000000000..ce2d8bd54e43 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rdbg-smp2p.txt @@ -0,0 +1,17 @@ +Qualcomm Technologies, Inc. Remote Debugger (RDBG) driver + +Required properties: +-compatible : Should be one of + To communicate with modem + qcom,smp2pgpio_client_rdbg_2_in (inbound) + qcom,smp2pgpio_client_rdbg_2_out (outbound) + To communicate with modem + qcom,smp2pgpio_client_rdbg_1_in (inbound) + qcom,smp2pgpio_client_rdbg_1_out (outbound) +-gpios : the relevant gpio pins of the entry. + +Example: + qcom,smp2pgpio_client_rdbg_2_in { + compatible = "qcom,smp2pgpio_client_rdbg_2_in"; + gpios = <&smp2pgpio_rdbg_2_in 0 0>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-log.txt b/Documentation/devicetree/bindings/arm/msm/rpm-log.txt new file mode 100644 index 000000000000..298dd1859b5b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-log.txt @@ -0,0 +1,61 @@ +* RPM Log + +RPM maintains Ulog in the RPM RAM. A device tree node is added +that will hold the address of the RPM RAM region from where +Ulog is read. The physical address from the RPM RAM region +contains a header where various parameters to read the log are +defined. These parameter's offsets in the header are also stored +as a part of the device tree node. + +The required properties for rpm-log are: + +- compatible: "qcom,rpm-log" +- reg: Specifies the base physical address and the size of the RPM + registers from where ulog is read. + Second register(optional) specifies the offset of the rpm + log start address pointer. If the second register is available, + the offset value read is added to the first register address + to read the ulog message. +- qcom,rpm-addr-phys: RPM reads physical address of the RPM RAM region + differently when compared to Apps. Physical address of + the RPM RAM region is at an offset when seen from Apps. + This property specifies the offset which will get added + to the physical address of RPM RAM to make it + accessible to the Apps. +- qcom,offset-version: Offset from the start of the phys_addr_base where version + information is stored. +- qcom,offset-page-buffer-addr: Offset from the start of the phys_addr_base + where raw log start address is stored. Raw log + start address is the start of raw log in the + RPM address space as it should be seen from rpm. +- qcom,offset-log-len: Offset from the start of the phy_addr_base where log + length is stored. +- qcom,offset-log-len-mask: Offset from the start of the phy_addr_base where + log length mask is stored. +- qcom,offset-page-indices: Offset from the start of the phy_addr_base where + index to the writer is stored. + +Example 1: +qcom,rpm-log@fc19dc00 { + compatible = "qcom,rpm-log"; + reg = <0xfc19dc00 0x2000>; + qcom,offset-rpm-addr = <0xfc000000>; + qcom,offset-version = <4>; + qcom,offset-page-buffer-addr = <36>; + qcom,offset-log-len = <40>; + qcom,offset-log-len-mask = <44>; + qcom,offset-page-indices = <56>; +}; + +Example 2: +qcom,rpm-log@fc000000 { + compatible = "qcom,rpm-log"; + reg = <0xfc000000 0x2000>, + <0xfc190018 0x4>; + qcom,offset-rpm-addr = <0xfc000000>; + qcom,offset-version = <4>; + qcom,offset-page-buffer-addr = <36>; + qcom,offset-log-len = <40>; + qcom,offset-log-len-mask = <44>; + qcom,offset-page-indices = <56>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-master-stats.txt b/Documentation/devicetree/bindings/arm/msm/rpm-master-stats.txt new file mode 100644 index 000000000000..02396745dd5e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-master-stats.txt @@ -0,0 +1,29 @@ +* RPM Master Stats + +RPM maintains each master data in RPM message RAM at a specific +offset. It tells about the individual masters information at +any given time like "number of active cores in sub system", +"number of shutdowns" and "wakeup reason for SS" etc. These stats +can be show to the user using the debugfs interface of the kernel. +To achieve this device tree node has been added and it will hold +the address of the RPM RAM from where master stats are read. +Added version number to distinguish the type of data structure +being read from the RAM for different targets. + +The required properties for rpm-master-stats are: + +- compatible: "qcom,rpm-master-stats". +- reg: The address on the RPM RAM from where stats are read. +- qcom,masters: Each master name. +- qcom,master-offset: Offset required to access each master stats area. +- qcom,master-stats-version: Version number. + +Example: + +qcom,rpm-stats@fc428150 { + compatible = "qcom,rpm-stats"; + reg = <0xfc428150 0x1000>; + qcom,masters = "APSS", "MPSS", "LPSS", "PRONTO"; + qcom,master-offset = <2560>; + qcom,master-stats-version = <2>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-rail-stats.txt b/Documentation/devicetree/bindings/arm/msm/rpm-rail-stats.txt new file mode 100644 index 000000000000..2253f0190fc0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-rail-stats.txt @@ -0,0 +1,27 @@ +* RPM Rail Stats + +RPM maintains rail and corner data in the RPM RAM. A device tree node +will hold the address of the RPM RAM from where rail stats are read. + +RPM maintains free heap space availability in the RPM RAM. RPM free heap +space value is required for debugging purpose. + +The required properties for rpm-rail-stats are: + +- compatible: "qcom,rpm-rail-stats" +- reg: The address on the RPM RAM from where stats are read. + + Second register specifies the offset of the rpm rail + stats start address pointer. + +- reg-names: Name of the register holding address. + +Example: + +qcom,rpm-stats@200000 { + compatible = "qcom,rpm-stats"; + reg = <0x200000 0x100>, + <0x290000 0x4>; + reg-names = "phys_addr_base", + "offset_addr" +}; diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-rbcpr-stats.txt b/Documentation/devicetree/bindings/arm/msm/rpm-rbcpr-stats.txt new file mode 100644 index 000000000000..9b69037a179a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-rbcpr-stats.txt @@ -0,0 +1,26 @@ +* RPM RBCPR + +The RBCPR(Rapid Bridge Core Power Reduction) is module on RPM that controls +the voltage level on the chip based on feedback received through various +sensors on the chip that allow compensation of the chip process variation, +temperature etc. +RPM maintains RBCPR (Rapid Bridge Core Power Reduction) related stats in +data memory. This module allows users to read those stats. + +The required properties for rpm-stats are: + +- compatible: "qcom,rpmrbcpr-stats" +- reg: Pointer to the start of the RPM Data Memory. The size of the memory + is inclusive of the entire RPM data memory. +- qcom,start_offset: The offset at which the RBCPR stats are maintained. The + driver module reads this parameter to get another offset + that contain the rbcpr stats. + + +Example: + +qcom,rpm-rbcpr-stats@fc000000 { + compatible = "qcom,rpmrbcpr-stats"; + reg = <0xfc000000 0x1a0000>; + qcom,start-offset = <0x190010>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-smd.txt b/Documentation/devicetree/bindings/arm/msm/rpm-smd.txt new file mode 100644 index 000000000000..4cba3ecaeb90 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-smd.txt @@ -0,0 +1,41 @@ +Resource Power Manager(RPM) + +RPM is a dedicated hardware engine for managing shared SoC resources, +which includes buses, clocks, power rails, etc. The goal of RPM is +to achieve the maximum power savings while satisfying the SoC's +operational and performance requirements. RPM accepts resource +requests from multiple RPM masters. It arbitrates and aggregates the +requests, and configures the shared resources. The RPM masters are +the application processor, the modem processor, as well as hardware +accelerators. The RPM driver communicates with the hardware engine using +SMD. + +The devicetree representation of the SPM block should be: + +Required properties + +- compatible: "qcom,rpm-smd" or "qcom,rpm-glink" +- rpm-channel-name: The string corresponding to the channel name of the + peripheral subsystem. Required for both smd and + glink transports. +- rpm-channel-type: The interal SMD edge for this subsystem found in + <soc/qcom/smd.h> +- qcom,glink-edge: Logical name of the remote subsystem. This is a required + property when rpm-smd driver using glink as trasport. + +Optional properties +- rpm-standalone: Allow RPM driver to run in standalone mode irrespective of RPM + channel presence. +- reg: Contains the memory address at which rpm messaging format version is + stored. If this field is not present, the target only supports v0 format. + +Example: + + qcom,rpm-smd@68150 { + compatible = "qcom,rpm-smd", "qcom,rpm-glink"; + reg = <0x68150 0x3200>; + qcom,rpm-channel-name = "rpm_requests"; + qcom,rpm-channel-type = 15; /* SMD_APPS_RPM */ + qcom,glink-edge = "rpm"; + } +} diff --git a/Documentation/devicetree/bindings/arm/msm/rpm-stats.txt b/Documentation/devicetree/bindings/arm/msm/rpm-stats.txt new file mode 100644 index 000000000000..3692ef8bd8d8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/rpm-stats.txt @@ -0,0 +1,43 @@ +* RPM Sleep Stats + +RPM maintains sleep data in the RPM RAM. A device tree node is added +that will hold the address of the RPM RAM from where sleep stats are read. +Additionally a version number is added to distinguish the type of data +structure being read from the RAM. + +RPM maintains free heap space availability in the RPM RAM. RPM free heap space +value is required for debugging purpose. + +The required properties for rpm-stats are: + +- compatible: "qcom,rpm-stats" +- reg: The address on the RPM RAM from where stats are read. + + Second register(optional) specifies the offset of the rpm + stats start address pointer. If the second register is + available, the offset value read is added to the first + register address to read the stats. + + Third register(optional) specifies the offset of the rpm + free heap space value. +- reg-names: Name given the register holding address. +- qcom,sleep-stats-version: Version number. + +Example 1: + +qcom,rpm-stats@fc19dbd0 { + compatible = "qcom,rpm-stats"; + reg = <0xfc19dbd0 0x1000>; + reg-names = "phys_addr_base"; + qcom,sleep-stats-version = <2>; +}; + +Example 2: + +qcom,rpm-stats@fc000000 { + compatible = "qcom,rpm-stats"; + reg = <0xfc000000 0x1000>, + <0xfc190014 0x4>; + reg-names = "phys_addr_base"; + qcom,sleep-stats-version = <2>; +}; diff --git a/Documentation/devicetree/bindings/arm/msm/sleepstate-smp2p.txt b/Documentation/devicetree/bindings/arm/msm/sleepstate-smp2p.txt new file mode 100644 index 000000000000..adfa94f9d1ff --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/sleepstate-smp2p.txt @@ -0,0 +1,13 @@ +Qualcomm Technologies, Inc. SMSM Point-to-Point (SMP2P) Sleepstate driver + +Required properties: +-compatible : should be one of the following: +- "qcom,smp2pgpio_sleepstate_3_out" - for sensor processor on remote pid 3 +- "qcom,smp2pgpio-sleepstate-out" - for other cases +-gpios : the relevant gpio pins of the entry. + +Example: + qcom,smp2pgpio-sleepstate-3-out { + compatible = "qcom,smp2pgpio_sleepstate_3_out"; + gpios = <&smp2pgpio_sleepstate_3_out 0 0>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/smdpkt.txt b/Documentation/devicetree/bindings/arm/msm/smdpkt.txt new file mode 100644 index 000000000000..eb1016bfa523 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/smdpkt.txt @@ -0,0 +1,43 @@ +Qualcomm Shared Memory Packet Driver (smdpkt) + +[Root level node] +Required properties: +-compatible : should be "qcom,smdpkt" + +[Second level nodes] +qcom,smdpkt-port-names +Required properties: +-qcom,smdpkt-remote : the remote subsystem name +-qcom,smdpkt-port-name : the smd channel name +-qcom,smdpkt-dev-name : the smdpkt device name + +Example: + + qcom,smdpkt { + compatible = "qcom,smdpkt"; + + qcom,smdpkt-data5-cntl { + qcom,smdpkt-remote = "modem"; + qcom,smdpkt-port-name = "DATA5_CNTL"; + qcom,smdpkt-dev-name = "smdcntl0"; + }; + + qcom,smdpkt-data6-cntl { + qcom,smdpkt-remote = "modem"; + qcom,smdpkt-port-name = "DATA6_CNTL"; + qcom,smdpkt-dev-name = "smdcntl1"; + }; + + qcom,smdpkt-cxm-qmi-port-8064 { + qcom,smdpkt-remote = "wcnss"; + qcom,smdpkt-port-name = "CXM_QMI_PORT_8064"; + qcom,smdpkt-dev-name = "smd_cxm_qmi"; + }; + + qcom,smdpkt-loopback { + qcom,smdpkt-remote = "modem"; + qcom,smdpkt-port-name = "LOOPBACK"; + qcom,smdpkt-dev-name = "smd_pkt_loopback"; + }; + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/smdtty.txt b/Documentation/devicetree/bindings/arm/msm/smdtty.txt new file mode 100644 index 000000000000..f661b84ae418 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/smdtty.txt @@ -0,0 +1,40 @@ +Qualcomm Shared Memory TTY Driver (smdtty) + +[Root level node] +Required properties: +-compatible : should be "qcom,smdtty" + +[Second level nodes] +qcom,smdtty-port-names +Required properties: +-qcom,smdtty-remote: the remote subsystem name +-qcom,smdtty-port-name : the smd channel name + +Optional properties: +-qcom,smdtty-dev-name : the smdtty device name + +Required alias: +- The index into TTY subsystem is specified via an alias with the following format + 'smd{n}' where n is the tty device index. + +Example: + aliases { + smd1 = &smdtty_apps_fm; + smd36 = &smdtty_loopback; + }; + + qcom,smdtty { + compatible = "qcom,smdtty"; + + smdtty_apps_fm: qcom,smdtty-apps-fm { + qcom,smdtty-remote = "wcnss"; + qcom,smdtty-port-name = "APPS_FM"; + }; + + smdtty_loopback: smdtty-loopback { + qcom,smdtty-remote = "modem"; + qcom,smdtty-port-name = "LOOPBACK"; + qcom,smdtty-dev-name = "LOOPBACK_TTY"; + }; + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/smem.txt b/Documentation/devicetree/bindings/arm/msm/smem.txt new file mode 100644 index 000000000000..2f92c0c2c4c4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/smem.txt @@ -0,0 +1,122 @@ +MSM Shared Memory + +[Root level node] +Required properties: +-compatible : should be "qcom,smem" +-reg : the location and size of smem (optional) + the irq register base address (required) + the location and size of auxiliary smem areas (optional) + the smem target info either from IMEM or register (optional) +-reg-names : "smem" - optional string to identify the shared memory region + "irq-reg-base" - string to identify the irq register region + "aux-mem1", "aux-mem2", "aux-mem3", ... - optional strings to + identify any auxiliary shared memory regions + "smem_targ_info_imem" - optional string to identify + the smem target info from IMEM memory + "smem_targ_info_reg" - optional string to identify + the smem target info from registers + one of the optional register names smem_targ_info_imem, + smem_targ_info_reg, or smem is required. + +Optional properties: +-qcom,mpu-enabled : boolean value indicating that Memory Protection Unit based + security is enabled on the "smem" shared memory region + +[Second level nodes] + +qcom,smd +Required properties: +-compatible : should be "qcom,smd" +-qcom,smd-edge : the smd edge +-qcom,smd-irq-offset : the offset into the irq register base memory for sending + interrupts +-qcom,smd-irq-bitmask : the sending irq bitmask +-interrupts : the receiving interrupt line +-label : the name of the remote subsystem for this edge + +Optional properties: +-qcom,irq-no-suspend: configure the incoming irq line as active during suspend +-qcom,not-loadable : indicates this processor cannot be loaded by PIL + +qcom,smsm +Required properties: +-compatible : should be "qcom,smsm" +-qcom,smsm-edge : the smsm edge +-qcom,smsm-irq-offset : the offset into the irq register base memory for sending + interrupts +-qcom,smsm-irq-bitmask : the sending irq bitmask +-interrupts : the receiving interrupt line + + +Example: + + qcom,smem@fa00000 { + compatible = "qcom,smem"; + reg = <0xfa00000 0x200000>, + <0xfa006000 0x1000>, + <0xfc428000 0x4000>; + reg-names = "smem", "irq-reg-base", "aux-mem1"; + + qcom,smd-modem { + compatible = "qcom,smd"; + qcom,smd-edge = <0>; + qcom,smd-irq-offset = <0x8>; + qcom,smd-irq-bitmask = <0x1000>; + interrupts = <0 25 1>; + label = "modem"; + }; + + qcom,smsm-modem { + compatible = "qcom,smsm"; + qcom,smsm-edge = <0>; + qcom,smsm-irq-offset = <0x8>; + qcom,smsm-irq-bitmask = <0x2000>; + interrupts = <0 26 1>; + }; + + qcom,smd-adsp { + compatible = "qcom,smd"; + qcom,smd-edge = <1>; + qcom,smd-irq-offset = <0x8>; + qcom,smd-irq-bitmask = <0x100>; + interrupts = <0 156 1>; + label = "adsp"; + }; + + qcom,smsm-adsp { + compatible = "qcom,smsm"; + qcom,smsm-edge = <1>; + qcom,smsm-irq-offset = <0x8>; + qcom,smsm-irq-bitmask = <0x200>; + interrupts = <0 157 1>; + }; + + qcom,smd-wcnss { + compatible = "qcom,smd"; + qcom,smd-edge = <6>; + qcom,smd-irq-offset = <0x8>; + qcom,smd-irq-bitmask = <0x20000>; + interrupts = <0 142 1>; + label = "wcnss"; + }; + + qcom,smsm-wcnss { + compatible = "qcom,smsm"; + qcom,smsm-edge = <6>; + qcom,smsm-irq-offset = <0x8>; + qcom,smsm-irq-bitmask = <0x80000>; + interrupts = <0 144 1>; + }; + + qcom,smd-rpm { + compatible = "qcom,smd"; + qcom,smd-edge = <15>; + qcom,smd-irq-offset = <0x8>; + qcom,smd-irq-bitmask = <0x1>; + interrupts = <0 168 1>; + label = "rpm"; + qcom,irq-no-syspend; + qcom,not-loadable; + }; + }; + diff --git a/Documentation/devicetree/bindings/arm/msm/smp2p.txt b/Documentation/devicetree/bindings/arm/msm/smp2p.txt new file mode 100644 index 000000000000..a7af9e7f1ef5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/smp2p.txt @@ -0,0 +1,18 @@ +Qualcomm SMSM Point-to-Point (SMP2P) + +Required properties: +-compatible : should be "qcom,smp2p" +-reg : the location of the irq register base memory +-qcom,remote-pid : the SMP2P remote processor ID (see smp2p_private_api.h) +-qcom,irq-bitmask : the sending irq bitmask +-interrupts : the receiving interrupt line + +Example: + + qcom,smp2p-modem { + compatible = "qcom,smp2p"; + reg = <0xf9011008 0x4>; + qcom,remote-pid = <1>; + qcom,irq-bitmask = <0x4000>; + interrupts = <0 27 1>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/spcom.txt b/Documentation/devicetree/bindings/arm/msm/spcom.txt new file mode 100644 index 000000000000..36a07ec686ad --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/spcom.txt @@ -0,0 +1,11 @@ +Qualcomm Technologies, Inc. Secure Proccessor Communication (spcom) + +Required properties: +-compatible : should be "qcom,spcom" +-qcom,spcom-ch-names: predefined channels name string + +Example: + qcom,spcom { + compatible = "qcom,spcom"; + qcom,spcom-ch-names = "sp_kernel" , "sp_ssr"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/spm-v2.txt b/Documentation/devicetree/bindings/arm/msm/spm-v2.txt new file mode 100644 index 000000000000..194059c39c68 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/spm-v2.txt @@ -0,0 +1,169 @@ +* MSM Subsystem Power Manager (spm-v2) + +S4 generation of MSMs have SPM hardware blocks to control the Application +Processor Sub-System power. These SPM blocks run individual state machine +to determine what the core (L2 or Krait/Scorpion) would do when the WFI +instruction is executed by the core. The SAW hardware block handles SPM and +AVS functionality for the cores. + +The devicetree representation of the SPM block should be: + +Required properties + +- compatible: "qcom,spm-v2" +- reg: The physical address and the size of the SPM's memory mapped registers +- qcom,cpu: phandle for the CPU that the SPM block is attached to. This field +is required on only for SPMs that control the CPU. This field is not required +for SPMs that control L2/CCI/L3 +- qcom,saw2-ver-reg: The location of the version register +- qcom,name: The name with which a SPM device is identified by the power +management code. + +---------------------------------------------------- +Non-PSCI targets should follow the rules shown below +---------------------------------------------------- +Required properties for only Non-PSCI targets: + +- qcom,saw2-cfg: SAW2 configuration register +- qcom,saw2-spm-ctl: The SPM control register +- qcom,saw2-spm-dly: Provides the values for the SPM delay command in the SPM + sequence + +Optional properties for only Non-PSCI targets +- reg-names: Register names for the physical address required if spm device + has more than one physical addressed to be mapped. Allowed register + names are: "saw-base", "q2s", "hw-flush", "slpreq" +- qcom,saw2-avs-ctl: The AVS control register +- qcom,saw2-avs-hysterisis: The AVS hysterisis register to delay the AVS + controller requests +- qcom,vctl-timeout-us: The timeout value in us to wait for voltage to change + after sending the voltage command to the PMIC +- qcom,saw2-avs-limit: The AVS limit register +- qcom,saw2-avs-dly: The AVS delay register is used to specify the delay values + between AVS controller requests +- qcom,saw2-pmic-data0..7: Specify the pmic data value and the associated FTS + index to send the PMIC data to +- qcom,vctl-port: The PVC (PMIC Virtual Channel) port used for changing + voltage +- qcom,phase-port: The PVC port used for changing the number of phases +- qcom,pfm-port: The PVC port used for enabling PWM/PFM modes +- qcom,cpu-vctl-mask: Mask of cpus, whose voltage the spm device can control. + Depricated: Replaced with cpu-vctl-list when cpu phandles are available. +- qcom,cpu-vctl-list: List of cpu node phandles, whose voltage the spm device + can control. +- qcom,use-qchannel-for-pc: Boolean property to specify if qchannel should be + ignored when entering power collapse. If this property is set qchannel + will not be ignored in power collapse. +- qcom,supports-rpm-hs: Indicates that this SPM instance allow handshake with +RPM processor when executing the sleep command in the SPM sequence. Supported +only on SAW2 v3.0 and above. +- qcom,use-spm-clock-gating: This boolean property is used to indicate that + the SPM needs to be used for clock gating. Using the SPM for clock + gating would result in auto clock gating being disabled. Use this on + targets that do not support or do not use auto clock gating. +- qcom,use-qchannel-for-wfi: This boolean property is used to indicate + that the SPM gets triggerd by the qchannel and not by means of + wfi. So a wfe could trigger a spm for clock gating as well. +- modes: Lists all the available low power modes for the device + +Second level properties for modes + +Required properties (if modes node is available) +- qcom,label: Specifies the mode name such as: + qcom,saw2-spm-cmd-wfi: WFI mode + qcom,saw2-spm-cmd-ret: Retention mode + qcom,saw2-spm-cmd-spc: Standalone PC mode + qcom,saw2-spm-cmd-pc: Power Collapse mode + qcom,saw2-spm-cmd-gdhs: GDHS mode +- qcom,sequence: Specifies sequence for the low power mode +Optional properties +- qcom,pc_mode: Specifies pc_mode bit should be set in the SPM control register +- qcom,ret_mode: Specifies ret_mode bit should be set in the SPM control register +- qcom,spm_en: Specifies spm_en bit should be set in the SPM control register +- qcom,isar: Specifies isar bit should be set in the SPM control register + Specify this property only if SPM should retain its start address at + the end of the program. +- qcom,slp_cmd_mode: Specifies slp_cmd_mode bit should be set in SPM control register. + Adding this property results in SPM handshaking with RPM. Please remove + the RPM handshake command from the sleep sequence, replace that with + Sleep without RPM handshake command. +- qcom,event_sync: Specifies event_sync byte should be set in SPM control + register. + +---------------------------------------------------- +PSCI targets should follow the rules shown below +---------------------------------------------------- +Optional properties for only PSCI targets: + +- qcom,saw2-avs-ctl: The AVS control register +- qcom,saw2-avs-hysterisis: The AVS hysterisis register to delay the AVS + controller requests +- qcom,vctl-timeout-us: The timeout value in us to wait for voltage to change + after sending the voltage command to the PMIC +- qcom,saw2-avs-limit: The AVS limit register +- qcom,saw2-avs-dly: The AVS delay register is used to specify the delay values + between AVS controller requests +- qcom,vctl-port: The PVC (PMIC Virtual Channel) port used for changing + voltage +- qcom,phase-port: The PVC port used for changing the number of phases +- qcom,pfm-port: The PVC port used for enabling PWM/PFM modes +- qcom,cpu-vctl-list: List of cpu node phandles, whose voltage the spm device + can control. + + +Example 1: + qcom,spm@f9089000 { + compatible = "qcom,spm-v2"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xf9089000 0x1000>; + qcom,cpu = <&CPU0>; + qcom,saw2-ver-reg = <0xfd0>; + qcom,saw2-cfg = <0x1b>; + qcom,saw2-avs-ctl = <0>; + qcom,saw2-avs-hysteresis = <0>; + qcom,saw2-avs-limit = <0>; + qcom,saw2-avs-dly= <0>; + qcom,saw2-spm-dly= <0x20000400>; + qcom,saw2-spm-ctl = <0x1>; + qcom,cpu-vctl-list = <&CPU0 &CPU1 &CPU2 &CPU3>; + qcom,mode0 { + qcom,label = "qcom,saw2-spm-cmd-wfi"; + qcom,sequence = [03 0b 0f]; + qcom,spm_en; + }; + + qcom,mode1 { + qcom,label = "qcom,saw2-spm-cmd-spc"; + qcom,sequence = [00 20 50 80 60 70 10 92 + a0 b0 03 68 70 3b 92 a0 b0 + 82 2b 50 10 30 02 22 30 0f]; + qcom,spm_en; + qcom,pc_mode; + }; + + qcom,mode2 { + qcom,label = "qcom,saw2-spm-cmd-pc"; + qcom,sequence = [00 20 10 92 a0 b0 07 3b 92 + a0 b0 82 10 30 02 22 30 0f]; + qcom,spm_en; + qcom,pc_mode; + }; + }; + +Example 2: + qcom,spm@9A10000 { + compatible = "qcom,spm-v2"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x9A10000 0x1000>; + qcom,name = "system-cbf"; /* CBF SAW */ + qcom,saw2-ver-reg = <0xFD0>; + qcom,cpu-vctl-list = <&CPU0 &CPU1 &CPU2 &CPU3>; + qcom,vctl-timeout-us = <50>; + qcom,vctl-port = <0x0>; + qcom,phase-port = <0x1>; + qcom,saw2-avs-ctl = <0x1100>; + qcom,pfm-port = <0x2>; +}; + diff --git a/Documentation/devicetree/bindings/arm/msm/spss_utils.txt b/Documentation/devicetree/bindings/arm/msm/spss_utils.txt new file mode 100644 index 000000000000..0e8e75ba87f8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/spss_utils.txt @@ -0,0 +1,35 @@ +Qualcomm Technologies, Inc. Secure Processor SubSystem Utilities (spss_utils) + +The Secure Processor SubSystem (SPSS) is a dedicated subsystem for security. +It has its own CPU, memories, and cryptographic engine. +It shall provide cryptographic services to other subsystems. +The SPSS firmware is loaded by PIL driver. +The communication with SPSS is done via spcom driver, using glink. + +The spss_utils driver selects the SPSS firmware file, +according to a dedicated fuse and the platform HW version. + +Required properties: +-compatible : should be "qcom,spss_utils" +-qcom,spss-fuse1-addr: fuse1 register physical address +-qcom,spss-fuse1-bit: fuse1 relevant bit +-qcom,spss-fuse2-addr: fuse2 register physical address +-qcom,spss-fuse2-bit: fuse2 relevant bit +-qcom,spss-test-firmware-name: test firmware file name +-qcom,spss-prod-firmware-name: production firmware file name +-qcom,spss-hybr-firmware-name: hybrid firmware file name +-qcom,spss-debug-reg-addr: debug register physical address + +Example: + qcom,spss_utils { + compatible = "qcom,spss-utils"; + + qcom,spss-fuse1-addr = <0x007841c4>; + qcom,spss-fuse1-bit = <27>; + qcom,spss-fuse2-addr = <0x0078413c>; + qcom,spss-fuse2-bit = <31>; + qcom,spss-test-firmware-name = "spss2t"; /* 8 chars max */ + qcom,spss-prod-firmware-name = "spss2p"; /* 8 chars max */ + qcom,spss-hybr-firmware-name = "spss2h"; /* 8 chars max */ + qcom,spss-debug-reg-addr = <0x01d06020>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/system_health_monitor.txt b/Documentation/devicetree/bindings/arm/msm/system_health_monitor.txt new file mode 100644 index 000000000000..bcc8e00d14c3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/system_health_monitor.txt @@ -0,0 +1,35 @@ +System Health Monitor + +[Root level node] +Required properties: +-compatible: should be "qcom,system-health-monitor" + +[Second level nodes] +Information about subsystems that are monitored by System Health Monitor. +Subsystems include modem, adsp, wcnss, external MDM(esoc). +Required properties: +-qcom,subsys-name: Name as identified by a subsystem +-qcom,ssrestart-string: String used by subsystem restart to identify + the subsystem + +Example: + qcom,system-health-monitor { + compatible = "qcom,system-health-monitor"; + + qcom,modem { + qcom,subsys-name = "msm_mpss"; + qcom,ssrestart-string = "modem"; + }; + qcom,adsp { + qcom,subsys-name = "msm_adsp"; + qcom,ssrestart-string = "adsp"; + }; + qcom,wcnss { + qcom,subsys-name = "msm_wcnss"; + qcom,ssrestart-string = "wcnss"; + }; + qcom,esoc { + qcom,subsystem-name = "mdm"; + qcom,ssrestart-string = "esoc"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/system_stats.txt b/Documentation/devicetree/bindings/arm/msm/system_stats.txt new file mode 100644 index 000000000000..39961ca534a5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/system_stats.txt @@ -0,0 +1,93 @@ +* System sleep stats + +Resource Power manager maintains information about system sleep and the time +each master spent in respective sleep modes. These were previously exported +through two modules, one for system and another for the respective master +votes. The two modules are now combined into a system stats drivers to provide +better visibility into system sleep modes. + +Main node properties + +- compatible + Usage: Required + Value type: <string> + Definition: must be "qcom,system-stats". + +- qcom,rpm-msg-ram + Usage: Required + Value type: <phandle> + Definition: phandle to RPM's message ram registers. + +- qcom,rpm-code-ram + Usage: Required + Value type: <phandle> + Definition: phandle to RPM's code ram registers. + +- qcom,masters: + Usage: Required + Value type: <string list> + +Definition of memory DT phandles that system stats module is dependent on. + +qcom,rpm-msg-ram: + +The required phandle pointed to by qcom,rpm-msg-ram are: +Node properties: +- compatible: + Usage: Required + Value Type: <string> + Definition: must be "qcom,rpm-msg-ram" + +- reg: + Usage: Required + Value Type: <prop-encoded-array> + Definition: Addresses and sizes for RPM address as visible to Apps and + Stats address location. + +- reg-names: + Usage: Required + Value Type: <stringlist> + Definition: Address names. Must be "phys_addr_base" or "msg-ram-base". + Must be specified in the same order as the + corresponding addresses in the reg property. + +qcom,rpm-code-ram: +The required phandle pointed to by qcom,rpm-msg-ram are: + +Node properties: +- compatible: + Usage: Required + Value Type: <string> + Definition: must be "qcom,rpm-code-ram". +- reg: + Usage: Required + Value Type: <prop-encoded-array> + Definition: Address and size for RPM code address. + +- reg-names: + Usage: Required + Value Type: <stringlist> + Definition: Address names. Must be "msg-ram-base" + +Example: + + rpm_code_ram: rpm-memory@0x68000 { + compatible = "qcom,rpm-code-ram"; + reg = <0x68000 0x5000>; + reg-name = "msg-ram-base"; + }; + + rpm_msg_ram: memory@0x200000 { + compatible = "qcom,rpm-msg-ram"; + reg = <0x200000 0x1000>, + <0x290000 0x1000>; + reg-names = "phys_addr_base", + "code-ram-base"; + }; + + qcom,system-stats@68140 { + compatible = "qcom,system-stats"; + qcom,rpm-msg-ram = <&rpm_msg_ram>; + qcom,rpm-code-ram = <&rpm_code_ram>; + qcom,masters = "APSS", "MPSS", "ADSP", "SLPI"; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/tz-log.txt b/Documentation/devicetree/bindings/arm/msm/tz-log.txt new file mode 100644 index 000000000000..d7e84a35e91d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/tz-log.txt @@ -0,0 +1,24 @@ +* TZLOG (Trust Zone Log) + +The tz_log driver is a platform device driver that exposes a debugfs +interface for accessing and displaying diagnostic information +related to secure code (Trustzone/QSEE). + +Required properties: +- compatible : Should be "qcom,tz-log" +- reg : Offset and size of the register set for the device + +Optional properties: +- qcom,hyplog-enabled : (boolean) indicates if driver supports HYP logger service. +- hyplog-address-offset : Register offset to get the HYP log base address. +- hyplog-size-offset : Register offset to get the HYP log size parameter. + +Example: + + qcom,tz-log@fe805720 { + compatible = "qcom,tz-log"; + reg = <0xfe805720 0x1000>; + qcom,hyplog-enabled; + hyplog-address-offset = 0x410; + hyplog-size-offset = 0x414; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/wil6210.txt b/Documentation/devicetree/bindings/arm/msm/wil6210.txt new file mode 100644 index 000000000000..b381bdebdfc9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/wil6210.txt @@ -0,0 +1,52 @@ +wil6210 - Qualcomm Technologies Inc. 802.11ad Wireless Driver + +wil6210 driver is responsible for managing 802.11ad chipset +connected to MSM over PCIe interface. + +The platform data is needed in order to perform proper +bus-scaling and SMMU initialization by the driver. + +Required properties: + +- compatible: "qcom,wil6210" +- qcom,smmu-support: Boolean flag indicating whether PCIe has SMMU support +- qcom,pcie-parent: phandle for the PCIe root complex to which 11ad card is connected +- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + the below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + +Optional properties: +- qcom,sleep-clk-en: GPIO for sleep clock used for low power modes by 11ad card +- qcom,wigig-en: Enable GPIO connected to 11ad card +- qcom,use-ext-supply: Boolean flag to indicate if 11ad SIP uses external power supply +- vdd-supply: phandle to 11ad VDD regulator node +- vddio-supply: phandle to 11ad VDDIO regulator node +- qcom,use-ext-clocks: Boolean flag to indicate if 11ad SIP uses external clocks +- clocks : List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. + +Example: + wil6210: qcom,wil6210 { + compatible = "qcom,wil6210"; + qcom,smmu-support; + qcom,pcie-parent = <&pcie1>; + qcom,wigig-en = <&tlmm 94 0>; + qcom,msm-bus,name = "wil6210"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <100 512 0 0>, + <100 512 600000 800000>; /* ~4.6Gbps (MCS12) */ + qcom,use-ext-supply; + vdd-supply= <&pm8998_s7>; + vddio-supply= <&pm8998_s5>; + qcom,use-ext-clocks; + clocks = <&clock_gcc clk_rf_clk3>, + <&clock_gcc clk_rf_clk3_pin>; + clock-names = "rf_clk3_clk", "rf_clk3_pin_clk"; + }; + diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 97ba45af04fc..251f18736767 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -24,6 +24,7 @@ Required properties: "qcom,scorpion-pmu" "qcom,scorpion-mp-pmu" "qcom,krait-pmu" + "qcom,kryo-pmuv3" - interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu interrupt (PPI) then 1 interrupt should be specified. @@ -45,6 +46,16 @@ Optional properties: - qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd events. +- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register + (SDER) is accessible. This will cause the driver to do + any setup required that is only possible in ARMv7 secure + state. If not present the ARMv7 SDER will not be touched, + which means the PMU may fail to operate unless external + code (bootloader or security monitor) has performed the + appropriate initialisation. Note that this property is + not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux + in Non-secure state. + Example: pmu { diff --git a/Documentation/devicetree/bindings/batterydata/batterydata.txt b/Documentation/devicetree/bindings/batterydata/batterydata.txt new file mode 100644 index 000000000000..39f9375a6c48 --- /dev/null +++ b/Documentation/devicetree/bindings/batterydata/batterydata.txt @@ -0,0 +1,221 @@ +Battery Profile Data + +Battery Data is a collection of battery profile data made available to +the QPNP Charger and BMS drivers via device tree. + +qcom,battery-data node required properties: +- qcom,rpull-up-kohm : The vadc pullup resistor's resistance value in kOhms. +- qcom,vref-batt-therm-uv : The vadc voltage used to make readings. + For Qualcomm Technologies, Inc. VADCs, this should be + 1800000uV. + +qcom,battery-data node optional properties: +- qcom,batt-id-range-pct : The area of variation between upper and lower bound + for which a given battery ID resistance is valid. This + value is expressed as a percentage of the specified kohm + resistance provided by qcom,batt-id-kohm. + +qcom,battery-data can also include any number of children nodes. These children +nodes will be treated as battery profile data nodes. + +Profile data node required properties: +- qcom,fcc-mah : Full charge count of the battery in milliamp-hours +- qcom,default-rbatt-mohm : The nominal battery resistance value +- qcom,rbatt-capacitive-mohm : The capacitive resistance of the battery. +- qcom,flat-ocv-threshold-uv : The threshold under which the battery can be + considered to be in the flat portion of the discharge + curve. +- qcom,max-voltage-uv : The maximum rated voltage of the battery +- qcom,v-cutoff-uv : The cutoff voltage of the battery at which the device + should shutdown gracefully. +- qcom,chg-term-ua : The termination charging current of the battery. +- qcom,batt-id-kohm : The battery id resistance of the battery. It can be + used as an array which could support multiple IDs for one battery + module when the ID resistance of some battery modules goes across + several ranges. +- qcom,battery-type : A string indicating the type of battery. +- qcom,fg-profile-data : An array of hexadecimal values used to configure more + complex fuel gauge peripherals which have a large amount + of coefficients used in hardware state machines and thus + influencing the final output of the state of charge read + by software. + +Profile data node optional properties: +- qcom,chg-rslow-comp-c1 : A constant for rslow compensation in the fuel gauge. + This will be provided by the profiling tool for + additional fuel gauge accuracy during charging. +- qcom,chg-rslow-comp-c2 : A constant for rslow compensation in the fuel gauge. + This will be provided by the profiling tool for + additional fuel gauge accuracy during charging. +- qcom,chg-rslow-comp-thr : A constant for rslow compensation in the fuel gauge. + This will be provided by the profiling tool for + additional fuel gauge accuracy during charging. +- qcom,chg-rs-to-rslow: A constant for rslow compensation in the fuel gauge. + This will be provided by the profiling tool for + additional fuel gauge accuracy during charging. +- qcom,fastchg-current-ma: Specifies the maximum fastcharge current. +- qcom,fg-cc-cv-threshold-mv: Voltage threshold in mV for transition from constant + charge (CC) to constant voltage (CV). This value should + be 10 mV less than the float voltage. + This property should only be specified if + "qcom,autoadjust-vfloat" property is specified in the + charger driver to ensure a proper operation. +- qcom,thermal-coefficients: Byte array of thermal coefficients for reading + battery thermistor. This should be exactly 6 bytes + in length. + Example: [01 02 03 04 05 06] + +Profile data node required subnodes: +- qcom,fcc-temp-lut : An 1-dimensional lookup table node that encodes + temperature to fcc lookup. The units for this lookup + table should be degrees celsius to milliamp-hours. +- qcom,pc-temp-ocv-lut : A 2-dimensional lookup table node that encodes + temperature and percent charge to open circuit voltage + lookup. The units for this lookup table should be + degrees celsius and percent to millivolts. +- qcom,rbatt-sf-lut : A 2-dimentional lookup table node that encodes + temperature and percent charge to battery internal + resistance lookup. The units for this lookup table + should be degrees celsius and percent to milliohms. + +Profile data node optional subnodes: +- qcom,ibat-acc-luit: A 2-dimentional lookup table that encodes temperature + and battery current to battery ACC (apparent charge + capacity). The units for this lookup table should be + temperature in degrees celsius, ibat in milli-amps + and ACC in milli-ampere-hour. + +Lookup table required properties: +- qcom,lut-col-legend : An array that encodes the legend of the lookup table's + columns. The length of this array will determine the + lookup table's width. +- qcom,lut-data : An array that encodes the lookup table's data. The size of this + array should be equal to the size of qcom,lut-col-legend + multiplied by 1 if it's a 1-dimensional table, or + the size of qcom,lut-row-legend if it's a 2-dimensional + table. The data should be in a flattened row-major + representation. + +Lookup table optional properties: +- qcom,lut-row-legend : An array that encodes the legend of the lookup table's rows. + If this property exists, then it is assumed that the + lookup table is a 2-dimensional table. + +Example: + +In msm8974-mtp.dtsi: + +mtp_batterydata: qcom,battery-data { + qcom,rpull-up-kohm = <100>; + qcom,vref-batt-therm-uv = <1800000>; + + /include/ "batterydata-palladium.dtsi" + /include/ "batterydata-mtp-3000mah.dtsi" +}; + +&pm8941_bms { + qcom,battery-data = <&mtp_batterydata>; +}; + +In batterydata-palladium.dtsi: + +qcom,palladium-batterydata { + qcom,fcc-mah = <1500>; + qcom,default-rbatt-mohm = <236>; + qcom,rbatt-capacitive-mohm = <50>; + qcom,flat-ocv-threshold-uv = <3800000>; + qcom,max-voltage-uv = <4200000>; + qcom,v-cutoff-uv = <3400000>; + qcom,chg-term-ua = <100000>; + qcom,batt-id-kohm = <75>; + qcom,battery-type = "palladium_1500mah"; + + qcom,fcc-temp-lut { + qcom,lut-col-legend = <(-20) 0 25 40 65>; + qcom,lut-data = <1492 1492 1493 1483 1502>; + }; + + qcom,pc-temp-ocv-lut { + qcom,lut-col-legend = <(-20) 0 25 40 65>; + qcom,lut-row-legend = <100 95 90 85 80 75 70>, + <65 60 55 50 45 40 35>, + <30 25 20 15 10 9 8>, + <7 6 5 4 3 2 1 0>; + qcom,lut-data = <4173 4167 4163 4156 4154>, + <4104 4107 4108 4102 4104>, + <4057 4072 4069 4061 4060>, + <3973 4009 4019 4016 4020>, + <3932 3959 3981 3982 3983>, + <3899 3928 3954 3950 3950>, + <3868 3895 3925 3921 3920>, + <3837 3866 3898 3894 3892>, + <3812 3841 3853 3856 3862>, + <3794 3818 3825 3823 3822>, + <3780 3799 3804 3804 3803>, + <3768 3787 3790 3788 3788>, + <3757 3779 3778 3775 3776>, + <3747 3772 3771 3766 3765>, + <3736 3763 3766 3760 3746>, + <3725 3749 3756 3747 3729>, + <3714 3718 3734 3724 3706>, + <3701 3703 3696 3689 3668>, + <3675 3695 3682 3675 3662>, + <3670 3691 3680 3673 3661>, + <3661 3686 3679 3672 3656>, + <3649 3680 3676 3669 3641>, + <3633 3669 3667 3655 3606>, + <3610 3647 3640 3620 3560>, + <3580 3607 3596 3572 3501>, + <3533 3548 3537 3512 3425>, + <3457 3468 3459 3429 3324>, + <3328 3348 3340 3297 3172>, + <3000 3000 3000 3000 3000>; + }; + + qcom,rbatt-sf-lut { + qcom,lut-col-legend = <(-20) 0 25 40 65>; + qcom,lut-row-legend = <100 95 90 85 80 75 70>, + <65 60 55 50 45 40 35>, + <30 25 20 15 10 9 8>, + <7 6 5 4 3 2 1 0>; + qcom,lut-data = <357 187 100 91 91>, + <400 208 105 94 94>, + <390 204 106 95 96>, + <391 201 108 98 98>, + <391 202 110 98 100>, + <390 200 110 99 102>, + <389 200 110 99 102>, + <393 202 101 93 100>, + <407 205 99 89 94>, + <428 208 100 91 96>, + <455 212 102 92 98>, + <495 220 104 93 101>, + <561 232 107 95 102>, + <634 245 112 98 98>, + <714 258 114 98 98>, + <791 266 114 97 100>, + <871 289 108 95 97>, + <973 340 124 108 105>, + <489 241 109 96 99>, + <511 246 110 96 99>, + <534 252 111 95 98>, + <579 263 112 96 96>, + <636 276 111 95 97>, + <730 294 109 96 99>, + <868 328 112 98 104>, + <1089 374 119 101 115>, + <1559 457 128 105 213>, + <12886 1026 637 422 3269>, + <170899 127211 98968 88907 77102>; + }; + + qcom,ibat-acc-lut { + qcom,lut-col-legend = <(-20) 0 25>; + qcom,lut-row-legend = <0 250 500 1000>; + qcom,lut-data = <1470 1470 1473>, + <1406 1406 1430>, + <1247 1247 1414>, + <764 764 1338>; + }; +}; + diff --git a/Documentation/devicetree/bindings/bif/bif.txt b/Documentation/devicetree/bindings/bif/bif.txt new file mode 100644 index 000000000000..c4ff08b388da --- /dev/null +++ b/Documentation/devicetree/bindings/bif/bif.txt @@ -0,0 +1,22 @@ +BIF (Battery Interface) Controllers + +Optional properties: +- qcom,known-device-addresses: Specifies a list of integers which correspond to + the 8-bit BIF bus device addresses of BIF slaves + found on the target. + +BIF Consumers + +Optional properties: +- qcom,bif-ctrl: phandle of parent BIF controller device node + +Example: + foo_ctrl: foo-controller { + ... + qcom,known-device-addresses = <0x80, 0x81>; + }; + + bar-consumer { + ... + qcom,bif-ctrl = <&foo_ctrl>; + }; diff --git a/Documentation/devicetree/bindings/bif/qpnp-bsi.txt b/Documentation/devicetree/bindings/bif/qpnp-bsi.txt new file mode 100644 index 000000000000..0ff10a46bc24 --- /dev/null +++ b/Documentation/devicetree/bindings/bif/qpnp-bsi.txt @@ -0,0 +1,93 @@ +Qualcomm QPNP BSI - battery serial interface devices + +qpnp-bsi is a BIF driver which supports the BSI peripheral inside of PMICs +that utilize the MSM SPMI implementation. + +Required properties: +- compatible: Must be "qcom,qpnp-bsi". +- reg: Specifies the SPMI address and size for this BSI device as + well as the address of the BATT_ID status register. +- reg-names: A list of strings identifying the reg property entries. The + list must contain both "bsi-base" and "batt-id-status". +- label: A string used as a descriptive name for this BIF controller. +- interrupts: Specifies a list of four interrupts corresponding to + IRQ ERR, IRQ RX, IRQ TX, and IRQ BATT_PRESENT in any order. +- interrupt-names: Must be a list of strings containing all three of these + strings: "err", "rx", "tx", "batt-present". The ordering of + these strings must match the ordering of the interrupts in + the "interrupts" property. + +Required structure: +- A qcom,qpnp-bsi node must be a child of an SPMI node that has specified the + spmi-slave-container property. + +Optional properties: +- qcom,min-clock-period: This property specifies a minimum clock period for the + Tau BIF reference in nanoseconds. It can be used to + impose a minimum period which is higher (i.e. more + restrictive) than that supported by the hardware. + The BSI module supports 8 possible periods between + 2080 ns and 150420 ns. +- qcom,max-clock-period: This property specifies a maximum clock period for the + Tau BIF reference in nanoseconds. It can be used to + impose a maximum period which is lower (i.e. more + restrictive) than that supported by the hardware. + The BSI module supports 8 possible periods between + 2080 ns and 150420 ns. +- qcom,sample-rate: Specifies the rate at which the BIF BCL should be + sampled during communication with respect to the Tau + BIF reference rate. Supported values are 4 and 8 + which represent 4x and 8x sampling rates + respectively. If this property is not specified, + then 4x sampling is assumed. +- qcom,channel-num: VADC channel number associated PMIC BATT_ID pin. If + no channel is specified, then it will not be + possible to measure the slave Rid. +- qcom,pullup-ohms: Host side pull-up resistance present on BCL in ohms. + If no value is specified, then 100000 ohms is + assumed. +- qcom,vref-microvolts: Reference voltage used for BCL divider circuit in + microvolts. If no value is specified, then + 1800000 uV is assumed. +- qcom,bsi-vadc: Corresponding VADC device phandle. + +All properties specified within for the BIF framework can also be used. These +properties can be found in bif.txt. + +Example: + qcom,spmi@fc4c0000 { + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <3>; + + qcom,pm8941@1 { + spmi-slave-container; + reg = <0x1>; + #address-cells = <1>; + #size-cells = <1>; + + qcom,bsi@1b00 { + compatible = "qcom,qpnp-bsi"; + reg = <0x1b00 0x100>, + <0x1208 0x1>; + reg-names = "bsi-base", "batt-id-status"; + label = "pm8941-bsi"; + interrupts = <0x0 0x1b 0x0>, + <0x0 0x1b 0x1>, + <0x0 0x1b 0x2>, + <0x0 0x12 0x0>; + interrupt-names = "err", + "rx", + "tx", + "batt-present"; + qcom,sample-rate = <8>; + qcom,min-clock-period = <15830>; + qcom,max-clock-period = <122080>; + qcom,channel-num = <0x31>; + qcom,pullup-ohms = <100000>; + qcom,vref-microvolts = <1800000>; + qcom,bsi-vadc = <&pm8941_vadc>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/bluetooth/bluetooth_power.txt b/Documentation/devicetree/bindings/bluetooth/bluetooth_power.txt new file mode 100644 index 000000000000..7b89497f4638 --- /dev/null +++ b/Documentation/devicetree/bindings/bluetooth/bluetooth_power.txt @@ -0,0 +1,59 @@ +* Bluetooth Controller +Bluetooth controller communicates with the Bluetooth Host using HCI Transport layer. +HCI Transport layer can be based on UART or USB serial communication protocol. + +Required properties: + - compatible: Should be set to one of the following: + qca,ar3002 + qca,qca6174 + qca,wcn3990 + - qca,bt-reset-gpio: GPIO pin to bring BT Controller out of reset + +Optional properties: + - qca,bt-vdd-pa-supply: Bluetooth VDD PA regulator handle + - qca,bt-vdd-io-supply: Bluetooth VDD IO regulator handle + - qca,bt-vdd-ldo-supply: Bluetooth VDD LDO regulator handle. Kept under optional parameters + as some of the chipsets doesn't require ldo or it may use from same vddio. + - qca,bt-vdd-xtal-supply: Bluetooth VDD XTAL regulator handle + - qca,bt-vdd-core-supply: Bluetooth VDD CORE regulator handle + - qca,bt-chip-pwd-supply: Chip power down gpio is required when bluetooth module + and other modules like wifi co-exist in a singe chip and shares a + common gpio to bring chip out of reset. + - qca,bt-vdd-pa-voltage-level: specifies VDD PA voltage levels for supply. + Should be specified in pairs (min, max), units uV + - qca,bt-vdd-io-voltage-level: specifies VDD IO voltage levels for supply. + Should be specified in pairs (min, max), units uV + - qca,bt-vdd-ldo-voltage-level: specifies VDD LDO voltage levels for supply. + Should be specified in pairs (min, max), units uV + - qca,bt-vdd-xtal-voltage-level: specifies VDD XTAL voltage levels for supply. + Should be specified in pairs (min, max), units uV + - qca,bt-vdd-core-voltage-level: specifies VDD CORE voltage levels for supply. + Should be specified in pairs (min, max), units uV + - qca,bt-vdd-io-current-level: specifies VDD IO current level in microamps + - qca,bt-vdd-xtal-current-level: specifies VDD XTAL current level in microamps + - qca,bt-vdd-core-current-level: specifies VDD CORE current level in microamps. + - qca,bt-vdd-ldo-current-level: specifies VDD LDO current level in microamps. + - qca,bt-vdd-pa-current-level: specifies VDD PA current level in microamps. + - qca,bt-chip-pwd-current-level: specifies Chip Power current level in microamps. + +Example: + bt-ar3002 { + compatible = "qca,ar3002"; + qca,bt-reset-gpio = <&pm8941_gpios 34 0>; + qca,bt-vdd-io-supply = <&pm8941_s3>; + qca,bt-vdd-pa-supply = <&pm8941_l19>; + qca,bt-vdd-xtal-supply = <&pm8994_l30>; + qca,bt-vdd-core-supply = <&pm8994_s3>; + qca,bt-chip-pwd-supply = <&ath_chip_pwd_l>; + + qca,bt-vdd-io-voltage-level = <1800000 1800000>; + qca,bt-vdd-pa-voltage-level = <2900000 2900000>; + qca,bt-vdd-xtal-voltage-level = <1800000 1800000>; + qca,bt-vdd-core-voltage-level = <1300000 1300000>; + + qca,bt-vdd-io-current-level = <1>; /* LPM/PFM */ + qca,bt-vdd-xtal-current-level = <1>; /* LPM/PFM */ + qca,bt-vdd-core-current-level = <1>; /* LPM/PFM */ + qca,bt-vdd-ldo-current-level = <1>; /* LPM/PFM */ + qca,bt-vdd-pa-current-level = <1>; /* LPM/PFM */ + }; diff --git a/Documentation/devicetree/bindings/bluetooth/btfm_slim.txt b/Documentation/devicetree/bindings/bluetooth/btfm_slim.txt new file mode 100644 index 000000000000..901db5fb502d --- /dev/null +++ b/Documentation/devicetree/bindings/bluetooth/btfm_slim.txt @@ -0,0 +1,20 @@ +* BTFM Slimbus Slave Driver +BTFM Slimbus Slave driver configure and initialize slimbus slave device. +Bluetooth SCO and FM Audio data is transferred over slimbus interface. + +Required properties: + - compatible: Should be set to one of the following: + btfmslim_slave + - qcom,btfm-slim-ifd: BTFM slimbus slave device entry name + +Optional properties: + - qcom,btfm-slim-ifd-elemental-addr: BTFM slimbus slave device enumeration + address + +Example: + btfmslim_codec: wcn3990 { + compatible = "qcom,btfmslim_slave"; + elemental-addr = [00 01 20 02 17 02]; + qcom,btfm-slim-ifd = "btfmslim_slave_ifd"; + qcom,btfm-slim-ifd-elemental-addr = [00 00 20 02 17 02]; + }; diff --git a/Documentation/devicetree/bindings/cache/arm64_cache_erp.txt b/Documentation/devicetree/bindings/cache/arm64_cache_erp.txt new file mode 100644 index 000000000000..8b600be55787 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/arm64_cache_erp.txt @@ -0,0 +1,34 @@ +* ARM Cortex A53 / A57 cache error reporting driver + +Required properties: +- compatible: Should be "arm,arm64-cpu-erp" +- interrupts: List of hardware interrupts that may indicate an error condition + in the CPU subsystem, or in the L1 / L2 caches. At least one interrupt entry + is required. +- interrupt-names: Must contain one or more of the following IRQ types: + "pri-dbe-irq" - double-bit error interrupt for primary cluster + "sec-dbe-irq" - double-bit error interrupt for secondary cluster + "pri-ext-irq" - external bus error interrupt for primary cluster + "sec-ext-irq" - external bus error interrupt for secondary cluster + "cci-irq" - CCI error interrupt. If this property is present, having + the 'cci' reg-base defined using the 'reg' property is + recommended. + At least one irq entry is required. + +Optional properties: +- reg: Should contain physical address of the CCI register space +- reg-names: Should contain 'cci'. Must be present if 'reg' property is present +- poll-delay-msec: Indicates how often the edac check callback should be called. Time in msec. + +Example: + cpu_cache_erp { + compatible = "arm,arm64-cpu-erp"; + interrupt-names = "pri-dbe-irq", + "sec-dbe-irq", + "pri-ext-irq", + "sec-ext-irq"; + interrupts = <0 92 0>, + <0 91 0>, + <0 96 0>, + <0 95 0>; + }; diff --git a/Documentation/devicetree/bindings/cache/msm_gladiator_erp.txt b/Documentation/devicetree/bindings/cache/msm_gladiator_erp.txt new file mode 100644 index 000000000000..5d022586e021 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/msm_gladiator_erp.txt @@ -0,0 +1,16 @@ +* MSM Gladiator error reporting driver + +Required properties: +- compatible: Should be "qcom,msm-gladiator" +- reg: I/O address Gladiator H/W block +- reg-names: Should be "gladiator_base" +- interrupts: Should contain the gladiator error interrupt number. + +Example: + +qcom,msm-gladiator@b1c0000 { + compatible = "qcom,msm-gladiator"; + reg = <0xB1C0000 0x4000>; + reg-names = "gladiator_base"; + interrupts = <0 34 0>; +} diff --git a/Documentation/devicetree/bindings/cache/msm_gladiator_erp_v2.txt b/Documentation/devicetree/bindings/cache/msm_gladiator_erp_v2.txt new file mode 100644 index 000000000000..3c1c5c010ba1 --- /dev/null +++ b/Documentation/devicetree/bindings/cache/msm_gladiator_erp_v2.txt @@ -0,0 +1,20 @@ +* MSM Gladiator error reporting driver + +Required properties: +- compatible: Should be "qcom,msm-gladiator-v2" +- reg: I/O address Gladiator H/W block +- reg-names: Should be "gladiator_base" +- interrupts: Should contain the gladiator error interrupt number +- clock-names: Should be "atb_clk" +- clocks: Handles to clocks specified in "clock-names" property. + +Example: + +qcom,msm-gladiator-v2@b1c0000 { + compatible = "qcom,msm-gladiator-v2"; + reg = <0xb1c0000 0xe000>; + reg-names = "gladiator_base"; + interrupts = <0 34 0>; + clock-names = "atb_clk"; + clocks = <&clock_gcc clk_qdss_clk>; +} diff --git a/Documentation/devicetree/bindings/clock/clk-qpnp-div.txt b/Documentation/devicetree/bindings/clock/clk-qpnp-div.txt new file mode 100644 index 000000000000..03b7b70d7f7e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clk-qpnp-div.txt @@ -0,0 +1,52 @@ +Qualcomm Technologies, Inc. QPNP clock divider (clkdiv) + +clkdiv configures the clock frequency of a set of outputs on the PMIC. +These clocks are typically wired through alternate functions on +gpio pins. + +======================= +Supported Properties +======================= + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,qpnp-clkdiv". + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of this CLKDIV + peripheral. + +- qcom,cxo-freq + Usage: required + Value type: <u32> + Definition: The frequency of the crystal oscillator (CXO) clock in Hz. + +- qcom,clkdiv-id + Usage: required + Value type: <u32> + Definition: Integer value specifies the hardware identifier of this + CLKDIV peripheral. + +- qcom,clkdiv-init-freq + Usage: optional + Value type: <u32> + Definition: Initial output frequency in Hz to configure for the CLKDIV + peripheral. The initial frequency value should be less than + or equal to CXO clock frequency and greater than or equal to + CXO_freq/64. + +======= +Example +======= + +qcom,clkdiv@5b00 { + compatible = "qcom,qpnp-clkdiv"; + reg = <0x5b00 0x100>; + + qcom,cxo-freq = <19200000>; + qcom,clkdiv-id = <1>; + qcom,clkdiv-init-freq = <9600000>; +}; diff --git a/Documentation/devicetree/bindings/clock/qcom,a53cc b/Documentation/devicetree/bindings/clock/qcom,a53cc new file mode 100644 index 000000000000..34f6cf8dd6ca --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,a53cc @@ -0,0 +1,25 @@ +Qualcomm A53 Clock Controller Binding +------------------------------------------------ +The A53 Clock Controller provides higher frequency clocks +and allows CPU frequency scaling on msm8916 based platforms. + +Required properties : +- compatible : shall contain: + "qcom,a53cc" +- reg : shall contain base register location and length + of the A53 PLL +- #clock-cells : shall contain 1 +- qcom,apcs : phandle of apcs syscon node + +Example: + apcs: syscon@b011000 { + compatible = "syscon"; + reg = <0x0b011000 0x1000>; + }; + + a53cc: clock-controller@0b016000 { + compatible = "qcom,clock-a53-msm8916"; + reg = <0x0b016000 0x40>; + #clock-cells = <1>; + qcom,apcs = <&apcs>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-dbg.txt b/Documentation/devicetree/bindings/clock/qcom,gcc-dbg.txt new file mode 100644 index 000000000000..5c770864898a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-dbg.txt @@ -0,0 +1,58 @@ +Qualcomm Technologies Inc Global Clock Debug Controller Binding +--------------------------------------------------------------- + +Required properties : +- compatible: shall contain the following: + "qcom,gcc-debug-sdm660" + +- reg: shall contain global clock controller + base register offset location and length. +- reg-name: "dbg_offset" +- #clock-cells: shall contain 1 +- qcom,cc-count: shall contain a non-zero value(min 1). This + indicates the number of debug clock controllers + available. +- clocks: XO clock phandle. +- clock-names: Name of the clock. +- qcom,gcc: The syscon phandle for GCC clock controller. + +Optional properties : +In the case where "qcom,cc-count" is > 1, the below needs to be defined. +- qcom,gpu : The syscon phandle for Graphics debug controller. +- qcom,cpu : The syscon phandle for CPU debug controller. +- qcom,mmss : The syscon phandle for Multimedia debug controller. + +Example: + clock_gcc: clock-controller@100000 { + compatible = "qcom,gcc-sdm660", "syscon"; + .... + }; + + cpu_debug: syscon@1791101c { + compatible = "syscon"; + reg = <0x1791101c 0x4>; + }; + + gpu_debug: syscon@5065120 { + compatible = "syscon"; + reg = <0x5065120 0x4>; + }; + + mmss_debug: syscon@c8c0900 { + compatible = "syscon"; + reg = <0xc8c0900 0x4>; + }; + + clock_debug: qcom,cc-debug@62000 { + compatible = "qcom,gcc-debug-sdm660"; + reg = <0x62000 0x4>; + reg-names = "cc_offset"; + clocks = <&clock_rpmcc RPM_XO_CLK_SRC>; + clock-names = "xo_clk_src"; + qcom,cc-count = <4>; + qcom,gcc = <&clock_gcc>; + qcom,cpu = <&cpu_debug>; + qcom,gpu = <&gpu_debug>; + qcom,mmss = <&mmss_debug>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 152dfaab2575..479a83df3808 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -13,6 +13,8 @@ Required properties : "qcom,gcc-msm8974" "qcom,gcc-msm8974pro" "qcom,gcc-msm8974pro-ac" + "qcom,gcc-msm8996" + "qcom,gcc-sdm660" - reg : shall contain base register location and length - #clock-cells : shall contain 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.txt b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt new file mode 100644 index 000000000000..2f8fb22439f9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.txt @@ -0,0 +1,33 @@ +Qualcomm Technologies, Inc Graphics Clock & Reset Controller Binding +-------------------------------------------------------------------- + +Required properties : +- compatible : shall contain only one of the following: + + "qcom,gpucc-sdm660", + "qcom,gpucc-sdm630", + "qcom,gpu-sdm660", + +- reg : shall contain base register location and length +- #clock-cells : shall contain 1 +- #reset-cells : shall contain 1 + +Optional properties : +- #power-domain-cells : shall contain 1 + +Example: + clock-controller@4000000 { + compatible = "qcom,gpucc-sdm660"; + reg = <0x5065000 0x10000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + + gpu-clock-controller@4000000 { + compatible = "qcom,gpu-sdm660"; + reg = <0x5065000 0x10000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,hfpll.txt b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt new file mode 100644 index 000000000000..fee92bb30344 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,hfpll.txt @@ -0,0 +1,40 @@ +High-Frequency PLL (HFPLL) + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,hfpll" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address and size of HPLL registers. An optional second + element specifies the address and size of the alias + register region. + +- clock-output-names: + Usage: required + Value type: <string> + Definition: Name of the PLL. Typically hfpllX where X is a CPU number + starting at 0. Otherwise hfpll_Y where Y is more specific + such as "l2". + +Example: + +1) An HFPLL for the L2 cache. + + clock-controller@f9016000 { + compatible = "qcom,hfpll"; + reg = <0xf9016000 0x30>; + clock-output-names = "hfpll_l2"; + }; + +2) An HFPLL for CPU0. This HFPLL has the alias register region. + + clock-controller@f908a000 { + compatible = "qcom,hfpll"; + reg = <0xf908a000 0x30>, <0xf900a000 0x30>; + clock-output-names = "hfpll0"; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt new file mode 100644 index 000000000000..874138f88ec6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,krait-cc.txt @@ -0,0 +1,22 @@ +Krait Clock Controller + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,krait-cc-v1" + "qcom,krait-cc-v2" + +- #clock-cells: + Usage: required + Value type: <u32> + Definition: must be 1 + +Example: + + kraitcc: clock-controller { + compatible = "qcom,krait-cc-v1"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt index 34e7614d5074..f7b1bfd257fd 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt @@ -9,6 +9,9 @@ Required properties : "qcom,mmcc-msm8660" "qcom,mmcc-msm8960" "qcom,mmcc-msm8974" + "qcom,mmcc-msm8996" + "qcom,mmcc-sdm660" + "qcom,mmcc-sdm630" - reg : shall contain base register location and length - #clock-cells : shall contain 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt new file mode 100644 index 000000000000..685fb3aa2e61 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -0,0 +1,46 @@ +Qualcomm RPM Clock Controller Binding +------------------------------------------------ +The RPM is a dedicated hardware engine for managing the shared +SoC resources in order to keep the lowest power profile. It +communicates with other hardware subsystems via shared memory +and accepts clock requests, aggregates the requests and turns +the clocks on/off or scales them on demand. + +Required properties : +- compatible : shall contain only one of the following. The generic + compatible "qcom,rpmcc" should be also included. + + "qcom,rpmcc-msm8916", "qcom,rpmcc" + "qcom,rpmcc-apq8064", "qcom,rpmcc" + "qcom,rpmcc-msm8996", "qcom,rpmcc" + "qcom,rpmcc-sdm660", "qcom,rpmcc" + +- #clock-cells : shall contain 1 + +Example: + smd { + compatible = "qcom,smd"; + + rpm { + interrupts = <0 168 1>; + qcom,ipc = <&apcs 8 0>; + qcom,smd-edge = <15>; + + rpm_requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + + rpmcc: clock-controller { + compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; + #clock-cells = <1>; + }; + }; + }; + }; + + The below are applicable for MSM8996 & SDM660. + + rpmcc: clock-controller { + compatible = "qcom,rpmcc-msm8996", "qcom,rpmcc"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/cnss/cnss-sdio-wlan.txt b/Documentation/devicetree/bindings/cnss/cnss-sdio-wlan.txt new file mode 100644 index 000000000000..187c5604b521 --- /dev/null +++ b/Documentation/devicetree/bindings/cnss/cnss-sdio-wlan.txt @@ -0,0 +1,57 @@ +* Qualcomm Connectivity SubSystem Platform Driver + +This platform driver adds support for the CNSS subsystem used for SDIO +based Wi-Fi devices. It also adds support to manage two 1.8V voltage +regulators and WLAN power enable 3.3V regulators. The main purpose of this +device tree entry below is to invoke the CNSS SDIO platform driver +and provide handle to the WLAN power enable 3.3V pmic GPIO and two 1.8V +PMIC voltage regulator resources. + +Required properties: + - compatible: "qcom,cnss_sdio" + - reg: memory resource to save firmware dump, optional. + - reg-names: memory resource name. + - subsys-name: cnss sdio subsytem device name, required. + - vdd-wlan-supply: phandle to the WLAN vdd regulator device tree node. + - vdd-wlan-dsrc-supply: phandle to the WLAN dsrc vdd regulator device tree node. + - vdd-wlan-io-supply: phandle to the WLAN IO regulator device tree node. + - vdd-wlan-xtal-supply: phandle to the WLAM XTAL regulator device tree node. + +Optional properties: + - pinctrl-names: Names corresponding to the numbered pinctrl states + - pinctrl-<n>: Pinctrl states as described in + bindings/pinctrl/pinctrl-bindings.txt + - qcom,is-antenna-shared: Enabled for Platforms with both sdio and pcie QCA + Chipsets are attached. + - qcom,cnss-enable-bus-bandwidth: Boolean - Define this property when target + support to vote for bus bandwidth. + - qcom,msm-bus,name: client name for msm bus register. + - qcom,msm-bus,num-cases: number of cases for bus scaling. + - qcom,msm-bus,num-paths: number of paths for bus scale vector. + - qcom,msm-bus,vectors-KBps: bus scale vector table. + - qcom,skip-wlan-en-toggle: Boolean property to be enabled for platforms where + wlan_en toggling is not supported. +Example: + qcom,cnss-sdio { + compatible = "qcom,cnss_sdio"; + reg = <0x87a00000, 0x200000>; + reg-names = "ramdump"; + subsys-name = "AR6320"; + vdd-wlan-supply = <&rome_vreg>; + vdd-wlan-dsrc-supply = <&sdcard_ext_vreg>; + vdd-wlan-io-supply = <&mdm9607_l11>; + vdd-wlan-xtal-supply = <&mdm9607_l2>; + qcom,is-antenna-shared; + pinctrl-names = "active", "sleep"; + pinctrl-0 = <&cnss_sdio_active>; + pinctrl-1 = <&cnss_sdio_sleep>; + qcom,cnss-enable-bus-bandwidth; + qcom,msm-bus,name = "msm-cnss"; + qcom,msm-bus,num-cases = <4>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <79 512 0 0>, /* No vote */ + <79 512 6250 200000>, /* 50 Mbps */ + <79 512 25000 200000>, /* 200 Mbps */ + <79 512 2048000 4096000>; /* MAX */ + }; diff --git a/Documentation/devicetree/bindings/cnss/cnss-wlan.txt b/Documentation/devicetree/bindings/cnss/cnss-wlan.txt new file mode 100644 index 000000000000..6d63d1123f4c --- /dev/null +++ b/Documentation/devicetree/bindings/cnss/cnss-wlan.txt @@ -0,0 +1,63 @@ +* Qualcomm ConNectivity SubSystem Platform Driver + +This platform driver adds support for the CNSS subsystem used for PCIe +based Wi-Fi devices. It also adds support to integrate PCIe WLAN module +to subsystem restart framework. Apart from that, it also manages the +3.3V voltage regulator, WLAN Enable GPIO signal and PCIe link dynamically +with support for suspend and resume by retaining the PCI config space +states when PCIe link is shutdown. The main purpose of this device tree +entry below is to invoke the CNSS platform driver and provide handle to +the WLAN enable GPIO, 3.3V fixed voltage regulator resources. It also +provides the reserved RAM dump memory location and size. + +Required properties: + - compatible: "qcom,cnss" + - wlan-en-gpio: WLAN_EN GPIO signal specified by QCA6174 specifications + - vdd-wlan-supply: phandle to the regulator device tree node + - pinctrl-names: Names corresponding to the numbered pinctrl states + - pinctrl-<n>: Pinctrl states as described in + bindings/pinctrl/pinctrl-bindings.txt + - qcom,wlan-rc-num: PCIe root complex number which WLAN chip is attached to + +Optional properties: + - qcom,notify-modem-status: Boolean property to decide whether modem + notification should be enabled or not in this platform + - wlan-soc-swreg-supply: phandle to the external 1.15V regulator for QCA6174 + - wlan-ant-switch-supply: phandle to the 2.7V regulator for the antenna + switch of QCA6174 + - qcom,wlan-uart-access: Boolean property to decide whether QCA6174 + has exclusive access to UART. + - vdd-wlan-io-supply: phandle to the 1.8V IO regulator for QCA6174 + - vdd-wlan-xtal-supply: phandle to the 1.8V XTAL regulator for QCA6174 + - vdd-wlan-xtal-aon-supply: phandle to the LDO-4 regulator. This is needed + on platforms where XTAL regulator depends on + always on regulator in VDDmin. + - vdd-wlan-core-supply: phandle to the 1.3V CORE regulator for QCA6174 + - vdd-wlan-sp2t-supply: phandle to the 2.7V SP2T regulator for QCA6174 + - qcom,wlan-smmu-iova-address: I/O virtual address range as <start length> + format to be used for allocations associated between WLAN/PCIe and SMMU + - qcom,wlan-ramdump-dynamic: To enable CNSS RAMDUMP collection + by providing the size of CNSS DUMP + - reg: Memory regions defined as starting address and size + - reg-names: Names of the memory regions defined in reg entry + - wlan-bootstrap-gpio: WLAN_BOOTSTRAP GPIO signal specified by QCA6174 + which should be drived depending on platforms + - qcom,is-dual-wifi-enabled: Boolean property to control wlan enable(wlan-en) + gpio on dual-wifi platforms. + +Example: + + qcom,cnss@0d400000 { + compatible = "qcom,cnss"; + reg = <0x0d400000 0x200000>; + reg-names = "ramdump"; + qcom,wlan-ramdump-dynamic = <0x200000>; + wlan-en-gpio = <&msmgpio 82 0>; + vdd-wlan-supply = <&wlan_vreg>; + qcom,notify-modem-status; + wlan-soc-swreg-supply = <&pma8084_l27>; + pinctrl-names = "default"; + pinctrl-0 = <&cnss_default>; + qcom,wlan-rc-num = <0>; + qcom,wlan-smmu-iova-address = <0 0x10000000>; + }; diff --git a/Documentation/devicetree/bindings/cnss/icnss.txt b/Documentation/devicetree/bindings/cnss/icnss.txt new file mode 100644 index 000000000000..c801e8486f87 --- /dev/null +++ b/Documentation/devicetree/bindings/cnss/icnss.txt @@ -0,0 +1,60 @@ +* Qualcomm Technologies Inc Q6 Integrated connectivity Platform Driver + +This platform driver adds support for the Integrated WLAN that runs +on Q6 based platforms. WLAN FW on these architecture runs on Q6. This +platform driver communicates with WLAN FW over QMI, WLAN on/off messages +to FW are communicated thru this interface. This driver also listens to +WLAN PD restart notifications. + +Required properties: + - compatible: "qcom,icnss" + - reg: Memory regions defined as starting address and size + - reg-names: Names of the memory regions defined in reg entry + - interrupts: Copy engine interrupt table + - qcom,wlan-msa-memory: MSA memory size + - clocks: List of clock phandles + - clock-names: List of clock names corresponding to the "clocks" property + - iommus: SMMUs and corresponding Stream IDs needed by WLAN + - qcom,wlan-smmu-iova-address: I/O virtual address range as <start length> + format to be used for allocations associated between WLAN and SMMU + +Optional properties: + - <supply-name>-supply: phandle to the regulator device tree node + optional "supply-name" is "vdd-0.8-cx-mx". + - qcom,<supply>-config: Specifies voltage levels for supply. Should be + specified in pairs (min, max), units uV. There can + be optional load in uA and Regulator settle delay in + uS. + - qcom,icnss-vadc: VADC handle for vph_pwr read APIs. + - qcom,icnss-adc_tm: VADC handle for vph_pwr notification APIs. + - qcom,smmu-s1-bypass: Boolean context flag to set SMMU to S1 bypass + +Example: + + qcom,icnss@0a000000 { + compatible = "qcom,icnss"; + reg = <0x0a000000 0x1000000>; + reg-names = "membase"; + clocks = <&clock_gcc clk_aggre2_noc_clk>; + clock-names = "smmu_aggre2_noc_clk"; + iommus = <&anoc2_smmu 0x1900>, + <&anoc2_smmu 0x1901>; + qcom,wlan-smmu-iova-address = <0 0x10000000>; + interrupts = + <0 130 0 /* CE0 */ >, + <0 131 0 /* CE1 */ >, + <0 132 0 /* CE2 */ >, + <0 133 0 /* CE3 */ >, + <0 134 0 /* CE4 */ >, + <0 135 0 /* CE5 */ >, + <0 136 0 /* CE6 */ >, + <0 137 0 /* CE7 */ >, + <0 138 0 /* CE8 */ >, + <0 139 0 /* CE9 */ >, + <0 140 0 /* CE10 */ >, + <0 141 0 /* CE11 */ >; + qcom,wlan-msa-memory = <0x200000>; + qcom,smmu-s1-bypass; + vdd-0.8-cx-mx-supply = <&pm8998_l5>; + qcom,vdd-0.8-cx-mx-config = <800000 800000 2400 1000>; + }; diff --git a/Documentation/devicetree/bindings/cpuss_dump/cpuss_dump.txt b/Documentation/devicetree/bindings/cpuss_dump/cpuss_dump.txt new file mode 100644 index 000000000000..e19632a0168b --- /dev/null +++ b/Documentation/devicetree/bindings/cpuss_dump/cpuss_dump.txt @@ -0,0 +1,27 @@ +CPU Subsystem Dump Driver + +The CPU Subsystem dump driver is used to dump various hardware entities +like the instruction and data tlbs or the unified tlbs etc. to an +allocated buffer. This allows the data to be analysed in case of corruption. + +Required Properties for the cpuss_dump node: +-compatible = "qcom,cpuss-dump"; + +All child nodes of cpuss_dump node are interpreted as the various hardware +entities which need to be dumped. + +Required properties of the dump nodes + +- qcom,dump-node: phandle to the acutal cpuss hardware entity present + in the cpu map +- qcom,dump-id: The ID within the data dump table where this entry needs to + be added. + +Example: + msm_cpuss_dump { + compatible = "qcom,cpuss-dump"; + qcom,itlb_dump100 { + qcom,dump-node = <&L1_itlb_100>; + qcom,dump-id = <34>; + }; + }; diff --git a/Documentation/devicetree/bindings/crypto/msm/ice.txt b/Documentation/devicetree/bindings/crypto/msm/ice.txt new file mode 100644 index 000000000000..2d0e58059da3 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/msm/ice.txt @@ -0,0 +1,32 @@ +* Inline Crypto Engine (ICE) + +Required properties: + - compatible : should be "qcom,ice" + - reg : <register mapping> + +Optional properties: + - interrupt-names : name describing the interrupts for ICE IRQ + - interrupts : <interrupt mapping for ICE IRQ> + - qcom,enable-ice-clk : should enable clocks for ICE HW + - clocks : List of phandle and clock specifier pairs + - clock-names : List of clock input name strings sorted in the same + order as the clocks property. + - qocm,op-freq-hz : max clock speed sorted in the same order as the clocks + property. + - qcom,instance-type : describe the storage type for which ICE node is defined + currently, only "ufs" and "sdcc" are supported storage type + +Example: + ufs_ice: ufsice@630000 { + compatible = "qcom,ice"; + reg = <0x630000 0x8000>; + interrupt-names = "ufs_ice_nonsec_level_irq", "ufs_ice_sec_level_irq"; + interrupts = <0 258 0>, <0 257 0>; + qcom,enable-ice-clk; + clock-names = "ice_core_clk_src", "ice_core_clk"; + clocks = <&clock_gcc clk_ufs_ice_core_clk_src>, + <&clock_gcc clk_gcc_ufs_ice_core_clk>; + qcom,op-freq-hz = <300000000>, <0>; + qcom,instance-type = "ufs"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/crypto/msm/qcedev.txt b/Documentation/devicetree/bindings/crypto/msm/qcedev.txt new file mode 100644 index 000000000000..1585d06da3f3 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/msm/qcedev.txt @@ -0,0 +1,43 @@ +* QCEDEV (Qualcomm Crypto Engine Device) + +Required properties: + - compatible : should be "qcom,qcedev" + - reg : should contain crypto, BAM register map. + - reg-names : should contain the crypto and bam base register names. + - interrupts : should contain crypto BAM interrupt. + - qcom,bam-pipe-pair : should contain crypto BAM pipe pair index. + - qcom,ce-hw-instance : should contain crypto HW instance. + - qcom,msm_bus,name: Should be "qcedev-noc" + - qcom,msm_bus,num_cases: Depends on the use cases for bus scaling + - qcom,msm_bus,active-only: Boolean flag for context of request (actve/dual) + - qcom,msm_bus,num_paths: The paths for source and destination ports + - qcom,msm_bus,vectors: Vectors for bus topology. + - qcom,ce-device: Device number. + - qcom,ce-opp-freq: indicates the CE operating frequency in Hz, changes from target to target. + +Optional properties: + - qcom,ce-hw-shared : optional, indicates if the hardware is shared between EE. + - qcom,ce-hw-key : optional, indicates if the hardware supports use of HW KEY. + - qcom,support-core-clk-only : optional, indicates if the HW supports single crypto core clk. + - qcom,bsm-ee : optional, indicate the BAM EE value, changes from target to target. Default value is 1 if not specified. + +Example: + + qcom,qcedev@fd440000 { + compatible = "qcom,qcedev"; + reg = <0xfd440000 0x20000>, + <0xfd444000 0x8000>; + reg-names = "crypto-base","crypto-bam-base"; + interrupts = <0 235 0>; + qcom,bam-pipe-pair = <0>; + qcom,ce-hw-instance = <1>; + qcom,ce-device = <0>; + qcom,ce-hw-shared; + qcom,msm-bus,name = "qcedev-noc"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <56 512 0 0>, + <56 512 3936000 393600>, + qcom,ce-opp-freq = <100000000>; + }; diff --git a/Documentation/devicetree/bindings/crypto/msm/qcota.txt b/Documentation/devicetree/bindings/crypto/msm/qcota.txt new file mode 100644 index 000000000000..3ce63af7d4e6 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/msm/qcota.txt @@ -0,0 +1,42 @@ +* QCOTA (Over The Air Crypto Device) + +Required properties: + - compatible : should be "qcom,qcota" + - reg : should contain crypto, BAM register map. + - reg-names : should contain the crypto and bam base register names. + - interrupts : should contain crypto BAM interrupt. + - qcom,bam-pipe-pair : should contain crypto BAM pipe pair index. + - qcom,ce-hw-instance : should contain crypto HW instance. + - qcom,ce-device: Unique QCOTA device identifier. 0 for first + instance, 1 for second instance, n-1 for n-th instance. + - qcom,ce-opp-freq: indicates the CE operating frequency in Hz, changes from target to target. + +Optional properties: + - qcom,support-core-clk-only : optional, indicates if the HW supports single crypto core clk. + - qcom,bsm-ee : optional, indicate the BAM EE value, changes from target to target.Default value is 1 if not specified. + +Example: + + qcom,qcota@fe140000 { + compatible = "qcom,qcota"; + reg = <0xfe140000 0x20000>, + <0xfe144000 0x8000>; + reg-names = "crypto-base","crypto-bam-base"; + interrupts = <0 111 0>; + qcom,bam-pipe-pair = <1>; + qcom,ce-hw-instance = <2>; + qcom,ce-device = <0>; + qcom,ce-opp-freq = <100000000>; + }; + + qcom,qcota@fe0c0000 { + compatible = "qcom,qcota"; + reg = <0xfe0c0000 0x20000>, + <0xfe0c4000 0x8000>; + reg-names = "crypto-base","crypto-bam-base"; + interrupts = <0 113 0>; + qcom,bam-pipe-pair = <1>; + qcom,ce-hw-instance = <4>; + qcom,ce-device = <1>; + qcom,ce-opp-freq = <100000000>; + }; diff --git a/Documentation/devicetree/bindings/crypto/msm/qcrypto.txt b/Documentation/devicetree/bindings/crypto/msm/qcrypto.txt new file mode 100644 index 000000000000..46e01578a1f0 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/msm/qcrypto.txt @@ -0,0 +1,61 @@ +* QCRYPTO (Qualcomm Crypto) + +Required properties: + - compatible : should be "qcom,qcrypto" + - reg : should contain crypto, BAM register map. + - reg-names : should contain the crypto and bam base register names. + - interrupts : should contain crypto BAM interrupt. + - qcom,bam-pipe-pair : should contain crypto BAM pipe pair index. + - qcom,ce-hw-instance : should contain crypto HW instance. + - qcom,msm_bus,name: Should be "qcrypto-noc" + - qcom,msm_bus,num_cases: Depends on the use cases for bus scaling + - qcom,msm_bus,active-only: Boolean flag for context of request (actve/dual) + - qcom,msm_bus,num_paths: The paths for source and destination ports + - qcom,ce-device: Device number. Device number is encoded with the following: + bit 3-0 device type: 0 for full disk encryption(fde) + 1 for per file encrption(pfe) + bit 7-4 unit number within the device type. + + +Optional properties: + - qcom,ce-hw-shared : optional, indicates if the hardware is shared between EE. + - qcom,ce-hw-key : optional, indicates if the hardware supports use of HW KEY. + - qcom,use-sw-aes-cbc-ecb-ctr-algo : optional, indicates if use SW aes-cbc/ecb/ctr algorithm. + - qcom,use-sw-aes-xts-algo : optional, indicates if use SW aes-xts algorithm. + - qcom,use-sw-aead-algo : optional, indicates if use SW aead algorithm. + - qcom,use-sw-ahash-algo : optional, indicates if use SW hash algorithm. + - qcom,use-sw-hmac-algo : optional, indicates if use SW hmac algorithm. + - qcom,use-sw-aes-ccm-algo : optional, indicates if use SW aes-ccm algorithm. + - qcom,clk-mgmt-sus-res : optional, indicate if the ce clocks need to be disabled/enabled in suspend/resume function. + - qcom,support-core-clk-only : optional, indicates if the HW supports single crypto core clk. + - qcom,bsm-ee : optional, indicate the BAM EE value, changes from target to target.Default value is 1 if not specified. + + - qcom,ce-opp-freq: optional, indicates the CE operating frequency in Hz, + changes from target to target. If not specified, by default the + frequency is set as 100MHZ. + + - qcom,msm_bus,vectors: optional, indicates vectors for bus topology. + This attribute is required for msm targets where bus scaling is + required. For other targets such as fsm, they do not perform + bus scaling. It is not required for those targets. + +Example: + + qcom,qcrypto@fd444000 { + compatible = "qcom,qcrypto"; + reg = <0xfd440000 0x20000>, + <0xfd444000 0x8000>; + reg-names = "crypto-base","crypto-bam-base"; + interrupts = <0 235 0>; + qcom,bam-pipe-pair = <1>; + qcom,ce-hw-instance = <1>; + qcom,ce-device = <0>; + qcom,ce-hw-shared; + qcom,msm-bus,name = "qcrypto-noc"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <56 512 0 0>, + <56 512 3936000 393600>, + qcom,ce-opp-freq = <100000000>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/arm-memlat-mon.txt b/Documentation/devicetree/bindings/devfreq/arm-memlat-mon.txt new file mode 100644 index 000000000000..01b2424359e1 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/arm-memlat-mon.txt @@ -0,0 +1,22 @@ +ARM CPU memory latency monitor device + +arm-memlat-mon is a device that represents the use of the PMU in ARM cores +to measure the parameters for latency driven memory access patterns. + +Required properties: +- compatible: Must be "qcom,arm-memlat-mon" +- qcom,cpulist: List of CPU phandles to be monitored in a cluster +- qcom,target-dev: The DT device that corresponds to this master port +- qcom,core-dev-table: A mapping table of core frequency to a required bandwidth vote at the + given core frequency. + +Example: + qcom,arm-memlat-mon { + compatible = "qcom,arm-memlat-mon"; + qcom,cpulist = <&CPU0 &CPU1>; + qcom,target-dev = <&memlat0>; + qcom,core-dev-table = + < 300000 1525>, + < 499200 3143>, + < 1881600 5859>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/armbw-pm.txt b/Documentation/devicetree/bindings/devfreq/armbw-pm.txt new file mode 100644 index 000000000000..d1bd4add515a --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/armbw-pm.txt @@ -0,0 +1,16 @@ +ARM PMU based bandwidth monitor device + +armbw-pm is a device that represents the use of the PMU present in ARM cores +to measure the bandwidth of bus access traffic from the cores. + +Required properties: +- compatible: Must be "qcom,armbw-pm" +- interrupts: Lists the required interrupt settings +- qcom,bytes-per-beat: The number of bytes present in each access + +Example: + qcom,armbw-pm { + compatible = "qcom,armbw-pm"; + interrupts = <1 7 0xF1>; + qcom,bytes-per-beat = <16>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/bimc-bwmon.txt b/Documentation/devicetree/bindings/devfreq/bimc-bwmon.txt new file mode 100644 index 000000000000..c77f84b61eaf --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/bimc-bwmon.txt @@ -0,0 +1,29 @@ +MSM BIMC bandwidth monitor device + +bimc-bwmon is a device that represents the MSM BIMC bandwidth monitors that +can be used to measure the bandwidth of read/write traffic from the BIMC +master ports. For example, the CPU subsystem sits on one BIMC master port. + +Required properties: +- compatible: Must be "qcom,bimc-bwmon", "qcom,bimc-bwmon2", + "qcom,bimc-bwmon3" or "qcom,bimc-bwmon4" +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. Expected + bases are: "base", "global_base" +- interrupts: Lists the threshold IRQ. +- qcom,mport: The hardware master port that this device can monitor +- qcom,target-dev: The DT device that corresponds to this master port +- qcom,hw-timer-hz: Hardware sampling rate in Hz. This field must be + specified for "qcom,bimc-bwmon4" + +Example: + qcom,cpu-bwmon { + compatible = "qcom,bimc-bwmon"; + reg = <0xfc388000 0x300>, <0xfc381000 0x200>; + reg-names = "base", "global_base"; + interrupts = <0 183 1>; + qcom,mport = <0>; + qcom,target-dev = <&cpubw>; + qcom,hw-timer-hz = <19200000>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/devbw.txt b/Documentation/devicetree/bindings/devfreq/devbw.txt new file mode 100644 index 000000000000..f02c8c857b69 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/devbw.txt @@ -0,0 +1,42 @@ +MSM device bandwidth device + +devbw is a device that represents a MSM device's BW requirements from its +master port(s) to a different device's slave port(s) in a MSM SoC. This +device is typically used to vote for BW requirements from a device's (Eg: +CPU, GPU) master port(s) to the slave (Eg: DDR) port(s). + +Required properties: +- compatible: Must be "qcom,devbw" +- qcom,src-dst-ports: A list of tuples where each tuple consists of a bus + master port number and a bus slave port number. +- qcom,bw-tbl: A list of meaningful instantaneous bandwidth values + (in MB/s) that can be requested from the device + master port to the slave port. The list of values + depend on the supported bus/slave frequencies and the + bus width. + +Optional properties: +- qcom,active-only: Indicates that the bandwidth votes need to be + enforced only when the CPU subsystem is active. +- governor: Initial governor to use for the device. + Default: "performance" +- qcom,ab-percent: Indicates a value in percent of instantaneous + bandwidth which will be used to calculate the + absolute/average bandwidth. + +Example: + + qcom,cpubw { + compatible = "qcom,devbw"; + qcom,src-dst-ports = <1 512>, <2 512>; + qcom,active-only; + qcom,bw-tbl = + < 572 /* 75 MHz */ >, + < 1144 /* 150 MHz */ >, + < 1525 /* 200 MHz */ >, + < 2342 /* 307 MHz */ >, + < 3509 /* 460 MHz */ >, + < 4684 /* 614 MHz */ >, + < 6103 /* 800 MHz */ >, + < 7102 /* 931 MHz */ >; + }; diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt new file mode 100644 index 000000000000..653753835caf --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt @@ -0,0 +1,53 @@ +Devfreq CPUfreq governor + +devfreq-cpufreq is a parent device that contains one or more child devices. +Each child device provides CPU frequency to device frequency mapping for a +specific device. Examples of devices that could use this are: DDR, cache and +CCI. + +Parent device name shall be "devfreq-cpufreq". + +Required child device properties: +- cpu-to-dev-map, or cpu-to-dev-map-<X>: + A list of tuples where each tuple consists of a + CPU frequency (KHz) and the corresponding device + frequency. CPU frequencies not listed in the table + will use the device frequency that corresponds to the + next rounded up CPU frequency. + Use "cpu-to-dev-map" if all CPUs in the system should + share same mapping. + Use cpu-to-dev-map-<cpuid> to describe different + mappings for different CPUs. The property should be + listed only for the first CPU if multiple CPUs are + synchronous. +- target-dev: Phandle to device that this mapping applies to. + +Example: + devfreq-cpufreq { + cpubw-cpufreq { + target-dev = <&cpubw>; + cpu-to-dev-map = + < 300000 1144 >, + < 422400 2288 >, + < 652800 3051 >, + < 883200 5996 >, + < 1190400 8056 >, + < 1497600 10101 >, + < 1728000 12145 >, + < 2649600 16250 >; + }; + + cache-cpufreq { + target-dev = <&cache>; + cpu-to-dev-map = + < 300000 300000 >, + < 422400 422400 >, + < 652800 499200 >, + < 883200 576000 >, + < 960000 960000 >, + < 1497600 1036800 >, + < 1574400 1574400 >, + < 1728000 1651200 >, + < 2649600 1728000 >; + }; + }; diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-simple-dev.txt b/Documentation/devicetree/bindings/devfreq/devfreq-simple-dev.txt new file mode 100644 index 000000000000..d00ebd84a520 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/devfreq-simple-dev.txt @@ -0,0 +1,48 @@ +Devfreq simple device + +devfreq-simple-dev is a device that represents a simple device that cannot do +any status reporting and uses a clock that can be scaled by one of more +devfreq governors. It provides a list of usable frequencies for the device +and some additional optional parameters. + +Required properties: +- compatible: Must be "devfreq-simple-dev" +- clock-names: Must be "devfreq_clk" +- clocks: Must refer to the clock that's fed to the device. +- freq-tbl-khz: A list of usable frequencies (in KHz) for the device + clock. +Optional properties: +- polling-ms: Polling interval for the device in milliseconds. Default: 50 +- governor: Initial governor to user for the device. Default: "performance" +- qcom,prepare-clk: Prepare the device clock during initialization. + +Example: + + qcom,cache { + compatible = "devfreq-simple-dev"; + clock-names = "devfreq_clk"; + clocks = <&clock_krait clk_l2_clk>; + polling-ms = 50; + governor = "cpufreq"; + freq-tbl-khz = + < 300000 >, + < 345600 >, + < 422400 >, + < 499200 >, + < 576000 >, + < 652800 >, + < 729600 >, + < 806400 >, + < 883200 >, + < 960000 >, + < 1036800 >, + < 1113600 >, + < 1190400 >, + < 1267200 >, + < 1344000 >, + < 1420800 >, + < 1497600 >, + < 1574400 >, + < 1651200 >, + < 1728000 >; + }; diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-spdm.txt b/Documentation/devicetree/bindings/devfreq/devfreq-spdm.txt new file mode 100644 index 000000000000..1f0d0a0db20e --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/devfreq-spdm.txt @@ -0,0 +1,86 @@ +MSM SPDM bandwidth monitor device + +devfreq-spdm is a device that represents a device that is monitored by the SPDM +hardware to measure the traffic status of configured master ports on the bus. + + +Required properties: +-compatible: Must be "qcom,devfreq_spdm" +-qcom,spdm-client: Client id of the port being monitored +-qcom,bw-upstep: Initial up vote size in MB/s +-qcom,bw-dwnstep: Initial down vote size in MB/s +-qcom,max-vote: Vote ceiling in MB/s +-qcom,ports: SPDM ports used by this device +-qcom,alpha-up: SPDM filter up alpha value +-qcom,alpha-down: SPDM filter down alpha value +-qcom,bucket-size: SPDM filter bucket size +-qcom,pl-freqs: The driver supports different filter values at + three different performance levels. This value + defines the cut-over frequenices +-qcom,reject-rate: Desired rejection rate used to calculate + SPDM threshold +-qcom,response-time-us: Desired response time used to calculate + SPDM threshold +-qcom,cci-response-time-us: Desired response time used to calculate + SPDM threshold when CCI is under heavy load +-qcom,max-cci-freq: CCI frequency at which cci_response_time_us + is used +-qcom,up-step-multp: used to increase rate of growth on up votes +-qcom,spdm-interval: down-vote polling interval + +Optional properties: +-clock-names: Clocks used to measure current bus frequency. + Expected names are "cci_clk" +-clocks: References to named clocks + +Example: +devfreq_spdm_cpu { + compatible = "qcom,devfreq_spdm"; + qcom,msm-bus,name = "devfreq_spdm"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <1 512 0 0>, + <1 512 0 0>; + qcom,spdm-client = <0>; + + clock-names = "cci_clk"; + clocks = <&clock_cpu clk_cci_clk>; + + qcom,bw-upstep = <100>; + qcom,bw-dwnstep = <100>; + qcom,max-vote = <10000>; + qcom,up-step-multp = <2>; + qcom,spdm-interval = <100>; + + qcom,ports = <16>; + qcom,alpha-up = <7>; + qcom,alpha-down = <15>; + qcom,bucket-size = <8>; + + /*max pl1 freq, max pl2 freq*/ + qcom,pl-freqs = <149999999 150000000>; + + /* pl1 low, pl1 high, pl2 low, pl2 high, pl3 low, pl3 high */ + qcom,reject-rate = <5000 5000 5000 5000 5000 5000>; + /* pl1 low, pl1 high, pl2 low, pl2 high, pl3 low, pl3 high */ + qcom,response-time-us = <220 220 2000 2000 900 900>; + /* pl1 low, pl1 high, pl2 low, pl2 high, pl3 low, pl3 high */ + qcom,cci-response-time-us = <50 50 30 30 20 20>; + qcom,max-cci-freq = <600000000>; +}; + +This device is always used with the SPDM governor which requires a device tree +entry to know what IRQ to respond to. + +Required properties: +-compatible Must be "qcom,gov_spdm_hyp" +-interrupt-names SPDM irq to handle. Name should be "spdm-irq" +-interrupts The interrupt number the SPDM hw is assigned + +Example: +devfreq_spdm_gov { + compatible = "qcom,gov_spdm_hyp"; + interrupt-names = "spdm-irq"; + interrupts = <0 192 0>; +}; diff --git a/Documentation/devicetree/bindings/devfreq/m4m-hwmon.txt b/Documentation/devicetree/bindings/devfreq/m4m-hwmon.txt new file mode 100644 index 000000000000..d0630899de37 --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/m4m-hwmon.txt @@ -0,0 +1,22 @@ +MSM M4M hardware monitor device + +m4m-hwmon is a device that represents the MSM M4M hardware monitors +that can be used to measure the various types of requests in the MSM M4M. + +Required properties: +- compatible: Must be "qcom,m4m-hwmon" +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- interrupts: Lists the threshold IRQ. +- qcom,counter-event-sel: Array of counter and event selection values. +- qcom,target-dev: The DT device that is monitored by this MSM M4M + counter configuration. + +Example: + qcom,m4m-hwmon { + compatible = "qcom,m4m-hwmon"; + reg = <0x6530000 0x160>; + interrupts = <0 19 4>; + qcom,counter-event-sel = <4 0x100>; + qcom,target-dev = <&m4m_cache>; + }; diff --git a/Documentation/devicetree/bindings/devfreq/msmcci-hwmon.txt b/Documentation/devicetree/bindings/devfreq/msmcci-hwmon.txt new file mode 100644 index 000000000000..bce08a3db9aa --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/msmcci-hwmon.txt @@ -0,0 +1,28 @@ +MSM CCI hardware monitor device + +msmcci-hwmon is a device that represents the MSM CCI hardware monitors +that can be used to measure the various types of requests in the MSM CCI. + +Required properties: +- compatible: Must be "qcom,msmcci-hwmon" +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- interrupts: Lists the threshold IRQ. +- qcom,counter-event-sel: Array of event selection values. +- qcom,target-dev: The DT device that is monitored by this MSM CCI + counter configuration. + +Optional properties: +- qcom,secure_io Indicates register access are secured. +- qcom,shared-irq Indicates ccci-hwmon counters share the interrupt. + +Example: + qcom,msmcci-hwmon { + compatible = "qcom,msmcci-hwmon"; + reg = <0xf910f000 0xb0>, + <0xf910f004 0xb0>; + interrupts = <0 345 4>, + <0 346 4>; + qcom,counter-event-sel = <1 2>; + qcom,target-dev = <&cci_cache>; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index f344b9e49198..ae2278fb3d1c 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -69,6 +69,20 @@ Required properties: Optional properties: - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY regulator is wanted. +- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode + panels in microseconds. Driver uses this number to adjust + the clock rate according to the expected transfer time. + Increasing this value would slow down the mdp processing + and can result in slower performance. + Decreasing this value can speed up the mdp processing, + but this can also impact power consumption. + As a rule this time should not be higher than the time + that would be expected with the processing at the + dsi link rate since anyways this would be the maximum + transfer time that could be achieved. + If ping pong split is enabled, this time should not be higher + than two times the dsi link rate time. + If the property is not specified, then the default value is 14000 us. Example: mdss_dsi0: qcom,mdss_dsi@fd922800 { @@ -105,6 +119,8 @@ Example: qcom,master-dsi; qcom,sync-dual-dsi; + qcom,mdss-mdp-transfer-time-us = <12000>; + pinctrl-names = "default", "sleep"; pinctrl-0 = <&mdss_dsi_active>; pinctrl-1 = <&mdss_dsi_suspend>; diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt b/Documentation/devicetree/bindings/display/msm/hdmi.txt index 379ee2ea9a3d..a0615ac9d73e 100644 --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt @@ -3,6 +3,7 @@ Qualcomm adreno/snapdragon hdmi output Required properties: - compatible: one of the following * "qcom,hdmi-tx-8996" + * "qcom,hdmi-tx-8998" * "qcom,hdmi-tx-8994" * "qcom,hdmi-tx-8084" * "qcom,hdmi-tx-8974" @@ -21,6 +22,7 @@ Required properties: Optional properties: - qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin +- qcom,hdmi-tx-hpd5v-gpio: hdmi 5v boost pin - qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin - power-domains: reference to the power domain(s), if available. - pinctrl-names: the pin control state names; should contain "default" diff --git a/Documentation/devicetree/bindings/display/msm/sde.txt b/Documentation/devicetree/bindings/display/msm/sde.txt new file mode 100644 index 000000000000..c9e7d7423d7f --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/sde.txt @@ -0,0 +1,472 @@ +Qualcomm Technologies, Inc. SDE KMS + +Snapdragon Display Engine implements Linux DRM/KMS APIs to drive user +interface to different panel interfaces. SDE driver is the core of +display subsystem which manage all data paths to different panel interfaces. + +Required properties +- compatible: Must be "qcom,sde-kms" +- reg: Offset and length of the register set for the device. +- reg-names : Names to refer to register sets related to this device +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. +- mmagic-supply: Phandle for mmagic mdss supply regulator device node. +- vdd-supply: Phandle for vdd regulator device node. +- interrupt-parent: Must be core interrupt controller. +- interrupts: Interrupt associated with MDSS. +- interrupt-controller: Mark the device node as an interrupt controller. +- #interrupt-cells: Should be one. The first cell is interrupt number. +- iommus: Specifies the SID's used by this context bank. +- qcom,sde-sspp-type: Array of strings for SDE source surface pipes type information. + A source pipe can be "vig", "rgb", "dma" or "cursor" type. + Number of xin ids defined should match the number of offsets + defined in property: qcom,sde-sspp-off. +- qcom,sde-sspp-off: Array of offset for SDE source surface pipes. The offsets + are calculated from register "mdp_phys" defined in + reg property + "sde-off". The number of offsets defined here should + reflect the amount of pipes that can be active in SDE for + this configuration. +- qcom,sde-sspp-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective source pipes. Number of xin ids + defined should match the number of offsets + defined in property: qcom,sde-sspp-off. +- qcom,sde-ctl-off: Array of offset addresses for the available ctl + hw blocks within SDE, these offsets are + calculated from register "mdp_phys" defined in + reg property. The number of ctl offsets defined + here should reflect the number of control paths + that can be configured concurrently on SDE for + this configuration. +- qcom,sde-wb-off: Array of offset addresses for the programmable + writeback blocks within SDE. +- qcom,sde-wb-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective writeback. Number of xin ids + defined should match the number of offsets + defined in property: qcom,sde-wb-off. +- qcom,sde-mixer-off: Array of offset addresses for the available + mixer blocks that can drive data to panel + interfaces. These offsets are be calculated from + register "mdp_phys" defined in reg property. + The number of offsets defined should reflect the + amount of mixers that can drive data to a panel + interface. +- qcom,sde-dspp-off: Array of offset addresses for the available dspp + blocks. These offsets are calculated from + register "mdp_phys" defined in reg property. +- qcom,sde-pp-off: Array of offset addresses for the available + pingpong blocks. These offsets are calculated + from register "mdp_phys" defined in reg property. +- qcom,sde-pp-slave: Array of flags indicating whether each ping pong + block may be configured as a pp slave. +- qcom,sde-intf-off: Array of offset addresses for the available SDE + interface blocks that can drive data to a + panel controller. The offsets are calculated + from "mdp_phys" defined in reg property. The number + of offsets defined should reflect the number of + programmable interface blocks available in hardware. + +Optional properties: +- clock-rate: List of clock rates in Hz. +- clock-max-rate: List of maximum clock rate in Hz that this device supports. +- qcom,platform-supply-entries: A node that lists the elements of the supply. There + can be more than one instance of this binding, + in which case the entry would be appended with + the supply entry index. + e.g. qcom,platform-supply-entry@0 + -- reg: offset and length of the register set for the device. + -- qcom,supply-name: name of the supply (vdd/vdda/vddio) + -- qcom,supply-min-voltage: minimum voltage level (uV) + -- qcom,supply-max-voltage: maximum voltage level (uV) + -- qcom,supply-enable-load: load drawn (uA) from enabled supply + -- qcom,supply-disable-load: load drawn (uA) from disabled supply + -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on + -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on + -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off + -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off +- qcom,sde-sspp-src-size: A u32 value indicates the address range for each sspp. +- qcom,sde-mixer-size: A u32 value indicates the address range for each mixer. +- qcom,sde-ctl-size: A u32 value indicates the address range for each ctl. +- qcom,sde-dspp-size: A u32 value indicates the address range for each dspp. +- qcom,sde-intf-size: A u32 value indicates the address range for each intf. +- qcom,sde-dsc-size: A u32 value indicates the address range for each dsc. +- qcom,sde-cdm-size: A u32 value indicates the address range for each cdm. +- qcom,sde-pp-size: A u32 value indicates the address range for each pingpong. +- qcom,sde-wb-size: A u32 value indicates the address range for each writeback. +- qcom,sde-len: A u32 entry for SDE address range. +- qcom,sde-intf-max-prefetch-lines: Array of u32 values for max prefetch lines on + each interface. +- qcom,sde-sspp-linewidth: A u32 value indicates the max sspp line width. +- qcom,sde-mixer-linewidth: A u32 value indicates the max mixer line width. +- qcom,sde-wb-linewidth: A u32 value indicates the max writeback line width. +- qcom,sde-sspp-scale-size: A u32 value indicates the scaling block size on sspp. +- qcom,sde-mixer-blendstages: A u32 value indicates the max mixer blend stages for + alpha blending. +- qcom,sde-qseed-type: A string entry indicates qseed support on sspp and wb. + It supports "qssedv3" and "qseedv2" entries for qseed + type. By default "qseedv2" is used if this optional property + is not defined. +- qcom,sde-csc-type: A string entry indicates csc support on sspp and wb. + It supports "csc" and "csc-10bit" entries for csc + type. +- qcom,sde-highest-bank-bit: A u32 property to indicate GPU/Camera/Video highest memory + bank bit used for tile format buffers. +- qcom,sde-panic-per-pipe: Boolean property to indicate if panic signal + control feature is available on each source pipe. +- qcom,sde-has-src-split: Boolean property to indicate if source split + feature is available or not. +- qcom,sde-has-mixer-gc: Boolean property to indicate if mixer has gamma correction + feature available or not. +- qcom,sde-has-cdp: Boolean property to indicate if cdp feature is + available or not. +- qcom,sde-sspp-clk-ctrl: Array of offsets describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register. Number of offsets defined should + match the number of offsets defined in + property: qcom,sde-sspp-off +- qcom,sde-sspp-clk-status: Array of offsets describing clk status + offsets for dynamic clock gating. 1st value + in the array represents offset of the status + register. 2nd value represents bit offset within + control register. Number of offsets defined should + match the number of offsets defined in + property: qcom,sde-sspp-off. +- qcom,sde-sspp-danger-lut: A 3 cell property, with a format of <linear, tile, nrt>, + indicating the danger luts on sspp. +- qcom,sde-sspp-safe-lut: A 3 cell property, with a format of <linear, tile, nrt>, + indicating the safe luts on sspp. +- qcom,sde-sspp-max-rects: Array of u32 values indicating maximum rectangles supported + on each sspp. This property is for multirect feature support. + Number of offsets defined should match the number of + offsets defined in property: qcom,sde-sspp-off. +- qcom,sde-intf-type: Array of string provides the interface type information. + Possible string values + "dsi" - dsi display interface + "dp" - Display Port interface + "hdmi" - HDMI display interface + An interface is considered as "none" if interface type + is not defined. +- qcom,sde-off: SDE offset from "mdp_phys" defined in reg property. +- qcom,sde-cdm-off: Array of offset addresses for the available + cdm blocks. These offsets will be calculated from + register "mdp_phys" defined in reg property. +- qcom,sde-vbif-off: Array of offset addresses for the available + vbif blocks. These offsets will be calculated from + register "vbif_phys" defined in reg property. +- qcom,sde-vbif-size: A u32 value indicates the vbif block address range. +- qcom,sde-te-off: A u32 offset indicates the te block offset on pingpong. + This offset is 0x0 by default. +- qcom,sde-te2-off: A u32 offset indicates the te2 block offset on pingpong. +- qcom,sde-te-size: A u32 value indicates the te block address range. +- qcom,sde-te2-size: A u32 value indicates the te2 block address range. +- qcom,sde-dsc-off: A u32 offset indicates the dsc block offset on pingpong. +- qcom,sde-sspp-vig-blocks: A node that lists the blocks inside the VIG hardware. The + block entries will contain the offset and version (if needed) + of each feature block. The presence of a block entry + indicates that the SSPP VIG contains that feature hardware. + e.g. qcom,sde-sspp-vig-blocks + -- qcom,sde-vig-csc-off: offset of CSC hardware + -- qcom,sde-vig-qseed-off: offset of QSEED hardware + -- qcom,sde-vig-pcc: offset and version of PCC hardware + -- qcom,sde-vig-hsic: offset and version of global PA adjustment + -- qcom,sde-vig-memcolor: offset and version of PA memcolor hardware +- qcom,sde-sspp-rgb-blocks: A node that lists the blocks inside the RGB hardware. The + block entries will contain the offset and version (if needed) + of each feature block. The presence of a block entry + indicates that the SSPP RGB contains that feature hardware. + e.g. qcom,sde-sspp-vig-blocks + -- qcom,sde-rgb-scaler-off: offset of RGB scaler hardware + -- qcom,sde-rgb-pcc: offset and version of PCC hardware +- qcom,sde-dspp-blocks: A node that lists the blocks inside the DSPP hardware. The + block entries will contain the offset and version of each + feature block. The presence of a block entry indicates that + the DSPP contains that feature hardware. + e.g. qcom,sde-dspp-blocks + -- qcom,sde-dspp-pcc: offset and version of PCC hardware + -- qcom,sde-dspp-gc: offset and version of GC hardware + -- qcom,sde-dspp-hsic: offset and version of global PA adjustment + -- qcom,sde-dspp-memcolor: offset and version of PA memcolor hardware + -- qcom,sde-dspp-sixzone: offset and version of PA sixzone hardware + -- qcom,sde-dspp-gamut: offset and version of Gamut mapping hardware + -- qcom,sde-dspp-dither: offset and version of dither hardware + -- qcom,sde-dspp-hist: offset and version of histogram hardware + -- qcom,sde-dspp-vlut: offset and version of PA vLUT hardware +- qcom,sde-mixer-blocks: A node that lists the blocks inside the layer mixer hardware. The + block entries will contain the offset and version (if needed) + of each feature block. The presence of a block entry + indicates that the layer mixer contains that feature hardware. + e.g. qcom,sde-mixer-blocks + -- qcom,sde-mixer-gc: offset and version of mixer GC hardware +- qcom,sde-dspp-ad-off: Array of u32 offsets indicate the ad block offset from the + DSPP offset. Since AD hardware is represented as part of + DSPP block, the AD offsets must be offset from the + corresponding DSPP base. +- qcom,sde-dspp-ad-version A u32 value indicating the version of the AD hardware +- qcom,sde-vbif-id: Array of vbif ids corresponding to the + offsets defined in property: qcom,sde-vbif-off. +- qcom,sde-vbif-default-ot-rd-limit: A u32 value indicates the default read OT limit +- qcom,sde-vbif-default-ot-wr-limit: A u32 value indicates the default write OT limit +- qcom,sde-vbif-dynamic-ot-rd-limit: A series of 2 cell property, with a format + of (pps, OT limit), where pps is pixel per second and + OT limit is the read limit to apply if the given + pps is not exceeded. +- qcom,sde-vbif-dynamic-ot-wr-limit: A series of 2 cell property, with a format + of (pps, OT limit), where pps is pixel per second and + OT limit is the write limit to apply if the given + pps is not exceeded. +- qcom,sde-wb-id: Array of writeback ids corresponding to the + offsets defined in property: qcom,sde-wb-off. +- qcom,sde-wb-clk-ctrl: Array of 2 cell property describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register. Number of offsets defined should + match the number of offsets defined in + property: qcom,sde-wb-off +- qcom,sde-dram-channels: This represents the number of channels in the + Bus memory controller. +- qcom,sde-num-nrt-paths: Integer property represents the number of non-realtime + paths in each Bus Scaling Usecase. This value depends on + number of AXI ports that are dedicated to non-realtime VBIF + for particular chipset. + These paths must be defined after rt-paths in + "qcom,msm-bus,vectors-KBps" vector request. +- qcom,sde-max-bw-low-kbps: This value indicates the max bandwidth in Kbps + that can be supported without underflow. + This is a low bandwidth threshold which should + be applied in most scenarios to be safe from + underflows when unable to satisfy bandwidth + requirements. +- qcom,sde-max-bw-high-kbps: This value indicates the max bandwidth in Kbps + that can be supported without underflow. + This is a high bandwidth threshold which can be + applied in scenarios where panel interface can + be more tolerant to memory latency such as + command mode panels. + +Bus Scaling Subnodes: +- qcom,sde-reg-bus: Property to provide Bus scaling for register access for + mdss blocks. +- qcom,sde-data-bus: Property to provide Bus scaling for data bus access for + mdss blocks. + +Bus Scaling Data: +- qcom,msm-bus,name: String property describing client name. +- qcom,msm-bus,num-cases: This is the number of Bus Scaling use cases + defined in the vectors property. +- qcom,msm-bus,num-paths: This represents the number of paths in each + Bus Scaling Usecase. +- qcom,msm-bus,vectors-KBps: * A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt + * Current values of src & dst are defined at + include/linux/msm-bus-board.h + + +Please refer to ../../interrupt-controller/interrupts.txt for a general +description of interrupt bindings. + +Example: + mdss_mdp: qcom,mdss_mdp@900000 { + compatible = "qcom,sde-kms"; + reg = <0x00900000 0x90000>, + <0x009b0000 0x1040>, + <0x009b8000 0x1040>; + reg-names = "mdp_phys", + "vbif_phys", + "vbif_nrt_phys"; + clocks = <&clock_mmss clk_mdss_ahb_clk>, + <&clock_mmss clk_mdss_axi_clk>, + <&clock_mmss clk_mdp_clk_src>, + <&clock_mmss clk_mdss_mdp_vote_clk>, + <&clock_mmss clk_smmu_mdp_axi_clk>, + <&clock_mmss clk_mmagic_mdss_axi_clk>, + <&clock_mmss clk_mdss_vsync_clk>; + clock-names = "iface_clk", + "bus_clk", + "core_clk_src", + "core_clk", + "iommu_clk", + "mmagic_clk", + "vsync_clk"; + clock-rate = <0>, <0>, <0>; + clock-max-rate= <0 320000000 0>; + mmagic-supply = <&gdsc_mmagic_mdss>; + vdd-supply = <&gdsc_mdss>; + interrupt-parent = <&intc>; + interrupts = <0 83 0>; + interrupt-controller; + #interrupt-cells = <1>; + iommus = <&mdp_smmu 0>; + + qcom,sde-off = <0x1000>; + qcom,sde-ctl-off = <0x00002000 0x00002200 0x00002400 + 0x00002600 0x00002800>; + qcom,sde-mixer-off = <0x00045000 0x00046000 + 0x00047000 0x0004a000>; + qcom,sde-dspp-off = <0x00055000 0x00057000>; + qcom,sde-dspp-ad-off = <0x24000 0x22800>; + qcom,sde-dspp-ad-version = <0x00030000>; + qcom,sde-wb-off = <0x00066000>; + qcom,sde-wb-xin-id = <6>; + qcom,sde-intf-off = <0x0006b000 0x0006b800 + 0x0006c000 0x0006c800>; + qcom,sde-intf-type = "none", "dsi", "dsi", "hdmi"; + qcom,sde-pp-off = <0x00071000 0x00071800 + 0x00072000 0x00072800>; + qcom,sde-pp-slave = <0x0 0x0 0x0 0x0>; + qcom,sde-cdm-off = <0x0007a200>; + qcom,sde-dsc-off = <0x00081000 0x00081400>; + qcom,sde-intf-max-prefetch-lines = <0x15 0x15 0x15 0x15>; + + qcom,sde-sspp-type = "vig", "vig", "vig", + "vig", "rgb", "rgb", + "rgb", "rgb", "dma", + "dma", "cursor", "cursor"; + + qcom,sde-sspp-off = <0x00005000 0x00007000 0x00009000 + 0x0000b000 0x00015000 0x00017000 + 0x00019000 0x0001b000 0x00025000 + 0x00027000 0x00035000 0x00037000>; + + qcom,sde-sspp-xin-id = <0 4 8 + 12 1 5 + 9 13 2 + 10 7 7>; + + /* offsets are relative to "mdp_phys + qcom,sde-off */ + qcom,sde-sspp-clk-ctrl = <0x2ac 0>, <0x2b4 0>, <0x2bc 0>, + <0x2c4 0>, <0x2ac 4>, <0x2b4 4>, <0x2bc 4>, + <0x2c4 4>, <0x2ac 8>, <0x2b4 8>, <0x3a8 16>, + <0x3b0 16>; + qcom,sde-sspp-clk-status = <0x2ac 0>, <0x2b4 0>, <0x2bc 0>, + <0x2c4 0>, <0x2ac 4>, <0x2b4 4>, <0x2bc 4>, + <0x2c4 4>, <0x2ac 8>, <0x2b4 8>, <0x3a8 16>, + <0x3b0 16>; + qcom,sde-mixer-linewidth = <2560>; + qcom,sde-sspp-linewidth = <2560>; + qcom,sde-mixer-blendstages = <0x7>; + qcom,sde-highest-bank-bit = <0x2>; + qcom,sde-panic-per-pipe; + qcom,sde-has-cdp; + qcom,sde-has-src-split; + qcom,sde-sspp-src-size = <0x100>; + qcom,sde-mixer-size = <0x100>; + qcom,sde-ctl-size = <0x100>; + qcom,sde-dspp-size = <0x100>; + qcom,sde-intf-size = <0x100>; + qcom,sde-dsc-size = <0x100>; + qcom,sde-cdm-size = <0x100>; + qcom,sde-pp-size = <0x100>; + qcom,sde-wb-size = <0x100>; + qcom,sde-len = <0x100>; + qcom,sde-wb-linewidth = <2560>; + qcom,sde-sspp-scale-size = <0x100>; + qcom,sde-mixer-blendstages = <0x8>; + qcom,sde-qseed-type = "qseedv2"; + qcom,sde-highest-bank-bit = <15>; + qcom,sde-has-mixer-gc; + qcom,sde-sspp-max-rects = <1 1 1 1 + 1 1 1 1 + 1 1 + 1 1>; + qcom,sde-te-off = <0x100>; + qcom,sde-te2-off = <0x100>; + qcom,sde-te-size = <0xffff>; + qcom,sde-te2-size = <0xffff>; + + qcom,sde-wb-id = <2>; + qcom,sde-wb-clk-ctrl = <0x2bc 16>; + + qcom,sde-sspp-danger-lut = <0x000f 0xffff 0x0000>; + qcom,sde-sspp-safe-lut = <0xfffc 0xff00 0xffff>; + + qcom,sde-vbif-off = <0 0>; + qcom,sde-vbif-id = <0 1>; + qcom,sde-vbif-default-ot-rd-limit = <32>; + qcom,sde-vbif-default-ot-wr-limit = <16>; + qcom,sde-vbif-dynamic-ot-rd-limit = <62208000 2>, + <124416000 4>, <248832000 16>; + qcom,sde-vbif-dynamic-ot-wr-limit = <62208000 2>, + <124416000 4>, <248832000 16>; + + qcom,sde-dram-channels = <2>; + qcom,sde-num-nrt-paths = <1>; + + qcom,sde-max-bw-high-kbps = <9000000>; + qcom,sde-max-bw-low-kbps = <9000000>; + + qcom,sde-sspp-vig-blocks { + qcom,sde-vig-csc-off = <0x320>; + qcom,sde-vig-qseed-off = <0x200>; + /* Offset from vig top, version of HSIC */ + qcom,sde-vig-hsic = <0x200 0x00010000>; + qcom,sde-vig-memcolor = <0x200 0x00010000>; + qcom,sde-vig-pcc = <0x1780 0x00010000>; + }; + + qcom,sde-sspp-rgb-blocks { + qcom,sde-rgb-scaler-off = <0x200>; + qcom,sde-rgb-pcc = <0x380 0x00010000>; + }; + + qcom,sde-dspp-blocks { + qcom,sde-dspp-pcc = <0x1700 0x00010000>; + qcom,sde-dspp-gc = <0x17c0 0x00010000>; + qcom,sde-dspp-hsic = <0x0 0x00010000>; + qcom,sde-dspp-memcolor = <0x0 0x00010000>; + qcom,sde-dspp-sixzone = <0x0 0x00010000>; + qcom,sde-dspp-gamut = <0x1600 0x00010000>; + qcom,sde-dspp-dither = <0x0 0x00010000>; + qcom,sde-dspp-hist = <0x0 0x00010000>; + qcom,sde-dspp-vlut = <0x0 0x00010000>; + }; + + qcom,sde-mixer-blocks { + qcom,sde-mixer-gc = <0x3c0 0x00010000>; + }; + + qcom,platform-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + qcom,platform-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vdd"; + qcom,supply-min-voltage = <0>; + qcom,supply-max-voltage = <0>; + qcom,supply-enable-load = <0>; + qcom,supply-disable-load = <0>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <0>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + + qcom,sde-data-bus { + qcom,msm-bus,name = "mdss_sde"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,num-paths = <3>; + qcom,msm-bus,vectors-KBps = + <22 512 0 0>, <23 512 0 0>, <25 512 0 0>, + <22 512 0 6400000>, <23 512 0 6400000>, + <25 512 0 6400000>, + <22 512 0 6400000>, <23 512 0 6400000>, + <25 512 0 6400000>; + }; + + qcom,sde-reg-bus { + /* Reg Bus Scale Settings */ + qcom,msm-bus,name = "mdss_reg"; + qcom,msm-bus,num-cases = <4>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,active-only; + qcom,msm-bus,vectors-KBps = + <1 590 0 0>, + <1 590 0 76800>, + <1 590 0 160000>, + <1 590 0 320000>; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/qcom-sps-dma.txt b/Documentation/devicetree/bindings/dma/qcom-sps-dma.txt new file mode 100644 index 000000000000..c6c8726dac26 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom-sps-dma.txt @@ -0,0 +1,42 @@ +* Qualcomm technologies inc, DMA engine driver for BAM (Bus Access Manager). + +Required properties: +- compatible: Should be "qcom,sps-dma". +- reg: Should contain DMA registers location and length. This should include + all of the per-channel registers. +- interrupts: Should contain the BAM interrupt number. +- qcom,summing-threshold: Should contain the BAM event threshold of + the sum of descriptors' sizes in bytes. + +Optional properties: +- qcom,managed-locally : Use when BAM global device control is managed locally + by the application processor. + +Example: + + dma_blsp1: qcom,sps-dma@f9904000 { /* BLSP1 */ + #dma-cells = <4>; + compatible = "qcom,sps-dma"; + reg = <0xf9904000 0x19000>; + interrupts = <0 238 0>; + qcom,summing-threshold = <10>; + }; + +DMA clients connected to the qcom-sps-dma DMA controller must use the format +described in the dma.txt file, using a five-cell specifier for each channel, +a phandle plus four integer cells, as shown below: + +dmas = <[phandle of the dma controller] [pipe index] [number of descriptors] + [sps_connect flags] [sps_register_event flags]>; + +Example: + +i2c_2: i2c@f9924000 { /* BLSP1 QUP2 */ + . + . + . + /* <&phandle pipe-idx n-descs connect-flags event-flags> */ + dmas = <&dma_blsp1 14 32 0x20000020 0x20>, + <&dma_blsp1 15 64 0x20000020 0x20>; + dma-names = "tx", "rx"; +}; diff --git a/Documentation/devicetree/bindings/dma/sps/sps.txt b/Documentation/devicetree/bindings/dma/sps/sps.txt new file mode 100644 index 000000000000..92dda7ffd632 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/sps/sps.txt @@ -0,0 +1,47 @@ +SPS (Smart Peripheral Switch) may be used as a DMA engine to move data +in either the Peripheral-to-Peripheral (a.k.a. BAM-to-BAM) mode or the +Peripheral-to-Memory (a.k.a. BAM-System) mode. SPS includes BAM (Bus +Access Module) hardware block, BAM DMA peripheral, and pipe memory. + +Required property: + - compatible: should be "qcom,msm_sps" or "qcom,msm_sps_4k" + +Optional properties: + - reg: offset and size for the memory mapping, including maps for + BAM DMA BAM, BAM DMA peripheral, pipe memory and reserved memory. + - reg-names: indicates various resources passed to driver (via reg + property) by name. "reg-names" examples are "bam_mem", "core_mem" + , "pipe_mem" and "res_mem". + - interrupts: IRQ line + - qcom,device-type: specify the device configuration of BAM DMA and + pipe memory. Can be one of + 1 - With BAM DMA and without pipe memory + 2 - With BAM DMA and with pipe memory + 3 - Without BAM DMA and without pipe memory + - qcom,pipe-attr-ee: BAM pipes are attributed to a specific EE, with + which we can know the pipes belong to apps side and can have the + error interrupts at the pipe level. + - clocks: This property shall provide a list of entries each of which + contains a phandle to clock controller device and a macro that is + the clock's name in hardware.These should be "clock_rpm" as clock + controller phandle and "clk_pnoc_sps_clk" as macro for "dfab_clk" + and "clock_gcc" as clock controller phandle and "clk_gcc_bam_dma_ahb_clk" + as macro for "dma_bam_pclk". + - clock-names: This property shall contain the clock input names used + by driver in same order as the clocks property.These should be "dfab_clk" + and "dma_bam_pclk". + +Example: + + qcom,sps@f9980000 { + compatible = "qcom,msm_sps"; + reg = <0xf9984000 0x15000>, + <0xf9999000 0xb000>, + <0xfe803000 0x4800>; + interrupts = <0 94 0>; + qcom,device-type = <2>; + qcom,pipe-attr-ee; + clocks = <&clock_rpm clk_pnoc_sps_clk>, + <&clock_gcc clk_gcc_bam_dma_ahb_clk>; + clock-names = "dfab_clk", "dma_bam_pclk"; + }; diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi-display.txt b/Documentation/devicetree/bindings/drm/msm/hdmi-display.txt new file mode 100644 index 000000000000..aaa3722659ab --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/hdmi-display.txt @@ -0,0 +1,59 @@ +Qualcomm Technologies,Inc. Adreno/Snapdragon hdmi display manager + +Required properties: +- compatible: "qcom,hdmi-display" +- label: label of this display manager + +Optional properties: +- qcom,display-type: display type of this manager. It could be "primary", + "secondary", "tertiary", etc. +- qcom,non-pluggable: Boolean to indicate if display is non pluggable. +- qcom,customize-modes: Customized modes when it's non pluggable display. +- qcom,customize-mode-id: Customized mode node. +- qcom,mode-name: String which indicates the mode name which shall be used + by the connector in non pluggable mode. Refer the example below for details. + In pluggable mode, the modes shall be filled up + after edid parsing. +- qcom,mode-h-active: Horizontal active pixels for this mode. +- qcom,mode-h-front-porch: Horizontal front porch in pixels for this mode. +- qcom,mode-h-pulse-width: Horizontal sync width in pixels for this mode. +- qcom,mode-h-back-porch: Horizontal back porch in pixels for this mode. +- qcom,mode-h-active-high: Boolean to indicate if mode horizontal polarity is active high. +- qcom,mode-v-active: Vertical active lines for this mode. +- qcom,mode-v-front-porch: Vertical front porch in lines for this mode. +- qcom,mode-v-pulse-width: Vertical sync width in lines for this mode. +- qcom,mode-v-back-porch: Vertical back porch in lines for this mode. +- qcom,mode-v-active-high: Boolean to indicate if mode vertical polarity is active high. +- qcom,mode-refersh-rate: Mode refresh rate in hertz. +- qcom,mode-clock-in-khz: Mode pixel clock in KHz. + +Example: + +/ { + ... + + hdmi_display: qcom,hdmi-display { + compatible = "qcom,hdmi-display"; + label = "hdmi_display"; + qcom,display-type = "secondary"; + qcom,non-pluggable; + qcom,customize-modes { + qcom,customize-mode-id@0 { + qcom,mode-name = "3840x2160@30Hz"; + qcom,mode-h-active = <3840>; + qcom,mode-h-front-porch = <176>; + qcom,mode-h-pulse-width = <88>; + qcom,mode-h-back-porch = <296>; + qcom,mode-h-active-high; + qcom,mode-v-active = <2160>; + qcom,mode-v-front-porch = <8>; + qcom,mode-v-pulse-width = <10>; + qcom,mode-v-back-porch = <72>; + qcom,mode-v-active-high; + qcom,mode-refersh-rate = <30>; + qcom,mode-clock-in-khz = <297000>; + }; + }; + }; + +}; diff --git a/Documentation/devicetree/bindings/drm/msm/sde-dsi.txt b/Documentation/devicetree/bindings/drm/msm/sde-dsi.txt new file mode 100644 index 000000000000..48a2c6c78297 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/sde-dsi.txt @@ -0,0 +1,96 @@ +Qualcomm Technologies, Inc. + +mdss-dsi is the master DSI device which supports multiple DSI host controllers +that are compatible with MIPI display serial interface specification. + +DSI Controller: +Required properties: +- compatible: Should be "qcom,dsi-ctrl-hw-v<version>". Supported + versions include 1.4 and 2.0. + eg: qcom,dsi-ctrl-hw-v1.4, qcom,dsi-ctrl-hw-v2.0 + And for dsi phy driver: + qcom,dsi-phy-v1.0, qcom,dsi-phy-v2.0, qcom,dsi-phy-v3.0, + qcom,dsi-phy-v4.0 +- reg: Base address and length of DSI controller's memory + mapped regions. +- reg-names: A list of strings that name the list of regs. + "dsi_ctrl" - DSI controller memory region. + "mmss_misc" - MMSS misc memory region. +- cell-index: Specifies the controller instance. +- clocks: Clocks required for DSI controller operation. +- clock-names: Names of the clocks corresponding to handles. Following + clocks are required: + "mdp_core_clk" + "iface_clk" + "core_mmss_clk" + "bus_clk" + "byte_clk" + "pixel_clk" + "core_clk" + "byte_clk_rcg" + "pixel_clk_rcg" +- gdsc-supply: phandle to gdsc regulator node. +- vdda-supply: phandle to vdda regulator node. +- vcca-supply: phandle to vcca regulator node. +- interrupt-parent phandle to the interrupt parent device node. +- interrupts: The interrupt signal from the DSI block. + +Bus Scaling Data: +- qcom,msm-bus,name: String property describing MDSS client. +- qcom,msm-bus,num-cases: This is the number of bus scaling use cases + defined in the vectors property. This must be + set to <2> for MDSS DSI driver where use-case 0 + is used to remove BW votes from the system. Use + case 1 is used to generate bandwidth requestes + when sending command packets. +- qcom,msm-bus,num-paths: This represents number of paths in each bus + scaling usecase. This value depends on number of + AXI master ports dedicated to MDSS for + particular chipset. +- qcom,msm-bus,vectors-KBps: A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt. + DSI driver should always set average bandwidth + (ab) to 0 and always use instantaneous + bandwidth(ib) values. + +Optional properties: +- label: String to describe controller. +- qcom,platform-te-gpio: Specifies the gpio used for TE. +- qcom,dsi-display-active: Current active display +- qcom,dsi-ctrl: handle to dsi controller device +- qcom,dsi-phy: handle to dsi phy device +- qcom,dsi-manager: Specifies dsi manager is present +- qcom,dsi-display: Specifies dsi display is present +- qcom,hdmi-display: Specifies hdmi is present +- qcom,dp-display: Specified dp is present +- qcom,<type>-supply-entries: A node that lists the elements of the supply used by the + a particular "type" of DSI module. The module "types" + can be "core", "ctrl", and "phy". Within the same type, + there can be more than one instance of this binding, + in which case the entry would be appended with the + supply entry index. + e.g. qcom,ctrl-supply-entry@0 + -- qcom,supply-name: name of the supply (vdd/vdda/vddio) + -- qcom,supply-min-voltage: minimum voltage level (uV) + -- qcom,supply-max-voltage: maximum voltage level (uV) + -- qcom,supply-enable-load: load drawn (uA) from enabled supply + -- qcom,supply-disable-load: load drawn (uA) from disabled supply + -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on + -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on + -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off + -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off +- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode + panels in microseconds. Driver uses this number to adjust + the clock rate according to the expected transfer time. + Increasing this value would slow down the mdp processing + and can result in slower performance. + Decreasing this value can speed up the mdp processing, + but this can also impact power consumption. + As a rule this time should not be higher than the time + that would be expected with the processing at the + dsi link rate since anyways this would be the maximum + transfer time that could be achieved. + If ping pong split enabled, this time should not be higher + than two times the dsi link rate time. + If the property is not specified, then the default value is 14000 us.
\ No newline at end of file diff --git a/Documentation/devicetree/bindings/drm/msm/sde-wb.txt b/Documentation/devicetree/bindings/drm/msm/sde-wb.txt new file mode 100644 index 000000000000..863b334e438a --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/sde-wb.txt @@ -0,0 +1,23 @@ +QTI Snapdragon Display Engine (SDE) writeback display + +Required properties: +- compatible: "qcom,wb-display" + +Optional properties: +- cell-index: Index of writeback device instance. + Default to 0 if not specified. +- label: String to describe this writeback display. + Default to "unknown" if not specified. + +Example: + +/ { + ... + + sde_wb: qcom,wb-display { + compatible = "qcom,wb-display"; + cell-index = <2>; + label = "wb_display"; + }; + +}; diff --git a/Documentation/devicetree/bindings/fb/adv7533.txt b/Documentation/devicetree/bindings/fb/adv7533.txt new file mode 100644 index 000000000000..8b85fcd730cb --- /dev/null +++ b/Documentation/devicetree/bindings/fb/adv7533.txt @@ -0,0 +1,51 @@ +ADV7533 DSI to HDMI bridge + + +Required properties: +- compatible: Must be "adv7533" +- reg: Main I2C slave ID (for I2C host driver) +- adi,video-mode: Excepted a number and possible inputs are 0 to 3, while: + 3 = 1080p + 2 = 720p + 1 = 480p + 0 = 1080p pattern +- adi,main-addr: Main I2C slave ID +- adi,cec-dsi-addr: CEC DSI I2C slave ID + +Optional properties: +- adi,enable-audio: +- adi,disable-gpios: +- adi,irq-gpio: Main IRQ gpio mapping +- adi,hpd-irq-gpio: HPD IRQ gpio mapping +- adi,switch-gpio: DSI switch gpio mapping +- qcom,supply-names: Regulator names that supply 5v to bridge chip +- qcom,min-voltage-level Minimum voltage level to be supplied to bridge chip +- qcom,max-voltage-level Maximum voltage level to be supplied to bridge chip +- qcom,enable-load Load current to bridge chip when enabled +- qcom,disable-load Load current to bridge chip when disabled + +Example: +&soc { + i2c@78b8000 { + adv7533@39 { + compatible = "adv7533"; + reg = <0x39>; + adi,video-mode = <3>; /* 3 = 1080p */ + adi,main-addr = <0x39>; + adi,cec-dsi-addr = <0x3C>; + adi,enable-audio; + pinctrl-names = "pmx_adv7533_active","pmx_adv7533_suspend"; + pinctrl-0 = <&adv7533_int_active &adv7533_hpd_int_active &adv7533_switch_active>; + pinctrl-1 = <&adv7533_int_suspend &adv7533_hpd_int_suspend &adv7533_switch_suspend>; + adi,irq-gpio = <&msm_gpio 31 0x2002>; + adi,hpd-irq-gpio = <&msm_gpio 20 0x2003>; + adi,switch-gpio = <&msm_gpio 32 0x0>; + hpd-5v-en-supply = <&adv_vreg>; + qcom,supply-names = "hpd-5v-en"; + qcom,min-voltage-level = <0>; + qcom,max-voltage-level = <0>; + qcom,enable-load = <0>; + qcom,disable-load = <0>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/fb/mdss-dp.txt b/Documentation/devicetree/bindings/fb/mdss-dp.txt new file mode 100644 index 000000000000..aa227c2628da --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-dp.txt @@ -0,0 +1,147 @@ +QTI MDSS DP + +MDSS DP is a display-port driver which supports panels that are compatible with +VESA DP and EDP display interface specification. + +When configuring the optional properties for external backlight, one should also +configure the gpio that drives the pwm to it. + +Required properties +- compatible : Must be "qcom,mdss-edp". +- reg : Offset and length of the register set for the + device. +- reg-names : Names to refer to register sets related to this + device +- gdsc-supply : Phandle for gdsc regulator device node. +- vdda-1p2-supply : Phandle for 1.2V vdda regulator device node. +- vdda-0p9-supply : Phandle for 0.9V vdda regulator device node. +- status : A string that has to be set to "okay/ok" to enable + the driver. By default this property will be set to + "disable". Will be set to "ok/okay" status for + specific platforms. +- qcom,mdss-fb-map: pHandle that specifies the framebuffer to which the + interface is mapped. +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. +- qcom,aux-en-gpio: Specifies the aux-channel enable gpio. +- qcom,aux-sel-gpio: Specifies the aux-channel select gpio. +- qcom,usbplug-cc-gpio: Specifies the usbplug orientation gpio. +- qcom,aux-cfg-settings: An array that specifies the DP AUX configuration settings. + +Optional properties: +- qcom,<type>-supply-entries: A node that lists the elements of the supply used by the + a particular "type" of DSI modulee. The module "types" + can be "core", "ctrl", and "phy". Within the same type, + there can be more than one instance of this binding, + in which case the entry would be appended with the + supply entry index. + e.g. qcom,ctrl-supply-entry@0 + -- qcom,supply-name: name of the supply (vdd/vdda/vddio) + -- qcom,supply-min-voltage: minimum voltage level (uV) + -- qcom,supply-max-voltage: maximum voltage level (uV) + -- qcom,supply-enable-load: load drawn (uA) from enabled supply + -- qcom,supply-disable-load: load drawn (uA) from disabled supply + -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on + -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on + -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off + -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off +- qcom,hpd-gpio: Specifies the HPD gpio. +- pinctrl-names: List of names to assign mdss pin states defined in pinctrl device node + Refer to pinctrl-bindings.txt +- pinctrl-<0..n>: Lists phandles each pointing to the pin configuration node within a pin + controller. These pin configurations are installed in the pinctrl + device node. Refer to pinctrl-bindings.txt +- qcom,logical2physical-lane-map: An array that specifies the DP logical to physical lane map setting. +- qcom,phy-register-offset: An integer specifying the offset value of DP PHY register space. +- qcom,max-pclk-frequency-khz: An integer specifying the max. pixel clock in KHz supported by Display Port. + +Example: + mdss_dp_ctrl: qcom,dp_ctrl@c990000 { + cell-index = <0>; + compatible = "qcom,mdss-dp"; + qcom,mdss-fb-map = <&mdss_fb3>; + + gdsc-supply = <&gdsc_mdss>; + vdda-1p2-supply = <&pm8998_l2>; + vdda-0p9-supply = <&pm8998_l1>; + + reg = <0xc990000 0xa84>, + <0xc011000 0x910>, + <0x1fcb200 0x050>; + reg-names = "dp_ctrl", "dp_phy", "tcsr_regs"; + + clocks = <&clock_mmss clk_mmss_mnoc_ahb_clk>, + <&clock_mmss clk_mmss_mdss_ahb_clk>, + <&clock_mmss clk_mmss_mdss_axi_clk>, + <&clock_mmss clk_mmss_mdss_mdp_clk>, + <&clock_mmss clk_mmss_mdss_hdmi_dp_ahb_clk>, + <&clock_mmss clk_mmss_mdss_dp_aux_clk>, + <&clock_gcc clk_gcc_usb_phy_cfg_ahb2phy_clk>, + <&clock_mmss clk_mmss_mdss_dp_link_clk>, + <&clock_mmss clk_mmss_mdss_dp_link_intf_clk>, + <&clock_mmss clk_mmss_mdss_dp_crypto_clk>, + <&clock_mmss clk_mmss_mdss_dp_pixel_clk>; + clock-names = "core_mnoc_clk", "core_iface_clk", "core_bus_clk", + "core_mdp_core_clk", "core_alt_iface_clk", + "core_aux_clk", "core_cfg_ahb_clk", "ctrl_link_clk", + "ctrl_link_iface_clk", "ctrl_crypto_clk", "ctrl_pixel_clk"; + + qcom,aux-cfg-settings = [00 13 00 10 0a 26 0a 03 8b 03]; + qcom,logical2physical-lane-map = [02 03 01 00]; + qcom,phy-register-offset = <0x4>; + qcom,max-pclk-frequency-khz = <593470>; + + qcom,core-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,core-supply-entry@0 { + reg = <0>; + qcom,supply-name = "gdsc"; + qcom,supply-min-voltage = <0>; + qcom,supply-max-voltage = <0>; + qcom,supply-enable-load = <0>; + qcom,supply-disable-load = <0>; + }; + }; + + qcom,ctrl-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,ctrl-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vdda-1p2"; + qcom,supply-min-voltage = <1200000>; + qcom,supply-max-voltage = <1200000>; + qcom,supply-enable-load = <12560>; + qcom,supply-disable-load = <4>; + }; + }; + + qcom,phy-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,phy-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vdda-0p9"; + qcom,supply-min-voltage = <880000>; + qcom,supply-max-voltage = <880000>; + qcom,supply-enable-load = <73400>; + qcom,supply-disable-load = <32>; + }; + }; + + pinctrl-names = "mdss_dp_active", "mdss_dp_sleep"; + pinctrl-0 = <&mdss_dp_aux_active &mdss_dp_usbplug_cc_active + &mdss_dp_hpd_active>; + pinctrl-1 = <&mdss_dp_aux_suspend &mdss_dp_usbplug_cc_suspend + &mdss_dp_hpd_suspend>; + qcom,aux-en-gpio = <&tlmm 77 0>; + qcom,aux-sel-gpio = <&tlmm 78 0>; + qcom,usbplug-cc-gpio = <&tlmm 38 0>; + qcom,hpd-gpio = <&tlmm 34 0>; + }; + diff --git a/Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt b/Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt new file mode 100644 index 000000000000..90ccfa7c62e2 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt @@ -0,0 +1,842 @@ +Qualcomm mdss-dsi-panel + +mdss-dsi-panel is a dsi panel device which supports panels that +are compatable with MIPI display serial interface specification. + +Required properties: +- compatible: This property applies to DSI V2 panels only. + This property should not be added for panels + that work based on version "V6.0" + DSI panels that are of different versions + are initialized by the drivers for dsi controller. + This property specifies the version + for DSI HW that this panel will work with + "qcom,dsi-panel-v2" = DSI V2.0 +- status: This property applies to DSI V2 panels only. + This property should not be added for panels + that work based on version "V6.0" + DSI panels that are of different versions + are initialized by the drivers for dsi controller. + A string that has to be set to "okay/ok" + to enable the panel driver. By default this property + will be set to "disable". Will be set to "ok/okay" + status for specific platforms. +- qcom,mdss-dsi-panel-controller: Specifies the phandle for the DSI controller that + this panel will be mapped to. +- qcom,mdss-dsi-panel-width: Specifies panel width in pixels. +- qcom,mdss-dsi-panel-height: Specifies panel height in pixels. +- qcom,mdss-dsi-bpp: Specifies the panel bits per pixel. + 3 = for rgb111 + 8 = for rgb332 + 12 = for rgb444 + 16 = for rgb565 + 18 = for rgb666 + 24 = for rgb888 +- qcom,mdss-dsi-panel-destination: A string that specifies the destination display for the panel. + "display_1" = DISPLAY_1 + "display_2" = DISPLAY_2 +- qcom,mdss-dsi-panel-timings: An array of length 12 that specifies the PHY + timing settings for the panel. +- qcom,mdss-dsi-panel-timings-phy-v2: An array of length 40 char that specifies the PHY version 2 + lane timing settings for the panel. +- qcom,mdss-dsi-on-command: A byte stream formed by multiple dcs packets base on + qcom dsi controller protocol. + byte 0: dcs data type + byte 1: set to indicate this is an individual packet + (no chain) + byte 2: virtual channel number + byte 3: expect ack from client (dcs read command) + byte 4: wait number of specified ms after dcs command + transmitted + byte 5, 6: 16 bits length in network byte order + byte 7 and beyond: number byte of payload +- qcom,mdss-dsi-off-command: A byte stream formed by multiple dcs packets base on + qcom dsi controller protocol. + byte 0: dcs data type + byte 1: set to indicate this is an individual packet + (no chain) + byte 2: virtual channel number + byte 3: expect ack from client (dcs read command) + byte 4: wait number of specified ms after dcs command + transmitted + byte 5, 6: 16 bits length in network byte order + byte 7 and beyond: number byte of payload +- qcom,mdss-dsi-lp-mode-on: This is used to enable display low persistence mode. + A byte stream formed by multiple dcs packets base on + qcom dsi controller protocol. + byte 0: dcs data type + byte 1: set to indicate this is an individual packet + (no chain) + byte 2: virtual channel number + byte 3: expect ack from client (dcs read command) + byte 4: wait number of specified ms after dcs command + transmitted + byte 5, 6: 16 bits length in network byte order + byte 7 and beyond: number byte of payload +- qcom,mdss-dsi-lp-mode-off: This is used to disable display low persistence mode. + A byte stream formed by multiple dcs packets base on + qcom dsi controller protocol. + byte 0: dcs data type + byte 1: set to indicate this is an individual packet + (no chain) + byte 2: virtual channel number + byte 3: expect ack from client (dcs read command) + byte 4: wait number of specified ms after dcs command + transmitted + byte 5, 6: 16 bits length in network byte order + byte 7 and beyond: number byte of payload +- qcom,mdss-dsi-post-panel-on-command: same as "qcom,mdss-dsi-on-command" except commands are + sent after displaying an image. + +Note, if a short DCS packet(i.e packet with Byte 0:dcs data type as 05) mentioned in +qcom,mdss-dsi-on-command/qcom,mdss-dsi-off-command stream fails to transmit, +then 3 options can be tried. + 1. Send the packet as a long packet instead + Byte 0: dcs data type = 05 (DCS short Packet) + Byte 0: dcs data type = 29 (DCS long Packet) + 2. Send the packet in one burst by prepending with the next packet in packet stream + Byte 1 = 01 (indicates this is an individual packet) + Byte 1 = 00 (indicates this will be appended to the next + individual packet in the packet stream) + 3. Prepend a NULL packet to the short packet and send both in one burst instead of + combining multiple short packets and sending them in one burst. + +Optional properties: +- qcom,mdss-dsi-panel-name: A string used as a descriptive name of the panel +- qcom,cmd-sync-wait-broadcast: Boolean used to broadcast dcs command to panels. +- qcom,mdss-dsi-fbc-enable: Boolean used to enable frame buffer compression mode. +- qcom,mdss-dsi-fbc-slice-height: Slice height(in lines) of compressed block. + Expressed as power of 2. To set as 128 lines, + this should be set to 7. +- qcom,mdss-dsi-fbc-2d-pred-mode: Boolean to enable 2D map prediction. +- qcom,mdss-dsi-fbc-ver2-mode: Boolean to enable FBC 2.0 that supports 1/3 + compression. +- qcom,mdss-dsi-fbc-bpp: Compressed bpp supported by the panel. + Specified color order is used as default value. +- qcom,mdss-dsi-fbc-packing: Component packing. + 0 = default value. +- qcom,mdss-dsi-fbc-quant-error: Boolean used to enable quantization error calculation. +- qcom,mdss-dsi-fbc-bias: Bias for CD. + 0 = default value. +- qcom,mdss-dsi-fbc-pat-mode: Boolean used to enable PAT mode. +- qcom,mdss-dsi-fbc-vlc-mode: Boolean used to enable VLC mode. +- qcom,mdss-dsi-fbc-bflc-mode: Boolean used to enable BFLC mode. +- qcom,mdss-dsi-fbc-h-line-budget: Per line extra budget. + 0 = default value. +- qcom,mdss-dsi-fbc-budget-ctrl: Extra budget level. + 0 = default value. +- qcom,mdss-dsi-fbc-block-budget: Per block budget. + 0 = default value. +- qcom,mdss-dsi-fbc-lossless-threshold: Lossless mode threshold. + 0 = default value. +- qcom,mdss-dsi-fbc-lossy-threshold: Lossy mode threshold. + 0 = default value. +- qcom,mdss-dsi-fbc-rgb-threshold: Lossy RGB threshold. + 0 = default value. +- qcom,mdss-dsi-fbc-lossy-mode-idx: Lossy mode index value. + 0 = default value. +- qcom,mdss-dsi-fbc-max-pred-err: Max quantization prediction error. + 0 = default value +- qcom,mdss-dsi-h-back-porch: Horizontal back porch value in pixel. + 6 = default value. +- qcom,mdss-dsi-h-front-porch: Horizontal front porch value in pixel. + 6 = default value. +- qcom,mdss-dsi-h-pulse-width: Horizontal pulse width. + 2 = default value. +- qcom,mdss-dsi-h-sync-skew: Horizontal sync skew value. + 0 = default value. +- qcom,mdss-dsi-v-back-porch: Vertical back porch value in pixel. + 6 = default value. +- qcom,mdss-dsi-v-front-porch: Vertical front porch value in pixel. + 6 = default value. +- qcom,mdss-dsi-v-pulse-width: Vertical pulse width. + 2 = default value. +- qcom,mdss-dsi-h-left-border: Horizontal left border in pixel. + 0 = default value +- qcom,mdss-dsi-h-right-border: Horizontal right border in pixel. + 0 = default value +- qcom,mdss-dsi-v-top-border: Vertical top border in pixel. + 0 = default value +- qcom,mdss-dsi-v-bottom-border: Vertical bottom border in pixel. + 0 = default value +- qcom,mdss-dsi-underflow-color: Specifies the controller settings for the + panel under flow color. + 0xff = default value. +- qcom,mdss-dsi-border-color: Defines the border color value if border is present. + 0 = default value. +- qcom,mdss-dsi-pan-enable-dynamic-fps: Boolean used to enable change in frame rate dynamically. +- qcom,mdss-dsi-pan-fps-update: A string that specifies when to change the frame rate. + "dfps_suspend_resume_mode"= FPS change request is + implemented during suspend/resume. + "dfps_immediate_clk_mode" = FPS change request is + implemented immediately using DSI clocks. + "dfps_immediate_porch_mode_hfp" = FPS change request is + implemented immediately by changing panel horizontal + front porch values. + "dfps_immediate_porch_mode_vfp" = FPS change request is + implemented immediately by changing panel vertical + front porch values. +- qcom,min-refresh-rate: Minimum refresh rate supported by the panel. Used in + adaptive variable refresh(AVR) to compute new avr vtotal +- qcom,max-refresh-rate: Maximum refresh rate supported by the panel. If max refresh + rate is not specified, then the frame rate of the panel in + qcom,mdss-dsi-panel-framerate is used. +- qcom,mdss-dsi-bl-pmic-control-type: A string that specifies the implementation of backlight + control for this panel. + "bl_ctrl_pwm" = Backlight controlled by PWM gpio. + "bl_ctrl_wled" = Backlight controlled by WLED. + "bl_ctrl_dcs" = Backlight controlled by DCS commands. + other: Unknown backlight control. (default) +- qcom,mdss-dsi-bl-pwm-pmi: Boolean to indicate that PWM control is through second pmic chip. +- qcom,mdss-dsi-bl-pmic-bank-select: LPG channel for backlight. + Requred if blpmiccontroltype is PWM +- qcom,mdss-dsi-bl-pmic-pwm-frequency: PWM period in microseconds. + Requred if blpmiccontroltype is PWM +- qcom,mdss-dsi-pwm-gpio: PMIC gpio binding to backlight. + Requred if blpmiccontroltype is PWM +- qcom,mdss-dsi-bl-min-level: Specifies the min backlight level supported by the panel. + 0 = default value. +- qcom,mdss-dsi-bl-max-level: Specifies the max backlight level supported by the panel. + 255 = default value. +- qcom,mdss-brightness-max-level: Specifies the max brightness level supported. + 255 = default value. +- qcom,mdss-dsi-interleave-mode: Specifies interleave mode. + 0 = default value. +- qcom,mdss-dsi-panel-type: Specifies the panel operating mode. + "dsi_video_mode" = enable video mode (default). + "dsi_cmd_mode" = enable command mode. +- qcom,5v-boost-gpio: Specifies the panel gpio for display 5v boost. +- qcom,mdss-dsi-te-check-enable: Boolean to enable Tear Check configuration. +- qcom,mdss-dsi-te-using-te-pin: Boolean to specify whether using hardware vsync. +- qcom,mdss-dsi-te-pin-select: Specifies TE operating mode. + 0 = TE through embedded dcs command + 1 = TE through TE gpio pin. (default) +- qcom,mdss-dsi-te-dcs-command: Inserts the dcs command. + 1 = default value. +- qcom,mdss-dsi-wr-mem-start: DCS command for write_memory_start. + 0x2c = default value. +- qcom,mdss-dsi-wr-mem-continue: DCS command for write_memory_continue. + 0x3c = default value. +- qcom,mdss-dsi-h-sync-pulse: Specifies the pulse mode option for the panel. + 0 = Don't send hsa/he following vs/ve packet(default) + 1 = Send hsa/he following vs/ve packet +- qcom,mdss-dsi-hfp-power-mode: Boolean to determine DSI lane state during + horizontal front porch (HFP) blanking period. +- qcom,mdss-dsi-hbp-power-mode: Boolean to determine DSI lane state during + horizontal back porch (HBP) blanking period. +- qcom,mdss-dsi-hsa-power-mode: Boolean to determine DSI lane state during + horizontal sync active (HSA) mode. +- qcom,mdss-dsi-last-line-interleave Boolean to determine if last line + interleave flag needs to be enabled. +- qcom,mdss-dsi-bllp-eof-power-mode: Boolean to determine DSI lane state during + blanking low power period (BLLP) EOF mode. +- qcom,mdss-dsi-bllp-power-mode: Boolean to determine DSI lane state during + blanking low power period (BLLP) mode. +- qcom,mdss-dsi-traffic-mode: Specifies the panel traffic mode. + "non_burst_sync_pulse" = non burst with sync pulses (default). + "non_burst_sync_event" = non burst with sync start event. + "burst_mode" = burst mode. +- qcom,mdss-dsi-pixel-packing: Specifies if pixel packing is used (in case of RGB666). + "tight" = Tight packing (default value). + "loose" = Loose packing. +- qcom,mdss-dsi-virtual-channel-id: Specifies the virtual channel identefier. + 0 = default value. +- qcom,mdss-dsi-color-order: Specifies the R, G and B channel ordering. + "rgb_swap_rgb" = DSI_RGB_SWAP_RGB (default value) + "rgb_swap_rbg" = DSI_RGB_SWAP_RBG + "rgb_swap_brg" = DSI_RGB_SWAP_BRG + "rgb_swap_grb" = DSI_RGB_SWAP_GRB + "rgb_swap_gbr" = DSI_RGB_SWAP_GBR +- qcom,mdss-dsi-lane-0-state: Boolean that specifies whether data lane 0 is enabled. +- qcom,mdss-dsi-lane-1-state: Boolean that specifies whether data lane 1 is enabled. +- qcom,mdss-dsi-lane-2-state: Boolean that specifies whether data lane 2 is enabled. +- qcom,mdss-dsi-lane-3-state: Boolean that specifies whether data lane 3 is enabled. +- qcom,mdss-dsi-t-clk-post: Specifies the byte clock cycles after mode switch. + 0x03 = default value. +- qcom,mdss-dsi-t-clk-pre: Specifies the byte clock cycles before mode switch. + 0x24 = default value. +- qcom,mdss-dsi-stream: Specifies the packet stream to be used. + 0 = stream 0 (default) + 1 = stream 1 +- qcom,mdss-dsi-mdp-trigger: Specifies the trigger mechanism to be used for MDP path. + "none" = no trigger + "trigger_te" = Tear check signal line used for trigger + "trigger_sw" = Triggered by software (default) + "trigger_sw_te" = Software trigger and TE +- qcom,mdss-dsi-dma-trigger: Specifies the trigger mechanism to be used for DMA path. + "none" = no trigger + "trigger_te" = Tear check signal line used for trigger + "trigger_sw" = Triggered by software (default) + "trigger_sw_seof" = Software trigger and start/end of frame trigger. + "trigger_sw_te" = Software trigger and TE +- qcom,mdss-dsi-panel-framerate: Specifies the frame rate for the panel. + 60 = 60 frames per second (default) +- qcom,mdss-dsi-host-esc-clk-freq-hz: Specifies the escape clock needed for the host. + 19200000 = 19.2 MHz (default) +- qcom,mdss-dsi-panel-clockrate: A 64 bit value specifies the panel clock speed in Hz. + 0 = default value. +- qcom,mdss-mdp-kickoff-threshold: This property can be used to define a region + (in terms of scanlines) where the +hardware is allowed + to trigger a data transfer from MDP to DSI. + If this property is used, the region must be defined setting + two values, the low and the high thresholds: + <low_threshold high_threshold> + Where following condition must be met: + low_threshold < high_threshold + These values will be used by the driver in such way that if + the Driver receives a request to kickoff a transfer (MDP to DSI), + the transfer will be triggered only if the following condition + is satisfied: + low_threshold < scanline < high_threshold + If the condition is not met, then the driver will delay the + transfer by the time defined in the following property: + "qcom,mdss-mdp-kickoff-delay". + So in order to use this property, the delay property must + be defined as well and greater than 0. +- qcom,mdss-mdp-kickoff-delay: This property defines the delay in microseconds that + the driver will delay before triggering an MDP transfer if the + thresholds defined by the following property are not met: + "qcom,mdss-mdp-kickoff-threshold". + So in order to use this property, the threshold property must + be defined as well. Note that this delay cannot be zero + and also should not be greater than +the fps window. + i.e. For 60fps value should not exceed +16666 uS. +- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode + panels in microseconds. Driver uses this number to adjust + the clock rate according to the expected transfer time. + Increasing this value would slow down the mdp processing + and can result in slower performance. + Decreasing this value can speed up the mdp processing, + but this can also impact power consumption. + As a rule this time should not be higher than the time + that would be expected with the processing at the + dsi link rate since anyways this would be the maximum + transfer time that could be achieved. + If ping pong split enabled, this time should not be higher + than two times the dsi link rate time. + 14000 = default value. +- qcom,mdss-dsi-on-command-state: String that specifies the ctrl state for sending ON commands. + "dsi_lp_mode" = DSI low power mode (default) + "dsi_hs_mode" = DSI high speed mode +- qcom,mdss-dsi-off-command-state: String that specifies the ctrl state for sending OFF commands. + "dsi_lp_mode" = DSI low power mode (default) + "dsi_hs_mode" = DSI high speed mode +- qcom,mdss-dsi-post-mode-switch-on-command-state: String that specifies the ctrl state for sending ON commands post mode switch. + "dsi_lp_mode" = DSI low power mode (default) + "dsi_hs_mode" = DSI high speed mode +- qcom,mdss-pan-physical-width-dimension: Specifies panel physical width in mm which corresponds + to the physical width in the framebuffer information. +- qcom,mdss-pan-physical-height-dimension: Specifies panel physical height in mm which corresponds + to the physical height in the framebuffer information. +- qcom,mdss-dsi-mode-sel-gpio-state: String that specifies the lcd mode for panel + (such as single-port/dual-port), if qcom,panel-mode-gpio + binding is defined in dsi controller. + "dual_port" = Set GPIO to LOW + "single_port" = Set GPIO to HIGH + "high" = Set GPIO to HIGH + "low" = Set GPIO to LOW + The default value is "dual_port". +- qcom,mdss-tear-check-disable: Boolean to disable mdp tear check. Tear check is enabled by default to avoid + tearing. Other tear-check properties are ignored if this property is present. + The below tear check configuration properties can be individually tuned if + tear check is enabled. +- qcom,mdss-tear-check-sync-cfg-height: Specifies the vertical total number of lines. + The default value is 0xfff0. +- qcom,mdss-tear-check-sync-init-val: Specifies the init value at which the read pointer gets loaded + at vsync edge. The reader pointer refers to the line number of + panel buffer that is currently being updated. + The default value is panel height. +- qcom,mdss-tear-check-sync-threshold-start: + Allows the first ROI line write to an panel when read pointer is + between the range of ROI start line and ROI start line plus this + setting. + The default value is 4. +- qcom,mdss-tear-check-sync-threshold-continue: + The minimum number of lines the write pointer needs to be + above the read pointer so that it is safe to write to the panel. + (This check is not done for the first ROI line write of an update) + The default value is 4. +- qcom,mdss-tear-check-start-pos: Specify the y position from which the start_threshold value is + added and write is kicked off if the read pointer falls within that + region. + The default value is panel height. +- qcom,mdss-tear-check-rd-ptr-trigger-intr: + Specify the read pointer value at which an interrupt has to be + generated. + The default value is panel height + 1. +- qcom,mdss-tear-check-frame-rate: Specify the value to be a real frame rate(fps) x 100 factor to tune the + timing of TE simulation with more precision. + The default value is 6000 with 60 fps. +- qcom,mdss-dsi-reset-sequence: An array that lists the + sequence of reset gpio values and sleeps + Each command will have the format defined + as below: + --> Reset GPIO value + --> Sleep value (in ms) +- qcom,partial-update-enabled: String used to enable partial + panel update for command mode panels. + "none": partial update is disabled + "single_roi": default enable mode, only single roi is sent to panel + "dual_roi": two rois are merged into one big roi. Panel ddic should be able + to process two roi's along with the DCS command to send two rois. + disabled if property is not specified. +- qcom,mdss-dsi-horizontal-line-idle: List of width ranges (EC - SC) in pixels indicating + additional idle time in dsi clock cycles that is needed + to compensate for smaller line width. +- qcom,partial-update-roi-merge: Boolean indicates roi combination is need + and function has been provided for dcs + 2A/2B command. +- qcom,dcs-cmd-by-left: Boolean to indicate that dcs command are sent + through the left DSI controller only in a dual-dsi configuration +- qcom,mdss-dsi-panel-hdr-enabled: Boolean to indicate HDR support in panel. +- qcom,mdss-dsi-panel-hdr-color-primaries: + Array of 8 unsigned integers denoting chromaticity of panel.These + values are specified in nits units. The value range is 0 through 50000. + To obtain real chromacity, these values should be divided by factor of + 50000. The structure of array is defined in below order + value 1: x value of white chromaticity of display panel + value 2: y value of white chromaticity of display panel + value 3: x value of red chromaticity of display panel + value 4: y value of red chromaticity of display panel + value 5: x value of green chromaticity of display panel + value 6: y value of green chromaticity of display panel + value 7: x value of blue chromaticity of display panel + value 8: y value of blue chromaticity of display panel +- qcom,mdss-dsi-panel-peak-brightness: Maximum brightness supported by panel.In absence of maximum value + typical value becomes peak brightness. Value is specified in nits units. + To obtail real peak brightness, this value should be divided by factor of + 10000. +- qcom,mdss-dsi-panel-blackness-level: Blackness level supported by panel. Blackness level is defined as + ratio of peak brightness to contrast. Value is specified in nits units. + To obtail real blackness level, this value should be divided by factor of + 10000. +- qcom,mdss-dsi-lp11-init: Boolean used to enable the DSI clocks and data lanes (low power 11) + before issuing hardware reset line. +- qcom,mdss-dsi-init-delay-us: Delay in microseconds(us) before performing any DSI activity in lp11 + mode. This master delay (t_init_delay as per DSI spec) should be sum + of DSI internal delay to reach fuctional after power up and minimum + delay required by panel to reach functional. +- qcom,mdss-dsi-rx-eot-ignore: Boolean used to enable ignoring end of transmission packets. +- qcom,mdss-dsi-tx-eot-append: Boolean used to enable appending end of transmission packets. +- qcom,ulps-enabled: Boolean to enable support for Ultra Low Power State (ULPS) mode. +- qcom,suspend-ulps-enabled: Boolean to enable support for ULPS mode for panels during suspend state. +- qcom,panel-roi-alignment: Specifies the panel ROI alignment restrictions on its + left, top, width, height alignments and minimum width and + height values +- qcom,esd-check-enabled: Boolean used to enable ESD recovery feature. +- qcom,mdss-dsi-panel-status-command: A byte stream formed by multiple dcs packets based on + qcom dsi controller protocol, to read the panel status. + This value is used to kick in the ESD recovery. + byte 0: dcs data type + byte 1: set to indicate this is an individual packet + (no chain) + byte 2: virtual channel number + byte 3: expect ack from client (dcs read command) + byte 4: wait number of specified ms after dcs command + transmitted + byte 5, 6: 16 bits length in network byte order + byte 7 and beyond: number byte of payload +- qcom,mdss-dsi-panel-status-command-mode: + String that specifies the ctrl state for reading the panel status. + "dsi_lp_mode" = DSI low power mode + "dsi_hs_mode" = DSI high speed mode +- qcom,mdss-dsi-panel-status-check-mode:Specifies the panel status check method for ESD recovery. + "bta_check" = Uses BTA to check the panel status + "reg_read" = Reads panel status register to check the panel status + "reg_read_nt35596" = Reads panel status register to check the panel + status for NT35596 panel. + "te_signal_check" = Uses TE signal behaviour to check the panel status +- qcom,mdss-dsi-panel-status-read-length: Integer array that specify the expected read-back length of values + for each of panel registers. Each length is corresponding to number of + returned parameters of register introduced in specification. +- qcom,mdss-dsi-panel-status-valid-params: Integer array that specify the valid returned values which need to check + for each of register. + Some panel need only check the first few values returned from panel. + So: if this property is the same to qcom,mdss-dsi-panel-status-read-length, + then just ignore this one. +- qcom,mdss-dsi-panel-status-value: Multiple integer arrays, each specifies the values of the panel status register + which is used to check the panel status. The size of each array is the sum of + length specified in qcom,mdss-dsi-panel-status-read-length, and must be equal. + This can cover that Some panel may return several alternative values. +- qcom,mdss-dsi-panel-max-error-count: Integer value that specifies the maximum number of errors from register + read that can be ignored before treating that the panel has gone bad. +- qcom,dynamic-mode-switch-enabled: Boolean used to mention whether panel supports + dynamic switching from video mode to command mode + and vice versa. +- qcom,dynamic-mode-switch-type: A string specifies how to perform dynamic mode switch. + If qcom,dynamic-mode-switch-enabled is set and no string specified, default value is + dynamic-switch-suspend-resume. + "dynamic-switch-suspend-resume"= Switch using suspend/resume. Panel will + go blank during transition. + "dynamic-switch-immediate"= Switch on next frame update. Panel will + not go blank for this transition. + "dynamic-resolution-switch-immediate"= Switch the panel resolution. Panel will + not go blank for this transition. +- qcom,mdss-dsi-post-mode-switch-on-command: Multiple dcs packets used for turning on DSI panel + after panel has switch modes. + Refer to "qcom,mdss-dsi-on-command" section for adding commands. +- qcom,video-to-cmd-mode-switch-commands: List of commands that need to be sent + to panel in order to switch from video mode to command mode dynamically. + Refer to "qcom,mdss-dsi-on-command" section for adding commands. +- qcom,cmd-to-video-mode-switch-commands: List of commands that need to be sent + to panel in order to switch from command mode to video mode dynamically. + Refer to "qcom,mdss-dsi-on-command" section for adding commands. +- qcom,mode-switch-commands-state: String that specifies the ctrl state for sending commands to switch + the panel mode, it applies for both switches, from command to video and + from video to command. + "dsi_lp_mode" = DSI low power mode (default) + "dsi_hs_mode" = DSI high speed mode +- qcom,send-pps-before-switch: Boolean propety to indicate when PPS commands should be sent, + either before or after switch commands during dynamic resolution + switch in DSC panels. If the property is not present, the default + behavior is to send PPS commands after the switch commands. +- qcom,mdss-dsi-panel-orientation: String used to indicate orientation of panel + "180" = panel is flipped in both horizontal and vertical directions + "hflip" = panel is flipped in horizontal direction + "vflip" = panel is flipped in vertical direction +- qcom,panel-ack-disabled: A boolean property to indicate, whether we need to wait for any ACK from the panel + for any commands that we send. +- qcom,mdss-dsi-force-clock-lane-hs: Boolean to force dsi clock lanes to HS mode always. + +- qcom,compression-mode: Select compression mode for panel. + "fbc" - frame buffer compression + "dsc" - display stream compression. + If "dsc" compression is used then config subnodes needs to be defined. +- qcom,panel-supply-entries: A node that lists the elements of the supply used to + power the DSI panel. There can be more than one instance + of this binding, in which case the entry would be appended + with the supply entry index. For a detailed description of + fields in the supply entry, refer to the qcom,ctrl-supply-entries + binding above. +- qcom,config-select: Optional property to select default configuration. +- qcom,panel-allow-phy-poweroff: A boolean property indicates that panel allows to turn off the phy power + supply during idle screen. A panel should able to handle the dsi lanes + in floating state(not LP00 or LP11) to turn on this property. Software + turns off PHY pmic power supply, phy ldo and DSI Lane ldo during + idle screen (footswitch control off) when this property is enabled. +[[Optional config sub-nodes]] These subnodes provide different configurations for a given same panel. + Default configuration can be chosen by specifying phandle of the + selected subnode in the qcom,config-select. +Required properties for sub-nodes: None +Optional properites: +- qcom,lm-split: An array of two values indicating MDP should use two layer + mixers to reduce power. + Ex: Normally 1080x1920 display uses single DSI and thus one layer + mixer. But if we use two layer mixers then mux the output of + those two mixers into single stream and route it to single DSI + then we can lower the clock requirements of MDP. To use this + configuration we need two fill this array with <540 540>. + Both values doesn't have to be same, but recommended, however sum of + both values has to be equal to the panel-width. + By default two mixer streams are merged using 2D mux, however if + 2 DSC encoders are used then merge is performed within compression + engine. +- qcom,split-mode: String property indicating which split mode MDP should use. Valid + entries are "pingpong-split" and "dualctl-split". + This property is mutually exclusive with qcom,lm-split. +- qcom,mdss-dsc-version: An 8 bit value indicates the DSC version supported by panel. Bits[0.3] + provides information about minor version while Bits[4.7] provides + major version information. It supports only DSC rev 1(Major).1(Minor) + right now. +- qcom,mdss-dsc-scr-version: Each DSC version can have multiple SCR. This 8 bit value indicates + current SCR revision information supported by panel. +- qcom,mdss-dsc-encoders: An integer value indicating how many DSC encoders should be used + to drive data stream to DSI. + Default value is 1 and max value is 2. + 2 encoder should be used only if qcom,mdss-lm-split or + qcom,split-mode with pingpong-split is used. +- qcom,mdss-dsc-slice-height: An integer value indicates the dsc slice height. +- qcom,mdss-dsc-slice-width: An integer value indicates the dsc slice width. + Multiple of slice width should be equal to panel-width. + Maximum 2 slices per DSC encoder can be used so if 2 DSC encoders + are used then minimum slice width is equal to panel-width/4. +- qcom,mdss-dsc-slice-per-pkt: An integer value indicates the slice per dsi packet. +- qcom,mdss-dsc-bit-per-component: An integer value indicates the bits per component before compression. +- qcom,mdss-dsc-bit-per-pixel: An integer value indicates the bits per pixel after compression. +- qcom,mdss-dsc-block-prediction-enable: A boolean value to enable/disable the block prediction at decoder. +- qcom,mdss-dsc-config-by-manufacture-cmd: A boolean to indicates panel use manufacture command to setup pps + instead of standard dcs type 0x0A. +- qcom,dba-panel: Indicates whether the current panel is used as a display bridge + to a non-DSI interface. +- qcom,bridge-name: A string to indicate the name of the bridge chip connected to DSI. qcom,bridge-name + is required if qcom,dba-panel is defined for the panel. +- qcom,adjust-timer-wakeup-ms: An integer value to indicate the timer delay(in ms) to accommodate + s/w delay while configuring the event timer wakeup logic. + +- qcom,mdss-dsi-display-timings: Parent node that lists the different resolutions that the panel supports. + Each child represents timings settings for a specific resolution. +- qcom,mdss-dsi-post-init-delay: Specifies required number of frames to wait so that panel can be functional + to show proper display. + +Additional properties added to the second level nodes that represent timings properties: +- qcom,mdss-dsi-timing-default: Property that specifies the current child as the default + timing configuration that will be used. +- qcom,mdss-dsi-timing-switch-command: List of commands that need to be sent + to panel when the resolution/timing switch happens dynamically. + Refer to "qcom,mdss-dsi-on-command" section for adding commands. +- qcom,mdss-dsi-timing-switch-command-state: String that specifies the ctrl state for sending resolution switch + commands. + "dsi_lp_mode" = DSI low power mode (default) + "dsi_hs_mode" = DSI high speed mode + +Note, if a given optional qcom,* binding is not present, then the driver will configure +the default values specified. + +Example: +&mdss_mdp { + dsi_sim_vid: qcom,mdss_dsi_sim_video { + qcom,mdss-dsi-panel-name = "simulator video mode dsi panel"; + qcom,mdss-dsi-panel-controller = <&mdss_dsi0>; + qcom,mdss-dsi-panel-height = <1280>; + qcom,mdss-dsi-panel-width = <720>; + qcom,mdss-dsi-bpp = <24>; + qcom,mdss-dsi-pixel-packing = <0>; + qcom,mdss-dsi-panel-destination = "display_1"; + qcom,cmd-sync-wait-broadcast; + qcom,mdss-dsi-fbc-enable; + qcom,mdss-dsi-fbc-slice-height = <5>; + qcom,mdss-dsi-fbc-2d-pred-mode; + qcom,mdss-dsi-fbc-ver2-mode; + qcom,mdss-dsi-fbc-bpp = <0>; + qcom,mdss-dsi-fbc-packing = <0>; + qcom,mdss-dsi-fbc-quant-error; + qcom,mdss-dsi-fbc-bias = <0>; + qcom,mdss-dsi-fbc-pat-mode; + qcom,mdss-dsi-fbc-vlc-mode; + qcom,mdss-dsi-fbc-bflc-mode; + qcom,mdss-dsi-fbc-h-line-budget = <0>; + qcom,mdss-dsi-fbc-budget-ctrl = <0>; + qcom,mdss-dsi-fbc-block-budget = <0>; + qcom,mdss-dsi-fbc-lossless-threshold = <0>; + qcom,mdss-dsi-fbc-lossy-threshold = <0>; + qcom,mdss-dsi-fbc-rgb-threshold = <0>; + qcom,mdss-dsi-fbc-lossy-mode-idx = <0>; + qcom,mdss-dsi-fbc-max-pred-err = <2>; + qcom,mdss-dsi-h-front-porch = <140>; + qcom,mdss-dsi-h-back-porch = <164>; + qcom,mdss-dsi-h-pulse-width = <8>; + qcom,mdss-dsi-h-sync-skew = <0>; + qcom,mdss-dsi-v-back-porch = <6>; + qcom,mdss-dsi-v-front-porch = <1>; + qcom,mdss-dsi-v-pulse-width = <1>; + qcom,mdss-dsi-h-left-border = <0>; + qcom,mdss-dsi-h-right-border = <0>; + qcom,mdss-dsi-v-top-border = <0>; + qcom,mdss-dsi-v-bottom-border = <0>; + qcom,mdss-dsi-border-color = <0>; + qcom,mdss-dsi-underflow-color = <0xff>; + qcom,mdss-dsi-bl-min-level = <1>; + qcom,mdss-dsi-bl-max-level = < 15>; + qcom,mdss-brightness-max-level = <255>; + qcom,mdss-dsi-interleave-mode = <0>; + qcom,mdss-dsi-panel-type = "dsi_video_mode"; + qcom,mdss-dsi-te-check-enable; + qcom,mdss-dsi-te-using-te-pin; + qcom,mdss-dsi-te-dcs-command = <1>; + qcom,mdss-dsi-wr-mem-continue = <0x3c>; + qcom,mdss-dsi-wr-mem-start = <0x2c>; + qcom,mdss-dsi-te-pin-select = <1>; + qcom,mdss-dsi-h-sync-pulse = <1>; + qcom,mdss-dsi-hfp-power-mode; + qcom,mdss-dsi-hbp-power-mode; + qcom,mdss-dsi-hsa-power-mode; + qcom,mdss-dsi-bllp-eof-power-mode; + qcom,mdss-dsi-bllp-power-mode; + qcom,mdss-dsi-last-line-interleave; + qcom,mdss-dsi-traffic-mode = <0>; + qcom,mdss-dsi-virtual-channel-id = <0>; + qcom,mdss-dsi-color-order = <0>; + qcom,mdss-dsi-lane-0-state; + qcom,mdss-dsi-lane-1-state; + qcom,mdss-dsi-lane-2-state; + qcom,mdss-dsi-lane-3-state; + qcom,mdss-dsi-t-clk-post = <0x20>; + qcom,mdss-dsi-t-clk-pre = <0x2c>; + qcom,mdss-dsi-stream = <0>; + qcom,mdss-dsi-mdp-trigger = <0>; + qcom,mdss-dsi-dma-trigger = <0>; + qcom,mdss-dsi-panel-framerate = <60>; + qcom,mdss-dsi-host-esc-clk-freq-hz = <19200000>; + qcom,mdss-dsi-panel-clockrate = <424000000>; + qcom,mdss-mdp-kickoff-threshold = <11 2430>; + qcom,mdss-mdp-kickoff-delay = <1000>; + qcom,mdss-mdp-transfer-time-us = <12500>; + qcom,mdss-dsi-panel-timings = [7d 25 1d 00 37 33 + 22 27 1e 03 04 00]; + qcom,mdss-dsi-panel-timings-phy-v2 = [23 20 06 09 05 03 04 a0 + 23 20 06 09 05 03 04 a0 + 23 20 06 09 05 03 04 a0 + 23 20 06 09 05 03 04 a0 + 23 2e 06 08 05 03 04 a0]; + qcom,mdss-dsi-on-command = [32 01 00 00 00 00 02 00 00 + 29 01 00 00 10 00 02 FF 99]; + qcom,mdss-dsi-on-command-state = "dsi_lp_mode"; + qcom,mdss-dsi-off-command = [22 01 00 00 00 00 00]; + qcom,mdss-dsi-off-command-state = "dsi_hs_mode"; + qcom,mdss-dsi-lp-mode-on = [32 01 00 00 00 00 02 00 00 + 29 01 00 00 10 00 02 FF 99]; + qcom,mdss-dsi-lp-mode-off = [22 01 00 00 00 00 00]; + qcom,mdss-dsi-bl-pmic-control-type = "bl_ctrl_wled"; + qcom,mdss-dsi-pan-enable-dynamic-fps; + qcom,mdss-dsi-pan-fps-update = "dfps_suspend_resume_mode"; + qcom,min-refresh-rate = <30>; + qcom,max-refresh-rate = <60>; + qcom,mdss-dsi-bl-pmic-bank-select = <0>; + qcom,mdss-dsi-bl-pmic-pwm-frequency = <0>; + qcom,mdss-dsi-pwm-gpio = <&pm8941_mpps 5 0>; + qcom,5v-boost-gpio = <&pm8994_gpios 14 0>; + qcom,mdss-pan-physical-width-dimension = <60>; + qcom,mdss-pan-physical-height-dimension = <140>; + qcom,mdss-dsi-mode-sel-gpio-state = "dsc_mode"; + qcom,mdss-tear-check-sync-cfg-height = <0xfff0>; + qcom,mdss-tear-check-sync-init-val = <1280>; + qcom,mdss-tear-check-sync-threshold-start = <4>; + qcom,mdss-tear-check-sync-threshold-continue = <4>; + qcom,mdss-tear-check-start-pos = <1280>; + qcom,mdss-tear-check-rd-ptr-trigger-intr = <1281>; + qcom,mdss-tear-check-frame-rate = <6000>; + qcom,mdss-dsi-reset-sequence = <1 2>, <0 10>, <1 10>; + qcom,partial-update-enabled = "single_roi"; + qcom,dcs-cmd-by-left; + qcom,mdss-dsi-lp11-init; + qcom,mdss-dsi-init-delay-us = <100>; + mdss-dsi-rx-eot-ignore; + mdss-dsi-tx-eot-append; + qcom,ulps-enabled; + qcom,suspend-ulps-enabled; + qcom,panel-roi-alignment = <4 4 2 2 20 20>; + qcom,esd-check-enabled; + qcom,panel-allow-phy-poweroff; + qcom,mdss-dsi-panel-status-command = [06 01 00 01 05 00 02 0A 08]; + qcom,mdss-dsi-panel-status-command-state = "dsi_lp_mode"; + qcom,mdss-dsi-panel-status-check-mode = "reg_read"; + qcom,mdss-dsi-panel-status-read-length = <8>; + qcom,mdss-dsi-panel-max-error-count = <3>; + qcom,mdss-dsi-panel-status-value = <0x1c 0x00 0x05 0x02 0x40 0x84 0x06 0x01>; + qcom,dynamic-mode-switch-enabled; + qcom,dynamic-mode-switch-type = "dynamic-switch-immediate"; + qcom,mdss-dsi-post-mode-switch-on-command = [32 01 00 00 00 00 02 00 00 + 29 01 00 00 10 00 02 B0 03]; + qcom,video-to-cmd-mode-switch-commands = [15 01 00 00 00 00 02 C2 0B + 15 01 00 00 00 00 02 C2 08]; + qcom,cmd-to-video-mode-switch-commands = [15 01 00 00 00 00 02 C2 03]; + qcom,mode-switch-commands-state = "dsi_hs_mode"; + qcom,send-pps-before-switch; + qcom,panel-ack-disabled; + qcom,mdss-dsi-horizontal-line-idle = <0 40 256>, + <40 120 128>, + <128 240 64>; + qcom,mdss-dsi-panel-orientation = "180" + qcom,mdss-dsi-force-clock-lane-hs; + qcom,compression-mode = "dsc"; + qcom,adjust-timer-wakeup-ms = <1>; + qcom,mdss-dsi-display-timings { + wqhd { + qcom,mdss-dsi-timing-default; + qcom,mdss-dsi-panel-width = <720>; + qcom,mdss-dsi-panel-height = <2560>; + qcom,mdss-dsi-h-front-porch = <20>; + qcom,mdss-dsi-h-back-porch = <8>; + qcom,mdss-dsi-h-pulse-width = <8>; + qcom,mdss-dsi-h-sync-skew = <0>; + qcom,mdss-dsi-v-back-porch = <4>; + qcom,mdss-dsi-v-front-porch = <728>; + qcom,mdss-dsi-v-pulse-width = <4>; + qcom,mdss-dsi-panel-framerate = <60>; + qcom,mdss-dsi-panel-timings = [E6 38 26 00 68 6E 2A 3C 2C 03 04 00]; + qcom,mdss-dsi-t-clk-post = <0x02>; + qcom,mdss-dsi-t-clk-pre = <0x2a>; + qcom,mdss-dsi-on-command = [05 01 00 00 a0 00 02 11 00 + 05 01 00 00 02 00 02 29 00]; + qcom,mdss-dsi-on-command-state = "dsi_lp_mode"; + qcom,mdss-dsi-timing-switch-command = [ + 29 00 00 00 00 00 02 B0 04 + 29 00 00 00 00 00 02 F1 00]; + qcom,mdss-dsi-timing-switch-command-state = "dsi_lp_mode"; + + qcom,config-select = <&dsi_sim_vid_config0>; + dsi_sim_vid_config0: config0 { + qcom,lm-split = <360 360>; + qcom,mdss-dsc-encoders = <2>; + qcom,mdss-dsc-slice-height = <16>; + qcom,mdss-dsc-slice-width = <360>; + qcom,mdss-dsc-slice-per-pkt = <2>; + qcom,mdss-dsc-bit-per-component = <8>; + qcom,mdss-dsc-bit-per-pixel = <8>; + qcom,mdss-dsc-block-prediction-enable; + qcom,mdss-dsc-config-by-manufacture-cmd; + }; + }; + }; + qcom,panel-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,panel-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vdd"; + qcom,supply-min-voltage = <2800000>; + qcom,supply-max-voltage = <2800000>; + qcom,supply-enable-load = <100000>; + qcom,supply-disable-load = <100>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <0>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + + qcom,panel-supply-entry@1 { + reg = <1>; + qcom,supply-name = "vddio"; + qcom,supply-min-voltage = <1800000>; + qcom,supply-max-voltage = <1800000>; + qcom,supply-enable-load = <100000>; + qcom,supply-disable-load = <100>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <0>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + + qcom,config-select = <&dsi_sim_vid_config0>; + qcom,dba-panel; + qcom,bridge-name = "adv7533"; + qcom,mdss-dsc-version = <0x11>; + qcom,mdss-dsc-scr-version = <0x1>; + + dsi_sim_vid_config0: config0 { + qcom,lm-split = <360 360>; + qcom,mdss-dsc-encoders = <2>; + qcom,mdss-dsc-slice-height = <16>; + qcom,mdss-dsc-slice-width = <360>; + qcom,mdss-dsc-slice-per-pkt = <2>; + qcom,mdss-dsc-bit-per-component = <8>; + qcom,mdss-dsc-bit-per-pixel = <8>; + qcom,mdss-dsc-block-prediction-enable; + qcom,mdss-dsc-config-by-manufacture-cmd; + }; + + dsi_sim_vid_config1: config1 { + qcom,mdss-dsc-encoders = <1>; + qcom,mdss-dsc-slice-height = <16>; + qcom,mdss-dsc-slice-width = <360>; + qcom,mdss-dsc-slice-per-pkt = <2>; + qcom,mdss-dsc-bit-per-component = <8>; + qcom,mdss-dsc-bit-per-pixel = <8>; + qcom,mdss-dsc-block-prediction-enable; + qcom,mdss-dsc-config-by-manufacture-cmd; + }; + + dsi_sim_vid_config2: config2 { + qcom,split-mode = "dualctl-split"; + }; + + dsi_sim_vid_config3: config3 { + qcom,split-mode = "pingpong-split"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/fb/mdss-dsi.txt b/Documentation/devicetree/bindings/fb/mdss-dsi.txt new file mode 100644 index 000000000000..6c20d22f98b4 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-dsi.txt @@ -0,0 +1,278 @@ +Qualcomm mdss-dsi + +mdss-dsi is the master DSI device which supports multiple DSI host controllers that +are compatible with MIPI display serial interface specification. + +Required properties: +- compatible: Must be "qcom,mdss-dsi" +- hw-config: Specifies the DSI host setup configuration + "hw-config" = "single_dsi" + "hw-config" = "dual_dsi" + "hw-config" = "split_dsi" +- ranges: The standard property which specifies the child address + space, parent address space and the length. +- vdda-supply: Phandle for vreg regulator device node. + +Bus Scaling Data: +- qcom,msm-bus,name: String property describing MDSS client. +- qcom, msm-bus,num-cases: This is the number of bus scaling use cases + defined in the vectors property. This must be + set to <2> for MDSS DSI driver where use-case 0 + is used to remove BW votes from the system. Use + case 1 is used to generate bandwidth requestes + when sending command packets. +- qcom,msm-bus,num-paths: This represents number of paths in each bus + scaling usecase. This value depends on number of + AXI master ports dedicated to MDSS for + particular chipset. +- qcom,msm-bus,vectors-KBps: A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt. + DSI driver should always set average bandwidth + (ab) to 0 and always use instantaneous + bandwidth(ib) values. + +Optional properties: +- vcca-supply: Phandle for vcca regulator device node. +- qcom,<type>-supply-entries: A node that lists the elements of the supply used by the + a particular "type" of DSI modulee. The module "types" + can be "core", "ctrl", and "phy". Within the same type, + there can be more than one instance of this binding, + in which case the entry would be appended with the + supply entry index. + e.g. qcom,ctrl-supply-entry@0 + -- qcom,supply-name: name of the supply (vdd/vdda/vddio) + -- qcom,supply-min-voltage: minimum voltage level (uV) + -- qcom,supply-max-voltage: maximum voltage level (uV) + -- qcom,supply-enable-load: load drawn (uA) from enabled supply + -- qcom,supply-disable-load: load drawn (uA) from disabled supply + -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on + -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on + -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off + -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off +- pll-src-config Specified the source PLL for the DSI + link clocks: + "PLL0" - Clocks sourced out of DSI PLL0 + "PLL1" - Clocks sourced out of DSI PLL1 + This property is only valid for + certain DSI hardware configurations + mentioned in the "hw-config" binding above. + For example, in split_dsi config, the clocks can + only be sourced out of PLL0. For + dual_dsi, both PLL would be active. + For single DSI, it is possible to + select either PLL. If no value is specified, + the default value for single DSI is set as PLL0. +- qcom,mmss-ulp-clamp-ctrl-offset: Specifies the offset for dsi ulps clamp control register. +- qcom,mmss-phyreset-ctrl-offset: Specifies the offset for dsi phy reset control register. +- qcom,dsi-clk-ln-recovery: Boolean which enables the clk lane recovery + +mdss-dsi-ctrl is a dsi controller device which is treated as a subnode of the mdss-dsi device. + +Required properties: +- compatible: Must be "qcom,mdss-dsi-ctrl" +- cell-index: Specifies the controller used among the two controllers. +- reg: Base address and length of the different register + regions(s) required for DSI device functionality. +- reg-names: A list of strings that map in order to the list of regs. + "dsi_ctrl" - MDSS DSI controller register region + "dsi_phy" - MDSS DSI PHY register region + "dsi_phy_regulator" - MDSS DSI PHY REGULATOR region + "mmss_misc_phys" - Register region for MMSS DSI clamps +- vdd-supply: Phandle for vdd regulator device node. +- vddio-supply: Phandle for vdd-io regulator device node. +- qcom,mdss-fb-map-prim: pHandle that specifies the framebuffer to which the + primary interface is mapped. +- qcom,mdss-mdp: pHandle that specifies the mdss-mdp device. +- qcom,platform-strength-ctrl: An array of length 2 or 10 that specifies the PHY + strengthCtrl settings. It use 10 bytes for 8996 pll. +- qcom,platform-lane-config: An array of length 45 or 20 that specifies the PHY + lane configuration settings. It use 20 bytes for 8996 pll. +- qcom,platform-bist-ctrl: An array of length 6 that specifies the PHY + BIST ctrl settings. +- qcom,dsi-pref-prim-pan: phandle that specifies the primary panel to be used + with the controller. + +Optional properties: +- label: A string used to describe the controller used. +- qcom,mdss-fb-map: pHandle that specifies the framebuffer to which the + interface is mapped. +- qcom,mdss-fb-map-sec: pHandle that specifies the framebuffer to which the + secondary interface is mapped. +- qcom,platform-enable-gpio: Specifies the panel lcd/display enable gpio. +- qcom,platform-reset-gpio: Specifies the panel reset gpio. +- qcom,platform-te-gpio: Specifies the gpio used for TE. +- qcom,platform-bklight-en-gpio: Specifies the gpio used to enable display back-light +- qcom,platform-bklight-en-gpio-invert: Invert the gpio used to enable display back-light +- qcom,panel-mode-gpio: Specifies the GPIO to select video/command/single-port/dual-port + mode of panel through gpio when it supports these modes. +- pinctrl-names: List of names to assign mdss pin states defined in pinctrl device node + Refer to pinctrl-bindings.txt +- pinctrl-<0..n>: Lists phandles each pointing to the pin configuration node within a pin + controller. These pin configurations are installed in the pinctrl + device node. Refer to pinctrl-bindings.txt +- qcom,regulator-ldo-mode: Boolean to enable ldo mode for the dsi phy regulator +- qcom,platform-regulator-settings: An array of length 7 or 5 that specifies the PHY + regulator settings. It use 5 bytes for 8996 pll. +- qcom,null-insertion-enabled: Boolean to enable NULL packet insertion + feature for DSI controller. +- qcom,dsi-irq-line: Boolean specifies if DSI has a different irq line than mdp. +- qcom,lane-map: Specifies the data lane swap configuration. + "lane_map_0123" = <0 1 2 3> (default value) + "lane_map_3012" = <3 0 1 2> + "lane_map_2301" = <2 3 0 1> + "lane_map_1230" = <1 2 3 0> + "lane_map_0321" = <0 3 2 1> + "lane_map_1032" = <1 0 3 2> + "lane_map_2103" = <2 1 0 3> + "lane_map_3210" = <3 2 1 0> + where lane_map_ABCD means: + Logical_Lane_A = Physical_Lane_0 + Logical_Lane_B = Physical_Lane_1 + Logical_Lane_C = Physical_Lane_2 + Logical_Lane_D = Physical_Lane_3 + The lane map can vary between multiple instances + of the DSI controller and should be set accordingly in all + of them based on the board configuration. +- qcom,lane-map-v2: An array of size 4 uint8s specifying the corresponding + mapping for each of the logical data lanes. + For example, a value of <A B C D> means + Logical_Lane_0 = Physical_Lane_A + Logical_Lane_1 = Physical_Lane_B + Logical_Lane_2 = Physical_Lane_C + Logical_Lane_3 = Physical_Lane_D + The default lane mapping is <0 1 2 3>. + Since the values are of type uint8, they need to be + specified as below: + qcom,lane-map-v2 = /bits/ 8 <0 1 2 3> + This binding supersedes qcom,lane-map binding and will + override any lane swap setting specified by qcom,lane-map. + Refer to qcom,lane-map for additional notes. +- qcom,pluggable Boolean to enable hotplug feature. +- qcom,timing-db-mode: Boolean specifies dsi timing mode registers are supported or not. +- qcom,display-id A string indicates the display ID for the controller. + The possible values are: + - "primary" + - "secondary" + - "tertiary" +- qcom,bridge-index: Instance id of the bridge chip connected to DSI. qcom,bridge-index is + required if a bridge chip panel is used. + +Example: + mdss_dsi: qcom,mdss_dsi@0 { + compatible = "qcom,mdss-dsi"; + hw-config = "single_dsi"; + pll-src-config = "PLL0"; + #address-cells = <1>; + #size-cells = <1>; + vdda-supply = <&pm8226_l4>; + vcca-supply = <&pm8226_l28>; + reg = <0x1a98000 0x1a98000 0x25c + 0x1a98500 0x1a98500 0x280 + 0x1a98780 0x1a98780 0x30 + 0x193e000 0x193e000 0x30>; + + qcom,dsi-clk-ln-recovery; + + qcom,core-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,core-supply-entry@0 { + reg = <0>; + qcom,supply-name = "gdsc"; + qcom,supply-min-voltage = <0>; + qcom,supply-max-voltage = <0>; + qcom,supply-enable-load = <0>; + qcom,supply-disable-load = <0>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <0>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + + qcom,phy-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,phy-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vddio"; + qcom,supply-min-voltage = <1800000>; + qcom,supply-max-voltage = <1800000>; + qcom,supply-enable-load = <100000>; + qcom,supply-disable-load = <100>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <20>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + + qcom,ctrl-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,ctrl-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vdda"; + qcom,supply-min-voltage = <1200000>; + qcom,supply-max-voltage = <1200000>; + qcom,supply-enable-load = <100000>; + qcom,supply-disable-load = <100>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <20>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + + mdss_dsi0: mdss_dsi_ctrl0@fd922800 { + compatible = "qcom,mdss-dsi-ctrl"; + label = "MDSS DSI CTRL->0"; + cell-index = <0>; + reg = <0xfd922800 0x1f8>, + <0xfd922b00 0x2b0>, + <0xfd998780 0x30>, + <0xfd828000 0x108>; + reg-names = "dsi_ctrl", "dsi_phy", + "dsi_phy_regulator", "mmss_misc_phys"; + + vdd-supply = <&pm8226_l15>; + vddio-supply = <&pm8226_l8>; + qcom,mdss-fb-map-prim = <&mdss_fb0>; + qcom,mdss-mdp = <&mdss_mdp>; + + qcom,dsi-pref-prim-pan = <&dsi_tosh_720_vid>; + + qcom,platform-strength-ctrl = [ff 06]; + qcom,platform-bist-ctrl = [00 00 b1 ff 00 00]; + qcom,platform-regulator-settings = [07 09 03 00 20 00 01]; + qcom,platform-lane-config = [00 00 00 00 00 00 00 01 97 + 00 00 00 00 05 00 00 01 97 + 00 00 00 00 0a 00 00 01 97 + 00 00 00 00 0f 00 00 01 97 + 00 c0 00 00 00 00 00 01 bb]; + + qcom,mmss-ulp-clamp-ctrl-offset = <0x20>; + qcom,mmss-phyreset-ctrl-offset = <0x24>; + qcom,regulator-ldo-mode; + qcom,null-insertion-enabled; + qcom,timing-db-mode; + + pinctrl-names = "mdss_default", "mdss_sleep"; + pinctrl-0 = <&mdss_dsi_active>; + pinctrl-1 = <&mdss_dsi_suspend>; + qcom,platform-reset-gpio = <&msmgpio 25 1>; + qcom,platform-te-gpio = <&msmgpio 24 0>; + qcom,platform-enable-gpio = <&msmgpio 58 1>; + qcom,platform-bklight-en-gpio = <&msmgpio 86 0>; + qcom,platform-bklight-en-gpio-invert; + qcom,panel-mode-gpio = <&msmgpio 107 0>; + qcom,dsi-irq-line; + qcom,lane-map = "lane_map_3012"; + qcom,display-id = "primary"; + qcom,bridge-index = <00>; + }; + }; diff --git a/Documentation/devicetree/bindings/fb/mdss-mdp.txt b/Documentation/devicetree/bindings/fb/mdss-mdp.txt new file mode 100644 index 000000000000..0ab4d53f2663 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-mdp.txt @@ -0,0 +1,892 @@ +Qualcomm MDSS MDP + +MDSS is Mobile Display SubSystem which implements Linux framebuffer APIs to +drive user interface to different panel interfaces. MDP driver is the core of +MDSS which manage all data paths to different panel interfaces. + +Required properties +- compatible : Must be "qcom,mdss_mdp" +- reg : offset and length of the register set for the device. +- reg-names : names to refer to register sets related to this device +- interrupts : Interrupt associated with MDSS. +- interrupt-controller: Mark the device node as an interrupt controller. + This is an empty, boolean property. +- #interrupt-cells: Should be one. The first cell is interrupt number. +- vdd-supply : Phandle for vdd regulator device node. +- qcom,max-clk-rate: Specify maximum MDP core clock rate in hz that this + device supports. +- qcom,mdss-pipe-vig-off: Array of offset for MDP source surface pipes of + type VIG, the offsets are calculated from + register "mdp_phys" defined in reg property. + The number of offsets defined here should + reflect the amount of VIG pipes that can be + active in MDP for this configuration. +- qcom,mdss-pipe-vig-fetch-id: Array of shared memory pool fetch ids + corresponding to the VIG pipe offsets defined in + previous property, the amount of fetch ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-vig-off +- qcom,mdss-pipe-vig-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective VIG pipes. Number of xin ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-vig-off +- qcom,mdss-pipe-vig-clk-ctrl-off: Array of offsets describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register and 3rd value represents bit + offset within status register. Number of tuples + defined should match the number of offsets + defined in property: qcom,mdss-pipe-vig-off +- qcom,mdss-pipe-rgb-off: Array of offsets for MDP source surface pipes of + type RGB, the offsets are calculated from + register "mdp_phys" defined in reg property. + The number of offsets defined here should + reflect the amount of RGB pipes that can be + active in MDP for this configuration. +- qcom,mdss-pipe-rgb-fetch-id: Array of shared memory pool fetch ids + corresponding to the RGB pipe offsets defined in + previous property, the amount of fetch ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-rgb-off +- qcom,mdss-pipe-rgb-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective RGB pipes. Number of xin ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-rgb-off +- qcom,mdss-pipe-rgb-clk-ctrl-off: Array of offsets describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register and 3rd value represents bit + offset within status register. Number of tuples + defined should match the number of offsets + defined in property: qcom,mdss-pipe-rgb-off +- qcom,mdss-pipe-dma-off: Array of offsets for MDP source surface pipes of + type DMA, the offsets are calculated from + register "mdp_phys" defined in reg property. + The number of offsets defined here should + reflect the amount of DMA pipes that can be + active in MDP for this configuration. +- qcom,mdss-pipe-dma-fetch-id: Array of shared memory pool fetch ids + corresponding to the DMA pipe offsets defined in + previous property, the amount of fetch ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-dma-off +- qcom,mdss-pipe-dma-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective DMA pipes. Number of xin ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-dma-off +- qcom,mdss-pipe-dma-clk-ctrl-off: Array of offsets describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register and 3rd value represents bit + offset within status register. Number of tuples + defined should match the number of offsets + defined in property: qcom,mdss-pipe-dma-off +- qcom,mdss-pipe-cursor-off: Array of offsets for MDP source surface pipes of + type cursor, the offsets are calculated from + register "mdp_phys" defined in reg property. + The number of offsets defined here should + reflect the amount of cursor pipes that can be + active in MDP for this configuration. Meant for + hardware that has hw cursors support as a + source pipe. +- qcom,mdss-rot-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective rotator pipes. +- qcom,mdss-pipe-cursor-xin-id: Array of VBIF clients ids (xins) corresponding + to the respective cursor pipes. Number of xin ids + defined should match the number of offsets + defined in property: qcom,mdss-pipe-cursor-off +- qcom,mdss-pipe-cursor-clk-ctrl-off: Array of offsets describing clk control + offsets for dynamic clock gating. 1st value + in the array represents offset of the control + register. 2nd value represents bit offset within + control register and 3rd value represents bit + offset within status register. Number of tuples + defined should match the number of offsets + defined in property: qcom,mdss-pipe-cursor-off +- qcom,mdss-ctl-off: Array of offset addresses for the available ctl + hw blocks within MDP, these offsets are + calculated from register "mdp_phys" defined in + reg property. The number of ctl offsets defined + here should reflect the number of control paths + that can be configured concurrently on MDP for + this configuration. +- qcom,mdss-wb-off: Array of offset addresses for the progammable + writeback blocks within MDP. The number of + offsets defined should match the number of ctl + blocks defined in property: qcom,mdss-ctl-off +- qcom,mdss-mixer-intf-off: Array of offset addresses for the available + mixer blocks that can drive data to panel + interfaces. + These offsets are be calculated from register + "mdp_phys" defined in reg property. + The number of offsets defined should reflect the + amount of mixers that can drive data to a panel + interface. +- qcom,mdss-dspp-off: Array of offset addresses for the available dspp + blocks. These offsets are calculated from + regsiter "mdp_phys" defined in reg property. + The number of dspp blocks should match the + number of mixers driving data to interface + defined in property: qcom,mdss-mixer-intf-off +- qcom,mdss-pingpong-off: Array of offset addresses for the available + pingpong blocks. These offsets are calculated + from regsiter "mdp_phys" defined in reg property. + The number of pingpong blocks should match the + number of mixers driving data to interface + defined in property: qcom,mdss-mixer-intf-off +- qcom,mdss-mixer-wb-off: Array of offset addresses for the available + mixer blocks that can be drive data to writeback + block. These offsets will be calculated from + register "mdp_phys" defined in reg property. + The number of writeback mixer offsets defined + should reflect the number of mixers that can + drive data to a writeback block. +- qcom,mdss-intf-off: Array of offset addresses for the available MDP + video interface blocks that can drive data to a + panel controller through timing engine. + The offsets are calculated from "mdp_phys" + defined in reg property. The number of offsets + defiend should reflect the number of progammable + interface blocks available in hardware. +- qcom,mdss-pref-prim-intf: A string which indicates the configured hardware + interface between MDP and the primary panel. + Individual panel controller drivers initialize + hardware based on this property. + Based on the interfaces supported at present, + possible values are: + - "dsi" + - "edp" + - "hdmi" + +Bus Scaling Data: +- qcom,msm-bus,name: String property describing MDSS client. +- qcom,msm-bus,num-cases: This is the the number of Bus Scaling use cases + defined in the vectors property. This must be + set to <3> for MDSS driver where use-case 0 is + used to take off MDSS BW votes from the system. + And use-case 1 & 2 are used in ping-pong fashion + to generate run-time BW requests. +- qcom,msm-bus,active-only: A boolean flag indicating if it is active only. +- qcom,msm-bus,num-paths: This represents the number of paths in each + Bus Scaling Usecase. This value depends on + how many number of AXI master ports are + dedicated to MDSS for particular chipset. This + value represents the RT + NRT AXI master ports. +- qcom,msm-bus,vectors-KBps: * A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt + * Current values of src & dst are defined at + include/linux/msm-bus-board.h + src values allowed for MDSS are: + 22 = MSM_BUS_MASTER_MDP_PORT0 + 23 = MSM_BUS_MASTER_MDP_PORT1 + 25 = MSM_BUS_MASTER_ROTATOR + dst values allowed for MDSS are: + 512 = MSM_BUS_SLAVE_EBI_CH0 + ab: Represents aggregated bandwidth. + ib: Represents instantaneous bandwidth. + * Total number of 4 cell properties will be + (number of use-cases * number of paths). + * These values will be overridden by the driver + based on the run-time requirements. So initial + ab and ib values defined here are random and + bare no logic except for the use-case 0 where ab + and ib values needs to be 0. + * Define realtime vector properties followed by + non-realtime vector properties. + +- qcom,mdss-prefill-outstanding-buffer-bytes: The size of mdp outstanding buffer + in bytes. The buffer is filled during prefill + time and the buffer size shall be included in + prefill bandwidth calculation. +- qcom,mdss-prefill-y-buffer-bytes: The size of mdp y plane buffer in bytes. The + buffer is filled during prefill time when format + is YUV and the buffer size shall be included in + prefill bandwidth calculation. +- qcom,mdss-prefill-scaler-buffer-lines-bilinear: The value indicates how many lines + of scaler line buffer need to be filled during + prefill time. If bilinear scalar is enabled, then this + number of lines is used to determine how many bytes + of scaler buffer to be included in prefill bandwidth + calculation. +- qcom,mdss-prefill-scaler-buffer-lines-caf: The value indicates how many lines of + of scaler line buffer need to be filled during + prefill time. If CAF mode filter is enabled, then + this number of lines is used to determine how many + bytes of scaler buffer to be included in prefill + bandwidth calculation. +- qcom,mdss-prefill-post-scaler-buffer: The size of post scaler buffer in bytes. + The buffer is used to smooth the output of the + scaler. If the buffer is present in h/w, it is + filled during prefill time and the number of bytes + shall be included in prefill bandwidth calculation. +- qcom,mdss-prefill-pingpong-buffer-pixels: The size of pingpong buffer in pixels. + The buffer is used to keep pixels flowing to the + panel interface. If the vertical start position of a + layer is in the beginning of the active area, pingpong + buffer must be filled during prefill time to generate + starting lines. The number of bytes to be filled is + determined by the line width, starting position, + byte per pixel and scaling ratio, this number shall be + included in prefill bandwidth calculation. +- qcom,mdss-prefill-fbc-lines: The value indicates how many lines are required to fill + fbc buffer during prefill time if FBC (Frame Buffer + Compressor) is enabled. The number of bytes to be filled + is determined by the line width, bytes per pixel and + scaling ratio, this number shall be included in prefill bandwidth + calculation. +- qcom,max-mixer-width: Specify maximum MDP mixer width that the device supports. + This is a mandatory property, if not specified then + mdp probe will fail. +- qcom,mdss-reg-bus: Subnode to provide Bus scaling for register access for + MDP and DSI Blocks. +- qcom,mdss-rot-reg-bus: Subnode to provide Bus scaling for register access for + Rotator Block. + +Optional properties: +- batfet-supply : Phandle for battery FET regulator device node. +- vdd-cx-supply : Phandle for vdd CX regulator device node. +- vdd-cx-min-uV : The minimum voltage level in uV for the CX rail + whenever the display is on. If vdd-cx-supply is + specified, then this binding is mandatory. +- vdd-cx-max-uV : The maximum voltage level in uV for the CX rail + whenever the display is on. If vdd-cx-supply is + specified, then this binding is mandatory. +- qcom,vbif-settings : Array with key-value pairs of constant VBIF register + settings used to setup MDSS QoS for optimum performance. + The key used should be offset from "vbif_phys" register + defined in reg property. +- qcom,vbif-nrt-settings : The key used should be offset from "vbif_nrt_phys" + register defined in reg property. Refer qcom,vbif-settings + for a detailed description of this binding. +- qcom,mdp-settings : Array with key-value pairs of constant MDP register + settings used to setup MDSS QoS for best performance. + The key used should be offset from "mdp_phys" register + defined in reg property. +- qcom,mdss-smp-data: Array of shared memory pool data for dynamic SMP. There + should be only two values in this property. The first + value corresponds to the number of smp blocks and the + second is the size of each block present in the mdss + hardware. This property is optional for MDP hardware + with fix pixel latency ram. +- qcom,mdss-rot-block-size: The size of a memory block (in pixels) to be used + by the rotator. If this property is not specified, + then a default value of 128 pixels would be used. +- qcom,mdss-has-bwc: Boolean property to indicate the presence of bandwidth + compression feature in the rotator. +- qcom,mdss-has-non-scalar-rgb: Boolean property to indicate the presence of RGB + pipes which have no scaling support. +- qcom,mdss-has-decimation: Boolean property to indicate the presence of + decimation feature in fetch. +- qcom,mdss-has-fixed-qos-arbiter-enabled: Boolean property to indicate the + presence of rt/nrt feature. This feature enables + increased performance by prioritizing the real time + (rt) traffic over non real time (nrt) traffic to + access the memory. +- qcom,mdss-num-nrt-paths: Integer property represents the number of non-realtime + paths in each Bus Scaling Usecase. This value depends on + number of AXI ports are dedicated to non-realtime VBIF for + particular chipset. This property is mandatory when + "qcom,mdss-has-fixed-qos-arbiter-enabled" is enabled. + These paths must be defined after rt-paths in + "qcom,msm-bus,vectors-KBps" vector request. +- qcom,mdss-has-source-split: Boolean property to indicate if source split + feature is available or not. +- qcom,mdss-has-rotator-downscale: Boolean property to indicate if rotator + downscale feature is available or not. +- qcom,mdss-ad-off: Array of offset addresses for the available + Assertive Display (AD) blocks. These offsets + are calculated from the register "mdp_phys" + defined in reg property. The number of AD + offsets should be less than or equal to the + number of mixers driving interfaces defined in + property: qcom,mdss-mixer-intf-off. Assumes + that AD blocks are aligned with the mixer + offsets as well (i.e. the first mixer offset + corresponds to the same pathway as the first + AD offset). +- qcom,mdss-has-wb-ad: Boolean property to indicate assertive display feature + support on write back framebuffer. +- qcom,mdss-no-lut-read: Boolean property to indicate reading of LUT is + not supported. +- qcom,mdss-no-hist-vote Boolean property to indicate histogram reads + and histogram LUT writes do not need additional + bandwidth voting. +- qcom,mdss-mdp-wfd-mode: A string that specifies what is the mode of + writeback wfd block. + "intf" = Writeback wfd block is + connected to the interface mixer. + "shared" = Writeback block shared + between wfd and rotator. + "dedicated" = Dedicated writeback + block for wfd using writeback mixer. +- qcom,mdss-smp-mb-per-pipe: Maximum number of shared memory pool blocks + restricted for a source surface pipe. If this + property is not specified, no such restriction + would be applied. +- qcom,mdss-highest-bank-bit: Property to indicate tile format as opposed to usual + linear format. The value tells the GPU highest memory + bank bit used. +- qcom,mdss-pipe-rgb-fixed-mmb: Array of indexes describing fixed Memory Macro + Blocks (MMBs) for rgb pipes. First value denotes + total numbers of MMBs per pipe while values, if + any, following first one denotes indexes of MMBs + to that RGB pipe. +- qcom,mdss-pipe-vig-fixed-mmb: Array of indexes describing fixed Memory Macro + Blocks (MMBs) for vig pipes. First value denotes + total numbers of MMBs per pipe while values, if + any, following first one denotes indexes of MMBs + to that VIG pipe. +- qcom,mdss-pipe-sw-reset-off: Property to indicate offset to the register which + holds sw_reset bitmap for different MDSS + components. +- qcom,mdss-pipe-vig-sw-reset-map: Array of bit offsets for vig pipes within + sw_reset register bitmap. Number of offsets + defined should match the number of offsets + defined in property: qcom,mdss-pipe-vig-off +- qcom,mdss-pipe-rgb-sw-reset-map: Array of bit offsets for rgb pipes within + sw_reset register bitmap. Number of offsets + defined should match the number of offsets + defined in property: qcom,mdss-pipe-rgb-off +- qcom,mdss-pipe-dma-sw-reset-map: Array of bit offsets for dma pipes within + sw_reset register bitmap. Number of offsets + defined should match the number of offsets + defined in property: qcom,mdss-pipe-dma-off +- qcom,mdss-default-ot-wr-limit: This integer value indicates maximum number of pending + writes that can be allowed on each WR xin. + This value can be used to reduce the pending writes + limit and can be tuned to match performance + requirements depending upon system state. + Some platforms require a dynamic ot limiting in + some cases. Setting this default ot write limit + will enable this dynamic limiting for the write + operations in the platforms that require these + limits. +- qcom,mdss-default-ot-rd-limit: This integer value indicates the default number of pending + reads that can be allowed on each RD xin. + Some platforms require a dynamic ot limiting in + some cases. Setting this default ot read limit + will enable this dynamic limiting for the read + operations in the platforms that require these + limits. +- qcom,mdss-clk-levels: This array indicates the mdp core clock level selection + array. Core clock is calculated for each frame and + hence depending upon calculated value, clock rate + will be rounded up to the next level according to + this table. Order of entries need to be ordered in + ascending order. +- qcom,mdss-vbif-qos-rt-setting: This array is used to program vbif qos remapper register + priority for real time clients. +- qcom,mdss-vbif-qos-nrt-setting: This array is used to program vbif qos remapper register + priority for non real time clients. +- qcom,mdss-traffic-shaper-enabled: This boolean property enables traffic shaper functionality + for MDSS rotator which spread out rotator bandwidth request + so that rotator don't compete with other real time read + clients. +- qcom,mdss-dram-channels: This represents the number of channels in the + Bus memory controller. +- qcom,regs-dump-mdp: This array represents the registers offsets that + will be dumped from the mdp when the debug logging + is enabled; each entry in the table is an start and + end offset from the MDP addres "mdp_phys", the + format of each entry is as follows: + <start_offset end_offset> + Ex: + <0x01000 0x01404> + Will dump the MDP registers + from the address: "mdp_phys + 0x01000" + to the address: "mdp_phys + 0x01404" +- qcom,regs-dump-names-mdp: This array represents the tag that will be used + for each of the entries defined within regs-dump. + Note that each tag matches with one of the + regs-dump entries in the same order as they + are defined. +- qcom,regs-dump-xin-id-mdp: Array of VBIF clients ids (xins) corresponding + to mdp block. Xin id property is not valid for mdp + internal blocks like ctl, lm, dspp. It should set + to 0xff for such blocks. +- qcom,max-dest-scaler-input-width: This 32 bit value provides + maximum width to the input of destination scaler. +- qcom,max-dest-scaler-output-width: This 32 bit value provides + maximum width to the output of destination scaler. + +Fudge Factors: Fudge factors are used to boost demand for + resources like bus bandswidth, clk rate etc. to + overcome system inefficiencies and avoid any + glitches. These fudge factors are expressed in + terms of numerator and denominator. First value + is numerator followed by denominator. They all + are optional but highly recommended. + Ex: + x = value to be fudged + a = numerator, default value is 1 + b = denominator, default value is 1 + FUDGE(x, a, b) = ((x * a) / b) +- qcom,mdss-ib-factor: This fudge factor is applied to calculated ib + values in default conditions. +- qcom,mdss-ib-factor-overlap: This fudge factor is applied to calculated ib + values when the overlap bandwidth is the + predominant value compared to prefill bandwidth + value. +- qcom,mdss-clk-factor: This fudge factor is applied to calculated mdp + clk rate in default conditions. + +- qcom,max-bandwidth-low-kbps: This value indicates the max bandwidth in KB + that can be supported without underflow. + This is a low bandwidth threshold which should + be applied in most scenarios to be safe from + underflows when unable to satisfy bandwith + requirements. +- qcom,max-bandwidth-high-kbps: This value indicates the max bandwidth in KB + that can be supported without underflow. + This is a high bandwidth threshold which can be + applied in scenarios where panel interface can + be more tolerant to memory latency such as + command mode panels. +- qcom,max-bandwidth-per-pipe-kbps: A two dimensional array indicating the max + bandwidth in KB that a single pipe can support + without underflow for various usecases. The + first parameter indicates the usecase and the + second parameter gives the max bw allowed for + the usecase. Following are the enum values for + modes in different cases: + For default case, mode = 1 + camera usecase, mode = 2 + hflip usecase, mode = 4 + vflip usecase, mode = 8 + First parameter/mode value need to match enum, + mdss_mdp_max_bw_mode, present in + include/uapi/linux/msm_mdp.h. +- qcom,max-bw-settings: This two dimension array indicates the max bandwidth + in KB that has to be supported when particular + scenarios are involved such as camera, flip. + The first parameter indicate the + scenario/usecase and second paramter indicate + the maximum bandwidth for that usecase. + Following are the enum values for modes in different + cases: + For default case, mode = 1 + camera usecase, mode = 2 + hflip usecase, mode = 4 + vflip usecase, mode = 8 + First parameter/mode value need to match enum, + mdss_mdp_max_bw_mode, present in + include/uapi/linux/msm_mdp.h. + +- qcom,mdss-has-panic-ctrl: Boolean property to indicate if panic/robust signal + control feature is available or not. +- qcom,mdss-en-svs-high: Boolean property to indicate if this target needs to + enable the svs high voltage level for CX rail. +- qcom,mdss-pipe-vig-panic-ctrl-offsets: Array of panic/robust signal offsets + corresponding to the respective VIG pipes. + Number of signal offsets should match the + number of offsets defined in property: + qcom,mdss-pipe-vig-off +- qcom,mdss-pipe-rgb-panic-ctrl-offsets: Array of panic/robust signal offsets + corresponding to the respective RGB pipes. + Number of signal offsets should match the + number of offsets defined in property: + qcom,mdss-pipe-rgb-off +- qcom,mdss-pipe-dma-panic-ctrl-offsets: Array of panic/robust signal offsets + corresponding to the respective DMA pipes. + Number of signal offsets should match the + number of offsets defined in property: + qcom,mdss-pipe-dma-off +- qcom,mdss-per-pipe-panic-luts: Array to configure the panic/robust luts for + each rt and nrt clients. This property is + for the MDPv1.7 and above, which configures + the panic independently on each client. + Each element of the array corresponds to: + First element - panic for linear formats + Second element - panic for tile formats + Third element - robust for linear formats + Fourth element - robust for tile formats +- qcom,mdss-has-pingpong-split: Boolean property to indicate if destination + split feature is available or not in the target. +- qcom,mdss-slave-pingpong-off: Offset address for the extra TE block which needs + to be programmed when pingpong split feature is enabled. + Offset is calculated from the "mdp_phys" + register value. Mandatory when qcom,mdss-has-pingpong-split + is enabled. +- qcom,mdss-ppb-ctl-off: Array of offset addresses of ping pong buffer control registers. + The offsets are calculated from the "mdp_phys" base address + specified. The number of offsets should match the + number of ping pong buffers available in the hardware. + Mandatory when qcom,mdss-has-pingpong-split is enabled. +- qcom,mdss-ppb-cfg-off: Array of offset addresses of ping pong buffer config registers. + The offsets are calculated from the "mdp_phys" base address + specified. The number of offsets should match the + number of ping pong buffers available in the hardware. + Mandatory when qcom,mdss-has-pingpong-split is enabled. +- qcom,mdss-cdm-off: Array of offset addresses for the available + chroma down modules that can convert RGB data + to YUV before sending it to the interface + block. These offsets will be calculated from + register "mdp_phys" define in reg property. The + number of cdm offsets should reflect the number + of cdm blocks present in hardware. +- qcom,mdss-dsc-off: Array of offset addresses for the available + display stream compression module block. + These offsets will be calculated from + register "mdp_phys" define in reg property. The + number of dsc offsets should reflect the number + of dsc blocks present in hardware. +- qcom,max-pipe-width: This value specifies the maximum MDP SSPP width + the device supports. If not specified, a default value + of 2048 will be applied. + +Optional subnodes: +- mdss_fb: Child nodes representing the frame buffer virtual devices. + +- qcom,mdss-hw-rt-bus: Subnode to request min vote on the bus. + Some targets expect min vote on the bus during SMMU + and TZ operations. Use this handle to request the vote needed. + +Subnode properties: +- compatible : Must be "qcom,mdss-fb" +- cell-index : Index representing frame buffer +- qcom,mdss-mixer-swap: A boolean property that indicates if the mixer muxes + need to be swapped based on the target panel. + By default the property is not defined. +- qcom,memblock-reserve: Specifies the memory location and the size reserved + for the framebuffer used to display the splash screen. + This property is required whenever the continuous splash + screen feature is enabled for the corresponding + framebuffer device. It should be used for only 32bit + kernel. +- qcom,cont-splash-memory: Specifies the memory block region reserved for + continuous splash screen feature. This property should be + defined for corresponding framebuffer device if + "qcom,memblock-reserve" is not defined when continuous + splash screen feature is enabled. +- linux,contiguous-region: Phandle to the continuous memory region reserved for + frame-buffer or continuous splash screen. Size of this + region is dependent on the display panel resolution and + buffering scheme for frame-buffer node. Currently driver + uses double buffering. + + Example: Width = 1920, Height = 1080, BytesPerPixel = 4, + Number of frame-buffers reserved = 2. + Size = 1920*1080*4*2 = ROUND_1MB(15.8MB) = 16MB. +- qcom,mdss-intf: Phandle to the kernel driver module that is mapped to the + frame buffer virtual device. +- qcom,mdss-fb-splash-logo-enabled: The boolean entry enables the framebuffer + driver to display the splash logo image. + It is independent of continuous splash + screen feature and has no relation with + qcom,cont-splash-enabled entry present in + panel configuration. +- qcom,mdss-idle-power-collapse-enabled: Boolean property that enables support + for mdss power collapse in idle + screen use cases with smart panels. +- qcom,boot-indication-enabled: Boolean property that enables turning on the blue + LED for notifying that the device is in boot + process. + +- qcom,mdss-pp-offets: A node that lists the offsets of post processing blocks + from base module. + -- qcom,mdss-mdss-sspp-igc-lut-off: This 32 bit value provides the + offset to the IGC lut rams from mdp_phys base. + -- qcom,mdss-sspp-vig-pcc-off: This 32 bit value provides the offset + to PCC block from the VIG pipe base address. + -- qcom,mdss-sspp-rgb-pcc-off: This 32 bit value provides the offset + to PCC block from the RGB pipe base address. + -- qcom,mdss-sspp-dma-pcc-off: This 32 bit value provides the offset + to PCC block from the DMA pipe base address. + -- qcom,mdss-dspp-pcc-off: This 32 bit value provides the offset + to PCC block from the DSPP pipe base address. + -- qcom,mdss-lm-pgc-off: This 32 bit value provides the offset + to PGC block from the layer mixer base address. + -- qcom,mdss-dspp-gamut-off: This 32 bit value provides the offset + to gamut block from DSPP base address. + -- qcom,mdss-dspp-pgc-off: This 32 bit value provides the offset to + PGC block from the DSPP base address. + +- qcom,mdss-scaler-offsets: A node that lists the offsets of scaler blocks + from base module. + -- qcom,mdss-vig-scaler-off: This 32 bit value provides the + offset to vig scaler from vig pipe base. + -- qcom,mdss-vig-scaler-lut-off: This 32 bit value provides the + offset to vig scaler lut from vig pipe base. + -- qcom,mdss-has-dest-scaler: Boolean property to indicate the + presence of destination scaler block. + -- qcom,mdss-dest-block-off: This 32 bit value provides the + offset from mdp base to destination scaler block. + -- qcom,mdss-dest-scaler-off: Array containing offsets of + destination scalar modules from the scaler block. + -- qcom,mdss-dest-scaler-lut-off: Array containing offsets of destination + scaler lut tables from scalar block. + +- qcom,mdss-has-separate-rotator: Boolean property to indicate support of + indpendent rotator. Indpendent rotator has + separate DMA pipe working in block mode only. + +- smmu_mdp_***: Child nodes representing the mdss smmu virtual devices. + Mandatory smmu v2 and not required for smmu v1. + +Subnode properties: +- compatible : Compatible name used in smmu v2. + smmu_v2 names should be: + "qcom,smmu_mdp_unsec" - smmu context bank device for + unsecure mdp domain. + "qcom,smmu_rot_unsec" - smmu context bank device for + unsecure rotation domain. + "qcom,smmu_mdp_sec" - smmu context bank device for + secure mdp domain. + "qcom,smmu_rot_sec" - smmu context bank device for + secure rotation domain. + "qcom,smmu_arm_mdp_unsec" - arm smmu context bank device for + unsecure mdp domain. + "qcom,smmu_arm_mdp_sec" - arm smmu context bank device for + secure mdp domain. +- gdsc-mmagic-mdss-supply: Phandle for mmagic mdss supply regulator device node. +- reg : offset and length of the register set for the device. +- reg-names : names to refer to register sets related to this device +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. + +Subnode properties: +Required properties: +- compatible: Must be "qcom,mdss_wb" +- qcom,mdss_pan_res: Array containing two elements, width and height which + specifies size of writeback buffer. +- qcom,mdss_pan_bpp: Specifies bits per pixel for writeback buffer. +- qcom,mdss-fb-map: Specifies the handle for frame buffer. + +Example: + mdss_mdp: qcom,mdss_mdp@fd900000 { + compatible = "qcom,mdss_mdp"; + reg = <0xfd900000 0x22100>, + <0xfd924000 0x1000>, + <0xfd925000 0x1000>; + reg-names = "mdp_phys", "vbif_phys", "vbif_nrt_phys"; + interrupts = <0 72 0>; + interrupt-controller; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + vdd-supply = <&gdsc_mdss>; + batfet-supply = <&pm8941_chg_batif>; + vdd-cx-supply = <&pm8841_s2_corner>; + + /* Bus Scale Settings */ + qcom,msm-bus,name = "mdss_mdp"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,num-paths = <2>; + qcom,mdss-dram-channels = <2>; + qcom,mdss-num-nrt-paths = <1>; + qcom,msm-bus,vectors-KBps = + <22 512 0 0>, <23 512 0 0>, + <22 512 0 6400000>, <23 512 0 6400000>, + <22 512 0 6400000>, <23 512 0 6400000>; + + /* Fudge factors */ + qcom,mdss-ab-factor = <2 1>; /* 2 times */ + qcom,mdss-ib-factor = <3 2>; /* 1.5 times */ + qcom,mdss-high-ib-factor = <2 1>; /* 2 times */ + qcom,mdss-clk-factor = <5 4>; /* 1.25 times */ + + /* Clock levels */ + qcom,mdss-clk-levels = <92310000, 177780000, 200000000>; + + /* VBIF QoS remapper settings*/ + qcom,mdss-vbif-qos-rt-setting = <2 2 2 2>; + qcom,mdss-vbif-qos-nrt-setting = <1 1 1 1>; + + qcom,max-bandwidth-low-kbps = <2300000>; + qcom,max-bandwidth-high-kbps = <3000000>; + qcom,max-bandwidth-per-pipe-kbps = <4 2100000>, + <8 1800000>; + qcom,max-bw-settings = <1 2300000>, + <2 1700000>, + <4 2300000>, + <8 2000000>; + + qcom,max-mixer-width = <2048>; + qcom,max-pipe-width = <2048>; + qcom,max-dest-scaler-input-width = <2048>; + qcom,max-dest-scaler-output-width = <2560>; + qcom,max-clk-rate = <320000000>; + qcom,vbif-settings = <0x0004 0x00000001>, + <0x00D8 0x00000707>; + qcom,vbif-nrt-settings = <0x0004 0x00000001>, + <0x00D8 0x00000707>; + qcom,mdp-settings = <0x02E0 0x000000AA>, + <0x02E4 0x00000055>; + qcom,mdss-pipe-vig-off = <0x00001200 0x00001600 + 0x00001A00>; + qcom,mdss-pipe-rgb-off = <0x00001E00 0x00002200 + 0x00002600>; + qcom,mdss-pipe-dma-off = <0x00002A00 0x00002E00>; + qcom,mdss-pipe-cursor-off = <0x00035000 0x00037000>; + qcom,mdss-dsc-off = <0x00081000 0x00081400>; + qcom,mdss-pipe-vig-fetch-id = <1 4 7>; + qcom,mdss-pipe-rgb-fetch-id = <16 17 18>; + qcom,mdss-pipe-dma-fetch-id = <10 13>; + qcom,mdss-pipe-rgb-fixed-mmb = <2 0 1>, + <2 2 3>, + <2 4 5>, + <2 6 7>; + qcom,mdss-pipe-vig-fixed-mmb = <1 8>, + <1 9>, + <1 10>, + <1 11>; + qcom,mdss-smp-data = <22 4096>; + qcom,mdss-rot-block-size = <64>; + qcom,mdss-rotator-ot-limit = <2>; + qcom,mdss-smp-mb-per-pipe = <2>; + qcom,mdss-pref-prim-intf = "dsi"; + qcom,mdss-has-non-scalar-rgb; + qcom,mdss-has-bwc; + qcom,mdss-has-decimation; + qcom,mdss-has-fixed-qos-arbiter-enabled; + qcom,mdss-has-source-split; + qcom,mdss-wfd-mode = "intf"; + qcom,mdss-no-lut-read; + qcom,mdss-no-hist-vote; + qcom,mdss-traffic-shaper-enabled; + qcom,mdss-has-rotator-downscale; + + qcom,mdss-has-pingpong-split; + qcom,mdss-pipe-vig-xin-id = <0 4 8>; + qcom,mdss-pipe-rgb-xin-id = <1 5 9>; + qcom,mdss-pipe-dma-xin-id = <2 10>; + qcom,mdss-pipe-cursor-xin-id = <7 7>; + qcom,mdss-rot-xin-id = <14 15>; + + qcom,mdss-pipe-vig-clk-ctrl-offsets = <0x3AC 0 0>, + <0x3B4 0 0>, + <0x3BC 0 0>, + <0x3C4 0 0>; + + qcom,mdss-pipe-rgb-clk-ctrl-offsets = <0x3AC 4 8>, + <0x3B4 4 8>, + <0x3BC 4 8>, + <0x3C4 4 8>; + + qcom,mdss-pipe-dma-clk-ctrl-offsets = <0x3AC 8 12>, + <0x3B4 8 12>; + + qcom,mdss-per-pipe-panic-luts = <0x000f>, + <0xffff>, + <0xfffc>, + <0xff00>; + + qcom,mdss-has-panic-ctrl; + qcom,mdss-pipe-vig-panic-ctrl-offsets = <0 1 2 3>; + qcom,mdss-pipe-rgb-panic-ctrl-offsets = <4 5 6 7>; + qcom,mdss-pipe-dma-panic-ctrl-offsets = <8 9>; + + qcom,mdss-pipe-sw-reset-off = <0x0128>; + qcom,mdss-pipe-vig-sw-reset-map = <5 6 7 8>; + qcom,mdss-pipe-rgb-sw-reset-map = <9 10 11 12>; + qcom,mdss-pipe-dma-sw-reset-map = <13 14>; + + qcom,mdss-ctl-off = <0x00000600 0x00000700 0x00000800 + 0x00000900 0x0000A00>; + qcom,mdss-mixer-intf-off = <0x00003200 0x00003600 + 0x00003A00>; + qcom,mdss-mixer-wb-off = <0x00003E00 0x00004200>; + qcom,mdss-dspp-off = <0x00004600 0x00004A00 0x00004E00>; + qcom,mdss-pingpong-off = <0x00012D00 0x00012E00 0x00012F00>; + qcom,mdss-wb-off = <0x00011100 0x00013100 0x00015100 + 0x00017100 0x00019100>; + qcom,mdss-intf-off = <0x00021100 0x00021300 + 0x00021500 0x00021700>; + qcom,mdss-cdm-off = <0x0007A200>; + qcom,mdss-ppb-ctl-off = <0x0000420>; + qcom,mdss-ppb-cfg-off = <0x0000424>; + qcom,mdss-slave-pingpong-off = <0x00073000> + + /* buffer parameters to calculate prefill bandwidth */ + qcom,mdss-prefill-outstanding-buffer-bytes = <1024>; + qcom,mdss-prefill-y-buffer-bytes = <4096>; + qcom,mdss-prefill-scaler-buffer-lines-bilinear = <2>; + qcom,mdss-prefill-scaler-buffer-lines-caf = <4>; + qcom,mdss-prefill-post-scaler-buffer-pixels = <2048>; + qcom,mdss-prefill-pingpong-buffer-pixels = <5120>; + qcom,mdss-prefill-fbc-lines = <2>; + qcom,mdss-idle-power-collapse-enabled; + + qcom,regs-dump-xin-id-mdp = <0xff 0xff 0xff 0xff 0x0 0x0>; + mdss_fb0: qcom,mdss_fb_primary { + cell-index = <0>; + compatible = "qcom,mdss-fb"; + qcom,mdss-mixer-swap; + linux,contiguous-region = <&fb_mem>; + qcom,mdss-fb-splash-logo-enabled: + qcom,cont-splash-memory { + linux,contiguous-region = <&cont_splash_mem>; + }; + }; + + qcom,mdss-pp-offsets { + qcom,mdss-sspp-mdss-igc-lut-off = <0x3000>; + qcom,mdss-sspp-vig-pcc-off = <0x1580>; + qcom,mdss-sspp-rgb-pcc-off = <0x180>; + qcom,mdss-sspp-dma-pcc-off = <0x180>; + qcom,mdss-lm-pgc-off = <0x3C0>; + qcom,mdss-dspp-gamut-off = <0x1600>; + qcom,mdss-dspp-pcc-off = <0x1700>; + qcom,mdss-dspp-pgc-off = <0x17C0>; + }; + + qcom,mdss-scaler-offsets { + qcom,mdss-vig-scaler-off = <0xA00>; + qcom,mdss-vig-scaler-lut-off = <0xB00>; + qcom,mdss-has-dest-scaler; + qcom,mdss-dest-block-off = <0x00061000>; + qcom,mdss-dest-scaler-off = <0x800 0x1000>; + qcom,mdss-dest-scaler-lut-off = <0x900 0x1100>; + }; + + qcom,mdss-reg-bus { + /* Reg Bus Scale Settings */ + qcom,msm-bus,name = "mdss_reg"; + qcom,msm-bus,num-cases = <4>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,active-only; + qcom,msm-bus,vectors-KBps = + <1 590 0 0>, + <1 590 0 76800>, + <1 590 0 160000>, + <1 590 0 320000>; + }; + + qcom,mdss-hw-rt { + /* hw-rt Bus Scale Settings */ + qcom,msm-bus,name = "mdss_hw_rt"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <22 512 0 0>, + <22 512 0 1000>; + }; + + smmu_mdp_sec: qcom,smmu_mdp_sec_cb { + compatible = "qcom,smmu_mdp_sec"; + iommus = <&mdp_smmu 1>; + reg = <0xd09000 0x000d00>, + reg-names = "mmu_cb"; + gdsc-mmagic-mdss-supply = <&gdsc_mmagic_mdss>; + clocks = <&clock_mmss clk_smmu_mdp_ahb_clk>, + <&clock_mmss clk_smmu_mdp_axi_clk>; + clock-names = "dummy_clk", "dummy_clk"; + }; + + qcom,mdss-rot-reg-bus { + /* Reg Bus Scale Settings */ + qcom,msm-bus,name = "mdss_rot_reg"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,active-only; + qcom,msm-bus,vectors-KBps = + <1 590 0 0>, + <1 590 0 76800>; + }; + }; + diff --git a/Documentation/devicetree/bindings/fb/mdss-pll.txt b/Documentation/devicetree/bindings/fb/mdss-pll.txt new file mode 100644 index 000000000000..2e9d2dae51a2 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-pll.txt @@ -0,0 +1,104 @@ +Qualcomm MDSS pll for DSI/EDP/HDMI + +mdss-pll is a pll controller device which supports pll devices that +are compatable with MIPI display serial interface specification, +HDMI and edp. + +Required properties: +- compatible: Compatible name used in the driver. Should be one of: + "qcom,mdss_dsi_pll_8916", "qcom,mdss_dsi_pll_8939", + "qcom,mdss_dsi_pll_8974", "qcom,mdss_dsi_pll_8994", + "qcom,mdss_dsi_pll_8994", "qcom,mdss_dsi_pll_8909", + "qcom,mdss_hdmi_pll", "qcom,mdss_hdmi_pll_8994", + "qcom,mdss_dsi_pll_8992", "qcom,mdss_hdmi_pll_8992", + "qcom,mdss_dsi_pll_8996", "qcom,mdss_hdmi_pll_8996", + "qcom,mdss_hdmi_pll_8996_v2", "qcom,mdss_dsi_pll_8996_v2", + "qcom,mdss_hdmi_pll_8996_v3", "qcom,mdss_hdmi_pll_8996_v3_1p8", + "qcom,mdss_dsi_pll_8998", "qcom,mdss_dp_pll_8998", + "qcom,mdss_hdmi_pll_8998", "qcom,mdss_dsi_pll_sdm660", + "qcom,mdss_dp_pll_sdm660", "qcom,mdss_dsi_pll_sdm630", + "qcom,mdss_dp_pll_sdm630" +- cell-index: Specifies the controller used +- reg: offset and length of the register set for the device. +- reg-names : names to refer to register sets related to this device +- gdsc-supply: Phandle for gdsc regulator device node. +- vddio-supply: Phandle for vddio regulator device node. +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. +- clock-rate: List of clock rates in Hz. + +Optional properties: +- label: A string used to describe the driver used. +- vcca-supply: Phandle for vcca regulator device node. + + +- qcom,dsi-pll-ssc-en: Boolean property to indicate that ssc is enabled. +- qcom,dsi-pll-ssc-mode: Spread-spectrum clocking. It can be either "down-spread" + or "center-spread". Default is "down-spread" if it is not specified. +- qcom,ssc-frequency-hz: Integer property to specify the spread frequency + to be programmed for the SSC. +- qcom,ssc-ppm: Integer property to specify the Parts per Million + value of SSC. + +- qcom,platform-supply-entries: A node that lists the elements of the supply. There + can be more than one instance of this binding, + in which case the entry would be appended with + the supply entry index. + e.g. qcom,platform-supply-entry@0 + - reg: offset and length of the register set for the device. + -- qcom,supply-name: name of the supply (vdd/vdda/vddio) + -- qcom,supply-min-voltage: minimum voltage level (uV) + -- qcom,supply-max-voltage: maximum voltage level (uV) + -- qcom,supply-enable-load: load drawn (uA) from enabled supply + -- qcom,supply-disable-load: load drawn (uA) from disabled supply + -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on + -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on + -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off + -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off + +Example: + mdss_dsi0_pll: qcom,mdss_dsi_pll@fd922A00 { + compatible = "qcom,mdss_dsi_pll_8974"; + label = "MDSS DSI 0 PLL"; + cell-index = <0>; + + reg = <0xfd922A00 0xD4>, + <0xfd922900 0x64>, + <0xfd8c2300 0x8>; + reg-names = "pll_base", "dynamic_pll_base", "gdsc_base"; + gdsc-supply = <&gdsc_mdss>; + vddio-supply = <&pm8941_l12>; + vcca-supply = <&pm8941_l28>; + + clocks = <&clock_gcc clk_gcc_mdss_mdp_clk>, + <&clock_gcc clk_gcc_mdss_ahb_clk>, + <&clock_gcc clk_gcc_mdss_axi_clk>; + clock-names = "mdp_core_clk", "iface_clk", "bus_clk"; + clock-rate = <0>, <0>, <0>; + + qcom,dsi-pll-slave; + qcom,dsi-pll-ssc-en; + qcom,dsi-pll-ssc-mode = "down-spread"; + qcom,ssc-frequency-hz = <30000>; + qcom,ssc-ppm = <5000>; + + qcom,platform-supply-entries { + #address-cells = <1>; + #size-cells = <0>; + + qcom,platform-supply-entry@0 { + reg = <0>; + qcom,supply-name = "vddio"; + qcom,supply-min-voltage = <1800000>; + qcom,supply-max-voltage = <1800000>; + qcom,supply-enable-load = <100000>; + qcom,supply-disable-load = <100>; + qcom,supply-pre-on-sleep = <0>; + qcom,supply-post-on-sleep = <20>; + qcom,supply-pre-off-sleep = <0>; + qcom,supply-post-off-sleep = <0>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/fb/mdss-rotator.txt b/Documentation/devicetree/bindings/fb/mdss-rotator.txt new file mode 100644 index 000000000000..5e077ac23819 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mdss-rotator.txt @@ -0,0 +1,78 @@ +QTI MDSS Rotator + +MDSS rotator is a rotator driver, which manages the rotator hw +block inside the Mobile Display Subsystem. + +Required properties +- compatible : Must be "qcom,mdss-rotator". +- qcom,mdss-wb-count: The number of writeback block + in the hardware +- <name>-supply: Phandle for <name> regulator device node. + +Bus Scaling Data: +- qcom,msm-bus,name: String property describing MDSS client. +- qcom,msm-bus,num-cases: This is the the number of Bus Scaling use cases + defined in the vectors property. This must be + set to <3> for MDSS driver where use-case 0 is + used to take off MDSS BW votes from the system. + And use-case 1 & 2 are used in ping-pong fashion + to generate run-time BW requests. +- qcom,msm-bus,num-paths: This represents the number of paths in each + Bus Scaling Usecase. This value depends on + how many number of AXI master ports are + dedicated to MDSS for particular chipset. +- qcom,msm-bus,vectors-KBps: * A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt + * Current values of src & dst are defined at + include/linux/msm-bus-board.h + src values allowed for MDSS are: + 22 = MSM_BUS_MASTER_MDP_PORT0 + 23 = MSM_BUS_MASTER_MDP_PORT1 + 25 = MSM_BUS_MASTER_ROTATOR + dst values allowed for MDSS are: + 512 = MSM_BUS_SLAVE_EBI_CH0 + ab: Represents aggregated bandwidth. + ib: Represents instantaneous bandwidth. + * Total number of 4 cell properties will be + (number of use-cases * number of paths). + * These values will be overridden by the driver + based on the run-time requirements. So initial + ab and ib values defined here are random and + bare no logic except for the use-case 0 where ab + and ib values needs to be 0. + * Define realtime vector properties followed by + non-realtime vector properties. + +Optional properties +- qcom,mdss-has-reg-bus: Boolean property to indicate + if rotator needs to vote for register bus. This + property is needed starting 8996 +- qcom,mdss-has-ubwc: Boolean property to indicate + if the hw supports universal + bandwidth compression (ubwc) +- qcom,mdss-has-downscale Boolean property to indicate + if the hw supports downscale + +Example: + mdss_rotator: qcom,mdss_rotator { + compatible = "qcom,mdss_rotator"; + qcom,mdss-has-downscale; + qcom,mdss-has-ubwc; + qcom,mdss-wb-count = <2>; + + qcom,mdss-has-reg-bus; + /* Bus Scale Settings */ + qcom,msm-bus,name = "mdss_rotator"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,num-paths = <1>; + qcom,mdss-num-nrt-paths = <1>; + qcom,msm-bus,vectors-KBps = + <25 512 0 0>, + <25 512 0 6400000>, + <25 512 0 6400000>; + + vdd-supply = <&gdsc_mdss>; + gdsc-mmagic-mdss-supply = <&gdsc_mmagic_mdss>; + qcom,supply-names = "vdd", "gdsc-mmagic-mdss"; + }; diff --git a/Documentation/devicetree/bindings/fb/msm-hdmi-tx.txt b/Documentation/devicetree/bindings/fb/msm-hdmi-tx.txt new file mode 100644 index 000000000000..628b4df9fd7d --- /dev/null +++ b/Documentation/devicetree/bindings/fb/msm-hdmi-tx.txt @@ -0,0 +1,131 @@ +* Qualcomm HDMI Tx + +Required properties: +- cell-index: hdmi tx controller index +- compatible: must be "qcom,hdmi-tx" +- reg: offset and length of the register regions(s) for the device. +- reg-names: a list of strings that map in order to the list of regs. + +- hpd-gdsc-supply: phandle to the mdss gdsc regulator device tree node. +- hpd-5v-supply: phandle to the 5V regulator device tree node. +- core-vdda-supply: phandle to the HDMI vdda regulator device tree node. +- core-vcc-supply: phandle to the HDMI vcc regulator device tree node. +- qcom,supply-names: a list of strings that map in order + to the list of supplies. +- qcom,min-voltage-level: specifies minimum voltage (uV) level + of supply(ies) mentioned above. +- qcom,max-voltage-level: specifies maximum voltage (uV) level + of supply(ies) mentioned above. +- qcom,enable-load: specifies the current (uA) that will be + drawn from the enabled supply(ies) mentioned above. +- qcom,disable-load: specifies the current (uA) that will be + drawn from the disabled supply(ies) mentioned above. + +- qcom,hdmi-tx-cec: gpio for Consumer Electronics Control (cec) line. +- qcom,hdmi-tx-ddc-clk: gpio for Display Data Channel (ddc) clock line. +- qcom,hdmi-tx-ddc-data: gpio for ddc data line. + +Optional properties: +- hpd-5v-en-supply: phandle to the 5V boost enable regulator device tree node. +- qcom,hdmi-tx-mux-sel: gpio required to toggle HDMI output between + docking station, type A, and liquid device, type D, ports. Required + property for liquid devices. +- qcom,hdmi-tx-ddc-mux-sel: gpio for ddc mux select. +- qcom,hdmi-tx-mux-en: gpio required to enable mux for HDMI output + on liquid devices. Required property for liquid devices. +- qcom,hdmi-tx-mux-lpm: gpio required for hdmi mux configuration + selection on liquid devices. Required property for liquid devices. +- qcom,conditional-power-on: Enables HPD conditionally on MTP targets. + Required property for MTP devices which are reworked to expose HDMI port. +- qcom,hdmi-tx-hpd: gpio required for HDMI hot-plug detect. Required on + platforms where companion chip is not used. +- pinctrl-names: a list of strings that map to the pinctrl states. +- pinctrl-0: list of phandles, each pointing at a pin configuration node. +... +- pinctrl-n: list of phandles, each pointing at a pin configuration node. +- qcom,conti-splash-enabled: Enables the hdmi continuous splash screen feature. + HDMI interface will remain powered on from LK to kernel with continuous + display of bootup logo. +- qcom,pluggable: boolean to enable hotplug feature. +- qcom,display-id: A string indicates the display ID for the controller. + The possible values are: + - "primary" + - "secondary" + - "tertiary" + +msm_ext_disp is a device which manages the interaction between external +displays (HDMI and Display Port) and the audio and display frameworks. + +Required properties: +- compatible: Must be "qcom,msm-ext-disp" + +[Required child nodes]: These nodes are for devices which are +dependent on msm_ext_disp. If msm_ext_disp is disabled then +these devices will be disabled as well. Ex. Audio Codec device. + +- ext_disp_audio_codec: Node for Audio Codec. + +Required properties: +- compatible : "qcom,msm-ext-disp-audio-codec-rx"; + +Example: + msm_ext_disp: qcom,msm_ext_disp { + compatible = "qcom,msm-ext-disp"; + + ext_disp_audio_codec: qcom,msm-ext-disp-audio-codec-rx { + compatible = "qcom,msm-ext-disp-audio-codec-rx"; + qcom,msm_ext_disp = <&msm_ext_disp>; + }; + }; + + mdss_hdmi_tx: qcom,hdmi_tx@fd922100 { + cell-index = <0>; + compatible = "qcom,hdmi-tx"; + reg = <0xfd922100 0x35C>, + <0xfd922500 0x7C>, + <0xfc4b8000 0x60F0>, + <0xfe2a0000 0xFFF>; + reg-names = "core_physical", "phy_physical", "qfprom_physical", + "hdcp_physical"; + + hpd-gdsc-supply = <&gdsc_mdss>; + hpd-5v-supply = <&pm8941_mvs2>; + hpd-5v-en-supply = <&hdmi_vreg>; + core-vdda-supply = <&pm8941_l12>; + core-vcc-supply = <&pm8941_s3>; + qcom,supply-names = "hpd-gdsc", "hpd-5v", "hpd-5v-en", "core-vdda", "core-vcc"; + qcom,min-voltage-level = <0 0 0 1800000 1800000>; + qcom,max-voltage-level = <0 0 0 1800000 1800000>; + qcom,enable-load = <0 0 0 1800000 0>; + qcom,disable-load = <0 0 0 0 0>; + + qcom,msm_ext_disp = <&msm_ext_disp>; + + qcom,hdmi-tx-ddc-mux-sel = <&pma8084_gpios 6 0>; + qcom,hdmi-tx-cec = <&msmgpio 31 0>; + qcom,hdmi-tx-ddc-clk = <&msmgpio 32 0>; + qcom,hdmi-tx-ddc-data = <&msmgpio 33 0>; + qcom,hdmi-tx-hpd = <&msmgpio 34 0>; + + qcom,hdmi-tx-mux-lpm = <&msmgpio 27 0>; + qcom,hdmi-tx-mux-en = <&msmgpio 83 0>; + qcom,hdmi-tx-mux-sel = <&msmgpio 85 0>; + + qcom,conditional-power-on; + qcom,pluggable; + qcom,display-id = "secondary"; + + pinctrl-names = "hdmi_hpd_active", "hdmi_ddc_active", + "hdmi_cec_active", "hdmi_active", + "hdmi_sleep"; + pinctrl-0 = <&mdss_hdmi_hpd_active &mdss_hdmi_ddc_suspend + &mdss_hdmi_cec_suspend>; + pinctrl-1 = <&mdss_hdmi_hpd_active &mdss_hdmi_ddc_active + &mdss_hdmi_cec_suspend>; + pinctrl-2 = <&mdss_hdmi_hpd_active &mdss_hdmi_cec_active + &mdss_hdmi_ddc_suspend>; + pinctrl-3 = <&mdss_hdmi_hpd_active &mdss_hdmi_ddc_active + &mdss_hdmi_cec_active>; + pinctrl-4 = <&mdss_hdmi_hpd_suspend &mdss_hdmi_ddc_suspend + &mdss_hdmi_cec_suspend>; + }; diff --git a/Documentation/devicetree/bindings/goldfish/audio.txt b/Documentation/devicetree/bindings/goldfish/audio.txt new file mode 100644 index 000000000000..d043fda433ba --- /dev/null +++ b/Documentation/devicetree/bindings/goldfish/audio.txt @@ -0,0 +1,17 @@ +Android Goldfish Audio + +Android goldfish audio device generated by android emulator. + +Required properties: + +- compatible : should contain "google,goldfish-audio" to match emulator +- reg : <registers mapping> +- interrupts : <interrupt mapping> + +Example: + + goldfish_audio@9030000 { + compatible = "google,goldfish-audio"; + reg = <0x9030000 0x100>; + interrupts = <0x4>; + }; diff --git a/Documentation/devicetree/bindings/goldfish/battery.txt b/Documentation/devicetree/bindings/goldfish/battery.txt new file mode 100644 index 000000000000..4fb613933214 --- /dev/null +++ b/Documentation/devicetree/bindings/goldfish/battery.txt @@ -0,0 +1,17 @@ +Android Goldfish Battery + +Android goldfish battery device generated by android emulator. + +Required properties: + +- compatible : should contain "google,goldfish-battery" to match emulator +- reg : <registers mapping> +- interrupts : <interrupt mapping> + +Example: + + goldfish_battery@9020000 { + compatible = "google,goldfish-battery"; + reg = <0x9020000 0x1000>; + interrupts = <0x3>; + }; diff --git a/Documentation/devicetree/bindings/goldfish/events.txt b/Documentation/devicetree/bindings/goldfish/events.txt new file mode 100644 index 000000000000..5babf46317a4 --- /dev/null +++ b/Documentation/devicetree/bindings/goldfish/events.txt @@ -0,0 +1,17 @@ +Android Goldfish Events Keypad + +Android goldfish events keypad device generated by android emulator. + +Required properties: + +- compatible : should contain "google,goldfish-events-keypad" to match emulator +- reg : <registers mapping> +- interrupts : <interrupt mapping> + +Example: + + goldfish-events@9040000 { + compatible = "google,goldfish-events-keypad"; + reg = <0x9040000 0x1000>; + interrupts = <0x5>; + }; diff --git a/Documentation/devicetree/bindings/goldfish/tty.txt b/Documentation/devicetree/bindings/goldfish/tty.txt new file mode 100644 index 000000000000..82648278da77 --- /dev/null +++ b/Documentation/devicetree/bindings/goldfish/tty.txt @@ -0,0 +1,17 @@ +Android Goldfish TTY + +Android goldfish tty device generated by android emulator. + +Required properties: + +- compatible : should contain "google,goldfish-tty" to match emulator +- reg : <registers mapping> +- interrupts : <interrupt mapping> + +Example: + + goldfish_tty@1f004000 { + compatible = "google,goldfish-tty"; + reg = <0x1f004000 0x1000>; + interrupts = <0xc>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-smp2p.txt b/Documentation/devicetree/bindings/gpio/gpio-smp2p.txt new file mode 100644 index 000000000000..7f5f939afa2d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-smp2p.txt @@ -0,0 +1,95 @@ +Qualcomm SMSM Point-to-Point (SMP2P) GPIO Driver + +Used to map an SMP2P entry and remote processor ID to a virtual GPIO controller +and virtual interrupt controller. + +Required properties: +-compatible : should be "qcom,smp2pgpio"; +-qcom,entry-name : name of the SMP2P entry +-qcom,remote-pid : the SMP2P remote processor ID (see smp2p_private_api.h) +-gpio-controller : specifies that this is a GPIO controller +-#gpio-cells : number of GPIO cells (should always be <2>) +-interrupt-controller : specifies that this is an interrupt controller +-#interrupt-cells : number of interrupt cells (should always be <2>) + +Optional properties: +-qcom,is-inbound : specifies that this is an inbound entry (default is outbound) + +Comments: +All device tree entries must be unique. Therefore to prevent naming collisions +between clients, it is recommended that the DT nodes should be named using the +format: + smp2pgpio_<ENTRY_NAME>_<REMOTE PID>_<in|out> + +Unit test devices ("smp2p" entries): +-compatible : should be one of + "qcom,smp2pgpio_test_smp2p_1_out" + "qcom,smp2pgpio_test_smp2p_1_in" + "qcom,smp2pgpio_test_smp2p_2_out" + "qcom,smp2pgpio_test_smp2p_2_in" + "qcom,smp2pgpio_test_smp2p_3_out" + "qcom,smp2pgpio_test_smp2p_3_in" + "qcom,smp2pgpio_test_smp2p_4_out" + "qcom,smp2pgpio_test_smp2p_4_in" + "qcom,smp2pgpio_test_smp2p_5_out" + "qcom,smp2pgpio_test_smp2p_5_in" + "qcom,smp2pgpio_test_smp2p_7_out" + "qcom,smp2pgpio_test_smp2p_7_in" + "qcom,smp2pgpio_test_smp2p_15_out" + "qcom,smp2pgpio_test_smp2p_15_in" +-gpios : the relevant gpio pins of the entry + +Example: + /* Maps inbound "smp2p" entry on remote PID 7 to GPIO controller. */ + smp2pgpio_smp2p_7_in: qcom,smp2pgpio-smp2p-7-in { + compatible = "qcom,smp2pgpio"; + qcom,entry-name = "smp2p"; + qcom,remote-pid = <7>; + qcom,is-inbound; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* + * Maps inbound "smp2p" entry on remote PID 7 to client driver + * "qcom,smp2pgpio_test_smp2p_7_in". + * + * Note: If all 32-pins are used by this client, then you + * can just list pin 0 here as a shortcut. + */ + qcom,smp2pgpio_test_smp2p_7_in { + compatible = "qcom,smp2pgpio_test_smp2p_7_in"; + gpios = <&smp2pgpio_smp2p_7_in 0 0>, /* pin 0 */ + <&smp2pgpio_smp2p_7_in 1 0>, + . . . + <&smp2pgpio_smp2p_7_in 31 0>; /* pin 31 */ + }; + + + /* Maps outbound "smp2p" entry on remote PID 7 to GPIO controller. */ + smp2pgpio_smp2p_7_out: qcom,smp2pgpio-smp2p-7-out { + compatible = "qcom,smp2pgpio"; + qcom,entry-name = "smp2p"; + qcom,remote-pid = <7>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* + * Maps outbound "smp2p" entry on remote PID 7 to client driver + * "qcom,smp2pgpio_test_smp2p_7_out". + * + * Note: If all 32-pins are used by this client, then you + * can just list pin 0 here as a shortcut. + */ + qcom,smp2pgpio_test_smp2p_7_out { + compatible = "qcom,smp2pgpio_test_smp2p_7_out"; + gpios = <&smp2pgpio_smp2p_7_out 0 0>, /* pin 0 */ + <&smp2pgpio_smp2p_7_out 1 0>, + . . . + <&smp2pgpio_smp2p_7_out 31 0>; /* pin 31 */ + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio_keys.txt b/Documentation/devicetree/bindings/gpio/gpio_keys.txt new file mode 100644 index 000000000000..0a9b31a946ec --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_keys.txt @@ -0,0 +1,49 @@ +Device-Tree bindings for input/gpio_keys.c keyboard driver + +Required properties: + - compatible = "gpio-keys"; + +Optional properties: + - input-name: input name of the device. + - autorepeat: Boolean, Enable auto repeat feature of Linux input subsystem. + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + It should specify the names of the configs that pinctrl can install in drive. + + Following are the pinctrl configs that can be installed: + "gpio_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt and reset gpio. + "gpio_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt and reset gpio. + +Each button (key) is represented as a sub-node of "gpio-keys": +Subnode properties: + + - gpios: OF device-tree gpio specification. + - label: Descriptive name of the key. + - linux,code: Keycode to emit. + +Optional subnode-properties: + - linux,input-type: Specify event type this button/key generates. + If not specified defaults to <1> == EV_KEY. + - debounce-interval: Debouncing interval time in milliseconds. + If not specified defaults to 5. + - gpio-key,wakeup: Boolean, button can wake-up the system. + +Example nodes: + +gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + autorepeat; + input-name = "gpio-keys"; + pinctrl-names = "tlmm_gpio_key_active","tlmm_gpio_key_suspend"; + pinctrl-0 = <&gpio_key_active>; + pinctrl-1 = <&gpio_key_suspend>; + button@21 { + label = "GPIO Key UP"; + linux,code = <103>; + gpios = <&gpio1 0 1>; + }; +}; diff --git a/Documentation/devicetree/bindings/gpio/qpnp-pin.txt b/Documentation/devicetree/bindings/gpio/qpnp-pin.txt new file mode 100644 index 000000000000..0f61ae72f766 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/qpnp-pin.txt @@ -0,0 +1,220 @@ +* msm-qpnp-pin + +msm-qpnp-pin is a GPIO chip driver for the MSM SPMI implementation. +It creates a platform_device for every block of device_nodes. +These device_nodes contained within specify the PMIC pin number associated +with each gpio chip. The driver will map these to Linux GPIO numbers. + +[PMIC GPIO Device Declarations] + +-Root Node- + +Required properties : + - gpio-controller : Specify as gpio-contoller. All child nodes will belong to + this gpio_chip. + - #gpio-cells: We encode a PMIC pin number and a 32-bit flag field to + specify the gpio configuration. This must be set to '2'. + - #address-cells: Specify one address field. This must be set to '1'. + - #size-cells: Specify one size-cell. This must be set to '1'. + - compatible = "qcom,qpnp-pin" : Specify driver matching for this driver. + - label: String giving the name for the gpio_chip device. This name + should be unique on the system and portray the specifics of the device. + +-Child Nodes- + +Required properties : + - reg : Specify the spmi offset and size for this pin device. + - qcom,pin-num : Specify the PMIC pin number for this device. + +Optional configuration properties : + - qcom,mode: indicates whether the pin should be input, output, or + both for gpios. mpp pins also support bidirectional, + analog in, analog out and current sink. + QPNP_PIN_MODE_DIG_IN = 0, (GPIO/MPP) + QPNP_PIN_MODE_DIG_OUT = 1, (GPIO/MPP) + QPNP_PIN_MODE_DIG_IN_OUT = 2, (GPIO/MPP) + QPNP_PIN_MODE_ANA_PASS_THRU = 3, (GPIO_LV/GPIO_MV) + QPNP_PIN_MODE_BIDIR = 3, (MPP) + QPNP_PIN_MODE_AIN = 4, (MPP) + QPNP_PIN_MODE_AOUT = 5, (MPP) + QPNP_PIN_MODE_SINK = 6 (MPP) + + - qcom,output-type: indicates gpio should be configured as CMOS or open + drain. + QPNP_PIN_OUT_BUF_CMOS = 0, (GPIO) + QPNP_PIN_OUT_BUF_OPEN_DRAIN_NMOS = 1, (GPIO) + QPNP_PIN_OUT_BUF_OPEN_DRAIN_PMOS = 2 (GPIO) + QPNP_PIN_OUT_BUF_NO_DRIVE = 3, (GPIO_LV/GPIO_MV) + + - qcom,invert: Invert the signal of the gpio line - + QPNP_PIN_INVERT_DISABLE = 0 (GPIO/MPP) + QPNP_PIN_INVERT_ENABLE = 1 (GPIO/MPP) + + - qcom,pull: This parameter should be programmed to different values + depending on whether it's GPIO or MPP. + For GPIO, it indicates whether a pull up or pull down + should be applied. If a pullup is required the + current strength needs to be specified. + Current values of 30uA, 1.5uA, 31.5uA, 1.5uA with 30uA + boost are supported. This value should be one of + the QPNP_PIN_GPIO_PULL_*. Note that the hardware ignores + this configuration if the GPIO is not set to input or + output open-drain mode. + QPNP_PIN_PULL_UP_30 = 0, (GPIO) + QPNP_PIN_PULL_UP_1P5 = 1, (GPIO) + QPNP_PIN_PULL_UP_31P5 = 2, (GPIO) + QPNP_PIN_PULL_UP_1P5_30 = 3, (GPIO) + QPNP_PIN_PULL_DN = 4, (GPIO) + QPNP_PIN_PULL_NO = 5 (GPIO) + + For MPP, it indicates whether a pullup should be + applied for bidirectitional mode only. The hardware + ignores the configuration when operating in other modes. + This value should be one of the QPNP_PIN_MPP_PULL_*. + + QPNP_PIN_MPP_PULL_UP_0P6KOHM = 0, (MPP) + QPNP_PIN_MPP_PULL_UP_OPEN = 1 (MPP) + QPNP_PIN_MPP_PULL_UP_10KOHM = 2, (MPP) + QPNP_PIN_MPP_PULL_UP_30KOHM = 3, (MPP) + + - qcom,vin-sel: specifies the voltage level when the output is set to 1. + For an input gpio specifies the voltage level at which + the input is interpreted as a logical 1. + QPNP_PIN_VIN0 = 0, (GPIO/MPP/GPIO_LV/GPIO_MV) + QPNP_PIN_VIN1 = 1, (GPIO/MPP/GPIO_MV) + QPNP_PIN_VIN2 = 2, (GPIO/MPP) + QPNP_PIN_VIN3 = 3, (GPIO/MPP) + QPNP_PIN_VIN4 = 4, (GPIO/MPP) + QPNP_PIN_VIN5 = 5, (GPIO/MPP) + QPNP_PIN_VIN6 = 6, (GPIO/MPP) + QPNP_PIN_VIN7 = 7 (GPIO/MPP) + + - qcom,out-strength: the amount of current supplied for an output gpio. + QPNP_PIN_OUT_STRENGTH_LOW = 1 (GPIO) + QPNP_PIN_OUT_STRENGTH_MED = 2, (GPIO) + QPNP_PIN_OUT_STRENGTH_HIGH = 3, (GPIO) + + - qcom,dtest-sel Route the pin internally to a DTEST line. + QPNP_PIN_DIG_IN_CTL_DTEST1 = 1 (GPIO/MPP) + QPNP_PIN_DIG_IN_CTL_DTEST2 = 2, (GPIO/MPP) + QPNP_PIN_DIG_IN_CTL_DTEST3 = 3, (GPIO/MPP) + QPNP_PIN_DIG_IN_CTL_DTEST4 = 4, (GPIO/MPP) + + - qcom,src-sel: select a function for the pin. Certain pins + can be paired (shorted) with each other. Some gpio pins + can act as alternate functions. + In the context of gpio, this acts as a source select. + For mpps, this is an enable select. + QPNP_PIN_SEL_FUNC_CONSTANT = 0, (GPIO/MPP) + QPNP_PIN_SEL_FUNC_PAIRED = 1, (GPIO/MPP) + QPNP_PIN_SEL_FUNC_1 = 2, (GPIO/MPP) + QPNP_PIN_SEL_FUNC_2 = 3, (GPIO/MPP) + QPNP_PIN_SEL_DTEST1 = 4, (GPIO/MPP) + QPNP_PIN_SEL_DTEST2 = 5, (GPIO/MPP) + QPNP_PIN_SEL_DTEST3 = 6, (GPIO/MPP) + QPNP_PIN_SEL_DTEST4 = 7 (GPIO/MPP) + + Below are the source-select values for GPIO_LV/MV. + QPNP_PIN_LV_MV_SEL_FUNC_CONSTANT = 0, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_FUNC_PAIRED = 1, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_FUNC_1 = 2, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_FUNC_2 = 3, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_FUNC_3 = 4, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_FUNC_4 = 5, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_DTEST1 = 6 (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_DTEST2 = 7, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_DTEST3 = 8, (GPIO_LV/GPIO_MV) + QPNP_PIN_LV_MV_SEL_DTEST4 = 9, (GPIO_LV/GPIO_MV) + + - qcom,master-en: 1 = Enable features within the + pin block based on configurations. (GPIO/MPP) + 0 = Completely disable the block and + let the pin float with high impedance + regardless of other settings. (GPIO/MPP) + - qcom,aout-ref: set the analog output reference. + + QPNP_PIN_AOUT_1V25 = 0, (MPP) + QPNP_PIN_AOUT_0V625 = 1, (MPP) + QPNP_PIN_AOUT_0V3125 = 2, (MPP) + QPNP_PIN_AOUT_MPP = 3, (MPP) + QPNP_PIN_AOUT_ABUS1 = 4, (MPP) + QPNP_PIN_AOUT_ABUS2 = 5, (MPP) + QPNP_PIN_AOUT_ABUS3 = 6, (MPP) + QPNP_PIN_AOUT_ABUS4 = 7 (MPP) + + - qcom,ain-route: Set the destination for analog input. + QPNP_PIN_AIN_AMUX_CH5 = 0, (MPP) + QPNP_PIN_AIN_AMUX_CH6 = 1, (MPP) + QPNP_PIN_AIN_AMUX_CH7 = 2, (MPP) + QPNP_PIN_AIN_AMUX_CH8 = 3, (MPP) + QPNP_PIN_AIN_AMUX_ABUS1 = 4, (MPP) + QPNP_PIN_AIN_AMUX_ABUS2 = 5, (MPP) + QPNP_PIN_AIN_AMUX_ABUS3 = 6, (MPP) + QPNP_PIN_AIN_AMUX_ABUS4 = 7 (MPP) + + - qcom,cs-out: Set the the amount of output to sync in mA. + QPNP_PIN_CS_OUT_5MA = 0, (MPP) + QPNP_PIN_CS_OUT_10MA = 1, (MPP) + QPNP_PIN_CS_OUT_15MA = 2, (MPP) + QPNP_PIN_CS_OUT_20MA = 3, (MPP) + QPNP_PIN_CS_OUT_25MA = 4, (MPP) + QPNP_PIN_CS_OUT_30MA = 5, (MPP) + QPNP_PIN_CS_OUT_35MA = 6, (MPP) + QPNP_PIN_CS_OUT_40MA = 7 (MPP) + + - qcom,apass-sel: Set the ATEST channel to route the signal + QPNP_PIN_APASS_SEL_ATEST1 = 0, (GPIO_LV/GPIO_MV) + QPNP_PIN_APASS_SEL_ATEST2 = 1, (GPIO_LV/GPIO_MV) + QPNP_PIN_APASS_SEL_ATEST3 = 2, (GPIO_LV/GPIO_MV) + QPNP_PIN_APASS_SEL_ATEST4 = 3, (GPIO_LV/GPIO_MV) + +*Note: If any of the configuration properties are not specified, then the + qpnp-pin driver will not modify that respective configuration in + hardware. + +[PMIC GPIO clients] + +Required properties : + - gpios : Contains 3 fields of the form <&gpio_controller pmic_pin_num flags> + +[Example] + +qpnp: qcom,spmi@fc4c0000 { + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <3>; + + qcom,pm8941@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <1>; + + pm8941_gpios: gpios { + compatible = "qcom,qpnp-pin"; + gpio-controller; + #gpio-cells = <2>; + #address-cells = <1>; + #size-cells = <1>; + + gpio@c000 { + reg = <0xc000 0x100>; + qcom,pin-num = <62>; + }; + + gpio@c100 { + reg = <0xc100 0x100>; + qcom,pin-num = <20>; + qcom,source_sel = <2>; + qcom,pull = <5>; + }; + }; + + qcom,testgpio@1000 { + compatible = "qcom,qpnp-testgpio"; + reg = <0x1000 0x1000>; + gpios = <&pm8941_gpios 62 0x0 &pm8941_gpios 20 0x1>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/gpu/adreno-busmon.txt b/Documentation/devicetree/bindings/gpu/adreno-busmon.txt new file mode 100644 index 000000000000..7bf2fe8274d0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/adreno-busmon.txt @@ -0,0 +1,16 @@ +Adreno bus monitor device + +kgsl-busmon is a psedo device that represents a devfreq bus bandwidth +governor. If this device is present then two different governors are used +for GPU DCVS and bus DCVS. + +Required properties: +- compatible: Must be "qcom,kgsl-busmon" +- label: Device name used for sysfs entry. + +Example: + + qcom,kgsl-busmon { + compatible = "qcom,kgsl-busmon"; + label = "kgsl-busmon"; + }; diff --git a/Documentation/devicetree/bindings/gpu/adreno-iommu.txt b/Documentation/devicetree/bindings/gpu/adreno-iommu.txt new file mode 100644 index 000000000000..b399145ea8a2 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/adreno-iommu.txt @@ -0,0 +1,86 @@ +Qualcomm Technologies, Inc. GPU IOMMU + +Required properties: + +Required properties: +- compatible : one of: + - "qcom,kgsl-smmu-v1" + - "qcom,kgsl-smmu-v2" + +- reg : Base address and size of the SMMU. + +- clocks : List of clocks to be used during SMMU register access. See + Documentation/devicetree/bindings/clock/clock-bindings.txt + for information about the format. For each clock specified + here, there must be a corresponding entry in clock-names + (see below). + +- clock-names : List of clock names corresponding to the clocks specified in + the "clocks" property (above). See + Documentation/devicetree/bindings/clock/clock-bindings.txt + for more info. +- qcom,protect : The GPU register region which must be protected by a CP + protected mode. On some targets this region must cover + the entire SMMU register space, on others there + is a separate aperture for CP to program context banks. + +Optional properties: +- qcom,micro-mmu-control : Some targets provide an implementation defined + register for blocking translation requests during GPU side + programming. This property specifies the offset of this + register within the iommu register space. +- qcom,retention : A boolean specifying if retention is supported on this target +- qcom,global_pt : A boolean specifying if global pagetable should be used. + When not set we use per process pagetables +- qcom,hyp_secure_alloc : A bool specifying if the hypervisor is used on this target + for secure buffer allocation +- qcom,secure_align_mask: A mask for determining how secure buffers need to + be aligned + +- List of sub nodes, one for each of the translation context banks supported. + The driver uses the names of these nodes to determine how they are used, + currently supported names are: + - gfx3d_user : Used for the 'normal' GPU address space. + - gfx3d_secure : Used for the content protection address space. + Each sub node has the following required properties: + + - compatible : "qcom,smmu-kgsl-cb" + - iommus : Specifies the SID's used by this context bank, this needs to be + <kgsl_smmu SID> pair, kgsl_smmu is the string parsed by iommu + driver to match this context bank with the kgsl_smmu device + defined in iommu device tree. On targets where the msm iommu + driver is used rather than the arm smmu driver, this property + may be absent. + - qcom,gpu-offset : Offset into the GPU register space for accessing + this context bank. On some targets the iommu registers are not + part of the GPU's register space, and a separate register aperture + is used. Otherwise the same register offsets may be used for CPU + or GPU side programming. + +Example: + + msm_iommu: qcom,kgsl-iommu { + compatible = "qcom,kgsl-smmu-v2"; + reg = <0xb40000 0x20000>; + qcom,protect = <0x40000 0x20000>; + clocks = <&clock_mmss clk_gpu_ahb_clk>, + <&clock_gcc clk_gcc_mmss_bimc_gfx_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_mmss clk_mmss_mmagic_cfg_ahb_clk>; + clock-names = "gpu_ahb_clk", "bimc_gfx_clk", "mmagic_ahb_clk", "mmagic_cfg_ahb_clk"; + qcom,secure_align_mask = <0xfff>; + qcom,retention; + qcom,global_pt; + + gfx3d_user: gfx3d_user { + compatible = "qcom,smmu-kgsl-cb"; + iommus = <&kgsl_smmu 0>, + <&kgsl_smmu 1>; + qcom,gpu-offset = <0x48000>; + }; + + gfx3d_secure: gfx3d_secure { + compatible = "qcom,smmu-kgsl-cb"; + iommus = <&kgsl_smmu 2>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpu/adreno-pwrlevels.txt b/Documentation/devicetree/bindings/gpu/adreno-pwrlevels.txt new file mode 100644 index 000000000000..7aa2dfbe873b --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/adreno-pwrlevels.txt @@ -0,0 +1,26 @@ +Qualcomm GPU powerlevels + +Powerlevels are defined in sets by qcom,gpu-pwrlevels. Multiple sets (bins) +can be defined within qcom,gpu-pwrelvel-bins. Each powerlevel defines a +voltage, bus, and bandwitdh level. + +- qcom,gpu-pwrlevel-bins: Contains one or more qcom,gpu-pwrlevels sets + +Properties: +- compatible: Must be qcom,gpu-pwrlevel-bins +- qcom,gpu-pwrlevels: Defines a set of powerlevels + +Properties: +- qcom,speed-bin: Speed bin identifier for the set - must match + the value read from the hardware +- qcom,initial-pwrlevel: GPU wakeup powerlevel + +- qcom,gpu-pwrlevel: A single powerlevel + +Properties: +- reg: Index of the powerlevel (0 = highest perf) +- qcom,gpu-freq GPU frequency for the powerlevel (in Hz) +- qcom,bus-freq Index to a bus level (defined by the bus + settings) +- qcom,bus-min Minimum bus level to set for the power level +- qcom,bus-max maximum bus level to set for the power level diff --git a/Documentation/devicetree/bindings/gpu/adreno.txt b/Documentation/devicetree/bindings/gpu/adreno.txt new file mode 100644 index 000000000000..d8c3a7c35465 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/adreno.txt @@ -0,0 +1,343 @@ +Qualcomm GPU + +Qualcomm Adreno GPU + +Required properties: +- label: A string used as a descriptive name for the device. +- compatible: Must be "qcom,kgsl-3d0" and "qcom,kgsl-3d" +- reg: Specifies the register base address and size. The second interval + specifies the shader memory base address and size. +- reg-names: Resource names used for the physical address of device registers + and shader memory. "kgsl_3d0_reg_memory" gives the physical address + and length of device registers while "kgsl_3d0_shader_memory" gives + physical address and length of device shader memory. If + specified, "qfprom_memory" gives the range for the efuse + registers used for various configuration options. +- interrupts: Interrupt mapping for GPU IRQ. +- interrupt-names: String property to describe the name of the interrupt. +- qcom,id: An integer used as an identification number for the device. +- qcom,gpu-bimc-interface-clk-freq: + GPU-BIMC interface clock needs to be set to this value for + targets where B/W requirements does not meet GPU Turbo use cases. +- clocks: List of phandle and clock specifier pairs, one pair + for each clock input to the device. +- clock-names: List of clock input name strings sorted in the same + order as the clocks property. + Current values of clock-names are: + "src_clk", "core_clk", "iface_clk", "mem_clk", "mem_iface_clk", + "alt_mem_iface_clk", "rbbmtimer_clk", "alwayson_clk", + "iref_clk" + "core_clk" and "iface_clk" are required and others are optional + +- qcom,base-leakage-coefficient: Dynamic leakage coefficient. +- qcom,lm-limit: Current limit for GPU limit management. +- qcom,isense-clk-on-level: below or equal this power level isense clock is at XO rate, + above this powerlevel isense clock is at working frequency. + +Bus Scaling Data: +- qcom,msm-bus,name: String property to describe the name of the 3D graphics processor. +- qcom,msm-bus,num-cases: This is the the number of Bus Scaling use cases defined in the vectors property. +- qcom,msm-bus,active-only: A boolean flag indicating if it is active only. +- qcom,msm-bus,num-paths: This represents the number of paths in each Bus Scaling Usecase. +- qcom,msm-bus,vectors-KBps: A series of 4 cell properties, format of which is: + <src dst ab ib>, <src dst ab ib>, // For Bus Scaling Usecase 1 + <src dst ab ib>, <src dst ab ib>, // For Bus Scaling Usecase 2 + <.. .. .. ..>, <.. .. .. ..>; // For Bus Scaling Usecase n + This property is a series of all vectors for all Bus Scaling Usecases. + Each set of vectors for each usecase describes bandwidth votes for a combination + of src/dst ports. The driver will set the desired use case based on the selected + power level and the desired bandwidth vote will be registered for the port pairs. + Current values of src are: + 0 = MSM_BUS_MASTER_GRAPHICS_3D + 1 = MSM_BUS_MASTER_GRAPHICS_3D_PORT1 + 2 = MSM_BUS_MASTER_V_OCMEM_GFX3D + Current values of dst are: + 0 = MSM_BUS_SLAVE_EBI_CH0 + 1 = MSM_BUS_SLAVE_OCMEM + ab: Represents aggregated bandwidth. This value is 0 for Graphics. + ib: Represents instantaneous bandwidth. This value has a range <0 8000 MB/s> + +- qcom,ocmem-bus-client: Container for another set of bus scaling properties + qcom,msm-bus,name + qcom,msm-bus,num-cases + qcom,msm-bus,num-paths + qcom,msm-bus,vectors-KBps + to be used by ocmem msm bus scaling client. + +GDSC Oxili Regulators: +- regulator-names: List of regulator name strings sorted in power-on order +- vddcx-supply: Phandle for vddcx regulator device node. +- vdd-supply: Phandle for vdd regulator device node. + +IOMMU Data: +- iommu: Phandle for the KGSL IOMMU device node + +GPU Power levels: +- qcom,gpu-pwrlevel-bins: Container for sets of GPU power levels (see + adreno-pwrlevels.txt) + +DCVS Core info +- qcom,dcvs-core-info Container for the DCVS core info (see + dcvs-core-info.txt) + +Optional Properties: +- qcom,initial-powerlevel: This value indicates which qcom,gpu-pwrlevel should be used at start time + and when coming back out of resume +- qcom,bus-control: Boolean. Enables an independent bus vote from the gpu frequency +- qcom,bus-width: Bus width in number of bytes. This enables dynamic AB bus voting based on + bus width and actual bus transactions. +- qcom,gpubw-dev: a phandle to a device representing bus bandwidth requirements + (see devdw.txt) +- qcom,idle-timeout: This property represents the time in milliseconds for idle timeout. +- qcom,no-nap: If it exists software clockgating will be disabled at boot time. +- qcom,chipid: If it exists this property is used to replace + the chip identification read from the GPU hardware. + This is used to override faulty hardware readings. +- qcom,disable-busy-time-burst: + Boolean. Disables the busy time burst to avoid switching + of power level for large frames based on the busy time limit. + +- qcom,pm-qos-active-latency: + Right after GPU wakes up from sleep, driver votes for + acceptable maximum latency to the pm-qos driver. This + voting demands that the system can not go into any + power save state *if* the latency to bring system back + into active state is more than this value. + Value is in microseconds. +- qcom,pm-qos-wakeup-latency: + Similar to the above. Driver votes against deep low + power modes right before GPU wakes up from sleep. +- qcom,l2pc-cpu-mask-latency: + The CPU mask latency in microseconds to avoid L2PC + on masked CPUs. + +- qcom,gpu-cx-ipeak: + To handle Cx peak current limit. + <phandle bit> + phandle - phandle of cx ipeak device node + bit - bit number of client in relevant register +- qcom,gpu-cx-ipeak-clk: + GPU clock threshold for Cx Ipeak voting. KGSL votes + to Cx Ipeak driver when GPU clock crosses this threshold. + Cx Ipeak can limit peak current based on voting from other clients. + +- qcom,force-32bit: + Force the GPU to use 32 bit data sizes even if + it is capable of doing 64 bit. + +- qcom,gpu-speed-bin: GPU speed bin information in the format + <offset mask shift> + offset - offset of the efuse register from the base. + mask - mask for the relevant bits in the efuse register. + shift - number of bits to right shift to get the speed bin + value. +- qcom,highest-bank-bit: + Specify the bit of the highest DDR bank. This + is programmed into protected registers and also + passed to the user as a property. + +- qcom,l2pc-cpu-mask: + Disables L2PC on masked CPUs when any of Graphics + rendering thread is running on masked CPUs. + Bit 0 is for CPU-0, bit 1 is for CPU-1... + +- qcom,snapshot-size: + Specify the size of snapshot in bytes. This will override + snapshot size defined in the driver code. + +- qcom,gpu-qdss-stm: + <baseAddr size> + baseAddr - base address of the gpu channels in the qdss stm memory region + size - size of the gpu stm region + +- qcom,gpu-qtimer: + <baseAddr size> + baseAddr - base address of the qtimer memory region + size - size of the qtimer region + +- qcom,tsens-name: + Specify the name of GPU temperature sensor. This name will be used + to get the temperature from the thermal driver API. + +- qcom,enable-midframe-timer: + Boolean. Enables the use of midframe sampling timer. This timer + samples the GPU powerstats if the cmdbatch expiry takes longer than + the threshold set by KGSL_GOVERNOR_CALL_INTERVAL. Enable only if + target has NAP state enabled. + +GPU Quirks: +- qcom,gpu-quirk-two-pass-use-wfi: + Signal the GPU to set Set TWOPASSUSEWFI bit in + A5XX_PC_DBG_ECO_CNTL (5XX only) +- qcom,gpu-quirk-critical-packets: + Submit a set of critical PM4 packets when the GPU wakes up +- qcom,gpu-quirk-fault-detect-mask: + Mask out RB1-3 activity signals from HW hang + detection logic +- qcom,gpu-quirk-dp2clockgating-disable: + Disable RB sampler data path clock gating optimization +- qcom,gpu-quirk-lmloadkill-disable: + Use register setting to disable local memory(LM) feature + to avoid corner case error + +KGSL Memory Pools: +- qcom,gpu-mempools: Container for sets of GPU mempools.Multiple sets + (pools) can be defined within qcom,gpu-mempools. + Each mempool defines a pool order, reserved pages, + allocation allowed. +Properties: +- compatible: Must be qcom,gpu-mempools. +- qcom,mempool-max-pages: Max pages for all mempools, If not defined there is no limit. +- qcom,gpu-mempool: Defines a set of mempools. + +Properties: +- reg: Index of the pool (0 = lowest pool order). +- qcom,mempool-page-size: Size of page. +- qcom,mempool-reserved: Number of pages reserved at init time for a pool. +- qcom,mempool-allocate: Allocate memory from the system memory when the + reserved pool exhausted. + +The following properties are optional as collecting data via coresight might +not be supported for every chipset. The documentation for coresight +properties can be found in: +Documentation/devicetree/bindings/coresight/coresight.txt + +- coresight-id Unique integer identifier for the bus. +- coresight-name Unique descriptive name of the bus. +- coresight-nr-inports Number of input ports on the bus. +- coresight-outports List of output port numbers on the bus. +- coresight-child-list List of phandles pointing to the children of this + component. +- coresight-child-ports List of input port numbers of the children. +- coresight-atid The unique ATID value of the coresight device + +Example of A330 GPU in MSM8916: + +&soc { + msm_gpu: qcom,kgsl-3d0@01c00000 { + label = "kgsl-3d0"; + compatible = "qcom,kgsl-3d0", "qcom,kgsl-3d"; + reg = <0x01c00000 0x10000 + 0x01c20000 0x20000>; + reg-names = "kgsl_3d0_reg_memory" , "kgsl_3d0_shader_memory"; + interrupts = <0 33 0>; + interrupt-names = "kgsl_3d0_irq"; + qcom,id = <0>; + + qcom,chipid = <0x03000600>; + + qcom,initial-pwrlevel = <1>; + + /* Idle Timeout = HZ/12 */ + qcom,idle-timeout = <8>; + qcom,strtstp-sleepwake; + + clocks = <&clock_gcc clk_gcc_oxili_gfx3d_clk>, + <&clock_gcc clk_gcc_oxili_ahb_clk>, + <&clock_gcc clk_gcc_oxili_gmem_clk>, + <&clock_gcc clk_gcc_bimc_gfx_clk>, + <&clock_gcc clk_gcc_bimc_gpu_clk>; + clock-names = "core_clk", "iface_clk", "mem_clk", + "mem_iface_clk", "alt_mem_iface_clk"; + + /* Bus Scale Settings */ + qcom,msm-bus,name = "grp3d"; + qcom,msm-bus,num-cases = <4>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <26 512 0 0>, + <26 512 0 1600000>, + <26 512 0 3200000>, + <26 512 0 4264000>; + + /* GDSC oxili regulators */ + vdd-supply = <&gdsc_oxili_gx>; + + /* IOMMU Data */ + iommu = <&gfx_iommu>; + + /* Trace bus */ + coresight-id = <67>; + coresight-name = "coresight-gfx"; + coresight-nr-inports = <0>; + coresight-outports = <0>; + coresight-child-list = <&funnel_in0>; + coresight-child-ports = <5>; + + /* GPU Mempools */ + qcom,gpu-mempools { + #address-cells= <1>; + #size-cells = <0>; + compatible = "qcom,gpu-mempools"; + + /* 4K Page Pool configuration */ + qcom,gpu-mempool@0 { + reg = <0>; + qcom,mempool-page-size = <4096>; + qcom,mempool-reserved = <2048>; + qcom,mempool-allocate; + }; + /* 8K Page Pool configuration */ + qcom,gpu-mempool@1 { + reg = <1>; + qcom,mempool-page-size = <8192>; + qcom,mempool-reserved = <1024>; + qcom,mempool-allocate; + }; + /* 64K Page Pool configuration */ + qcom,gpu-mempool@2 { + reg = <2>; + qcom,mempool-page-size = <65536>; + qcom,mempool-reserved = <256>; + }; + /* 1M Page Pool configuration */ + qcom,gpu-mempool@3 { + reg = <3>; + qcom,mempool-page-size = <1048576>; + qcom,mempool-reserved = <32>; + }; + }; + + /* Power levels */ + qcom,gpu-pwrlevels-bins { + #address-cells = <1>; + #size-cells = <0>; + + qcom,gpu-pwrlevels-0 { + #address-cells = <1>; + #size-cells = <0>; + + qcom,speed-bin = <0>; + + qcom,gpu-pwrlevel@0 { + reg = <0>; + qcom,gpu-freq = <400000000>; + qcom,bus-freq = <3>; + qcom,io-fraction = <33>; + }; + + qcom,gpu-pwrlevel@1 { + reg = <1>; + qcom,gpu-freq = <310000000>; + qcom,bus-freq = <2>; + qcom,io-fraction = <66>; + }; + + qcom,gpu-pwrlevel@2 { + reg = <2>; + qcom,gpu-freq = <200000000>; + qcom,bus-freq = <1>; + qcom,io-fraction = <100>; + }; + + qcom,gpu-pwrlevel@3 { + reg = <3>; + qcom,gpu-freq = <27000000>; + qcom,bus-freq = <0>; + qcom,io-fraction = <0>; + }; + }; + }; + + }; +}; diff --git a/Documentation/devicetree/bindings/hwmon/epm_adc.txt b/Documentation/devicetree/bindings/hwmon/epm_adc.txt new file mode 100644 index 000000000000..add8a9f9fc20 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/epm_adc.txt @@ -0,0 +1,28 @@ +Embedded Power Measurement(EPM) using Cypress Progammable System on a chip (PSOC) + +The EPM using the PSoC5 is used by clients to measure on target power +measurement on supported channels. The PSoC5 is a microcontroller +that is communicated over the SPI from the MSM. Primary configuration +supports upto 31 channels and the scope of the driver is to support +userspace clients. + +EPM node + +Required properties: +- compatible : should be "cy,epm-adc-cy8c5568lti-114" for EPM using PSoC5. +- reg : chip select for the device. +- interrupt-parent : should be phandle of the interrupt controller + servicing the interrupt for this device. +- spi-max-frequency : existing support is set for 960kHz. +- qcom,channels : The number of voltage and current channels that + are supported. +- qcom,gain : The gain for each of the supported channels. +- qcom,rsense : The rsense value for each channel. The current channels + rsense values units are in milliohms. The voltage channels + rsense value is 1. +- qcom,channel-type : Bitmak of channels to set as voltage and current. + These are platform dependent and the appropriate scaling + functions are used for returning voltage and current. +- qcom,<gpio-name>-gpio : Handle to the GPIO node, see "gpios property" in + Documentation/devicetree/bindings/gpio/gpio.txt. + "gpio-name" can be "epm-enable" which is the EPM global enable GPIO for powering up the PSoC. diff --git a/Documentation/devicetree/bindings/hwmon/qpnp-adc-current.txt b/Documentation/devicetree/bindings/hwmon/qpnp-adc-current.txt new file mode 100644 index 000000000000..9450b5df6d21 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/qpnp-adc-current.txt @@ -0,0 +1,104 @@ +Qualcomm's QPNP PMIC current ADC driver + +QPNP PMIC current ADC (IADC) provides interface to clients to read +current. A 16 bit ADC is used for current measurements. There are multiple +peripherals to the IADC and the scope of the driver is to provide interface +for the USR peripheral of the IADC. + +IADC node + +Required properties: +- compatible : should be "qcom,qpnp-iadc" for Current ADC driver. +- reg : offset and length of the PMIC Arbiter register map. +- reg-names : resource names used for the physical base address of the PMIC IADC + peripheral, the SMBB_BAT_IF_TRIM_CNST_RDS register. + Should be "iadc-base" for the PMIC IADC peripheral base register. + Should be "batt-id-trim-cnst-rds" for reading the + SMBB_BAT_IF_TRIM_CNST_RDS register. +- address-cells : Must be one. +- size-cells : Must be zero. +- interrupts : The USR bank peripheral IADC interrupt. +- interrupt-names : Should contain "eoc-int-en-set". +- qcom,adc-bit-resolution : Bit resolution of the ADC. +- qcom,adc-vdd-reference : Voltage reference used by the ADC. + +Optional properties: +- qcom,rsense : Use this property when external rsense should be used + for current calculation and specify the units in nano-ohms. +- qcom,iadc-poll-eoc: Use polling instead of interrupts for End of Conversion completion. +- qcom,pmic-revid : Phandle pointing to the revision peripheral node. Use it to query the + PMIC type and revision for applying the appropriate temperature + compensation parameters. +- qcom,use-default-rds-trim : Add this property to check if certain conditions are to be checked + reading the SMBB_BAT_IF_CNST_RDS, IADC_RDS trim register and + manufacturer type. Check the driver for conditions that each of the type. + 0 : Select the TypeA to read the IADC and SMBB trim register and + apply the default RSENSE if conditions are met. + 1 : Select the TypeB to read the IADC, SMBB trim register and + manufacturer type and apply the default RSENSE if conditions are met. + 2 : Select the TypeC to read the IADC, SMBB trim register and + apply the default RSENSE if conditions are met. + +Channel node +NOTE: Atleast one Channel node is required. + +Client required property: +- qcom,<consumer name>-iadc : The phandle to the corresponding iadc device. + The consumer name passed to the driver when calling + qpnp_get_iadc() is used to associate the client + with the corresponding device. + +Required properties: +- label : Channel name used for sysfs entry. +- reg : AMUX channel number. +- qcom,channel-num : Channel number associated to the AMUX input. +- qcom,decimation : Sampling rate to use for the individual channel measurement. + Select from the following unsigned int. + 0 : 512 + 1 : 1K + 2 : 2K + 3 : 4K +- qcom,fast-avg-setup : Average number of samples to be used for measurement. Fast averaging + provides the option to obtain a single measurement from the ADC that + is an average of multiple samples. The value selected is 2^(value) + Select from the following unsigned int. + 0 : 1 + 1 : 2 + 2 : 4 + 3 : 8 + 4 : 16 + 5 : 32 + 6 : 64 + 7 : 128 + 8 : 256 +- qcom,iadc-vadc : Corresponding phandle of the VADC device to read the die_temperature and set + simultaneous voltage and current conversion requests. + +Example: + /* Main Node */ + qcom,iadc@3200 { + compatible = "qcom,qpnp-iadc"; + reg = <0x3200 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 0x36 0>; + interrupt-names = "eoc-int-en-set"; + qcom,adc-bit-resolution = <16>; + qcom,adc-vdd-reference = <1800>; + qcom,rsense = <1500>; + qcom,iadc-vadc = <&pm8941_vadc>; + + /* Channel Node */ + chan@0 = { + label = "rsense"; + reg = <0>; + qcom,decimation = <0>; + qcom,fast-avg-setup = <0>; + }; + }; + +Client device example: +/* Add to the clients node that needs the IADC */ +client_node { + qcom,client-iadc = <&pm8941_iadc>; +}; diff --git a/Documentation/devicetree/bindings/hwmon/qpnp-adc-voltage.txt b/Documentation/devicetree/bindings/hwmon/qpnp-adc-voltage.txt new file mode 100644 index 000000000000..1dfa97ca6648 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/qpnp-adc-voltage.txt @@ -0,0 +1,197 @@ +Qualcomm's QPNP PMIC Voltage ADC Arbiter + +QPNP PMIC Voltage ADC (VADC) provides interface to clients to read +Voltage. A 15 bit ADC is used for Voltage measurements. There are multiple +peripherals to the VADC and the scope of the driver is to provide interface +for the USR peripheral of the VADC. + +VADC node + +Required properties: +- compatible : should be "qcom,qpnp-vadc" for Voltage ADC device driver and + "qcom,qpnp-vadc-hc" for VADC_HC voltage ADC device driver. +- reg : offset and length of the PMIC Aribter register map. +- address-cells : Must be one. +- size-cells : Must be zero. +- interrupts : The USR bank peripheral VADC interrupt. +- interrupt-names : Should contain "eoc-int-en-set" for EOC, + "high-thr-en-set" for high threshold interrupts and + "low-thr-en-set" for low threshold interrupts. High and low threshold + interrupts are to be enabled if VADC_USR needs to support recurring measurement. +- qcom,adc-bit-resolution : Bit resolution of the ADC. +- qcom,adc-vdd-reference : Voltage reference used by the ADC. + +Channel nodes +NOTE: Atleast one Channel node is required. + +Optional properties: +- qcom,vadc-poll-eoc: Use polling instead of interrupts for End of Conversion completion. +- qcom,pmic-revid : Phandle pointing to the revision peripheral node. Use it to query the + PMIC type and revision for applying the appropriate temperature + compensation parameters. +-qcom,vadc-meas-int-mode : Enable VADC_USR to handle requests to perform recurring measurements + for any one supported channel along with supporting single conversion + requests. +- qcom,vadc-recalib-check: Add this property to check if recalibration required due to inaccuracy. +- qcom,vadc-thermal-node : If present a thermal node is created and the channel is registered as + part of the thermal sysfs which allows clients to use the thermal framework + to set temperature thresholds and receive notification when the temperature + crosses a set threshold, read temperature and enable/set trip types supported + by the thermal framework. +- hkadc_ldo-supply : Add this property if VADC needs to perform a Software Vote for the HKADC. +- hkadc_ok-supply : Add this property if the VADC needs to perform a Software vote for the HKADC VREG_OK. +- qcom,cal-val : Add this property for VADC_HC voltage ADC device to select from the following + unsigned int. If the property is not present the default calibration value of + using the timer value is chosen. + 0 : The calibration values used for measurement are from a timer. + 1 : Forces a fresh measurement for calibration values at the same time + measurement is taken. + +Client required property: +- qcom,<consumer name>-vadc : The phandle to the corresponding vadc device. + The consumer name passed to the driver when calling + qpnp_get_vadc() is used to associate the client + with the corresponding device. + +Required properties: +- label : Channel name used for sysfs entry. +- reg : AMUX channel number. +- qcom,decimation : Sampling rate to use for the individual channel measurement. + Select from following unsigned int for Voltage ADC device. + 0 : 512 + 1 : 1K + 2 : 2K + 3 : 4K + Select from following unsigned int for VADC_HC voltage ADC device. + 0 : 256 + 1 : 512 + 2 : 1024 +- qcom,pre-div-channel-scaling : Pre-div used for the channel before the signal + is being measured. Some of the AMUX channels + support dividing the signal from a predetermined + ratio. The configuration for this node is to know + the pre-determined ratio and use it for post scaling. + Select from the following unsinged int. + 0 : {1, 1} + 1 : {1, 3} + 2 : {1, 4} + 3 : {1, 6} + 4 : {1, 20} + 5 : {1, 8} + 6 : {10, 81} + 7 : {1, 10} +- qcom,calibration-type : Reference voltage to use for channel calibration. + Channel calibration is dependendent on the channel. + Certain channels like XO_THERM, BATT_THERM use ratiometric + calibration. Most other channels fall under absolute calibration. + Select from the following strings. + "absolute" : Uses the 625mv and 1.25V reference channels. + "ratiometric" : Uses the reference Voltage/GND for calibration. +- qcom,scale-function : Scaling function used to convert raw ADC code to units specific to + a given channel. + Select from the following unsigned int. + 0 : Default scaling to convert raw adc code to voltage. + 1 : Conversion to temperature based on btm parameters. + 2 : Returns result in degC for 100k pull-up. + 3 : Returns current across 0.1 ohm resistor. + 4 : Returns XO thermistor voltage in degree's Centigrade. + 5 : Returns result in degC for 150k pull-up. + 9 : Conversion to temperature based on -15~55 allowable + battery charging tempeature setting for btm parameters. +- qcom,hw-settle-time : Settling period for the channel before ADC read. + Select from the following unsigned int. + 0 : 0us + 1 : 100us + 2 : 200us + 3 : 300us + 4 : 400us + 5 : 500us + 6 : 600us + 7 : 700us + 8 : 800us + 9 : 900us + 0xa : 1ms + 0xb : 2ms + 0xc : 4ms + 0xd : 6ms + 0xe : 8ms + 0xf : 10ms +- qcom,fast-avg-setup : Average number of samples to be used for measurement. Fast averaging + provides the option to obtain a single measurement from the ADC that + is an average of multiple samples. The value selected is 2^(value) + Select from the following unsigned int for Voltage ADC device. + 0 : 1 + 1 : 2 + 2 : 4 + 3 : 8 + 4 : 16 + 5 : 32 + 6 : 64 + 7 : 128 + 8 : 256 + Select from the following unsigned int for VADC_HC ADC device. + 0 : 1 + 1 : 2 + 2 : 4 + 3 : 8 + 4 : 16 + +Example: + /* Main Node */ + qcom,vadc@3100 { + compatible = "qcom,qpnp-vadc"; + reg = <0x3100 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0x0 0x31 0x0>; + interrupt-names = "eoc-int-en-set"; + qcom,adc-bit-resolution = <15>; + qcom,adc-vdd-reference = <1800>; + + /* Channel Node */ + chan@0 { + label = "usb_in"; + reg = <0>; + qcom,decimation = <0>; + qcom,pre-div-channel-scaling = <4>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <0>; + qcom,hw-settle-time = <0>; + qcom,fast-avg-setup = <0>; + }; + }; + +Client device example: +/* Add to the clients node that needs the VADC channel A/D */ +client_node { + qcom,client-vadc = <&pm8941_vadc>; +}; + +/* Clients have an option of measuring an analog signal through an MPP. + MPP block is not part of the VADC block but is an individual PMIC + block that has an option to support clients to configure an MPP as + an analog input which can be routed through one of the VADC pre-mux + inputs. Here is an example of how to configure an MPP as an analog + input */ + +/* Configure MPP4 as an Analog input to AMUX8 and read from channel 0x23 */ +/* MPP DT configuration in the platform DT file*/ + mpp@a300 { /* MPP 4 */ + qcom,mode = <4>; /* AIN input */ + qcom,invert = <1>; /* Enable MPP */ + qcom,ain-route = <3>; /* AMUX 8 */ + qcom,master-en = <1>; + qcom,src-sel = <0>; /* Function constant */ + }; + +/* VADC Channel configuration */ + chan@23 { + label = "mpp4_div3"; + reg = <0x23>; + qcom,decimation = <0>; + qcom,pre-div-channel-scaling = <1>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <0>; + qcom,hw-settle-time = <0>; + qcom,fast-avg-setup = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-msm-v2.txt b/Documentation/devicetree/bindings/i2c/i2c-msm-v2.txt new file mode 100644 index 000000000000..fa3abb215773 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-msm-v2.txt @@ -0,0 +1,55 @@ +Qualcomm I2C controller + +Required properties: + - reg : Offset and length of the register region for the device named in + reg-names and has the same index. + - reg-names : Register region name(s) referenced in reg above + "qup_phys_addr" : Physical address of QUP register space. + - compatible : should be "qcom,i2c-msm-v2" + - interrupts : Interrupt number which correspond to the entry with the same + index in interrupt-names. + - interrupt-names: QUP core interrupt name(s) referenced in interrupts above + "qup_irq" : QUP interrupt used by the controller. + - dmas : DMA engine API's parameters for blsp. + <[phandle of the dma controller] [pipe index] [number of descriptors] + [sps_connect flags] [sps_register_event flags]>; + - dma-names : dma channel names. + - qcom,clk-freq-out : Desired I2C bus clock frequency in Hz + - qcom,clk-freq-in : Supplied core clock frequency in Hz. + +Required alias: + - The desired bus-number is specified by an alias with the following format: + 'i2c{n}' where n is the bus number. + +Optional property: + - qcom,noise-rjct-scl : number of low samples on clock line to consider it low. + When missing default to 0. + - qcom,noise-rjct-sda : number of low samples on data line to consider it low. + When missing default to 0. + - qcom,disable-dma : disables DMA transfer mode. + - qcom,master-id : Master-port value used on voting for the clock path. + - qcom,high-time-clk-div : high time divider value to configure clk-ctl + register. When missing, default to the value given in driver. + - qcom,fs-clk-div: fs divider value to configure clk-ctl register. When + missing, default to the value given in driver. + +Example: + aliases { + i2c10 = &i2c_10; + }; + + i2c_10: i2c@f9966000 { + compatible = "qcom,i2c-msm-v2"; + reg-names = "qup_phys_addr", "dma_phys_addr"; + reg = <0xf9966000 0x1000>; + interrupt-names = "qup_irq"; + interrupts = <0 104 0>; + dmas = <&dma_blsp1 14 32 0x20000020 0x20>, + <&dma_blsp1 15 64 0x20000020 0x20>; + dma-names = "tx", "rx"; + qcom,clk-freq-out = <100000>; + qcom,clk-freq-in = <24000000>; + qcom,noise-rjct-scl = <0>; + qcom,noise-rjct-sda = <0>; + + }; diff --git a/Documentation/devicetree/bindings/i2c/sii8334-i2c.txt b/Documentation/devicetree/bindings/i2c/sii8334-i2c.txt new file mode 100644 index 000000000000..27a2149d9c86 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/sii8334-i2c.txt @@ -0,0 +1,28 @@ +* Silicon Image-8334 MHL Tx + +Required properties: +- compatible: must be "qcom,mhl-sii8334" +- reg: i2c slave address +- mhl-intr-gpio: MHL interrupt gpio coming out of sii8334 +- mhl-pwr-gpio: MHL power gpio required for power rails +- mhl-rst-gpio: MHL reset gpio going into sii8334 for toggling reset pin +- <supply-name>-supply: phandle to the regulator device tree node. +- qcom,hdmi-tx-map: phandle to the hdmi tx device tree node. + +Example: + i2c@f9967000 { + sii8334@72 { + compatible = "qcom,mhl-sii8334"; + reg = <0x72>; + interrupt-parent = <&msmgpio>; + interrupts = <82 0x8>; + mhl-intr-gpio = <&msmgpio 82 0>; + mhl-pwr-gpio = <&msmgpio 12 0>; + mhl-rst-gpio = <&pm8941_mpps 8 0>; + avcc_18-supply = <&pm8941_l24>; + avcc_12-supply = <&pm8941_l2>; + smps3a-supply = <&pm8941_s3>; + vdda-supply = <&pm8941_l12>; + qcom,hdmi-tx-map = <&mdss_hdmi_tx>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/sii8620-i2c.txt b/Documentation/devicetree/bindings/i2c/sii8620-i2c.txt new file mode 100644 index 000000000000..ccfcc8e85c35 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/sii8620-i2c.txt @@ -0,0 +1,27 @@ +* Silicon Image-8620 MHL Tx + +Required properties: +- compatible: must be "sil,sii-8620" +- reg: i2c slave address +- sil,pwr-gpio: MHL power gpio required to power sii8620 +- sil,fw-wake: MHL fw wake gpio going into sii8620 +- sil,reset-gpio: MHL reset gpio going into sii8620 for toggling reset pin +- sil,irq-gpio: MHL interrupt gpio coming out of sii8620 +- sil,i2c_port#: Port number of i2c device +- pinctrl-0: Pin control group to be used for this controller. +- pinctrl-names: Should contain only one value - "mhl_active". + +Example: + i2c@f9923000 { + sil,sii-8620@72 { + compatible = "sil,sii-8620"; + reg = <0x72>; + sil,pwr-gpio = <&pm8994_gpios 2 0>; + sil,fw-wake = <&msm_gpio 38 0>; + sil,reset-gpio = <&msm_gpio 58 0>; + sil,irq-gpio = <&msm_gpio 57 0>; + sil,i2c_port# = <1>; + pinctrl-names = "mhl_active"; + pinctrl-0 = <&mhl_intr_active &mhl_reset_active>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/qcom-rradc.txt b/Documentation/devicetree/bindings/iio/adc/qcom-rradc.txt new file mode 100644 index 000000000000..1ab49edfe30c --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom-rradc.txt @@ -0,0 +1,63 @@ +Qualcomm Technologies Inc., PMIC Round Robin ADC (RRADC) + +PMIC RRADC provides an interface to the clients to read +the voltage, current and temperature for supported channels +such as battery ID, battery thermistor, die temperature, +charger temperature, USB_IN and DC_IN voltage and current. + +Main node properties: + +- compatible: + Usage: required + Value type: <string> + Definition: Should contain "qcom,rradc". + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: RRADC base address and length in the PMIC register map. + +- #address-cells: + Usage: required + Value type: <u32> + Definition: Must be one. Child node 'channel' property should define ADC + channel number. For details about IIO bindings see: + Documentation/devicetree/bindings/iio/iio-bindings.txt + +- #size-cells: + Usage: required + Value type: <u32> + Definition: Must be zero. For details about IIO bindings see: + Documentation/devicetree/bindings/iio/iio-bindings.txt + +- #io-channel-cells: + Usage: required + Value type: <u32> + Definition: Must be one. For details about IIO bindings see: + Documentation/devicetree/bindings/iio/iio-bindings.txt + +IIO client nodes need to specify the RRADC channel number while requesting ADC reads. +The channel list supported by the RRADC driver is available in the enum rradc_channel_id +located at at drivers/iio/adc/qcom-rradc.c. Clients can use this index from the enum +as the channel number while requesting ADC reads. + +Optional property: +- qcom,pmic-revid : Phandle pointing to the revision peripheral node. Use it to query the + PMIC fabrication ID for applying the appropriate temperature + compensation parameters. +Example: + + /* RRADC node */ + pmic_rradc: rradc@4500 { + compatible = "qcom,rradc"; + reg = <0x4500 0x100>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + }; + + /* IIO client node */ + charger { + io-channels = <&pmic_rradc 0>; + io-channel-names = "rradc_batt_id"; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/qcom-tadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom-tadc.txt new file mode 100644 index 000000000000..6880d304367d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom-tadc.txt @@ -0,0 +1,141 @@ +Qualcomm Technologies, Inc. TADC Specific Bindings + +TADC (Telemetry ADC) is a 10 bit resolution ADC which has 8 channels: battery +temperature, skin temperature, die temperature, battery current, battery +voltage, input current, input voltage, and OTG current. + +======================= +Required Node Structure +======================= + +A TADC must be described in two levels of devices nodes. + +======================= +First Level Node - TADC +======================= + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Address and size of the TADC register block. + +TADC specific properties: +- compatible + Usage: required + Value type: <string> + Definition: Must be "qcom,tadc". + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: Peripheral interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. + +============================================= +Second Level Nodes - TADC Thermistor Channels +============================================= + +- reg + Usage: required + Value type: <u32> + Definition: The 0 based channel number. + +TADC thermistor channel specific properties: +- qcom,rbias + Usage: required + Value type: <u32> + Definition: The bias resistor value. + +- qcom,therm-at-25degc + Usage: required + Value type: <u32> + Definition: The thermistor resistance at 25 DegC. + +- qcom,beta-coefficient + Usage: required + Value type: <u32> + Definition: The beta coefficeent or B-parameter of the thermistor. + +=============================================== +Second Level Nodes - TADC Scale/Offset Channels +=============================================== + +- reg + Usage: required + Value type: <u32> + Definition: The 0 based channel number. + +TADC scale/offset channel specific properties: +- qcom,scale + Usage: required + Value type: <s32> + Definition: The RAW scaling factor. + +- qcom,offset + Usage: optional + Value type: <s32> + Definition: The offset after scaling. + +======= +Example +======= + +smb138x_tadc: qcom,tadc@3600 { + compatible = "qcom,tadc"; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + interrupts = <0x36 0x0 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "eoc"; + + batt_temp@0 { + reg = <0>; + qcom,rbias = <68100>; + qcom,rtherm-at-25degc = <68000>; + qcom,beta-coefficient = <3450>; + }; + + skin_temp@1 { + reg = <1>; + qcom,rbias = <33000>; + qcom,rtherm-at-25degc = <68000>; + qcom,beta-coefficient = <3450>; + }; + + die_temp@2 { + reg = <2>; + qcom,scale = <(-1032)>; + qcom,offset = <344125>; + }; + + batt_i@3 { + reg = <3>; + qcom,channel = <3>; + qcom,scale = <20000000>; + }; + + batt_v@4 { + reg = <4>; + qcom,scale = <5000000>; + }; + + input_i@5 { + reg = <5>; + qcom,scale = <14285714>; + }; + + input_v@6 { + reg = <6>; + qcom,scale = <25000000>; + }; + + otg_i@7 { + reg = <7>; + qcom,scale = <5714286>; + }; +}; diff --git a/Documentation/devicetree/bindings/input/gen_vkeys.txt b/Documentation/devicetree/bindings/input/gen_vkeys.txt new file mode 100644 index 000000000000..2f8d65e9f578 --- /dev/null +++ b/Documentation/devicetree/bindings/input/gen_vkeys.txt @@ -0,0 +1,28 @@ +Touchscreen Virtual Keys Device + +Generate virtual keys sysfs entry for Android + +Required properties: + + - compatible : should be "qcom,gen-vkeys" + - label : name of the touch controller + - qcom,disp-maxx : Maximum x-coordinate of display + - qcom,disp-maxy : Maximum y-coordinate of display + - qcom,panel-maxx : Maximum x-coordinate of touch panel + - qcom,panel-maxy : Maximum y-coordinate of touch panel + - qcom,key-codes : Array of key codes for virtual keys + +Optional properties: + - qcom,y-offset : Offset of y-location for virtual keys, default 0 + +Example: + gen-vkeys { + compatible = "qcom,gen-vkeys"; + label = "atmel_mxt_ts"; + qcom,disp-maxx = <720>; + qcom,disp-maxy = <1280>; + qcom,panel-maxx = <760>; + qcom,panel-maxy = <1424>; + qcom,key-codes = <158 139 102 217>; + qcom,y-offset = <35>; + }; diff --git a/Documentation/devicetree/bindings/input/hbtp-input.txt b/Documentation/devicetree/bindings/input/hbtp-input.txt new file mode 100644 index 000000000000..ad28952c5e7e --- /dev/null +++ b/Documentation/devicetree/bindings/input/hbtp-input.txt @@ -0,0 +1,89 @@ +Platform device for Host Based Touch Processing (HBTP) + +hbtp_input is a kernel driver that provides functionality needed by +Host Based Touch Processing (HBTP) from the kernel. One of the +functionality is to manage the power source for touch Analog Front +End (AFE). + +Required properties: + + - compatible : should be "qcom,hbtp-input" + +Optional properties: + + - vcc_ana-supply : Analog power supply needed to power device + - qcom,afe-load : AFE/Analog supply load in uA + - qcom,afe-vtg-min : AFE/Analog minimum voltage in uV + - qcom,afe-vtg-max : AFE/Analog maximum voltage in uV + - qcom,dig-load : Digital supply load in uA + - qcom,dig-vtg-min : Digital supply minimum voltage in uV + - qcom,dig-vtg-max : Digital supply maximum voltage in uV + - qcom,display-resolution : Display resolution - maxX, maxY + - qcom,use-scale : boolean, enables the scaling for touch coordinates + - pinctrl-names : defines pinctrl names + "pmx_ts_active" : Required pinctrl name. + This should specify active config of TS RST gpio + "pmx_ts_suspend" : Required pinctrl name + This should specify suspend config of TS RST gpio + "ddic_rst_active" : Required pinctrl name + This should specify active config of DDIC RST gpio + "ddic_rst_suspend" : Required pinctrl name + This should specify suspend config of DDIC RST gpio + - pinctrl-0 : pin control to be used for TS active config + - pinctrl-1 : pin control to be used for TS suspend config + - pinctrl-2 : pin control to be used for DDIC active config + - pinctrl-3 : pin control to be used for DDIC suspend config + +Optional properties if qcom,use-scale DT property is defined: + - qcom,def-maxx : default X-resolution of the touch panel. + - qcom,def-maxy : default Y-resolution of the touch panel. + (Above two properties should be defined in pairs only) + - qcom,des-maxx : desired X-resolution of the touch panel. + - qcom,des-maxy : desired Y-resolution of the touch panel. + (Above two properties should be defined in pairs only) + +Optional Properties if pinctrl names are defined: + - qcom,pmx-ts-on-seq-delay-us : unsigned integer type for + delay after active TS RST gpio is changed + - qcom,fb-resume-delay-us : unsigned integer type for + delay in early resume framebuffer callback + - qcom,ddic-rst-on-seq-delay-us : array of unsigned integer type for + delay of each step in series of DDIC RST gpio control + +Optional Properties if qcom,afe-vtg and qcom,dig-vtg are defined + - qcom,afe-power-on-delay-us : unsigned integer type for + delay between turning on analog and digital power supply + - qcom,afe-power-off-delay-us : unsigned integer type for + delay between turning off digital and analog power supply + +Example: + &soc { + hbtp { + compatible = "qcom,hbtp-input"; + vcc_ana-supply = <&pm8941_l17>; + vcc_dig-supply = <&pm8950_l16>; + qcom,afe-load = <50000>; + qcom,afe-vtg-min = <2850000>; + qcom,afe-vtg-max = <2850000>; + qcom,dig-load = <15000>; + qcom,dig-vtg-min = <1800000>; + qcom,dig-vtg-max = <1800000>; + qcom,display-resolution = <719 1279>; + qcom,use-scale; + qcom,default-max-x = <1080>; + qcom,default-max-y = <1920>; + qcom,desired-max-x = <720>; + qcom,desired-max-y = <1280>; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend", + "ddic_rst_active", "ddic_rst_suspend"; + pinctrl-0 = <&ts_rst_active>; + pinctrl-1 = <&ts_rst_suspend>; + pinctrl-2 = <&ddic_rst_active>; + pinctrl-3 = <&ddic_rst_suspend>; + qcom,pmx-ts-on-seq-delay-us = <1000>; + qcom,ddic-rst-on-seq-delay-us = <10000 10000 10000 10000>; + qcom,fb-resume-delay-us = <90000>; + qcom,afe-power-on-delay-us = <1000>; + qcom,afe-power-off-delay-us = <6>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/pixart-pat9125-switch.txt b/Documentation/devicetree/bindings/input/pixart-pat9125-switch.txt new file mode 100644 index 000000000000..d9caa295cc6e --- /dev/null +++ b/Documentation/devicetree/bindings/input/pixart-pat9125-switch.txt @@ -0,0 +1,58 @@ +PixArt pat9125 rotating switch + +The Pixart's PAT9125 controller is connected to the host processor via I2C. +It detects the rotation when user rotates the switch and generates interrupt +to the Host processor. The host processor reads the direction and number of +steps over I2C and passes the data to the rest of the system. + +Required properties: + - compatible : should be "pixart,pat9125". + - reg : i2c slave address of the device. + - interrupt-parent : parent of interrupt. + - interrupts : interrupt to indicate motion of the rotating switch. + - vdd-supply : Power supply needed to power up the device. + - vld-supply : Power source required to power up I2C bus. + +Optional properties: + - pixart,inverse-x : boolean, use this to invert the x data before sending it to input framework + - pixart,inverse-y : boolean, use this to invert the y data before sending it to input framework + - pixart,press-enabled : boolean, use this to enable detection of pressing the button + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt + It should specify the names of the configs that pinctrl can + install in driver. + Following are the pinctrl configs that can be installed: + "pmx_rot_switch_active" : Active configuration of pins, + it should specify active config + defined in pin groups of + interrupt gpio. + "pmx_rot_switch_suspend" : Disabled configuration of + pins, it should specify sleep + config defined in pin groups + of interrupt gpio. + "pmx_rot_switch_release" : Release configuration of + pins, it should specify release + config defined in pin groups of + interrupt gpio. + - pixart,irq-gpio : This should be defined if a target doesn't use pinctrl framework. + irq gpio, which is to provide interrupts to host, same as "interrupts" node. + +Required properties if 'pixart,press-enabled' DT property is defined: + - pixart,press-keycode : keycode to be sent when press is detected by the driver. + +Example: + pixart_pat9125@75 { + compatible = "pixart,pat9125"; + reg = <0x75>; + interrupt-parent = <&msm_gpio>; + interrupts = <98 0x2008>; + vdd-supply = <&pm8110_l5>; + vld-supply = <&pm8110_l17>; + pixart,irq-gpio = <&msm_gpio 98 0x2008>; + pinctrl-names = "pmx_rot_switch_active", + "pmx_rot_switch_suspend", + "pmx_rot_switch_release"; + pinctrl-0 = <&pix_int_active>; + pinctrl-1 = <&pix_int_suspend>; + pinctrl-2 = <&pix_release>; + }; diff --git a/Documentation/devicetree/bindings/input/qpnp-power-on.txt b/Documentation/devicetree/bindings/input/qpnp-power-on.txt new file mode 100644 index 000000000000..a596aa1c595d --- /dev/null +++ b/Documentation/devicetree/bindings/input/qpnp-power-on.txt @@ -0,0 +1,199 @@ +Qualcomm QPNP power-on + +The qpnp-power-on is a driver which supports the power-on(PON) +peripheral on Qualcomm PMICs. The supported functionality includes +power on/off reason, key press/release detection, PMIC reset configurations +and other PON specific features. The PON module supports multiple physical +power-on (KPDPWR_N, CBLPWR) and reset (KPDPWR_N, RESIN, KPDPWR+RESIN) sources. +This peripheral is connected to the host processor via the SPMI interface. + +Required properties: +- compatible: Must be "qcom,qpnp-power-on" +- reg: Specifies the SPMI address and size for this PON (power-on) + peripheral. +- interrupts: Specifies the interrupt associated with PON. +- interrupt-names: Specify the interrupt names associated with interrupts. + Must be one of "kpdpwr", "kpdpwr-bark", "resin", + "resin-bark", "cblpwr", "kpdpwr-resin-bark".Bark + interrupts are associated with system reset + configuration to allow default reset configuration to + be activated. If system reset configuration is not + supported then bark interrupts are nops. Additionally, + the "pmic-wd-bark" interrupt can be added if the system + needs to handle PMIC watch dog barks. + +Optional properties: +- qcom,pon-dbc-delay The debounce delay for the power-key interrupt + specified in us. + Possible values for GEN1 PON are: + 15625, 31250, 62500, 125000, 250000, 500000, + 1000000 and 2000000. + Possible values for GEN2 PON are: + 62, 123, 245, 489, 977, 1954, 3907, 7813, + 15625, 31250, 62500, 125000 and 250000. + Intermediate value is rounded down to the + nearest valid value. +- qcom,pon_1 ...pon_n These represent the child nodes which describe + the properties (reset, key) for each of the pon + reset source. All the child nodes are optional. + If none of them is specified, the driver fails + to register. +- qcom,system-reset Specifies that this PON peripheral can be used + to reset the system. This property can only be + used by one device on the system. It is an + error to include it more than once. +- qcom,s3-debounce The debounce delay for stage3 reset trigger in + secs. The values range from 0 to 128. +- qcom,s3-src The source for stage 3 reset. It can be one of + "kpdpwr", "resin", "kpdpwr-or-resin" or + "kpdpwr-and-resin". The default value is + "kpdpwr-and-resin". +- qcom,uvlo-panic If this property is present, the device will + set to panic during reboot if this reboot is + due to under voltage lock out. +- qcom,clear-warm-reset Specifies that the WARM_RESET reason registers + need to be cleared for this target. The + property is used for the targets which have a + hardware feature to catch resets which aren't + triggered by the MSM. + In such cases clearing WARM_REASON registers + across MSM resets keeps the registers in good + state. +- qcom,secondary-pon-reset Boolean property which indicates that the PON + peripheral is a secondary PON device which + needs to be configured during reset in addition + to the primary PON device that is configured + for system reset through qcom,system-reset + property. + This should not be defined along with the + qcom,system-reset property. +- qcom,store-hard-reset-reason Boolean property which if set will store the + hardware reset reason to SOFT_RB_SPARE register + of the core PMIC PON peripheral. +- qcom,warm-reset-poweroff-type Poweroff type required to be configured on + PS_HOLD reset control register when the system + goes for warm reset. If this property is not + specified, then the default type, warm reset + will be configured to PS_HOLD reset control + register. +- qcom,hard-reset-poweroff-type Same description as qcom,warm-reset-poweroff- + type but this applies for the system hard reset + case. +- qcom,shutdown-poweroff-type Same description as qcom,warm-reset-poweroff- + type but this applies for the system shutdown + case. + + +All the below properties are in the sub-node section (properties of the child +node). + +Sub-nodes (if defined) should belong to either a PON configuration or a +regulator configuration. + +Regulator sub-node required properties: +- regulator-name Regulator name for the PON regulator that + is being configured. +- qcom,pon-spare-reg-addr Register offset from the base address of the + PON peripheral that needs to be configured for + the regulator being controlled. +- qcom,pon-spare-reg-bit Bit position in the specified register that + needs to be configured for the regulator being + controlled. + +PON sub-node required properties: +- qcom,pon-type The type of PON/RESET source. The driver + currently supports KPDPWR(0), RESIN(1) and + CBLPWR(2) pon/reset sources. + +PON sub-node optional properties: +- qcom,pull-up The initial state of the reset pin under + consideration. + 0 = No pull-up + 1 = pull-up enabled + This property is set to '0' if not specified. +- qcom,support-reset Indicates if this PON source supports + reset functionality. + 0 = Not supported + 1 = Supported + If this property is not defined, then do not + modify S2 reset values. +- qcom,use-bark Specify if this pon type needs to handle bark + irq. +- linux,code The input key-code associated with the reset + source. + The reset source in its default configuration + can be used to support standard keys. + +The below mentioned properties are required only when qcom,support-reset DT +property is defined and is set to 1. + +- qcom,s1-timer The debounce timer for the BARK interrupt for + that reset source. Value is specified in ms. + Supported values are: + - 0, 32, 56, 80, 128, 184, 272, 408, 608, 904 + 1352, 2048, 3072, 4480, 6720, 10256 +- qcom,s2-timer The debounce timer for the S2 reset specified + in ms. On the expiry of this timer, the PMIC + executes the reset sequence. + Supported values are: + - 0, 10, 50, 100, 250, 500, 1000, 2000 +- qcom,s2-type The type of reset associated with this source. + The supported resets are: + SOFT(0), WARM(1), SHUTDOWN(4), HARD(7) + +Example: + qcom,power-on@800 { + compatible = "qcom,qpnp-power-on"; + reg = <0x800 0x100>; + interrupts = <0x0 0x8 0x0>, + <0x0 0x8 0x1>, + <0x0 0x8 0x4>, + <0x0 0x8 0x5>; + interrupt-names = "kpdpwr", "resin", + "resin-bark", "kpdpwr-resin-bark"; + qcom,pon-dbc-delay = <15625>; + qcom,system-reset; + qcom,s3-debounce = <32>; + qcom,s3-src = "resin"; + qcom,clear-warm-reset; + qcom,store-hard-reset-reason; + + qcom,pon_1 { + qcom,pon-type = <0>; + qcom,pull-up = <1>; + linux,code = <116>; + }; + + qcom,pon_2 { + qcom,pon-type = <1>; + qcom,support-reset = <1>; + qcom,pull-up = <1>; + qcom,s1-timer = <0>; + qcom,s2-timer = <2000>; + qcom,s2-type = <1>; + linux,code = <114>; + qcom,use-bark; + }; + + qcom,pon_3 { + qcom,pon-type = <3>; + qcom,support-reset = <1>; + qcom,s1-timer = <6720>; + qcom,s2-timer = <2000>; + qcom,s2-type = <7>; + qcom,pull-up = <1>; + qcom,use-bark; + }; + }; + qcom,power-on@800 { + compatible = "qcom,qpnp-power-on"; + reg = <0x800 0x100>; + qcom,secondary-pon-reset; + qcom,hard-reset-poweroff-type = <PON_POWER_OFF_SHUTDOWN>; + + pon_perph_reg: qcom,pon_perph_reg { + regulator-name = "pon_spare_reg"; + qcom,pon-spare-reg-addr = <0x8c>; + qcom,pon-spare-reg-bit = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/STMicroelectronics.txt b/Documentation/devicetree/bindings/input/touchscreen/STMicroelectronics.txt new file mode 100644 index 000000000000..7799392700a7 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/STMicroelectronics.txt @@ -0,0 +1,54 @@ +STMicroelectronics touch controller + +The STMicroelectronics controller is connected to host processor +via i2c. The controller generates interrupts when the +user touches the panel. The host controller is expected +to read the touch coordinates over i2c and pass the coordinates +to the rest of the system. + +Required properties: + + - compatible : should be "st,fts". + - reg : i2c slave address of the device. + - interrupt-parent : parent of interrupt. + - interrupts : touch sample interrupt to indicate presense or release + of fingers on the panel. + - vdd-supply : Power supply needed to power up the device. + - vcc-supply : Power source required to power up i2c bus. + - st,irq-gpio : irq gpio which is to provide interrupts to host, + same as "interrupts" node. It will also + contain active low or active high information. + - st,reset-gpio : reset gpio to control the reset of chip. + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + Specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_release" : Release configuration of pins, this should specify + release config defined in pin groups of interrupt and reset gpio. + - st,regulator_avdd : name of Power supply needed to power up the device. + - st,regulator_dvdd : name of Power source required to power up i2c bus. +Optional properties: + + +Example: + i2c@78b9000 { /* BLSP1 QUP5 */ + st_fts@49 { + compatible = "st,fts"; + reg = <0x49>; + interrupt-parent = <&msm_gpio>; + interrupts = <13 0x2008>; + vdd-supply = <&pm8916_l17>; + vcc-supply = <&pm8916_l6>; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend"; + pinctrl-0 = <&ts_int_active &ts_reset_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; + st,irq-gpio = <&msm_gpio 13 0x00000001>; + st,reset-gpio = <&msm_gpio 12 0x0>; + st,regulator_dvdd = "vdd"; + st,regulator_avdd = "avdd"; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/atmel-maxtouch-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/atmel-maxtouch-ts.txt new file mode 100644 index 000000000000..bf719275a51a --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/atmel-maxtouch-ts.txt @@ -0,0 +1,85 @@ +Atmel touch controller + +Required properties: + + - compatible : should be "atmel,maxtouch-ts" + - reg : i2c slave address of the device + - interrupt-parent : parent of interrupt + - interrupts : touch sample interrupt to indicate presense or release + of fingers on the panel. + - atmel,panel-coords : touch panel minimum x, minimum y, maximum x and + maximum y resolution + - atmel,display-coords : LCD display minimum x, minimum y, maximum x and + maximum y resolution + - vdd-supply : digital power supply. It powers up the digital + block of the controller to enable i2c communication. + - avdd-supply : analog Power supply. It powers up the analog + channel block of the controller to detect the touches. + - atmel,irq-gpio : irq gpio + - atmel,reset-gpio : reset gpio + +Optional property: + - atmel,cfg-name : Configuration file name with file extension as "raw". + Default value maxtouch_generic_cfg.raw. + - atmel,ignore-crc : Boolean flag to ignore cyclic redundancy check (CRC) on + configuration + - xvdd-supply : x-line drive voltage supply. It is used for charging + the capacitors on the touch panel. + - atmel,bl-addr : bootloader address, by default is looked up + in mxt_slave_addresses structure + - atmel,key-codes : key codes corresponding to keyarray object + - atmel,i2cmode-gpio : i2cmode gpio. This pin is used for selecting the i2c communication mode. + Pull the line low for HID and high for STANDARD i2c. + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + It should specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt, i2cmode and reset gpio. + "pmx_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt, i2cmode and reset gpio. + - clocks : specify the clocks associated with the underlying bus when secure touch + is enabled. + This property is required only if secure touch is enabled and used with + this driver. + - clock-names: : clock names used for secure touch. The names are: + "iface_clk", "core_clk". + +Optional sub-child properties: +The sub-child properties are used to identify different firmware versions supported. +- atmel,version : Firmware version of the controller +- atmel,build : Firmware build of the controller +- atmel,fw-name : Firmware file name for the next upgrade. Do not specify this + when the firmware version is latest. + +Example: + i2c@f9966000 { + atmel_maxtouch_ts@4a { + compatible = "atmel,maxtouch-ts"; + reg = <0x4a> + interrupt-parent = <&msmgpio> + interrupts = <48 0x0>; + vdd-supply = <&pm8941_l18>; + avdd-supply = <&pm8941_lvs1>; + xvdd-supply = <&pm8941_s4>; + atmel,panel-coords = <0 0 479 799>; + atmel,display-coords = <0 0 479 799>; + atmel,irq-gpio = <&msmgpio 48 0>; + atmel,reset-gpio = <&msmgpio 26 0>; + atmel,i2cmode-gpio = <&msmgpio 27 0>; + atmel,ignore-crc; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend"; + pinctrl-0 = <&ts_int_active &ts_reset_active &ts_i2cmode_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend &ts_i2cmode_suspend>; + /* Underlying clocks used by secure touch */ + clock-names = "iface_clk", "core_clk"; + clocks = <&clock_gcc clk_gcc_blsp1_ahb_clk>, + <&clock_gcc clk_gcc_blsp1_qup2_i2c_apps_clk>; + atmel,cfg-name = "maxtouch_8994_liquid_cfg.raw"; + atmel,cfg_1 { + atmel,version = <0x10>; + atmel,build = <0xaa>; + atmel,fw-name = "maxtouch_8994_liquid_v1_1_AB.fw"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/ft5x06-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/ft5x06-ts.txt new file mode 100644 index 000000000000..f7494c4c6e2b --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/ft5x06-ts.txt @@ -0,0 +1,120 @@ +FocalTech touch controller + +The focaltech controller is connected to host processor +via i2c. The controller generates interrupts when the +user touches the panel. The host controller is expected +to read the touch coordinates over i2c and pass the coordinates +to the rest of the system. + +Required properties: + + - compatible : should be "focaltech,5x06". + - reg : i2c slave address of the device. + - interrupt-parent : parent of interrupt. + - interrupts : touch sample interrupt to indicate presense or release + of fingers on the panel. + - vdd-supply : Power supply needed to power up the device. + - vcc_i2c-supply : Power source required to power up i2c bus. + - focaltech,family-id : family identification of the controller. + - focaltech,irq-gpio : irq gpio which is to provide interrupts to host, + same as "interrupts" node. It will also + contain active low or active high information. + - focaltech,reset-gpio : reset gpio to control the reset of chip. + - focaltech,display-coords : display coordinates in pixels. It is a four + tuple consisting of min x, min y, max x and + max y values + - focaltech,name : name of the controller + - focaltech,group-id : group id of this device + - focaltech,hard-reset-delay-ms : hard reset delay in ms + - focaltech,soft-reset-delay-ms : soft reset delay in ms + - focaltech,fw-delay-aa-ms : specify the delay in ms after programming 0xaa + register for firmware upgrade + - focaltech,fw-delay-55-ms : specify the delay in ms after programming 0x55 + register for firmware upgrade + - focaltech,fw-upgrade-id1 : specify the upgrade id1 for firmware upgrade + - focaltech,fw-upgrade-id2 : specify the upgrade id2 for firmware upgrade + - focaltech,fw-delay-readid-ms : specify the read id delay in ms for firmware upgrade + - focaltech,fw-delay-era-flsh-ms : specify the erase flash delay in ms for firmware upgrade + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + Specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_release" : Release configuration of pins, this should specify + release config defined in pin groups of interrupt and reset gpio. + +Optional properties: + + - focaltech,panel-coords : panel coordinates for the chip in pixels. + It is a four tuple consisting of min x, + min y, max x and max y values. + - focaltech,i2c-pull-up : to specify pull up is required. + - focaltech,no-force-update : to specify force update is allowed. + - focaltech,button-map : button map of key codes. The number + of key codes depend on panel + - focaltech,fw-name : specify the firmware file name + - focaltech,fw-delay-aa-ms : specify the "aa" delay in ms for firmware upgrade + - focaltech,fw-delay-55-ms : specify the "55" delay in ms for firmware upgrade + - focaltech,fw-upgrade-id1 : specify the upgrade id1 for firmware upgrade + - focaltech,fw-upgrade-id2 : specify the upgrade id2 for firmware upgrade + - focaltech,fw-delay-readid-ms : specify the read id delay in ms for firmware upgrade + - focaltech,fw-delay-era-flsh-ms : specify the erase flash delay in ms for firmware upgrade + - focaltech,fw-auto-cal : specify whether calibration is needed after firmware upgrade + - focaltech,fw-vkey-support : specify if virtual keys are supported through firmware + - focaltech,ignore-id-check : specify ignore family-id check + - focaltech,panel-coords : panel coordinates for the chip in pixels. + It is a four tuple consisting of min x, + min y, max x and max y values + - focaltech,fw-name : specify the firmware file name + - focaltech,psensor-support : specify whether support the proximity sensor + - focaltech,gesture-support : specify whether support gesture feature + - focaltech,resume-in-workqueue : specifiy whether to defer the resume to workqueue + - clock-names: : Clock names used for secure touch. They are: "iface_clk", "core_clk" + - clocks : Defined if 'clock-names' DT property is defined. These clocks + are associated with the underlying I2C bus. + +Example: + i2c@f9923000{ + focaltech@38{ + compatible = "focaltech,5x06"; + reg = <0x38>; + interrupt-parent = <&msmgpio>; + interrupts = <1 0x2>; + vdd-supply = <&pm8110_l19>; + vcc_i2c-supply = <&pm8110_l14>; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend","pmx_ts_release"; + pinctrl-0 = <&ts_int_active &ts_reset_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; + pinctrl-2 = <&ts_release>; + focaltech,name = "ft6x06"; + focaltech,family-id = <0x06>; + focaltech,reset-gpio = <&msmgpio 0 0x00>; + focaltech,irq-gpio = <&msmgpio 1 0x00>; + focaltech,display-coords = <0 0 480 800>; + focaltech,panel-coords = <0 0 480 800>; + focaltech,button-map= <139 102 158>; + focaltech,no-force-update; + focaltech,i2c-pull-up; + focaltech,group-id = <1>; + focaltech,hard-reset-delay = <20>; + focaltech,soft-reset-delay = <150>; + focaltech,num-max-touches = <2>; + focaltech,fw-name = "ft_8610_qrd_fw.bin"; + focaltech,fw-delay-aa-ms = <100>; + focaltech,fw-delay-55-ms = <30>; + focaltech,fw-upgrade-id1 = <0x79>; + focaltech,fw-upgrade-id2 = <0x08>; + focaltech,fw-delay-readid-ms = <10>; + focaltech,fw-delay-era-flsh-ms = <2000>; + focaltech,fw-auto-cal; + focaltech,psensor-support; + focaltech,gesture-support; + /* Underlying clocks used by secure touch */ + clock-names = "iface_clk", "core_clk"; + clocks = <&clock_gcc clk_gcc_blsp1_ahb_clk>, + <&clock_gcc clk_gcc_blsp1_qup3_i2c_apps_clk>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/it7258_ts_i2c.txt b/Documentation/devicetree/bindings/input/touchscreen/it7258_ts_i2c.txt new file mode 100644 index 000000000000..3b2c272d7378 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/it7258_ts_i2c.txt @@ -0,0 +1,82 @@ +ITE Tech. touch controller + +The ITE Tech. touch controller is connected to host processor +via i2c. The controller generates interrupts when the user +touches the panel. The host controller is expected to read +the touch coordinates over i2c and pass the coordinates to +the rest of the system. + +Required properties: + + - compatible : should be "ite,it7260_ts" + - reg : i2c slave address of the device + - interrupt-parent : parent of interrupt + - interrupts : touch sample interrupt to indicate presence or release + of fingers on the panel. + - ite,irq-gpio : irq gpio which is to provide interrupts to host, + same as "interrupts" node. It will also + contain active low or active high information. + - ite,reset-gpio : reset gpio to control the reset of chip + - ite,reset-delay : reset delay for controller (ms), default 20 + +Optional properties: + - avdd-supply : Analog power supply needed to power device + - vdd-supply : Power source required to pull up i2c bus + - ite,wakeup : boolean, use this to support touch-to-wake feature. + - ite,palm-detect-en : boolean, use this to send palm-detect-keycode when + palm is detected. + - ite,fw-name : Specify firmware file name in /etc/firmware + - ite,cfg-name : Specify config file name in /etc/firmware + - ite,panel-coords : touch panel min x, min y, max x and + max y resolution + - ite,display-coords : display min x, min y, max x and + max y resolution + - ite,num-fingers : number of fingers supported by the touch controller + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + It should specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_release" : Release configuration of pins, this should specify + release config defined in pin groups of interrupt and reset gpio. + - ite,low-reset : boolean, if the controller needs low-state of the reset gpio while + initializing, and reset gpio should be made as high-state to reset the + controller. It means the controller needs "active-high" reset gpio. + - ite,avdd-lpm-cur : avdd lpm current value(mA) in suspend state. + +Required properties palm-detect-en feature: + - ite,palm-detect-keycode : The keycode that is required to be sent when + palm is detected by the ITE tech driver. + +Example: + i2c@f9927000 { + it7260@46 { + compatible = "ite,it7260_ts"; + reg = <0x46>; + interrupt-parent = <&msmgpio>; + /* pins used by touchscreen */ + pinctrl-names = "pmx_ts_active","pmx_ts_suspend","pmx_ts_release"; + pinctrl-0 = <&ts_int_active &ts_reset_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; + pinctrl-2 = <&ts_release> + interrupts = <17 0x2>; + avdd-supply = <&pm8226_l19>; + vdd-supply = <&pm8226_lvs1>; + ite,reset-gpio = <&msmgpio 16 0x00>; + ite,irq-gpio = <&msmgpio 17 0x2008>; + ite,wakeup; + ite,palm-detect-en; + ite,palm-detect-keycode = <142>; + ite,fw-name = "ite7260_fw.bin"; + ite,cfg-name = "ite7260_cfg.bin"; + ite,panel-coords = <0 0 320 320>; + ite,display-coords = <0 0 320 320>; + ite,num-fingers = <2>; + ite,reset-delay = <20>; + ite,low-reset; + ite,vdd-lpm-cur = <3000>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/maxim-sti.txt b/Documentation/devicetree/bindings/input/touchscreen/maxim-sti.txt new file mode 100644 index 000000000000..c0f29f20b5da --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/maxim-sti.txt @@ -0,0 +1,48 @@ +Maxim STI touch controller: + +Required properties: +- spi-max-frequency: Maximum SPI frequency supported by the controller. +- avdd-supply: analog power supply. +- dvdd-supply: digial power supply. +- maxim_sti,irq-gpio: irq gpio. +- maxim_sti,reset-gpio: reset gpio. +- maxim_sti,touch_fusion: path to touch_fusion daemon. +- maxim_sti,config_file: path to config file. +- maxim_sti,fw_name: name of firmware file. + +Optional properties: + - pinctrl-names : this should be defined if a target uses pinctrl framework. + See "pinctrl" in documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + It should specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : active configuration of pins. This should specify active + config defined in pin groups of interrupt and reset gpios. + "pmx_ts_suspend" : disabled configuration of pins. This should specify sleep + config defined in pin groups of interrupt and reset gpios. + - maxim_sti,mt_type_b_enabled : Boolean type. This should be used to enable type B multitouch protocol. +Example: + +&spi_13 { /* BLSP1 QUP3 */ + status = "ok"; + maxim_sti@0 { + compatible = "maxim,maxim_sti"; + reg = <0>; + interrupt-parent = <&msm_gpio>; + interrupts = <65 0>; + spi-max-frequency = <16000000>; + avdd-supply = <&pm8950_l17>; + dvdd-supply = <&pm8950_l6>; + spi-supply = <&pm8950_l5>; + maxim_sti,irq-gpio = <&msm_gpio 65 0x00>; + maxim_sti,reset-gpio = <&msm_gpio 64 0x00>; + maxim_sti,touch_fusion = "/vendor/bin/touch_fusion"; + maxim_sti,config_file = "/vendor/firmware/touch_fusion_panel_id_0x%04x.cfg"; + maxim_sti,fw_name = "maxim_fp35.bin"; + maxim_sti,mt_type_b_enabled; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend","pmx_ts_release"; + pinctrl-0 = <&ts_int_active &ts_reset_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; + pinctrl-2 = <&ts_release>; + }; +}; + diff --git a/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsx_i2c.txt b/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsx_i2c.txt new file mode 100644 index 000000000000..ebe95f03ea92 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsx_i2c.txt @@ -0,0 +1,115 @@ +Synaptics DSX touch controller + +Required properties: + + - compatible : should be "synaptics,dsx" + - reg : i2c slave address of the device + - interrupt-parent : parent of interrupt + - interrupts : touch sample interrupt to indicate presense or release + of fingers on the panel. + - synaptics,irq-gpio : irq gpio + - synaptics,reset-gpio : reset gpio + - vdd-supply : digital voltage power supply needed to power device + - avdd-supply : analog voltage power supply needed to power device + - synaptics,vdd-voltage : digital voltage range for vdd-supply + - synaptics,avdd-voltage : analog voltage range for avdd-supply + - synaptics,vdd-current : current load for vdd-supply + - synaptics,avdd-current : current load for avdd-supply + +Optional property: + - synaptics,button-map : virtual key code mappings to be used + - synaptics,x-flip : modify orientation of the x axis + - synaptics,y-flip : modify orientation of the y axis + - synaptics,reset-delay-ms : reset delay for controller (ms), default 100 + - synaptics,panel-coords : touch panel min x, min y, max x and + max y resolution + - synaptics,display-coords : display min x, min y, max x and + max y resolution + - synaptics,fw-name : name of firmware .img file in /etc/firmware + - synaptics,disable-gpios : specify this to disable gpios in suspend + - pinctrl-names : This should be defined if a target uses pinctrl framework. + See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt. + It should specify the names of the configs that pinctrl can install in driver. + Following are the pinctrl configs that can be installed: + "pmx_ts_active" : Active configuration of pins, this should specify active + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_suspend" : Disabled configuration of pins, this should specify sleep + config defined in pin groups of interrupt and reset gpio. + "pmx_ts_release" : Release configuration of pins, this should specify + release config defined in pin groups of interrupt and reset gpio. + - synaptics,detect-device : Define this property when two Synaptics Touchscreen controllers + need to be supported without changing the DT. In this case, all + such devices are placed as child nodes of Synaptics touchscreen + node. Following are the properties that can be defined inside + these child nodes: + - synaptics-package-id + - synaptics,panel-coords + - synaptics-display-coords + - synaptics,button-map + - synaptics,key-codes + - clocks : Optional property that represents the clocks associated + with the underlying bus when secure touch is enabled. This property + is required only if secure touch is enabled and used with this driver. + - clock-names: : Clock names used for secure touch. The names are: + "iface_clk", "core_clk". + - synaptics,config-id : Specifies the Config Id of touch controller. + - synaptics,bypass-packrat-id-check : Specifies if packrat ID needs to be ignored for smart + firmware upgrade + +Optional properties inside child node: +These properties are defined only when synaptics,detect-device property is defined in DT. + - synaptics,package-id : Specifies the Package Id of touch controller. + - synaptics,panel-coords : Specifies the Touch panel min x, min y, max x and max y + resolution. + - synaptics,display-coords : Specifies the display min x, min y, max x and max y + resolution. + - synaptics,button-map : Key code mappings to be used when device + supports 0D buttons and directly sends key codes. + - synaptics,key-codes : Virtual key code mappings to be used when device + supports 2D buttons and sends coordinates instead of + key codes. + - synaptics,bypass-sensor-coords-check : Bypass the comparison of sensor coordinates + range read from DT and touch controller. Used when some + touch panels in the field are unprogrammed and misprogrammed. + - synaptics,resume-in-workqueue : specifiy whether to defer the resume to workqueue. + +Example: + i2c@f9927000 { + synaptics@20 { + compatible = "synaptics,dsx"; + reg = <0x20>; + interrupt-parent = <&msmgpio>; + interrupts = <17 0x2>; + vdd-supply = <&pm8226_l19>; + avdd-supply = <&pm8226_lvs1>; + synaptics,vdd-voltage = <1808000 1808000>; + synaptics,avdd-voltage = <3008000 3008000>; + synaptics,vdd-current = <40000>; + synaptics,avdd-current = <20000>; + synaptics,reset-gpio = <&msmgpio 16 0x00>; + synaptics,irq-gpio = <&msmgpio 17 0x00>; + synaptics,reset-delay-ms = <100>; + synaptics,x-flip; + synaptics,y-flip; + synaptics,disable-gpios; + synaptics,fw-name = "PR1610974.img"; + pinctrl-names = "pmx_ts_active","pmx_ts_suspend", "pmx_ts_release"; + pinctrl-0 = <&ts_int_active &ts_reset_active>; + pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>; + pinctrl-2 = <&ts_release>; + synaptics,detect-device; + synaptics,device1 { + synaptics,package-id = <3202>; + synaptics,button-map = <139 172 158>; + }; + synaptics,device2 { + synaptics,package-id = <3408>; + synaptics,display-coords = <0 0 1079 1919>; + synaptics,panel-coords = <0 0 1079 2084>; + synaptics,key-codes = <139 172 158 217>; + }; + clocks = <&clock_gcc clk_gcc_blsp1_ahb_clk>, + <&clock_gcc clk_gcc_blsp1_qup5_i2c_apps_clk>; + clock-names = "iface_clk", "core_clk"; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsxv26_i2c.txt b/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsxv26_i2c.txt new file mode 100644 index 000000000000..c10fd981df2b --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/synaptics_dsxv26_i2c.txt @@ -0,0 +1,57 @@ +Synaptics DSXV26 touch controller + +Please add this description here: The Synaptics Touch controller is connected to the +host processor via I2C. The controller generates interrupts when the user touches +the panel. The host controller is expected to read the touch coordinates over I2C and +pass the coordinates to the rest of the system. + +Required properties: + + - compatible : should be "synaptics,dsx-i2c". + - reg : i2c slave address of the device. + - interrupt-parent : parent of interrupt. + - synaptics,irq-gpio : irq gpio. + - synaptics,irq-flags : irq flags. + +Optional property: + - vdd_ana-supply : digital voltage power supply needed to power device. + - vcc_i2c-supply : analog voltage power supply needed to power device. + - synaptics,pwr-reg-name : power reg name of digital voltage. + - synaptics,bus-reg-name : bus reg name of analog voltage. + - synaptics,irq-on-state : status of irq gpio. + - synaptics,cap-button-codes : virtual key code mappings to be used. + - synaptics,vir-button-codes : virtual key code and the response region on panel. + - synaptics,x-flip : modify orientation of the x axis. + - synaptics,y-flip : modify orientation of the y axis. + - synaptics,reset-delay-ms : reset delay for controller (ms), default 100. + - synaptics,max-y-for-2d : maximal y value of the panel. + - clock-names : Clock names used for secure touch. They are: "iface_clk", "core_clk" + - clocks : Defined if 'clock-names' DT property is defined. These clocks + are associated with the underlying I2C bus. + +Example: + i2c@78b7000 { + status = "ok"; + synaptics@4b { + compatible = "synaptics,dsx-i2c"; + reg = <0x4b>; + interrupt-parent = <&tlmm>; + interrupts = <65 0x2008>; + vdd_ana-supply = <&pmtitanium_l17>; + vcc_i2c-supply = <&pmtitanium_l6>; + synaptics,pwr-reg-name = "vdd_ana"; + synaptics,bus-reg-name = "vcc_i2c"; + synaptics,irq-gpio = <&tlmm 65 0x2008>; + synaptics,irq-on-state = <0>; + synaptics,irq-flags = <0x2008>; /* IRQF_ONESHOT | IRQF_TRIGGER_LOW */ + synaptics,power-delay-ms = <200>; + synaptics,reset-delay-ms = <200>; + synaptics,max-y-for-2d = <1919>; /* remove if no virtual buttons */ + synaptics,cap-button-codes = <139 172 158>; + synaptics,vir-button-codes = <139 180 2000 320 160 172 540 2000 320 160 158 900 2000 320 160>; + /* Underlying clocks used by secure touch */ + clock-names = "iface_clk", "core_clk"; + clocks = <&clock_gcc clk_gcc_blsp1_ahb_clk>, + <&clock_gcc clk_gcc_blsp1_qup3_i2c_apps_clk>; + }; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index 718074501fcb..9e512d1ea763 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -16,6 +16,7 @@ conditions. "arm,mmu-400" "arm,mmu-401" "arm,mmu-500" + "qcom,smmu-v2" depending on the particular implementation and/or the version of the architecture implemented. @@ -55,6 +56,92 @@ conditions. aliases of secure registers have to be used during SMMU configuration. +- qcom,smmu-invalidate-on-map : Enable proper handling of buggy + implementations that require a TLB invalidate + operation to occur at map time. + +- qcom,halt-and-tlb-on-atos : Enable proper handling of buffy + implementations that require a halt and TLB invalidate + before performing ATOS operations. + +- qcom,register-save : Enable register saving awareness. This causes the + driver to assume that configuration registers will retain + their values across gdsc power gating. + +- qcom,skip-init : Disable resetting configuration for all context banks + during device reset. This is useful for targets where + some context banks are dedicated to other execution + environments outside of Linux and those other EEs are + programming their own stream match tables, SCTLR, etc. + Without setting this option we will trample on their + configuration. + +- qcom,errata-ctx-fault-hang : Enable workaround for a context fault hang + hardware errata. + +- qcom,fatal-asf : Enable BUG_ON for address size faults. Some hardware + requires special fixups to recover from address size + faults. Rather than applying the fixups just BUG since + address size faults are due to a fundamental programming + error from which we don't care about recovering anyways. + +- qcom,tz-device-id : A string indicating the device ID for this SMMU known + to TZ. See msm_tz_smmu.c for a full list of mappings. + +- qcom,errata-tz-atos : Enable workaround for an ATOS hardware errata on + Thulium v1. You *must* also set qcom,tz-device-id for + this to work. + +- qcom,no-smr-check : Usually when an SMMU probes we do a sanity check on + the SMR registers to make sure they can fully support all + of the mask bits. This check can cause problems for use + cases where the SMMU is already in use when the SMMU + probes. For example, for continuous splash screen + support, the stream matching table is programmed before + control is even turned over to Linux. + +- qcom,dynamic : Allow dynamic domains to be attached. This is only + useful if the upstream hardware is capable of switching + between multiple domains within a single context bank. + +- qcom,enable-smmu-halt : Before SMMU is powered down, SMMU needs to be in + idle state prior to power collapse. When 'halt' is received by + SMMU, it ensures that no new requests enters and all + outstanding requests are completed and generates an + acknowledgment for halt request. So add an option to register + a call back notifier on regulators in whcih SMMU can be halted + or resumed when regulator is powered down/up. + +- qcom,enable-static-cb : Enables option to use pre-defined static context bank + allocation programmed by TZ. Global register including SMR and + S2CR registers are configured by TZ before kernel comes up and + this programming is not altered throughout the life of system. + We would be reading through these registers at run time to + identify CB allocated for a particular sid. SID masking isn't + supported as we are directly comparing client SID with ID bits + of SMR registers. + +- clocks : List of clocks to be used during SMMU register access. See + Documentation/devicetree/bindings/clock/clock-bindings.txt + for information about the format. For each clock specified + here, there must be a corresponding entery in clock-names + (see below). + +- clock-names : List of clock names corresponding to the clocks specified in + the "clocks" property (above). See + Documentation/devicetree/bindings/clock/clock-bindings.txt + for more info. + +- vdd-supply : Phandle of the regulator that should be powered on during + SMMU register access. + +- attach-impl-defs : global registers to program at device attach + time. This should be a list of 2-tuples of the format: + <offset reg_value>. + +Optional bus bindings as defined in +Documentation/devicetree/bindings/arm/msm/msm_bus.txt may also be present. + Example: smmu { @@ -74,4 +161,8 @@ Example: */ mmu-masters = <&dma0 0xd01d 0xd01e>, <&dma1 0xd11c>; + + attach-impl-defs = <0x124 0x3>, + <0x128 0xa5>, + <0x12c 0x1>; }; diff --git a/Documentation/devicetree/bindings/iommu/iommu-debug.txt b/Documentation/devicetree/bindings/iommu/iommu-debug.txt new file mode 100644 index 000000000000..1d79f1865aa5 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/iommu-debug.txt @@ -0,0 +1,27 @@ +This document describes the device tree binding for IOMMU test devices. + +The iommu-debug framework can optionally make use of some platform devices +for improved standalone testing and other features. + +- compatible: iommu-debug-test + + +Required properties +=================== + +- iommus: The IOMMU for the test device (see iommu.txt) + + +Example +======= + + iommu_test_device { + compatible = "iommu-debug-test"; + /* + * 42 shouldn't be used by anyone on the cpp_fd_smmu. We just + * need _something_ here to get this node recognized by the + * SMMU driver. Our test uses ATOS, which doesn't use SIDs + * anyways, so using a dummy value is ok. + */ + iommus = <&cpp_fd_smmu 42>; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-qpnp-flash-v2.txt b/Documentation/devicetree/bindings/leds/leds-qpnp-flash-v2.txt new file mode 100644 index 000000000000..da54fb11ffd4 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-qpnp-flash-v2.txt @@ -0,0 +1,308 @@ +Qualcomm Technologies Inc. PNP v2 Flash LED + +QPNP (Qualcomm Technologies Inc. Plug N Play) Flash LED (Light +Emitting Diode) driver v2 is used to provide illumination to +camera sensor when background light is dim to capture good +picture. It can also be used for flashlight/torch application. +It is part of PMIC on Qualcomm Technologies Inc. reference platforms. + +Main node: + +Required properties: +- compatible : Should be "qcom,qpnp-flash-led-v2" +- reg : Base address and size for flash LED modules +- qcom,pmic-revid : phandle of PMIC revid module. This is used to + identify the PMIC subtype. + +Optional properties: +- interrupts : Specifies the interrupts associated with flash-led. +- interrupt-names : Specify the interrupt names associated with interrupts. +- qcom,hdrm-auto-mode : Boolean type to select headroom auto mode enabled or not +- qcom,isc-delay-us : Integer type to specify short circuit delay. Valid values are 32, 64, + 128, 192. Unit is uS. +- qcom,warmup-delay-us : Integer type to specify warm up delay. Valid values are 32, 64, + 128, 192. Unit is uS. +- qcom,short-circuit-det : Boolean property which enables short circuit fault detection. +- qcom,open-circuit-det : Boolean property which enables open circuit fault detection. +- qcom,vph-droop-det : Boolean property which enables VPH droop detection. +- qcom,vph-droop-hys-mv : Integer property to specify VPH droop hysteresis. It is only used if + qcom,vph-droop-det is specified. Valid values are 0, 25, 50 and 75. + Unit is mV. +- qcom,vph-droop-thresh-mv : Integer property to specify VPH droop threshold. It is only used if + qcom,vph-droop-det is specified. Valid values are + 2500 to 3200 with step size of 100. Unit is mV. +- qcom,vph-droop-debounce-us : Integer property to specify VPH droop debounce time. It is only used + if qcom,vph-droop-det is specified. Valid values are 0, 8, 16 and 26. + Unit is uS. +- qcom,led1n2-iclamp-low-ma : Integer property to specify current clamp low + level for mitigation. Unit is mA. Allowed + values are same as under qcom,max-current. +- qcom,led1n2-iclamp-mid-ma : Integer property to specify current clamp mid + level for mitigation. Unit is mA. Allowed + values are same as under qcom,max-current. +- qcom,led3-iclamp-low-ma : Integer property to specify current clamp low + level for mitigation. Unit is mA. Allowed + values are same as under qcom,max-current. +- qcom,led3-iclamp-mid-ma : Integer property to specify current clamp mid + level for mitigation. Unit is mA. Allowed + values are same as under qcom,max-current. +- qcom,vled-max-uv : Integer property for flash current predictive mitigation. + Default value is 3500000 uV. +- qcom,ibatt-ocp-threshold-ua : Integer property for flash current predictive mitigation. + Default value is 4500000 uA. +- qcom,rparasitic-uohm : Integer property for flash current predictive mitigation indicating + parasitic component of battery resistance. Default value is 0 uOhm. +- qcom,lmh-ocv-threshold-uv : Required property for flash current preemptive LMH mitigation. + Default value is 3700000 uV. +- qcom,lmh-rbatt-threshold-uohm : Required property for flash current preemptive LMH mitigation. + Default value is 400000 uOhm. +- qcom,lmh-mitigation-sel : Optional property to configure flash current preemptive LMH mitigation. + Accepted values are: + 0: MITIGATION_DISABLED + 1: MITIGATION_BY_ILED_THRESHOLD + 2: MITIGATION_BY_SW + Default value is 2. +- qcom,chgr-mitigation-sel : Optional property to configure flash current preemptive charger mitigation. + Accepted values are: + 0: MITIGATION_DISABLED + 1: MITIGATION_BY_ILED_THRESHOLD + 2: MITIGATION_BY_SW + Default value is 2. +- qcom,lmh-level : Optional property to configure flash current preemptive LMH mitigation. + Accepted values are 0, 1, and 3. Default value is 0. +- qcom,iled-thrsh-ma : Optional property to configure the led current threshold at which HW + preemptive mitigation is triggered. Unit is mA. Default value is 1000. + Accepted values are in the range 0 - 3100, with steps of 100. + 0 disables autonomous HW mitigation. +- qcom,thermal-derate-en : Boolean property to enable flash current thermal mitigation. +- qcom,thermal-derate-current : Array of currrent limits for thermal mitigation. Required if + qcom,thermal-derate-en is specified. Unit is mA. Format is + qcom,thermal-derate-current = <OTST1_LIMIT, OTST2_LIMIT, OTST3_LIMIT>. +- qcom,otst-ramp-back-up-dis : Boolean property to disable current ramp + backup after thermal derate trigger is + deasserted. +- qcom,thermal-derate-slow : Integer property to specify slow ramping + down thermal rate. Unit is in uS. Allowed + values are: 128, 256, 512, 1024, 2048, 4096, + 8192 and 314592. +- qcom,thermal-derate-fast : Integer property to specify fast ramping + down thermal rate. Unit is in uS. Allowed + values are: 32, 64, 96, 128, 256, 384 and + 512. +- qcom,thermal-debounce : Integer property to specify thermal debounce + time. It is only used if qcom,thermal-derate-en + is specified. Unit is in uS. Allowed values + are: 0, 16, 32, 64. +- qcom,thermal-hysteresis : Integer property to specify thermal derating + hysteresis. Unit is in deciDegC. It is only + used if qcom,thermal-derate-en is specified. + Allowed values are: + 0, 15, 30, 45 for pmi8998. + 0, 20, 40, 60 for pm660l. +- qcom,thermal-thrsh1 : Integer property to specify OTST1 threshold + for thermal mitigation. Unit is in Celsius. + Accepted values are: + 85, 79, 73, 67, 109, 103, 97, 91. +- qcom,thermal-thrsh2 : Integer property to specify OTST2 threshold + for thermal mitigation. Unit is in Celsius. + Accepted values are: + 110, 104, 98, 92, 134, 128, 122, 116. +- qcom,thermal-thrsh3 : Integer property to specify OTST3 threshold + for thermal mitigation. Unit is in Celsius. + Accepted values are: + 125, 119, 113, 107, 149, 143, 137, 131. +- qcom,hw-strobe-option : Integer type to specify hardware strobe option. Based on the specified + value, additional GPIO configuration may be required to provide strobing + support. Supported values are: + 0: Flash strobe is used for LED1, LED2, LED3 + 1: Flash strobe is used for LED1, LED2 and GPIO10 is used for LED3 + 2: Flash strobe is used for LED1; GPIO9 is used for LED2; GPIO10 is used for LED3 +- switchX-supply : phandle of the regulator that needs to be used + as a supply for flash switch_X device. + +Child node: Contains settings for each individual LED. Each LED channel needs a flash node and +torch node for itself, and an individual switch node to serve as an overall switch. + +Required Properties: +- label : Type of led that will be used, either "flash", "torch", or "switch. +- qcom,led-name : Name of the LED. +- qcom,default-led-trigger : Trigger for the camera flash and torch. Accepted values are + "flash0_trigger", "flash1_trigger", "flash2_trigger, "torch0_trigger", + "torch1_trigger", "torch2_trigger", and "switch_trigger". +- qcom,id : ID for each physical LED equipped. In order to handle situation when + only 1 or 2 LEDs are installed, flash and torch nodes on LED channel 0 + should be specified with ID 0; nodes on channel 1 be ID 1, etc. This is + not required for switch node. +- qcom,max-current : Maximum current allowed on this LED. Valid values should be + integer from 0 to 1500 inclusive. Flash 2 should have maximum current of + 750 per hardware requirement. Unit is mA. For torch, the maximum current + is clamped at 500 mA. This is not required for the switch node. +- qcom,duration-ms : Required property for flash nodes but not needed for torch. Integer + type specifying flash duration. Values are from 10ms to 1280ms with + 10ms resolution. This is not required for switch node. +- qcom,led-mask : Required property for switch nodes. Bitmask to indicate which leds are + controlled by this switch node. Accepted values are in the range 1 to 7, + inclusive. Example: + qcom,led-mask = <4>; /* This switch node controls the flash2/torch2 led. */ + +Optional properties: +- qcom,current-ma : operational current intensity for LED in mA. Accepted values are a + positive integer in the range of 0 to qcom,max-current inclusive. +- qcom,ires-ua : Integer type to specify current resolution. Accepted values should be + 12500, 10000, 7500, and 5000. Unit is uA. +- qcom,hdrm-voltage-mv : Integer type specifying headroom voltage. Values are from 125mV to 500mV + with 25mV resolution. Default setting is 325mV +- qcom,hdrm-vol-hi-lo-win-mv : Integer type to specify headroom voltage swing range. Values are + from 0mV to 375mV with 25mV resolution. Default setting is 100mV. +- pinctrl-names : Name of the pinctrl configuration that will be used when external GPIOs + are used for enabling/disabling, HW strobing of flash LEDs. For more + information on using pinctrl, please refer + Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt + Following are the pinctrl configs that can be specified: + "led_enable" : pinctrl config to enable led. This should specify the active + configuration defined for each pin or pin group. + "led_disable" : pinctrl config to disable led. This should specify the sleep + configuration defined for each pin or pin group. + "strobe_enable" : pinctrl config to enable hw-strobe. This should specify the + active configuration defined for each pin or pin group. + "strobe_disable" : pinctrl config to disable hw-strobe. This should specify the + sleep configuration defined for each pin or pin group. +- qcom,hw-strobe-gpio : phandle to specify GPIO for hardware strobing. This is used when there is no + pinctrl support or PMIC GPIOs are used. +- qcom,hw-strobe-sel : Boolean property to enable hardware strobe. If not defined, software strobe + will be used. +- qcom,hw-strobe-edge-trigger : Boolean property to select trigger type. If defined, hw-strobe is set to + be edge triggered. Otherwise, it is level triggered. +- qcom,hw-strobe-active-low : Boolean property to select strobe signal polarity. If defined, hw-strobe + signal polarity is set to active-low, else it is active-high. +Example: + qcom,leds@d300 { + compatible = "qcom,qpnp-flash-led-v2"; + status = "okay"; + reg = <0xd300 0x100>; + label = "flash"; + interrupts = <0x3 0xd3 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x5 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x6 IRQ_TYPE_EDGE_BOTH>, + <0x3 0xd3 0x7 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "led-fault-irq", + "mitigation-irq", + "flash-timer-exp-irq", + "all-ramp-down-done-irq", + "all-ramp-up-done-irq", + "led3-ramp-up-done-irq", + "led2-ramp-up-done-irq", + "led1-ramp-up-done-irq"; + + qcom,hdrm-auto-mode; + qcom,isc-delay = <192>; + switch0-supply = <&pmi8998_bob>; + + pmi8998_flash0: qcom,flash_0 { + label = "flash"; + qcom,led-name = "led:flash_0"; + qcom,max-current = <1500>; + qcom,default-led-trigger = + "flash0_trigger"; + qcom,id = <0>; + qcom,current-ma = <1000>; + qcom,duration-ms = <1280>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + }; + + pmi8998_flash1: qcom,flash_1 { + label = "flash"; + qcom,led-name = "led:flash_1"; + qcom,max-current = <1500>; + qcom,default-led-trigger = + "flash1_trigger"; + qcom,id = <1>; + qcom,current-ma = <1000>; + qcom,duration-ms = <1280>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + }; + + pmi8998_flash2: qcom,flash_2 { + label = "flash"; + qcom,led-name = "led:flash_2"; + qcom,max-current = <750>; + qcom,default-led-trigger = + "flash2_trigger"; + qcom,id = <2>; + qcom,current-ma = <500>; + qcom,duration-ms = <1280>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + pinctrl-names = "led_enable","led_disable"; + pinctrl-0 = <&led_enable>; + pinctrl-1 = <&led_disable>; + }; + + pmi8998_torch0: qcom,torch_0 { + label = "torch"; + qcom,led-name = "led:torch_0"; + qcom,max-current = <500>; + qcom,default-led-trigger = + "torch0_trigger"; + qcom,id = <0>; + qcom,current-ma = <300>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + }; + + pmi8998_torch1: qcom,torch_1 { + label = "torch"; + qcom,led-name = "led:torch_1"; + qcom,max-current = <500>; + qcom,default-led-trigger = + "torch1_trigger"; + qcom,id = <1>; + qcom,current-ma = <300>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + }; + + pmi8998_torch2: qcom,torch_2 { + label = "torch"; + qcom,led-name = "led:torch_2"; + qcom,max-current = <500>; + qcom,default-led-trigger = + "torch2_trigger"; + qcom,id = <2>; + qcom,current-ma = <300>; + qcom,ires-ua = <12500>; + qcom,hdrm-voltage-mv = <325>; + qcom,hdrm-vol-hi-lo-win-mv = <100>; + pinctrl-names = "led_enable","led_disable"; + pinctrl-0 = <&led_enable>; + pinctrl-1 = <&led_disable>; + }; + + pmi8998_switch0: qcom,led_switch_0 { + label = "switch"; + qcom,led-name = "led:switch_0"; + qcom,led-mask = <3>; + qcom,default-led-trigger = + "switch0_trigger"; + }; + + pmi8998_switch1: qcom,led_switch_1 { + label = "switch"; + qcom,led-name = "led:switch_1"; + qcom,led-mask = <4>; + qcom,default-led-trigger = + "switch1_trigger"; + }; + }; + diff --git a/Documentation/devicetree/bindings/leds/leds-qpnp-wled.txt b/Documentation/devicetree/bindings/leds/leds-qpnp-wled.txt new file mode 100644 index 000000000000..1e6aac56c44e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-qpnp-wled.txt @@ -0,0 +1,124 @@ +Qualcomm Technologies QPNP WLED + +QPNP (Qualcomm Technologies Plug N Play) WLED (White Light +Emitting Diode) driver is used for controlling display +backlight that is part of PMIC on Qualcomm Technologies +reference platforms. The PMIC is connected to the host +processor via SPMI bus. + +Required properties: +- compatible : should be "qcom,qpnp-wled" +- reg : base address and size for wled modules +- reg-names : names associated with base addresses. It + should be "qpnp-wled-ctrl-base", "qpnp-wled-sink-base", + "qpnp-wled-ibb-base", "qpnp-wled-lab-base". +- qcom,pmic-revid : phandle of PMIC revid module. This is used to + identify the PMIC subtype. + +Optional properties for WLED: + - interrupts : Specifies the interrupts associated with WLED. The available + interrupts are over voltage protection(ovp) and short circuit(sc). + The values for ovp and sc are <0x3 0xd8 0x1> and <0x3 0xd8 0x2>. + - interrupt-names : Specify the interrupt names associated with interrupts. Must be + one of "ovp-irq" or "sc-irq" +- linux,name : name of the wled. default is "wled". +- linux,default-trigger : trigger for the backlight. default is NONE. +- qcom,fdbk-output : string feedback current output for wled module. The accepted values + are "wled1", "wled2", "wled3", "wled4" and "auto". default is "auto". +- qcom,vref-uv : maximum reference voltage in uV. + For pmi8994/8952/8996, supported values are from 300000 to 675000 + with a step size of 25000, the default value is 350000. + For pmi8998/pm660l, supported values are from 60000 to 397500 + with a step size of 22500, the default value is 127500. +- qcom,switch-freq-khz : switch frequency in khz. default is 800. +- qcom,ovp-mv : Over voltage protection threshold in mV. Default is + 29500. Supported values are: + - 31000, 29500, 19400, 17800 for pmi8994/8952/8996. + - 31100, 29600, 19600, 18100 for pmi8998/pm660l. + Should only be used if qcom,disp-type-amoled is not + specified. +- qcom,ilim-ma : Current limit threshold in mA. + For pmi8994/8952/8996, default value for LCD is 980mA + and AMOLED is 385mA. + Supported values are: + - 105, 385, 660, 980, 1150, 1420, 1700, 1980. + For pmi8998/pm660l, default value for LCD is + 970mA and AMOLED is 620mA. + Supported values are: + - 105, 280, 450, 620, 970, 1150, 1300, 1500. +- qcom,boost-duty-ns : maximum boost duty cycle in ns. default is 104. +- qcom,mod-freq-khz : modulation frequency in khz. default is 9600. +- qcom,dim-mode : dimming mode. supporting dimming modes are "analog", + "digital", and "hybrid". default is "hybrid". +- qcom,hyb-thres : threshold value when used in hybrid mode. It represents the + percentage of brightntess at which dimming mode is switched + from "digital" to "analog". the default value is 6.25%. as the + floating point cannot be represented directly, the value is + multiplied by 100. so the default is 625. +- qcom,sync-dly-us : delay for current sync in us. default is 400. +- qcom,fs-curr-ua : maximum full scale current in ua. default is 25000. +- qcom,en-9b-dim-res : boolean, specify if 9-bit dim resultion is needed. otherwise 12-bit is used. +- qcom,en-phase-stag : boolean, specify if phase staggering is needed. +- qcom,en-cabc : boolean, specify if cabc (content adaptive backlight control) is needed. +- qcom,disp-type-amoled : specify if the display is amoled +- qcom,led-strings-list : Wled module has four strings of leds numbered from 0 to 3. each string of leds + are operated individually. specify the list of strings used by the device. + any combination of led strings can be used. default value is [00 01 02 03] +- qcom,en-ext-pfet-sc-pro : Specify if external pfet short circuit protection is needed +- qcom,cons-sync-write-delay-us : Specify in 'us' the duration of delay between two consecutive writes to + SYNC register. +- qcom,sc-deb-cycles : debounce time for short circuit detection +- qcom,loop-ea-gm : control the gm for gm stage in control loop. default is 3. +- qcom,loop-auto-gm-en : A boolean property to specify if auto gm is enabled. +- qcom,loop-auto-gm-thresh : Specify auto gm threshold if "loop-auto-gm-en" is defined. + Supported values are: 0 - 3. +- qcom,lcd-auto-pfm-thresh : Specify the auto-pfm threshold, if the headroom voltage level + falls below this threshold and auto PFM is enabled, boost + controller will enter into PFM mode automatically. +- qcom,lcd-psm-ctrl : A boolean property to specify if PSM needs to be + controlled dynamically when WLED module is enabled + or disabled. + +Optional properties if 'qcom,disp-type-amoled' is mentioned in DT: +- qcom,loop-comp-res-kohm : control to select the compensation resistor in kohm. default is 320. +- qcom,vref-psm-mv : reference psm voltage in mv. default for amoled is 450. +- qcom,avdd-mode-spmi: Boolean property to enable AMOLED_VOUT programming via SPMI. If not specified, + AMOLED_VOUT is programmed via S-wire. This can be specified only for newer + PMICs like pmi8998/pm660l. +- qcom,avdd-target-voltage-mv: The voltage required for AMOLED_VOUT. Accepted values are in the range + of 5650 to 7900 in steps of 150. Default value is 7600. Unit is in mV. + For old revisions, accepted values are: 7900, 7600, 7300, 6400, 6100, + 5800. + +Example: + qcom,leds@d800 { + compatible = "qcom,qpnp-wled"; + reg = <0xd800 0x100>, + <0xd900 0x100>, + <0xdc00 0x100>, + <0xde00 0x100>; + reg-names = "qpnp-wled-ctrl-base", + "qpnp-wled-sink-base", + "qpnp-wled-ibb-base", + "qpnp-wled-lab-base"; + interrupts = <0x3 0xd8 0x2>; + interrupt-names = "sc-irq"; + status = "okay"; + linux,name = "wled"; + linux,default-trigger = "bkl-trigger"; + qcom,fdbk-output = "auto"; + qcom,vref-uv = <350000>; + qcom,switch-freq-khz = <800>; + qcom,ovp-mv = <29500>; + qcom,ilim-ma = <980>; + qcom,boost-duty-ns = <26>; + qcom,mod-freq-khz = <9600>; + qcom,dim-mode = "hybrid"; + qcom,dim-method = "linear"; + qcom,hyb-thres = <625>; + qcom,sync-dly-us = <800>; + qcom,fs-curr-ua = <16000>; + qcom,en-phase-stag; + qcom,led-strings-list = [00 01 02 03]; + qcom,en-ext-pfet-sc-pro; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-qpnp.txt b/Documentation/devicetree/bindings/leds/leds-qpnp.txt new file mode 100644 index 000000000000..85e097586466 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-qpnp.txt @@ -0,0 +1,358 @@ +Qualcomm Technologies, Inc. QPNP LEDs + +Qualcomm Technologies, Inc. Plug N Play (QPNP) LED modules +are used for controlling LEDs that are connected to a QPNP PMIC. +The PMIC is connected to a host processor via the SPMI bus. Various +LED modules are supported such as Keypad backlight, WLED (white LED), +RGB LED and flash LED. + +Each LED module is represented as a node of "leds-qpnp". This +node will further contain the type of LED supported and its +properties. At least one child node is required for each LED +module. Each must have the required properties below, in addition +to the properties for the LED type, WLED, Flash, RGB and MPP. + +Required properties for each child node, WLED, Flash and RGB: +- compatible : should be "qcom,leds-qpnp" +- qcom,id : must be one of values supported in enum qpnp_led +- label : type of led that will be used, ie "wled" +- qcom,max-current : maximum current that the LED can sustain in mA +- linux,name : name of the led that is used in led framework + +Optional properties for each child node, WLED, Flash, MPP, RGB and KPDBL: +- qcom,in-order-command-processing : specify if user space requests leds in order + +WLED is primarily used as display backlight. Display subsystem uses +LED triggers for WLED to control the brightness as needed. + +Optional properties for WLED: +- qcom,num-strings: number of wled strings to be configured +- qcom,num-physical-strings: number of physical wled strings supported +- qcom,ovp-val: over voltage protection threshold, + follows enum wled_ovp_threshold +- qcom,boost-curr-lim: boot currnet limit, follows enum wled_current_bost_limit +- qcom,ctrl-delay-us: delay in activation of led +- qcom,dig-mod-gen-en: digital module generator +- qcom,cs-out-en: current sink output enable +- qcom,op-fdbck: selection of output as feedback for the boost, 00 = automatic selection, 01 = select LED1 output, 02 = select LED2 output, 03 = select LED3 output +- qcom,cp-select: high pole capacitance +- linux,default-trigger: trigger the led from external modules such as display +- qcom,default-state: default state of the led, should be "on" or "off" + +Flash is used primarily as a camera or video flash. + +Optional properties for flash: +- qcom,headroom: headroom to use. Values should be 0, 1, 2, 3 for 250mV, 300mV, 400mV and 500mV +- qcom,duration: duration of the flash and torch, 10ms - 1280ms for flash and 2s - 33s for torch +- qcom,clamp-curr: current to clamp at, mA +- qcom,startup-dly: delay before flashing after flash executed. Values should 0, 1, 2, 3 for 10us, 32us, 64us, and 128us +- qcom,saftey-timer: include for safety timer use, otherwise watchdog timer will be used +- linux,default-trigger: trigger the led from external modules such as display +- qcom,default-state: default state of the led, should be "on" or "off" +- qcom,torch-enable: set flash led to torch mode functionality and triggers software workaround for torch if hardware does not support +- qcom,sw_vreg_ok: Specify if software strobe is used to inform the readiness of flash module to fire the flash LED when there is no smbb support +- qcom,no-smbb-support: Specify if smbb boost is not required and there is a single regulator for both flash and torch. +- flash-boost-supply: SMBB regulator for LED flash mode +- torch-boost-supply: SMBB regulator for LED torch mode +- flash-wa-supply: SMBB regulator for flash workarounds. + +RGB Led is a tri-colored led, Red, Blue & Green. + +Required properties for RGB led: +- qcom,mode: mode the led should operate in, options "pwm" and "lpg". "manual" mode is not supported for RGB led. + +Required properties for PWM mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) + +Required properties for LPG mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) +- qcom,duty-pcts: array of values for duty cycle to go through +- qcom,start-idx: starting point duty-pcts array + +Optional properties for LPG mode only: +- qcom,pause-lo: pause at low end of cycle +- qcom,pause-hi: pause at high end of cycle +- qcom,ramp-step-ms: step between each cycle (ms) +- qcom,lut-flags: flags to be used in lut configuration + +Optional properties for RGB led: +- linux,default-trigger: trigger the led from external modules such as display +- qcom,default-state: default state of the led, should be "on" or "off" +- qcom,turn-off-delay-ms: delay in millisecond for turning off the led when its default-state is "on". Value is being ignored in case default-state is "off". +- qcom,use-blink: Use blink sysfs entry for switching into lpg mode. For optimal use, set default mode to pwm. All required lpg parameters must be supplied. + +MPP LED is an LED controlled through a Multi Purpose Pin. + +Optional properties for MPP LED: +- linux,default-trigger: trigger the led from external modules such as display +- qcom,default-state: default state of the led, should be "on" or "off" +- qcom,source-sel: select power source, default 1 (enabled) +- qcom,mode-ctrl: select operation mode, default 0x60 = Mode Sink +- qcom,mode: mode the led should operate in, options "pwm", "lpg" and "manual" +- qcom,vin-ctrl: select input source, supported values are 0 to 3 +- qcom,use-blink: Use blink sysfs entry for switching into lpg mode. For optimal use, set default mode to pwm. All required lpg parameters must be supplied. +- qcom,min-brightness - Lowest possible brightness supported on this LED other than 0. +- qcom,current-setting: default current value for wled used as button backlight in mA +- mpp-power-supply: regulator support for MPP LED +- qcom,mpp-power-max-voltage - maximum voltage for MPP LED regulator. This should not be specified when no regulator is in use. +- qcom,mpp-power-min-voltage - minimum voltage for MPP LED regulator. This should not be specified when no regulator is in use. + +Required properties for PWM mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) + +Required properties for LPG mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) +- qcom,duty-pcts: array of values for duty cycle to go through +- qcom,start-idx: starting point duty-pcts array + +Optional properties for LPG mode only: +- qcom,pause-lo: pause at low end of cycle +- qcom,pause-hi: pause at high end of cycle +- qcom,ramp-step-ms: step between each cycle (ms) +- qcom,lut-flags: flags to be used in lut configuration + +Keypad backlight is a backlight source for buttons. It supports four rows +and the required rows are enabled by specifying values in the properties. + +Required properties for keypad backlight: +- qcom,mode: mode the led should operate in, options "pwm" and "lpg". "manual" mode is not supported for keypad backlight. +- qcom,row-id: specify the id of the row. Supported values are 0 to 3. + +Optional properties for keypad backlight: +- qcom,row-src-vbst: select source for rows. Specify for vbst and ignore it + for vph_pwr. +- qcom,row-src-en: specify to enable row source +- qcom,always-on: specify if the module has to be always on +- qcom,use-blink: Use blink sysfs entry for switching into lpg mode. For optimal use, set default mode to pwm. All required lpg parameters must be supplied. + +Required properties for PWM mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) + +Required properties for LPG mode only: +- pwms: Use the phandle of pwm device +- qcom,pwm-us: time the pwm device will modulate at (us) +- qcom,duty-pcts: array of values for duty cycle to go through +- qcom,start-idx: starting point duty-pcts array + +Optional properties for LPG mode only: +- qcom,pause-lo: pause at low end of cycle +- qcom,pause-hi: pause at high end of cycle +- qcom,ramp-step-ms: step between each cycle (ms) +- qcom,lut-flags: flags to be used in lut configuration + +GPIO LED is an LED controlled through a PMIC GPIO. + +Optional properties for GPIO LED: +- linux,default-trigger: trigger the led from external modules such as charging +- qcom,default-state: default state of the led, should be "on" or "off" +- qcom,turn-off-delay-ms: delay in millisecond for turning off the led when its default-state is "on". Value is being ignored in case default-state is "off". +- qcom,source-sel: select power source, default 1 (enabled) +- qcom,mode-ctrl: select operation mode, default 0x60 = Mode Sink +- qcom,vin-ctrl: select input source, supported values are 0 to 7 + +Example: + + qcom,leds@a100 { + status = "okay"; + qcom,led_mpp_2 { + label = "mpp"; + linux,name = "button-backlight"; + linux,default-trigger = "hr-trigger"; + qcom,default-state = "off"; + qcom,current-setting = <20>; + qcom,max-current = <40>; + qcom,id = <6>; + qcom,source-sel = <1>; + qcom,mode-ctrl = <0x61>; + qcom,mode = "manual"; + }; + }; + + qcom,leds@a200 { + status = "okay"; + qcom,led_mpp_3 { + label = "mpp"; + linux,name = "wled-backlight"; + linux-default-trigger = "none"; + qcom,default-state = "on"; + qcom,max-current = <40>; + qcom,id = <6>; + qcom,source-sel = <1>; + qcom,mode-ctrl = <0x10>; + qcom,vin-ctrl = <0x03>; + qcom,min-brightness = <20>; + }; + }; + + qcom,leds@a300 { + status = "okay"; + qcom,led_mpp_pwm { + label = "mpp"; + linux,name = "green"; + linux,default-trigger = "none"; + qcom,default-state = "off"; + qcom,max-current = <40>; + qcom,current-setting = <5>; + qcom,id = <6>; + qcom,mode = "pwm"; + qcom,source-sel = <8>; + qcom,mode-ctrl = <0x60>; + pwms = <&pm8941_pwm_1 0 0>; + qcom,pwm-us = <1000>; + }; + }; + + qcom,leds@d000 { + status = "okay"; + qcom,rgb_pwm { + label = "rgb"; + linux,name = "led:rgb_red"; + qcom,mode = "pwm"; + qcom,pwm-us = <1000>; + pwms = <&pm8941_pwm_7 0 0>; + qcom,max-current = <12>; + qcom,default-state = "off"; + qcom,id = <3>; + linux,default-trigger = + "battery-charging"; + }; + qcom,rgb_lpg { + label = "rgb"; + linux,name = "led:rgb_green"; + qcom,mode = "lpg"; + pwms = <&pm8941_pwm_6 0 0>; + qcom,pwm-us = <1000>; + qcom,duty-ms = <20>; + qcom,start-idx = <1>; + qcom,idx-len = <10>; + qcom,duty-pcts = [00 19 32 4B 64 + 64 4B 32 19 00]; + qcom,max-current = <12>; + qcom,default-state = "off"; + qcom,id = <3>; + linux,default-trigger = + "battery-charging"; + }; + + qcom,rgb_blink { + label = "rgb"; + linux,name = "led:rgb_blue"; + qcom,mode = "pwm"; + pwms = <&pm8941_pwm_5 0 0>; + qcom,start-idx = <1>; + qcom,idx-len = <10>; + qcom,duty-pcts = [00 19 32 4B 64 + 64 4B 32 19 00]; + qcom,lut-flags = <3>; + qcom,pause-lo = <0>; + qcom,pause-hi = <0>; + qcom,ramp-step-ms = <255>; + qcom,max-current = <12>; + qcom,default-state = "on"; + qcom,turn-off-delay-ms = <500>; + qcom,id = <5>; + linux,default-trigger = "none"; + qcom,pwm-us = <1000>; + qcom,use-blink; + }; + }; + + qcom,leds@d300 { + compatible = "qcom,leds-qpnp"; + status = "okay"; + flash-boost-supply = <&pm8941_chg_boost>; + torch-boost-supply = <&pm8941_boost>; + qcom,flash_0 { + qcom,max-current = <1000>; + qcom,default-state = "off"; + qcom,headroom = <0>; + qcom,duration = <200>; + qcom,clamp-curr = <200>; + qcom,startup-dly = <1>; + qcom,safety-timer; + label = "flash"; + linux,default-trigger = + "flash0_trigger"; + linux,name = "led:flash_0"; + qcom,current = <625>; + qcom,id = <1>; + qcom,no-torch-module; + }; + }; + + qcom,leds@d800 { + compatible = "qcom,leds-qpnp"; + status = "okay"; + qcom,wled_0 { + linux,default-trigger = "bkl-trigger" + label = "wled"; + qcom,cs-out-en; + qcom,op-fdbck = <1>; + qcom,default-state "off"; + qcom,max-current = <25>; + qcom,ctrl-delay-us = <0>; + qcom,boost-curr-lim = <3>; + qcom,cp-sel = <0>; + qcom,switch-freq = <2>; + qcom,ovp-val = <2>; + qcom,num-strings = <1>; + qcom,id = <0>; + linux,name = "led:wled_backlight"; + }; + }; + + qcom,leds@e200 { + status = "okay"; + + qcom,kpdbl1 { + label = "kpdbl"; + linux,name = "kpdbl-pwm-1"; + qcom,mode = <0>; + pwms = <&pm8941_pwm_9 0 0>; + qcom,pwm-us = <1000>; + qcom,id = <7>; + qcom,max-current = <20>; + qcom,row-id = <0>; + qcom,row-src-en; + qcom,always-on; + }; + + qcom,kpdbl2 { + label = "kpdbl"; + linux,name = "kpdbl-lut-2"; + qcom,mode = <1>; + pwms = <&pm8941_pwm_10 0 0>; + qcom,pwm-us = <1000>; + qcom,start-idx = <1>; + qcom,duty-pcts = [00 00 00 00 64 + 64 00 00 00 00]; + qcom,id = <7>; + qcom,max-current = <20>; + qcom,row-id = <1>; + qcom,row-src-en; + }; + + }; + + qcom,leds@c900 { + compatible = "qcom,leds-qpnp"; + reg = <0xc900 0x100>; + status = "okay"; + qcom,led_gpio_10 { + label = "gpio"; + linux,name = "led:notification"; + qcom,max-current = <40>; + qcom,id = <8>; + linux,default-trigger = "notification"; + qcom,default-state = "on"; + qcom,turn-off-delay-ms = <1000>; + qcom,source-sel = <1>; + qcom,mode-ctrl = <0x10>; + qcom,vin-ctrl = <0x02>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/video/laser-sensor.txt b/Documentation/devicetree/bindings/media/video/laser-sensor.txt new file mode 100644 index 000000000000..1bcb0b93cb10 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/laser-sensor.txt @@ -0,0 +1,28 @@ +Laser Sensor Device Tree Bindings. +======================================== + +Boards with the Laser Sensor connected to CCI shall have the following +properties: + +Required node properties: + - cell-index: cci hardware core index + - compatible: + - "st,stmvl53l0" : STMiecroelectronics VL53L0 Laser sensor. + - reg : offset and length of the register set for the device + - qcom, cci-master: cci master the sensor connected to + - cam_cci-supply : cci voltage regulator used + - cam_laser-supply: laser sensor voltage regulator + - qcom,cam-vreg-name: voltage regulators name + - qcom, cam-vreg-min-voltage: specify minimum voltage level for + regulators used + - qcom, cam-vreg-max-voltage: specify maximum voltage level for + regulators used + - pinctrl-names : should specify the pin control groups followed by + the definition of each group + - gpios : should contain phandle to gpio controller node and array of + #gpio-cells specifying specific gpio (controller specific) + - qcom,gpio-req-tbl-num : contains index to gpios specific to the sensor + - qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) + - qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) diff --git a/Documentation/devicetree/bindings/media/video/msm-cam-smmu.txt b/Documentation/devicetree/bindings/media/video/msm-cam-smmu.txt new file mode 100644 index 000000000000..b078cb9ab374 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-cam-smmu.txt @@ -0,0 +1,37 @@ +* Qualcomm Technologies, Inc. MSM Camera SMMU + +[Root level node] +The complete set of context banks for camera are encapsulated under this +root node. Each second level node encapsulates the information related to +the corresponding context bank. During the kernel initialization all +the devices are probed recursively and a device pointer is created for +each context bank keeping track of the virtual address mapping information. + +Required properties: +- compatible : + - "qcom,msm-cam-smmu" + +[Second level nodes] +Required properties: +- compatible : one of: + - "qcom,msm-cam-smmu-cb" + - "qcom,qsmmu-cam-cb" +- iommus : Handle parsed by smmu driver. Number of entries will vary + across targets. +- label - string describing iommu domain usage. + +Optional properties: +- qcom,scratch-buf-support : Enables iommu scratch buffer support in + that context bank. + +Example: + qcom,cam_smmu@0 { + compatible = "qcom,msm-cam-smmu"; + msm_cam_smmu_cb1: msm_cam_smmu_cb1 { + compatible = "qcom,msm-cam-smmu-cb"; + iommus = <&vfe_iommu 0>; + label = "vfe"; + qcom,scratch-buf-support; + } + } + diff --git a/Documentation/devicetree/bindings/media/video/msm-cam-soc.txt b/Documentation/devicetree/bindings/media/video/msm-cam-soc.txt new file mode 100644 index 000000000000..382395fa5365 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-cam-soc.txt @@ -0,0 +1,41 @@ +* Qualcomm Technologies, Inc. MSM Camera SOC + +The below set of properties need to be defined by all the camera +modules in their respective dtsi to adapt to SOC layer + +Required properties: + - clock-names: name of the clocks required for the device + - qcom,clock-rates: clock rate in Hz + - 0 if appropriate clock is required but doesn't have to apply the rate + - qcom,vdd-names: names of all the regulators for the device + - Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + - qcom,msm-bus-vector-dyn-vote: indicated dynamic or static voting + - qcom,clock-cntl-support: indicates if further control supported for clocks + - Refer to "Documentation/devicetree/bindings/media/video/msm-ispif.txt" for + below optional property: + - qcom,clock-control + +Example: + + cpp: qcom,cpp@a04000 { + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_cpp>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clock-names = "camss_top_ahb_clk", + "ispif_ahb_clk", "csiphy_timer_src_clk", + "csiphy_timer_clk"; + qcom,clock-rates = <0 0 200000000 0>; + qcom,msm-bus,name = "msm_camera_cpp"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <106 512 0 0>, + <106 512 0 0>; + qcom,msm-bus-vector-dyn-vote; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-cam.txt b/Documentation/devicetree/bindings/media/video/msm-cam.txt new file mode 100644 index 000000000000..371447cfb64e --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-cam.txt @@ -0,0 +1,19 @@ +* Qualcomm Technologies, Inc. MSM Camera + +Required properties: +- compatible : + - "qcom,msm-cam" +- reg : offset and length of msm camera device registers. +- reg-names : should specify relevant names for each reg property defined. + +Optional properties: +- qcom,gpu-limit : valid kgsl frequency. + +Example: + + qcom,msm-cam@fd8c0000 { + compatible = "qcom,msm-cam"; + reg = <0xfd8C0000 0x10000>; + reg-names = "msm-cam"; + qcom,gpu-limit = <700000000>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-camera-flash.txt b/Documentation/devicetree/bindings/media/video/msm-camera-flash.txt new file mode 100644 index 000000000000..f4885d5d9392 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-camera-flash.txt @@ -0,0 +1,72 @@ +* Qualcomm Technologies, Inc. MSM CAMERA FLASH + +Required properties: +- cell-index : Should contain flash source index to diffentiate + between different flash devices. These indexes represent flash devices + for multiple flashes. + - 0, 1, 2, 3 +- compatible : + - "qcom,camera-led-flash" + - "qcom,camera-flash" + - "qcom,led-flash" + - "qcom,led-flash1" +- qcom,flash-type : Should contain type flash device + - 1 for LED flash + - 2 for strobe flash + - 3 for simple led flash controlled by one gpio + This is a low cost led used for camera flash, the led is driven by + system power, and use a transistor controlled by external pin to + gate its on/off state. +- qcom,flash-source : Should contain array of phandles to flash source nodes. + - pm8941_flash0 pm8941_flash1 + +Optional properties: +-qcom,torch-source : Should contain phandle to torch source node. + -pm8941_torch +- qcom,slave-id : should contain i2c slave address, device id address + and expected id read value. +- qcom,max-current: Max current in mA supported by flash +- qcom,max-duration: Max duration in milliseconds the flash can glow. +-qcom,switch-source : Should contain phandle to switch source node. + This is used to trigger dual led at same time to avoid sync issues. +- qcom,cci-master : should contain i2c master id to be used for this flash. + - 0 -> MASTER 0 + - 1 -> MASTER 1 +- reg : offset and length of the register set for the device. + for the flash operating in compatible mode. +- gpios : should contain phandle to gpio controller node and array of + #gpio-cells specifying specific gpio (controller specific) +- qcom,gpio-req-tbl-num : should contain index to gpios specific to this flash +- qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-flash-reset : should contain index to gpio used by flash's "flash reset" pin. +- qcom,gpio-flash-en : should contain index to gpio used by flash's "flash enable" pin. +- qcom,gpio-flash-now : should contain index to gpio used by flash's "flash now" pin. +- label : should contain unique flash name to differentiate from other flash + - "adp1660" + - "bd7710" +Example: + +qcom,led-flash@60 { + reg = <0x60>; + cell-index = <0>; + qcom,slave-id = <0x60 0x00 0x0011>; + compatible = "qcom,led-flash"; + label = "adp1660"; + qcom,flash-type = <1>; + qcom,cci-master = <0>; + gpios = <&msmgpio 23 0>, + <&msmgpio 24 0>; + <&msmgpio 25 0>; + qcom,gpio-flash-reset = <0>; + qcom,gpio-flash-en = <0>; + qcom,gpio-flash-now = <1>; + qcom,gpio-req-tbl-num = <0 1>; + qcom,gpio-req-tbl-flags = <0 0>; + qcom,gpio-req-tbl-label = "FLASH_EN", + "FLASH_NOW"; + qcom,max-current = <750>; + qcom,max-duration = <1600>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-cci.txt b/Documentation/devicetree/bindings/media/video/msm-cci.txt new file mode 100644 index 000000000000..9fb84020add7 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-cci.txt @@ -0,0 +1,373 @@ +* Qualcomm Technologies, Inc. MSM CCI + +[First level nodes] +Required properties: +- cell-index: cci hardware core index +- compatible : + - "qcom,cci" +- reg : offset and length of the register set for the device + for the cci operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the cci interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- gpios : should contain phandle to gpio controller node and array of + #gpio-cells specifying specific gpio (controller specific) +- qcom,gpio-req-tbl-num : should contain index to gpios specific to this sensor +- qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- clock-names: name of the clocks required for the device +- clock-rates: clock rate in Hz + +Optional properties: +- qcom,cam-vreg-name : name of the voltage regulators required for the device. +- gdscr-supply : should contain gdsr regulator used for cci clocks. +- mmagic-supply : should contain mmagic regulator used for mmagic clocks. + +- I2c speed settings (*) + - i2c_freq_100Khz: qcom,i2c_standard_mode - node should contain clock settings for + 100Khz + - i2c_freq_400Khz: qcom,i2c_fast_mode - node should contain clock settings for + 400Khz + - i2c_freq_custom: qcom,i2c_custom_mode - node can contain clock settings for + frequencies other than 100Khz and 400Khz which is specific to usecase. + Currently it has settings for 375Khz. + - i2c_freq_1Mhz: qcom,i2c_fast_plus_mode - node should contain clock + settings for 1Mhz + * if speed settings is not defined the low level driver can use "i2c_freq_custom" + like default + +[Second level nodes] +* Qualcomm Technologies, Inc. CCI clock settings + +Optional properties: +- qcom,hw-thigh : should contain high period of the SCL clock in terms of CCI + clock cycle +- qcom,hw-tlow : should contain high period of the SCL clock in terms of CCI + clock cycle +- qcom,hw-tsu-sto : should contain setup time for STOP condition +- qcom,hw-tsu-sta : should contain setup time for Repeated START condition +- qcom,hw-thd-dat : should contain hold time for the data +- qcom,hw-thd-sta : should contain hold time for START condition +- qcom,hw-tbuf : should contain free time between a STOP and a START condition +- qcom,hw-scl-stretch-en : should contain enable or disable clock stretching +- qcom,hw-trdhld : should contain internal hold time for SDA +- qcom,hw-tsp : should contain filtering of glitches + +* Qualcomm Technologies, Inc. MSM Sensor + +MSM sensor node contains properties of camera sensor + +Required properties: +- compatible : should be manufacturer name followed by sensor name + - "qcom,camera" + - "shinetech,gc0310" +- reg : should contain i2c slave address of the device +- qcom,csiphy-sd-index : should contain csiphy instance that will used to + receive sensor data + - 0, 1, 2 +- qcom,csid-sd-index : should contain csid core instance that will used to + receive sensor data + - 0, 1, 2, 3 +- cam_vdig-supply : should contain regulator from which digital voltage is + supplied +- cam_vana-supply : should contain regulator from which analog voltage is + supplied +- cam_vio-supply : should contain regulator from which IO voltage is supplied +- qcom,cam-vreg-name : should contain names of all regulators needed by this + sensor + - "cam_vdig", "cam_vana", "cam_vio", "cam_vaf" +- qcom,cam-vreg-min-voltage : should contain minimum voltage level for + regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-max-voltage : should contain maximum voltage level for + regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-op-mode : should contain optimum voltage level for regulators + mentioned in qcom,cam-vreg-name property (in the same order) + +Optional properties: +- qcom,slave-id : should contain i2c slave address, device id address + ,expected id read value and device id mask +- qcom,sensor-name : should contain unique sensor name to differentiate from + other sensor + - "s5k3l1yx" +- qcom,sensor-mode : should contain sensor mode supported + - 0 -> back camera 2D + - 1 -> front camera 2D + - 2 -> back camera 3D + - 3 -> back camera int 3D +- qcom,sensor-type : should contain format of data that sensor streams + - 0 -> bayer format + - 1 -> yuv format +- qcom,is-vpe : should be enabled if VPE module is required for post processing + of this sensor + - 1 if required, 0 otherwise +- qcom,mount-angle : should contain the physical mount angle of the sensor on + the target + - 0, 90, 180, 360 +- qcom,secure : should be enabled to operate the camera in secure mode + - 0, 1 +- qcom,mclk-23880000 : should be enabled if the supported mclk is 23.88Mhz and + not 24 Mhz. +- qcom,gpio-no-mux : should contain field to indicate whether gpio mux table is + available + - 1 if gpio mux is not available, 0 otherwise +- cam_vaf-supply : should contain regulator from which AF voltage is supplied +- gpios : should contain phandle to gpio controller node and array of + #gpio-cells specifying specific gpio (controller specific) +- qcom,gpio-reset : should contain index to gpio used by sensors reset_n +- qcom,gpio-standby : should contain index to gpio used by sensors standby_n +- qcom,gpio-vio : should contain index to gpio used by sensors io vreg enable +- qcom,gpio-vana : should contain index to gpio used by sensors analog vreg enable +- qcom,gpio-vdig : should contain index to gpio used by sensors digital vreg enable +- qcom,gpio-vaf : should contain index to gpio used by sensors af vreg enable +- qcom,gpio-af-pwdm : should contain index to gpio used by sensors af pwdm_n +- qcom,gpio-req-tbl-num : should contain index to gpios specific to this sensor +- qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-set-tbl-num : should contain index of gpios that need to be + configured by msm +- qcom,gpio-set-tbl-flags : should contain value to be configured for the gpios + present in qcom,gpio-set-tbl-num property (in the same order) +- qcom,gpio-set-tbl-delay : should contain amount of delay after configuring + gpios as specified in gpio_set_tbl_flags property (in the same order) +- qcom,csi-lane-assign : should contain lane assignment value to map CSIPHY + lanes to CSID lanes + - 0x4320 +- qcom,csi-lane-mask : should contain lane mask that specifies CSIPHY lanes to + be enabled +- qcom,csi-phy-sel : should contain CSIPHY core instance from which CSID should + receive data +- qcom,actuator-cam-name : should contain actuator cam name associated with + this sensor + - If actuator does not exist, this property should not be initialized + - If actuator exist, this field should indicate the index of actuator to + be used +- qcom,actuator-vcm-pwd : should contain the gpio pin of vcm power to be enabled + for actuator +- qcom,actuator-vcm-enable : should contain value to be set for actuator vcm + gpio +- qcom,sensor-position : should contain the mount angle of the camera sensor + - 0 -> back camera + - 1 -> front camera +- qcom,cci-master : should contain i2c master id to be used for this camera + sensor + - 0 -> MASTER 0 + - 1 -> MASTER 1 +- qcom,actuator-src : if auto focus is supported by this sensor, this + property should contain phandle of respective actuator node +- qcom,led-flash-src : if LED flash is supported by this sensor, this + property should contain phandle of respective LED flash node +- qcom,vdd-cx-supply : should contain regulator from which cx voltage is + supplied +- qcom,vdd-cx-name : should contain names of cx regulator +- qcom,eeprom-src : if eeprom memory is supported by this sensor, this + property should contain phandle of respective eeprom nodes +- qcom,ois-src : if optical image stabilization is supported by this sensor, + this property should contain phandle of respective ois node +- qcom,ir-led-src : if ir led is supported by this sensor, this property + should contain phandle of respective ir-led node +- qcom,ir-cut-src : if ir cut is supported by this sensor, this property + should contain phandle of respective ir-cut node +- qcom,special-support-sensors: if only some special sensors are supported + on this board, add sensor name in this property. + +* Qualcomm Technologies, Inc. MSM ACTUATOR + +Required properties: +- cell-index : should contain unique identifier to differentiate + between multiple actuators +- reg : should contain i2c slave address of the actuator and length of + data field which is 0x0 +- compatible : + - "qcom,actuator" +- qcom,cci-master : should contain i2c master id to be used for this camera + sensor + - 0 -> MASTER 0 + - 1 -> MASTER 1 + +Optional properties: +- qcom,cam-vreg-name : should contain names of all regulators needed by this + actuator + - "cam_vaf" +- qcom,cam-vreg-min-voltage : should contain minimum voltage level in mcrovolts + for regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-max-voltage : should contain maximum voltage level in mcrovolts + for regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-op-mode : should contain the maximum current in microamps + required from the regulators mentioned in the qcom,cam-vreg-name property + (in the same order). +- cam_vaf-supply : should contain regulator from which AF voltage is supplied + +* Qualcomm Technologies, Inc. MSM OIS + +Required properties: +- cell-index : should contain unique identifier to differentiate + between multiple ois drivers +- reg : should contain i2c slave address of the ois and length of + data field which is 0x0 +- compatible : + - "qcom,ois" +- qcom,cci-master : should contain i2c master id to be used for this camera + sensor + - 0 -> MASTER 0 + - 1 -> MASTER 1 + +Optional properties: +- qcom,cam-vreg-name : should contain names of all regulators needed by this + ois + - "cam_vaf" +- qcom,cam-vreg-min-voltage : should contain minimum voltage level in mcrovolts + for regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-max-voltage : should contain maximum voltage level in mcrovolts + for regulators mentioned in qcom,cam-vreg-name property (in the same order) +- qcom,cam-vreg-op-mode : should contain the maximum current in microamps + required from the regulators mentioned in the qcom,cam-vreg-name property + (in the same order). +- cam_vaf-supply : should contain regulator from which ois voltage is supplied + +Example: + + qcom,cci@0xfda0c000 { + cell-index = <0>; + compatible = "qcom,cci"; + reg = <0xfda0c000 0x300>; + reg-names = "cci"; + interrupts = <0 50 0>; + interrupt-names = "cci"; + clock-names = "camss_top_ahb_clk", "vfe_clk_src", + "camss_vfe_vfe_clk", "iface_clk", "cpp_core_clk", + "cpp_iface_clk", "cpp_bus_clk", "micro_iface_clk"; + qcom,clock-rates = <0 266670000 0 0 266670000 0 0 0>; + gpios = <&msmgpio 19 0>, + <&msmgpio 20 0>, + <&msmgpio 21 0>, + <&msmgpio 22 0>; + qcom,gpio-tbl-num = <0 1 2 3>; + qcom,gpio-tbl-flags = <1 1 1 1>; + qcom,gpio-tbl-label = "CCI_I2C_DATA0", + "CCI_I2C_CLK0", + "CCI_I2C_DATA1", + "CCI_I2C_CLK1"; + i2c_freq_100Khz: qcom,i2c_standard_mode { + status = "disabled"; + }; + i2c_freq_400Khz: qcom,i2c_fast_mode { + status = "disabled"; + }; + i2c_freq_custom: qcom,i2c_custom_mode { + status = "disabled"; + }; + + actuator0: qcom,actuator@18 { + cell-index = <0>; + reg = <0x18>; + compatible = "qcom,actuator"; + qcom,cci-master = <0>; + cam_vaf-supply = <&pm8941_l23>; + qcom,cam-vreg-name = "cam_vaf"; + qcom,cam-vreg-min-voltage = <3000000>; + qcom,cam-vreg-max-voltage = <3000000>; + qcom,cam-vreg-op-mode = <100000>; + }; + + qcom,camera@0 { + cell-index = <0>; + compatible = "qcom,camera"; + reg = <0x0>; + qcom,csiphy-sd-index = <0>; + qcom,csid-sd-index = <0>; + qcom,mount-angle = <90>; + qcom,secure = <1>; + qcom,led-flash-src = <&led_flash0>; + qcom,actuator-src = <&actuator0>; + qcom,eeprom-src = <&eeprom0>; + cam_vdig-supply = <&pm8994_s3>; + cam_vio-supply = <&pm8994_lvs1>; + cam_vana-supply = <&pm8994_l17>; + qcom,cam-vreg-name = "cam_vdig", "cam_vio", "cam_vana"; + qcom,cam-vreg-min-voltage = <1300000 0 2500000>; + qcom,cam-vreg-max-voltage = <1300000 0 2500000>; + qcom,cam-vreg-op-mode = <105000 0 80000>; + qcom,gpio-no-mux = <0>; + pinctrl-names = "cam_default", "cam_suspend"; + pinctrl-0 = <&cam_sensor_mclk0_active &cam_sensor_rear_active>; + pinctrl-1 = <&cam_sensor_mclk0_suspend &cam_sensor_rear_suspend>; + gpios = <&tlmm 13 0>, + <&tlmm 30 0>, + <&tlmm 29 0>; + qcom,gpio-reset = <1>; + qcom,gpio-standby = <2>; + qcom,gpio-req-tbl-num = <0 1 2>; + qcom,gpio-req-tbl-flags = <1 0 0>; + qcom,gpio-req-tbl-label = "CAMIF_MCLK0", + "CAM_RESET0", + "CAM_STANDBY0"; + qcom,sensor-position = <0>; + qcom,sensor-mode = <0>; + qcom,cci-master = <0>; + status = "ok"; + clocks = <&clock_mmss clk_mclk0_clk_src>, + <&clock_mmss clk_camss_mclk0_clk>; + clock-names = "cam_src_clk", "cam_clk"; + }; + +&i2c_freq_100Khz { + qcom,hw-thigh = <78>; + qcom,hw-tlow = <114>; + qcom,hw-tsu-sto = <28>; + qcom,hw-tsu-sta = <28>; + qcom,hw-thd-dat = <10>; + qcom,hw-thd-sta = <77>; + qcom,hw-tbuf = <118>; + qcom,hw-scl-stretch-en = <0>; + qcom,hw-trdhld = <6>; + qcom,hw-tsp = <1>; + status = "ok"; +}; + +&i2c_freq_400Khz { + qcom,hw-thigh = <20>; + qcom,hw-tlow = <28>; + qcom,hw-tsu-sto = <21>; + qcom,hw-tsu-sta = <21>; + qcom,hw-thd-dat = <13>; + qcom,hw-thd-sta = <18>; + qcom,hw-tbuf = <25>; + qcom,hw-scl-stretch-en = <0>; + qcom,hw-trdhld = <6>; + qcom,hw-tsp = <3>; + status = "ok"; +}; + +&i2c_freq_custom { + qcom,hw-thigh = <15>; + qcom,hw-tlow = <28>; + qcom,hw-tsu-sto = <21>; + qcom,hw-tsu-sta = <21>; + qcom,hw-thd-dat = <13>; + qcom,hw-thd-sta = <18>; + qcom,hw-tbuf = <25>; + qcom,hw-scl-stretch-en = <1>; + qcom,hw-trdhld = <6>; + qcom,hw-tsp = <3>; + status = "ok"; +}; + +&i2c_freq_1Mhz { + qcom,hw-thigh = <16>; + qcom,hw-tlow = <22>; + qcom,hw-tsu-sto = <17>; + qcom,hw-tsu-sta = <18>; + qcom,hw-thd-dat = <16>; + qcom,hw-thd-sta = <15>; + qcom,hw-tbuf = <19>; + qcom,hw-scl-stretch-en = <1>; + qcom,hw-trdhld = <3>; + qcom,hw-tsp = <3>; + qcom,cci-clk-src = <37500000>; + status = "ok"; +}; diff --git a/Documentation/devicetree/bindings/media/video/msm-cpp.txt b/Documentation/devicetree/bindings/media/video/msm-cpp.txt new file mode 100644 index 000000000000..450e4d6ee8f0 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-cpp.txt @@ -0,0 +1,145 @@ +* Qualcomm Technologies, Inc. MSM CPP + +Required properties: +- cell-index: cpp hardware core index +- compatible : + - "qcom,cpp" +- reg : offset and length of the register set for the device + for the cpp operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. + - cpp - has CPP MICRO register set. + - cpp_vbif - has VBIF core register set used by CPP. + - cpp_hw - has CPP hardware register set. +- interrupts : should contain the cpp interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- vdd-supply: phandle to GDSC regulator controlling VFE & CPP core. +- clocks: list of phandles to the clock controller device and coresponding + clock names. +- clock-names: name of the clocks required for the device used by the consumer. +- qcom,clock-rates: clock rate in Hz. +- qcom,min-clock-rate: minimum clock rate in Hz, to be set to CPP hardware in + case dynamic clock scaling based on prevalent streams need lower clock rate. +- qcom,cpp-fw-payload-info: Child node for cpp node having infomration on + cpp firmware payload offsets. This is mandatory node. +- resets: reset specifier pair consists of phandle for the reset controller + and reset lines used by this controller. +- reset-names: reset signal name strings sorted in the same order as the resets + property. +- qcom,src-clock-rates = This is an array which holds clock rates for cpp src + clocks. The maximum size for the array is 10. + +Required properties of the child node: +- qcom,stripe-base = Base offset of stripes in cpp payload. +- qcom,plane-base = Base offset of planes in cpp payload. +- qcom,stripe-size = size of each stripe in payload. +- qcom,plane-size = size of each plane in payload. +- qcom,fe-ptr-off = offset from stripe base to fetch engine address + location in payload. +- qcom,we-ptr-off = offset from stripe base to write engine address + location in payload. + +Optional properties of the child node: +- qcom,ref-fe-ptr-off = offset from stripe base to reference fetch engine + address location in payload. +- qcom,ref-we-ptr-off = offset from stripe base to reference write engine + address location in payload. +- qcom,we-meta-ptr-off = offset from stripe base to metadata address + location in payload. +- qcom,fe-mmu-pf-ptr-off = offset from plane base to fetch engine mmu prefetch + address min location in payload. +- qcom,ref-fe-mmu-pf-ptr-off = offset from plane base to reference fetch engine + mmu prefetch address min location in payload. +- qcom,we-mmu-pf-ptr-off = offset from plane base to write engine mmu prefetch + address min location in payload. +- qcom,dup-we-mmu-pf-ptr-off = offset from plane base to duplicate write engine + mmu prefetch address min location in payload. +- qcom,ref-we-mmu-pf-ptr-off = offset from plane base to reference write engine + mmu prefetch address min location in payload. +- qcom,set-group-buffer-len = length/size of set group buffer command used for + hfr. +- qcom,dup-frame-indicator-off = offset for duplicate frame indicator in a + batch for frames + +Optional properties: +- mmagic-vdd-supply: phandle to GDSC regulator controlling mmagic. +- camss-vdd-supply: phandle to GDSC regulator controlling camss. +- qcom,bus-master: Flag for presence of CPP bus master. It has to be set only for + platforms that support such feature. +- qcom,vbif-setting: The offset and value for vbif core qos registers. + The first entry is register offset and second entry is register value. +- qcom,micro-reset: Boolean flag indicating if micro reset need to be enabled. + This needs to present on platforms that support this feature. +- qcom,cpp-cx-ipeak: To handle Cx peak current limit. + <phandle bit> + phandle - phandle of cx ipeak device node + bit - bit number of client in relevant register + This is used to access Cx ipeak HW module to limit the current drawn by + various subsystem blocks on Cx power rail. CPP set their bit in tcsr register + if it is going to cross its own threshold. + +Example: + + qcom,cpp@fda04000 { + cell-index = <0>; + compatible = "qcom,cpp"; + reg = <0xfda04000 0x100>, + <0xfda80000 0x200>, + <0xfda18000 0x008>, + <0xfd8c36D4 0x4>; + reg-names = "cpp", "cpp_vbif", "cpp_hw", "camss_cpp"; + interrupts = <0 49 0>; + interrupt-names = "cpp"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_cpp>; + clocks = <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_cpp_clk_src>, + <&clock_mmss clk_camss_cpp_ahb_clk>, + <&clock_mmss clk_camss_cpp_axi_clk>, + <&clock_mmss clk_camss_cpp_clk>, + <&clock_mmss clk_camss_micro_ahb_clk>, + <&clock_mmss clk_camss_ahb_clk>; + <&clock_mmss clk_smmu_cpp_axi_clk>, + <&clock_mmss clk_camss_cpp_vbif_ahb_clk>, + clock-names = "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk", + "mmagic_camss_axi_clk", "camss_top_ahb_clk", + "cpp_core_clk", "camss_cpp_ahb_clk", + "camss_cpp_axi_clk", "camss_cpp_clk", + "micro_iface_clk", "camss_ahb_clk"; + "smmu_cpp_axi_clk", "cpp_vbif_ahb_clk"; + qcom,clock-rates = <0 0 0 0 465000000 0 0 465000000 0 0 0 0>; + qcom,cpp-cx-ipeak = <&cx_ipeak_lm 2>; + qcom,min-clock-rate = <320000000>; + qcom,bus-master = <1>; + qcom,vbif-qos-setting = <0x20 0x10000000>, + <0x24 0x10000000>, + <0x28 0x10000000>, + <0x2C 0x10000000>; + qcom,src-clock-rates = <100000000 200000000 384000000 404000000 + 480000000 576000000 600000000>; + qcom,micro-reset; + qcom,cpp-fw-payload-info { + qcom,stripe-base = <553>; + qcom,plane-base = <481>; + qcom,stripe-size = <61>; + qcom,plane-size = <24>; + qcom,fe-ptr-off = <11>; + qcom,we-ptr-off = <23>; + qcom,ref-fe-ptr-off = <17>; + qcom,ref-we-ptr-off = <36>; + qcom,we-meta-ptr-off = <42>; + qcom,fe-mmu-pf-ptr-off = <6>; + qcom,ref-fe-mmu-pf-ptr-off = <9>; + qcom,we-mmu-pf-ptr-off = <12>; + qcom,dup-we-mmu-pf-ptr-off = <17>; + qcom,ref-we-mmu-pf-ptr-off = <22>; + qcom,set-group-buffer-len = <135>; + qcom,dup-frame-indicator-off = <70>; + resets = <&clock_mmss MMSS_CAMSS_MICRO_BCR>; + reset-names = "micro_iface_reset"; + }; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-csi-phy.txt b/Documentation/devicetree/bindings/media/video/msm-csi-phy.txt new file mode 100644 index 000000000000..8a6b3c4355af --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-csi-phy.txt @@ -0,0 +1,40 @@ +* Qualcomm Technologies, Inc. MSM CSI Phy + +Required properties: +- cell-index: csi phy hardware core index +- compatible : + - "qcom,csiphy" + - "qcom,csiphy-v2.0" + - "qcom,csiphy-v2.2" + - "qcom,csiphy-v3.0" + - "qcom,csiphy-v3.1" + - "qcom,csiphy-v3.1.1" + - "qcom,csiphy-v3.2" + - "qcom,csiphy-v3.4.2" + - "qcom,csiphy-v3.5" + - "qcom,csiphy-v5.0" + - "qcom,csiphy-v5.01" +- reg : offset and length of the register set for the device + for the csiphy operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the csiphy interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- clock-names: name of the clocks required for the device +- qcom,clock-rates: clock rate in Hz + - 0 if appropriate clock is required but doesn't have to apply the rate + +Example: + + qcom,csiphy@fda0ac00 { + cell-index = <0>; + compatible = "qcom,csiphy-v2.0", "qcom,csiphy"; + reg = <0xfda0ac00 0x200>; + reg-names = "csiphy"; + interrupts = <0 78 0>; + interrupt-names = "csiphy"; + clock-names = "camss_top_ahb_clk", + "ispif_ahb_clk", "csiphy_timer_src_clk", + "csiphy_timer_clk"; + qcom,clock-rates = <0 0 200000000 0>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-csid.txt b/Documentation/devicetree/bindings/media/video/msm-csid.txt new file mode 100644 index 000000000000..340d98688b76 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-csid.txt @@ -0,0 +1,52 @@ +* Qualcomm Technologies, Inc. MSM CSID + +Required properties: +- cell-index: csid hardware core index +- compatible : + - "qcom,csid" + - "qcom,csid-v2.0" + - "qcom,csid-v2.2" + - "qcom,csid-v3.0" + - "qcom,csid-v3.1" + - "qcom,csid-v3.2" + - "qcom,csid-v3.5" + - "qcom,csid-v4.0" + - "qcom,csid-v3.4.2" + - "qcom,csid-v3.5.1" + - "qcom,csid-v3.4.3" + - "qcom,csid-v5.0" +- reg : offset and length of the register set for the device + for the csid operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the csid interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- qcom,csi-vdd-voltage : should specify voltage level + for mipi csi in uV. +- qcom,mipi-csi-vdd-supply : should contain regulator to be used for + this csid core +- clock-names: name of the clocks required for the device +- qcom,clock-rates: clock rate in Hz + - 0 if appropriate clock is required but doesn't have to apply the rate + +Optional properties: +- qcom,cam-vreg-name : name of the voltage regulators required for the device. +- gdscr-supply : should contain regulator used for csid clocks. +- mmagic-supply : should contain mmagic regulator used for mmagic clocks. + +Example: + + qcom,csid@fda08000 { + cell-index = <0>; + compatible = "qcom,csid-v2.0", "qcom,csid"; + reg = <0xfda08000 0x200>; + reg-names = "csid"; + interrupts = <0 51 0>; + interrupt-names = "csiphy"; + qcom,csi-vdd-voltage = <1800000>; + qcom,mipi-csi-vdd-supply = <&pm8941_l12>; + clock-names = "camss_top_ahb_clk", "ispif_ahb_clk", + "csi_ahb_clk", "csi_src_clk", "csi_clk", + "csi_phy_clk", "csi_pix_clk", "csi_rdi_clk"; + qcom,clock-rates = <0 0 0 200000000 0 0 0 0>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-eeprom.txt b/Documentation/devicetree/bindings/media/video/msm-eeprom.txt new file mode 100644 index 000000000000..f951b2167012 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-eeprom.txt @@ -0,0 +1,199 @@ +* Qualcomm Technologies, Inc. MSM EEPROM + +EEPROM is an one time programmed(OTP) device that stores the calibration data +use for camera sensor. It may either be integrated in the sensor module or in +the sensor itself. As a result, the power, clock and GPIOs may be the same as +the camera sensor. The following describes the page block map, power supply, +clock, GPIO and power on sequence properties of the EEPROM device. + +Required properties if probe happens from camera daemon: +- cell-index: eeprom hardware core index +- compatible : + - "qcom,eeprom" +- reg : offset of eeprom device registers. +- qcom,cci-master : should specify the cci core index that eeprom use. +- cam_vio-supply : should contain regulator to be used for the IO vdd. +- qcom,cam-vreg-name : should specify the regulator name to be used for + this eeprom. +- qcom,cam-vreg-type : should specify the regulator type to be used for + this eeprom. +- qcom,cam-vreg-min-voltage : should specify minimum voltage level + for eeprom in uV. +- qcom,cam-vreg-max-voltage : should specify maximum voltage level + for eeprom in uV. +- qcom,cam-vreg-op-mode : should specify current level for eeprom in uA. +- qcom,gpio-no-mux : should specify the gpio mux type. +- gpios : should specify the gpios to be used for the eeprom. +- qcom,gpio-reset : should specify the reset gpio index. +- qcom,gpio-standby : should specify the standby gpio index. +- qcom,gpio-req-tbl-num : should specify the gpio table index. +- qcom,gpio-req-tbl-flags : should specify the gpio functions. +- qcom,gpio-req-tbl-label : should specify the gpio labels. +- qcom,cam-power-seq-type : should specify the power on sequence types. +- qcom,cam-power-seq-val : should specify the power on sequence values. +- qcom,cam-power-seq-cfg-val : should specify the power on sequence config + values. +- qcom,cam-power-seq-delay : should specify the power on sequence delay + time in ms. + +Optional properties: +- cam_vdig-supply : should contain regulator to be used for the digital vdd. + + + +Example: + + eeprom0: qcom,eeprom@60 { + cell-index = <0>; + reg = <0x60 0x0>; + compatible = "qcom,eeprom"; + qcom,cci-master = <0>; + cam_vdig-supply = <&pm8226_l5>; + cam_vio-supply = <&pm8226_lvs1>; + qcom,cam-vreg-name = "cam_vdig", "cam_vio"; + qcom,cam-vreg-type = <0 1>; + qcom,cam-vreg-min-voltage = <1200000 0>; + qcom,cam-vreg-max-voltage = <1200000 0>; + qcom,cam-vreg-op-mode = <200000 0>; + qcom,gpio-no-mux = <0>; + gpios = <&msmgpio 26 0>, + <&msmgpio 37 0>, + <&msmgpio 36 0>; + qcom,gpio-reset = <1>; + qcom,gpio-standby = <2>; + qcom,gpio-req-tbl-num = <0 1 2>; + qcom,gpio-req-tbl-flags = <1 0 0>; + qcom,gpio-req-tbl-label = "CAMIF_MCLK", + "CAM_RESET1", + "CAM_STANDBY"; + qcom,cam-power-seq-type = "sensor_vreg", + "sensor_vreg", "sensor_clk", + "sensor_gpio", "sensor_gpio"; + qcom,cam-power-seq-val = "cam_vdig", + "cam_vio", "sensor_cam_mclk", + "sensor_gpio_reset", + "sensor_gpio_standby"; + qcom,cam-power-seq-cfg-val = <1 1 24000000 1 1>; + qcom,cam-power-seq-delay = <1 1 5 5 10>; + }; + + + +Required properties if eeprom probe is kernel probe: +- cell-index: eeprom hardware core index +- compatible : + - "qcom,eeprom" +- reg : offset of eeprom device registers. +- qcom,eeprom-name : should specify relevant names of the eeprom module + library. +- qcom,slave-addr : should specify the slave address of the eeprom. +- qcom,cci-master : should specify the cci core index that eeprom use. +- qcom,num-blocks : should specify the total block number that eeprom contains, + every block should contains page poll and mem. +- qcom,page%d : number %d page size, start address, address type, data, + data type, delay in ms. size 0 stand for non-paged. + - address type : 1 byte, 2 word. + - data type : 1 byte, 2 word. +- qcom,poll%d : number %d poll size, poll reg address, address type, data, + data type, delay in ms. size 0 stand for not used. + - address type : 1 byte, 2 word. + - data type : 1 byte, 2 word. +- qcom,mem%d : number %d memory size, start address, address type, data, + data type, delay in ms. size 0 stand for not used. + - address type : 1 byte, 2 word. + - data type : 1 byte, 2 word. +- cam_vio-supply : should contain regulator to be used for the IO vdd. +- qcom,cam-vreg-name : should specify the regulator name to be used for + this eeprom. +- qcom,cam-vreg-type : should specify the regulator type to be used for + this eeprom. +- qcom,cam-vreg-min-voltage : should specify minimum voltage level + for eeprom in uV. +- qcom,cam-vreg-max-voltage : should specify maximum voltage level + for eeprom in uV. +- qcom,cam-vreg-op-mode : should specify current level for eeprom in uA. +- pinctrl-names : should specify the pin control groups followed by + the definition of each group +- qcom,gpio-no-mux : should specify the gpio mux type. +- gpios : should specify the gpios to be used for the eeprom. +- qcom,gpio-reset : should specify the reset gpio index. +- qcom,gpio-standby : should specify the standby gpio index. +- qcom,gpio-req-tbl-num : should specify the gpio table index. +- qcom,gpio-req-tbl-flags : should specify the gpio functions. +- qcom,gpio-req-tbl-label : should specify the gpio labels. +- qcom,cam-power-seq-type : should specify the power on sequence types. +- qcom,cam-power-seq-val : should specify the power on sequence values. +- qcom,cam-power-seq-cfg-val : should specify the power on sequence config + values. +- qcom,cam-power-seq-delay : should specify the power on sequence delay + time in ms. + +Optional properties: +- qcom,pageen%d : number %d page enable reg size, start address, address type, + data, data type, delay in ms. size 0 stand for not used. +- cam_vdig-supply : should contain regulator to be used for the digital vdd. +- qcom,saddr%d : property should specify the slave address for block (%d). +- qcom,i2c-freq-mode : property should specify the I2C speed mode. + +Optional properties -EEPROM Camera Multimodule +- qcom,cmm-data-support - Camera MultiModule data capability flag. +- qcom,cmm-data-compressed - Camera MultiModule data compression flag. +- qcom,cmm-data-offset - Camera MultiModule data start offset. +- qcom,cmm-data-size - Camera MultiModule data size. + + + +Example: + + eeprom0: qcom,eeprom@60 { + cell-index = <0>; + reg = <0x60 0x0>; + qcom,eeprom-name = "msm_eeprom"; + compatible = "qcom,eeprom"; + qcom,slave-addr = <0x60>; + qcom,cci-master = <0>; + qcom,num-blocks = <2>; + qcom,page0 = <1 0x0100 2 0x01 1 1>; + qcom,poll0 = <0 0x0 2 0 1 1>; + qcom,mem0 = <0 0x0 2 0 1 0>; + qcom,page1 = <1 0x0200 2 0x8 1 1>; + qcom,pageen1 = <1 0x0202 2 0x01 1 10>; + qcom,poll1 = <0 0x0 2 0 1 1>; + qcom,mem1 = <32 0x3000 2 0 1 0>; + qcom,saddr1 = <0x62>; + + qcom,cmm-data-support; + qcom,cmm-data-compressed; + qcom,cmm-data-offset = <0>; + qcom,cmm-data-size = <0>; + + cam_vdig-supply = <&pm8226_l5>; + cam_vio-supply = <&pm8226_lvs1>; + qcom,cam-vreg-name = "cam_vdig", "cam_vio"; + qcom,cam-vreg-type = <0 1>; + qcom,cam-vreg-min-voltage = <1200000 0>; + qcom,cam-vreg-max-voltage = <1200000 0>; + qcom,cam-vreg-op-mode = <200000 0>; + qcom,gpio-no-mux = <0>; + gpios = <&msmgpio 26 0>, + <&msmgpio 37 0>, + <&msmgpio 36 0>; + qcom,gpio-reset = <1>; + qcom,gpio-standby = <2>; + qcom,gpio-req-tbl-num = <0 1 2>; + qcom,gpio-req-tbl-flags = <1 0 0>; + qcom,gpio-req-tbl-label = "CAMIF_MCLK", + "CAM_RESET1", + "CAM_STANDBY"; + qcom,cam-power-seq-type = "sensor_vreg", + "sensor_vreg", "sensor_clk", + "sensor_gpio", "sensor_gpio"; + qcom,cam-power-seq-val = "cam_vdig", + "cam_vio", "sensor_cam_mclk", + "sensor_gpio_reset", + "sensor_gpio_standby"; + qcom,cam-power-seq-cfg-val = <1 1 24000000 1 1>; + qcom,cam-power-seq-delay = <1 1 5 5 10>; + }; + + diff --git a/Documentation/devicetree/bindings/media/video/msm-fd.txt b/Documentation/devicetree/bindings/media/video/msm-fd.txt new file mode 100644 index 000000000000..05635999a86a --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-fd.txt @@ -0,0 +1,99 @@ +* Qualcomm Technologies, Inc. MSM FD + +Face detection hardware block. +The Face Detection Hardware Block will offload processing +on the host and also reduce power consumption. +Supports: +Front and back camera face detection concurrently. +Sizes: QVGA, VGA, WQVGA, WVGA at 20 pix minimum face size. + +Required properties: + +- compatible: + - "qcom,face-detection" +- reg: offset and length of the register set for the device. +- reg-names: should specify relevant names to each reg property defined. + - "fd_core" - FD CORE hardware register set. + - "fd_misc" - FD MISC hardware register set. + - "fd_vbif" - FD VBIF hardware register set. +- interrupts: should contain the fd interrupts. From fd cores with + revisions 0x10010000 and higher, power collapse sequence is required. + Face detection misc irq is needed to perform power collapse. +- interrupt-names: should specify relevant names to each interrupts + property defined. +- vdd-supply: phandle to GDSC regulator controlling face detection hw. +- clocks: list of entries each of which contains: + - phandle to the clock controller. + - macro containing clock's name in hardware. +- clock-names: should specify relevant names to each clocks + property defined. + +Optional properties: + +- clock-rates: should specify clock rates in Hz to each clocks + property defined. + If we want to have different operating clock frequencies we can define + rate levels. They should be defined in incremental order. +- qcom,bus-bandwidth-vectors: Specifies instant and average bus bandwidth + vectors per clock rate. + Each of entries contains: + - ab. Average bus bandwidth (Bps). + - ib. Instantaneous bus bandwidth (Bps). +- mmagic-vdd-supply: phandle to GDSC regulator controlling mmagic. +- camss-vdd-supply: phandle to GDSC regulator controlling camss. +- qcom,fd-core-reg-settings: relative address offsets and value pairs for + FD CORE registers and bit mask. + Format: <reg_addr_offset reg_value reg_mask> +- qcom,fd-misc-reg-settings: relative address offsets and value pairs for + FD MISC registers and bit mask. + Format: <reg_addr_offset reg_value reg_mask> +- qcom,fd-vbif-reg-settings: relative address offsets and value pairs for + FD VBIF registers and bit mask. + Format: <reg_addr_offset reg_value reg_mask> + +Example: + + qcom,fd@fd878000 { + compatible = "qcom,face-detection"; + reg = <0xfd878000 0x800>, + <0xfd87c000 0x800>, + <0xfd860000 0x1000>; + reg-names = "fd_core", "fd_misc", "fd_vbif"; + interrupts = <0 316 0>; + interrupt-names = "fd"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_fd>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clocks = <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_fd_core_clk_src>, + <&clock_mmss clk_fd_core_clk>, + <&clock_mmss clk_fd_core_uar_clk>, + <&clock_mmss clk_fd_ahb_clk>, + <&clock_mmss clk_smmu_cpp_axi_clk>, + <&clock_mmss clk_camss_ahb_clk>, + <&clock_mmss clk_camss_cpp_axi_clk>, + <&clock_mmss clk_camss_cpp_vbif_ahb_clk>, + <&clock_mmss clk_smmu_cpp_ahb_clk>; + clock-names = "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk" , + "mmagic_camss_axi_clk", "camss_top_ahb_clk", + "fd_core_clk_src", "fd_core_clk", + "fd_core_uar_clk", "fd_ahb_clk", + "smmu_cpp_axi_clk", "camss_ahb_clk", + "camss_cpp_axi_clk", "cpp_vbif_ahb_clk", + "smmu_cpp_ahb_clk"; + clock-rates = <0 0 0 0 400000000 400000000 400000000 80000000 0 0 0 0 0>; + qcom,bus-bandwidth-vectors = <13000000 13000000>, + <45000000 45000000>, + <90000000 90000000>; + qcom,fd-vbif-reg-settings = <0x20 0x10000000 0x30000000>, + <0x24 0x10000000 0x30000000>, + <0x28 0x10000000 0x30000000>, + <0x2c 0x10000000 0x30000000>; + qcom,fd-misc-reg-settings = <0x20 0x2 0x3>, + <0x24 0x2 0x3>; + qcom,fd-core-reg-settings = <0x8 0x20 0xffffffff>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-ir-cut.txt b/Documentation/devicetree/bindings/media/video/msm-ir-cut.txt new file mode 100644 index 000000000000..96cb28d692c1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-ir-cut.txt @@ -0,0 +1,26 @@ +* QTI MSM IR CUT + +Required properties: +- cell-index : ir cut filter hardware core index +- compatible : + - "qcom,ir-cut" + +Optional properties: +- gpios : should specify the gpios to be used for the ir cut filter. +- qcom,gpio-req-tbl-num : should contain index to gpios specific to ir cut filter +- qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- label : should contain unique ir cut filter name +Example: + +qcom,ir-cut@60 { + cell-index = <0>; + compatible = "qcom,ir-cut"; + label = "led-ir-label"; + gpios = <&tlmm 60 0>; + qcom,gpio-req-tbl-num = <0>; + qcom,gpio-req-tbl-flags = <0>; + qcom,gpio-req-tbl-label = "LED_IR_EN"; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-ir-led.txt b/Documentation/devicetree/bindings/media/video/msm-ir-led.txt new file mode 100644 index 000000000000..7e66fa0cef5b --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-ir-led.txt @@ -0,0 +1,26 @@ +* QTI MSM IR LED + +Required properties: +- cell-index : ir led hardware core index +- compatible : + - "qcom,ir-led" + +Optional properties: +- gpios : should specify the gpios to be used for the ir led. +- qcom,gpio-req-tbl-num : should contain index to gpios specific to ir led +- qcom,gpio-req-tbl-flags : should contain direction of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- qcom,gpio-req-tbl-label : should contain name of gpios present in + qcom,gpio-req-tbl-num property (in the same order) +- label : should contain unique ir led name +Example: + +qcom,ir-led { + cell-index = <0>; + compatible = "qcom,ir-led"; + label = "led-ir-label"; + gpios = <&tlmm 60 0>; + qcom,gpio-req-tbl-num = <0>; + qcom,gpio-req-tbl-flags = <0>; + qcom,gpio-req-tbl-label = "LED_IR_EN"; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-irqrouter.txt b/Documentation/devicetree/bindings/media/video/msm-irqrouter.txt new file mode 100644 index 000000000000..fbcb74d3b900 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-irqrouter.txt @@ -0,0 +1,18 @@ +* Qualcomm Technologies, Inc. MSM IRQ Router + +Required properties: +- cell-index: irq router hardware core index +- compatible : + - "qcom,irqrouter" +- reg : offset and length of the register set for the device + for the irqrouter operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. + +Example: + + qcom,irqrouter@0xfda0c000 { + cell-index = <0>; + compatible = "qcom,irqrouter"; + reg = <0xfda00000 0x100>; + reg-names = "irqrouter"; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-ispif.txt b/Documentation/devicetree/bindings/media/video/msm-ispif.txt new file mode 100644 index 000000000000..d635a4ed1ea0 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-ispif.txt @@ -0,0 +1,159 @@ +* Qualcomm Technologies, Inc. MSM ISPIF + +Required properties: +- cell-index: ispif hardware core index +- compatible : + - "qcom,ispif" + - "qcom,ispif-v3.0" +- reg : offset and length of the register set for the device + for the ispif operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the ispif interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- camss-vdd-supply: phandle to GDSC regulator. +- mmagic-vdd-supply: phandle to mmagic regulator. +- vfe0-vdd-supply: phandle to vfe0 regulator. +- vfe1-vdd-supply: phandle to vfe1 regulator. +- clocks: list of phandles to the clock controller device and coresponding + clock names. +- clock-names: name of the clocks required for the device used by the consumer. +- qcom,clock-rates: clock rate in Hz. +- qcom,clock-control: The valid fields are "NO_SET_RATE", "INIT_RATE" and + "SET_RATE". "NO_SET_RATE" the corresponding clock is enabled without setting + the rate assuming some other driver has already set it to appropriate rate. + "INIT_RATE" clock rate is not queried assuming some other driver has set + the clock rate and ispif will set the the clock to this rate. + "SET_RATE" clock is enabled and the rate is set to the value specified + in the property qcom,clock-rates. + +Optional properties: +- qcom,num-isps: The number of ISPs the ISPIF module is connected to. If not set + the default value used is 1 + +Example: + + qcom,ispif@fda0a000 { + cell-index = <0>; + compatible = "qcom,ispif"; + reg = <0xfda0a000 0x300>; + reg-names = "ispif"; + interrupts = <0 55 0>; + interrupt-names = "ispif"; + camss-vdd-supply = <&gdsc_camss_top>; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + vfe0-vdd-supply = <&gdsc_vfe0>; + vfe1-vdd-supply = <&gdsc_vfe1>; + clocks = <&clock_mmss clk_camss_ispif_ahb_clk>, + <&clock_mmss clk_csi0_clk_src>, + <&clock_mmss clk_camss_csi0_clk>, + <&clock_mmss clk_camss_csi0rdi_clk>, + <&clock_mmss clk_camss_csi0pix_clk>, + <&clock_mmss clk_csi1_clk_src>, + <&clock_mmss clk_camss_csi1_clk>, + <&clock_mmss clk_camss_csi1rdi_clk>, + <&clock_mmss clk_camss_csi1pix_clk>, + <&clock_mmss clk_csi2_clk_src>, + <&clock_mmss clk_camss_csi2_clk>, + <&clock_mmss clk_camss_csi2rdi_clk>, + <&clock_mmss clk_camss_csi2pix_clk>, + <&clock_mmss clk_csi3_clk_src>, + <&clock_mmss clk_camss_csi3_clk>, + <&clock_mmss clk_camss_csi3rdi_clk>, + <&clock_mmss clk_camss_csi3pix_clk>, + <&clock_mmss clk_vfe0_clk_src>, + <&clock_mmss clk_camss_vfe0_clk>, + <&clock_mmss clk_camss_csi_vfe0_clk>, + <&clock_mmss clk_vfe1_clk_src>, + <&clock_mmss clk_camss_vfe1_clk>, + <&clock_mmss clk_camss_csi_vfe1_clk>; + clock-names = "ispif_ahb_clk", + "csi0_src_clk", "csi0_clk", + "csi0_pix_clk", "csi0_rdi_clk", + "csi1_src_clk", "csi1_clk", + "csi1_pix_clk", "csi1_rdi_clk", + "csi2_src_clk", "csi2_clk", + "csi2_pix_clk", "csi2_rdi_clk", + "csi3_src_clk", "csi3_clk", + "csi3_pix_clk", "csi3_rdi_clk", + "vfe0_clk_src", "camss_vfe_vfe0_clk", "camss_csi_vfe0_clk", + "vfe1_clk_src", "camss_vfe_vfe1_clk", "camss_csi_vfe1_clk"; + qcom,clock-rates = <0 + 200000000 0 0 0 + 200000000 0 0 0 + 200000000 0 0 0 + 200000000 0 0 0 + 0 0 0 + 0 0 0>; + qcom,clock-control = "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "INIT_RATE", "NO_SET_RATE", "NO_SET_RATE", + "INIT_RATE", "NO_SET_RATE", "NO_SET_RATE"; + + }; + +or + + qcom,ispif@fda0a000 { + cell-index = <0>; + compatible = "qcom,ispif-v3.0", "qcom,ispif"; + reg = <0xfda0a000 0x300>; + reg-names = "ispif"; + interrupts = <0 55 0>; + interrupt-names = "ispif"; + qcom,num-isps = <2> + vdd-supply = <&gdsc_camss_top>; + clocks = <&clock_mmss clk_camss_ispif_ahb_clk>, + <&clock_mmss clk_csi0_clk_src>, + <&clock_mmss clk_camss_csi0_clk>, + <&clock_mmss clk_camss_csi0rdi_clk>, + <&clock_mmss clk_camss_csi0pix_clk>, + <&clock_mmss clk_csi1_clk_src>, + <&clock_mmss clk_camss_csi1_clk>, + <&clock_mmss clk_camss_csi1rdi_clk>, + <&clock_mmss clk_camss_csi1pix_clk>, + <&clock_mmss clk_csi2_clk_src>, + <&clock_mmss clk_camss_csi2_clk>, + <&clock_mmss clk_camss_csi2rdi_clk>, + <&clock_mmss clk_camss_csi2pix_clk>, + <&clock_mmss clk_csi3_clk_src>, + <&clock_mmss clk_camss_csi3_clk>, + <&clock_mmss clk_camss_csi3rdi_clk>, + <&clock_mmss clk_camss_csi3pix_clk>, + <&clock_mmss clk_vfe0_clk_src>, + <&clock_mmss clk_camss_vfe0_clk>, + <&clock_mmss clk_camss_csi_vfe0_clk>, + <&clock_mmss clk_vfe1_clk_src>, + <&clock_mmss clk_camss_vfe1_clk>, + <&clock_mmss clk_camss_csi_vfe1_clk>; + clock-names = "ispif_ahb_clk", + "csi0_src_clk", "csi0_clk", + "csi0_pix_clk", "csi0_rdi_clk", + "csi1_src_clk", "csi1_clk", + "csi1_pix_clk", "csi1_rdi_clk", + "csi2_src_clk", "csi2_clk", + "csi2_pix_clk", "csi2_rdi_clk", + "csi3_src_clk", "csi3_clk", + "csi3_pix_clk", "csi3_rdi_clk", + "vfe0_clk_src", "camss_vfe_vfe0_clk", "camss_csi_vfe0_clk", + "vfe1_clk_src", "camss_vfe_vfe1_clk", "camss_csi_vfe1_clk"; + qcom,clock-rates = <0 + 200000000 0 0 0 + 200000000 0 0 0 + 200000000 0 0 0 + 200000000 0 0 0 + 0 0 0 + 0 0 0>; + qcom,clock-control = "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "SET_RATE", "NO_SET_RATE", "NO_SET_RATE", "NO_SET_RATE", + "INIT_RATE", "NO_SET_RATE", "NO_SET_RATE", + "INIT_RATE", "NO_SET_RATE", "NO_SET_RATE"; + + }; + diff --git a/Documentation/devicetree/bindings/media/video/msm-jpeg.txt b/Documentation/devicetree/bindings/media/video/msm-jpeg.txt new file mode 100644 index 000000000000..5aed7c3837ad --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-jpeg.txt @@ -0,0 +1,140 @@ +* Qualcomm Technologies, Inc. MSM JPEG + +Required properties: +- cell-index: jpeg hardware core index +- compatible : + - "qcom,jpeg" + - "qcom,jpeg_dma" +- reg : offset and length of the register set of jpeg device and vbif device + for the jpeg operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the jpeg interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- clock-names : names of clocks required for the device. +- clocks : clocks required for the device. +- qcom, clock-rates: rates of the required clocks. +- vdd-supply: phandle to GDSC regulator controlling JPEG core. +- mmagic-vdd-supply: phandle to GDSC regulator controlling mmagic. +- camss-vdd-supply: phandle to GDSC regulator controlling camss. + +Optional properties: +- qcom,vbif-reg-settings: relative address offsets and value pairs for VBIF registers. +- qcom,qos-reg-settings: relative address offsets and value pairs for QoS registers. +- qcom,prefetch-reg-settings: relative address offsets and value pairs for + MMU prefetch registers. + +Example: + + qcom,jpeg@a1c000 { + cell-index = <0>; + compatible = "qcom,jpeg"; + reg = <0xa1c000 0x4000>, + <0xa60000 0x3000>; + reg-names = "jpeg"; + interrupts = <0 316 0>; + interrupt-names = "jpeg"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_jpeg>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clock-names = "core_clk", "iface_clk", "bus_clk0", + "camss_top_ahb_clk", "camss_ahb_clk", "smmu_jpeg_axi_clk", + "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk", + "mmagic_camss_axi_clk"; + clocks = <&clock_mmss clk_camss_jpeg0_clk>, + <&clock_mmss clk_camss_jpeg_ahb_clk>, + <&clock_mmss clk_camss_jpeg_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_camss_ahb_clk>, + <&clock_mmss clk_smmu_jpeg_axi_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>; + qcom,clock-rates = <320000000 0 0 0 0 0 0 0 0>; + qcom,vbif-reg-settings = <0x4 0x1>, + <0xb0 0x00100010>, + <0xc0 0x10001000>; + qcom,qos-reg-settings = <0x28 0x00000008>; + qcom,prefetch-reg-settings = <0x30c 0x1111>, + <0x318 0x31>, + <0x324 0x31>, + <0x330 0x31>, + <0x33c 0x0>; + status = "ok"; + }; + + qcom,jpeg@a24000 { + cell-index = <2>; + compatible = "qcom,jpeg"; + reg = <0xa24000 0x4000>, + <0xa60000 0x3000>; + reg-names = "jpeg"; + interrupts = <0 318 0>; + interrupt-names = "jpeg"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_jpeg>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clock-names = "core_clk", "iface_clk", "bus_clk0", + "camss_top_ahb_clk", "camss_ahb_clk", "smmu_jpeg_axi_clk", + "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk", + "mmagic_camss_axi_clk"; + clocks = <&clock_mmss clk_camss_jpeg2_clk>, + <&clock_mmss clk_camss_jpeg_ahb_clk>, + <&clock_mmss clk_camss_jpeg_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_camss_ahb_clk>, + <&clock_mmss clk_smmu_jpeg_axi_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>; + qcom,clock-rates = <266670000 0 0 0 0 0 0 0 0>; + qcom,vbif-reg-settings = <0x4 0x1>, + <0xb0 0x00100010>, + <0xc0 0x10001000>; + qcom,qos-reg-settings = <0x28 0x00000008>; + qcom,prefetch-reg-settings = <0x30c 0x1111>, + <0x318 0x0>, + <0x324 0x31>, + <0x330 0x31>, + <0x33c 0x31>; + status = "ok"; + }; + + qcom,jpeg@aa0000 { + cell-index = <3>; + compatible = "qcom,jpeg_dma"; + reg = <0xaa0000 0x4000>, + <0xa60000 0x3000>; + reg-names = "jpeg"; + interrupts = <0 304 0>; + interrupt-names = "jpeg"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_jpeg>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clock-names = "core_clk", "iface_clk", "bus_clk0", + "camss_top_ahb_clk", "camss_ahb_clk", "smmu_jpeg_axi_clk", + "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk", + "mmagic_camss_axi_clk"; + clocks = <&clock_mmss clk_camss_jpeg_dma_clk>, + <&clock_mmss clk_camss_jpeg_ahb_clk>, + <&clock_mmss clk_camss_jpeg_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_camss_ahb_clk>, + <&clock_mmss clk_smmu_jpeg_axi_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>; + qcom,clock-rates = <266670000 0 0 0 0 0 0 0 0>; + qcom,vbif-reg-settings = <0x4 0x1>, + <0xb0 0x00100010>, + <0xc0 0x10001000>; + qcom,qos-reg-settings = <0x28 0x00000008>; + qcom,prefetch-reg-settings = <0x18c 0x11>, + <0x1a0 0x31>, + <0x1b0 0x31>; + status = "ok"; + }; + diff --git a/Documentation/devicetree/bindings/media/video/msm-jpegdma.txt b/Documentation/devicetree/bindings/media/video/msm-jpegdma.txt new file mode 100644 index 000000000000..a1d604218219 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-jpegdma.txt @@ -0,0 +1,74 @@ +* Qualcomm Technologies, Inc. MSM JPEG DMA + +Jpeg dma hardware block. + +Jpeg dma can replicate and downscale yuv frames. +Supported formats: Monochrome, NV12 and NV21. + +Required properties: +- compatible : "qcom,jpegdma". +- reg : offset and length of the register set of jpeg dma device and + vbif device for the jpeg dma operating in compatible mode. +- reg-names : should specify relevant names to each reg property defined. +- interrupts : should contain the jpeg interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. +- mmagic-vdd-supply: phandle to GDSC regulator controlling mmagic. +- camss-vdd-supply: phandle to GDSC regulator controlling camss. +- clock-names : names of clocks required for the device. +- clocks : clocks required for the device. +- qcom,clock-rates: should specify clock rates in Hz to each clocks + property defined. +- qcom,max-ds-factor: should specify the max dma downscale factor, + supported by HW. +- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + +Optional properties: +- qcom,vbif-reg-settings: relative address offsets and value pairs for VBIF registers. +- qcom,qos-reg-settings: relative address offsets and value pairs for QoS registers. +- qcom,prefetch-reg-settings: relative address offsets and value pairs for + MMU prefetch registers. + +Example: + qcom,jpegdma@aa0000 { + compatible = "qcom,jpegdma"; + reg = <0xaa0000 0x4000>, + <0xa60000 0x3000>; + reg-names = "jpegdma_core", "jpeg_vbif"; + interrupts = <0 304 0>; + interrupt-names = "jpeg"; + mmagic-vdd-supply = <&gdsc_mmagic_camss>; + camss-vdd-supply = <&gdsc_camss_top>; + vdd-supply = <&gdsc_jpeg>; + qcom,vdd-names = "mmagic-vdd", "camss-vdd", "vdd"; + clock-names = "core_clk", "iface_clk", "bus_clk0", + "camss_top_ahb_clk", "camss_ahb_clk", "smmu_jpeg_axi_clk", + "mmss_mmagic_ahb_clk", "mmssnoc_axi_clk", + "mmagic_camss_axi_clk"; + clocks = <&clock_mmss clk_camss_jpeg_dma_clk>, + <&clock_mmss clk_camss_jpeg_ahb_clk>, + <&clock_mmss clk_camss_jpeg_axi_clk>, + <&clock_mmss clk_camss_top_ahb_clk>, + <&clock_mmss clk_camss_ahb_clk>, + <&clock_mmss clk_smmu_jpeg_axi_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>, + <&clock_gcc clk_mmssnoc_axi_clk>, + <&clock_mmss clk_mmagic_camss_axi_clk>; + qcom,clock-rates = <266670000 0 0 0 0 0 0 0 0>, + qcom,vbif-reg-settings = <0x4 0x1>; + qcom,prefetch-reg-settings = <0x18c 0x11>, + <0x1a0 0x31>, + <0x1b0 0x31>; + qcom,msm-bus,name = "msm_camera_jpeg_dma"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = <62 512 0 0>, + <62 512 666675 666675>; + qcom,max-ds-factor = <128>; + status = "ok"; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-sde-rotator.txt b/Documentation/devicetree/bindings/media/video/msm-sde-rotator.txt new file mode 100644 index 000000000000..bd35d80ccaff --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-sde-rotator.txt @@ -0,0 +1,151 @@ +SDE Rotator + +SDE rotator is a v4l2 rotator driver, which manages the rotator hw +block inside the Snapdragon Display Engine (or Mobile Display Subsystem) + +Required properties +- compatible: Must be "qcom,sde-rotator". +- reg: offset and length of the register set for the device. +- reg-names: names to refer to register sets related to this device +- interrupt-parent: phandle for the interrupt controller that + services interrupts for this device. +- interrupts: Interrupt associated with rotator. +- <name>-supply: Phandle for <name> regulator device node. +- qcom,supply-names: names to refer to regulator device node. +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. +Bus Scaling Data: +- qcom,msm-bus,name: String property describing rotator client. +- qcom,msm-bus,num-cases: This is the the number of Bus Scaling use cases + defined in the vectors property. This must be + set to <3> for rotator driver where use-case 0 is + used to take off rotator BW votes from the system. + And use-case 1 & 2 are used in ping-pong fashion + to generate run-time BW requests. +- qcom,msm-bus,num-paths: This represents the number of paths in each + Bus Scaling Usecase. This value depends on + how many number of AXI master ports are + dedicated to rotator for particular chipset. +- qcom,msm-bus,vectors-KBps: * A series of 4 cell properties, with a format + of (src, dst, ab, ib) which is defined at + Documentation/devicetree/bindings/arm/msm/msm_bus.txt + * Current values of src & dst are defined at + include/linux/msm-bus-board.h + src values allowed for rotator are: + 25 = MSM_BUS_MASTER_ROTATOR + dst values allowed for rotator are: + 512 = MSM_BUS_SLAVE_EBI_CH0 + ab: Represents aggregated bandwidth. + ib: Represents instantaneous bandwidth. + * Total number of 4 cell properties will be + (number of use-cases * number of paths). + * These values will be overridden by the driver + based on the run-time requirements. So initial + ab and ib values defined here are random and + bare no logic except for the use-case 0 where ab + and ib values needs to be 0. + * Define realtime vector properties followed by + non-realtime vector properties. + +Optional properties +- qcom,rot-vbif-settings: Array with key-value pairs of constant VBIF register + settings used to setup MDSS QoS for optimum performance. + The key used should be offset from "rot_vbif_phys" register + defined in reg property. +- qcom,mdss-rot-block-size: This integer value indicates the size of a memory block + (in pixels) to be used by the rotator. If this property + is not specified, then a default value of 128 pixels + would be used. +- qcom,mdss-highest-bank-bit: This integer value indicate tile format as opposed to usual + linear format. The value tells the GPU highest memory + bank bit used. +- qcom,mdss-default-ot-wr-limit: This integer value indicates maximum number of pending + writes that can be allowed on each WR xin. + This value can be used to reduce the pending writes + limit and can be tuned to match performance + requirements depending upon system state. + Some platforms require a dynamic ot limiting in + some cases. Setting this default ot write limit + will enable this dynamic limiting for the write + operations in the platforms that require these + limits. +- qcom,mdss-default-ot-rd-limit: This integer value indicates the default number of pending + reads that can be allowed on each RD xin. + Some platforms require a dynamic ot limiting in + some cases. Setting this default ot read limit + will enable this dynamic limiting for the read + operations in the platforms that require these + limits. +- qcom,mdss-rot-vbif-qos-setting: This array is used to program vbif qos remapper register + priority for rotator clients. +- qcom,mdss-rot-mode: This is integer value indicates operation mode + of the rotator device + +Subnode properties: +- compatible: Compatible name used in smmu v2. + smmu_v2 names should be: + "qcom,smmu_sde_rot_unsec"- smmu context bank device for + unsecure rotation domain. + "qcom,smmu_sde_rot_sec" - smmu context bank device for + secure rotation domain. +- iommus: specifies the SID's used by this context bank +- gdsc-mdss-supply: Phandle for mdss supply regulator device node. +- clocks: List of Phandles for clock device nodes + needed by the device. +- clock-names: List of clock names needed by the device. + + +Example: + mdss_rotator: qcom,mdss_rotator { + compatible = "qcom,sde_rotator"; + reg = <0xfd900000 0x22100>, + <0xfd925000 0x1000>; + reg-names = "mdp_phys", "rot_vbif_phys"; + interrupt-parent = <&mdss_mdp>; + interrupts = <2 0>; + + qcom,mdss-mdp-reg-offset = <0x00001000>; + + rot-vdd-supply = <&gdsc_mdss>; + qcom,supply-names = "rot-vdd"; + + clocks = <&clock_mmss clk_mmss_mdss_ahb_clk>, + <&clock_mmss clk_mmss_mdss_rot_clk>; + clock-names = "iface_clk", "rot_core_clk"; + + qcom,mdss-highest-bank-bit = <0x2>; + + /* Bus Scale Settings */ + qcom,msm-bus,name = "mdss_rotator"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <25 512 0 0>, + <25 512 0 6400000>, + <25 512 0 6400000>; + + /* VBIF QoS remapper settings*/ + qcom,mdss-rot-vbif-qos-setting = <1 1 1 1>; + + qcom,mdss-default-ot-rd-limit = <8>; + qcom,mdss-default-ot-wr-limit = <16>; + + smmu_rot_unsec: qcom,smmu_rot_unsec_cb { + compatible = "qcom,smmu_sde_rot_unsec"; + iommus = <&mdp_smmu 0xe00>; + gdsc-mdss-supply = <&gdsc_bimc_smmu>; + clocks = <&clock_mmss clk_bimc_smmu_ahb_clk>, + <&clock_mmss clk_bimc_smmu_axi_clk>; + clock-names = "rot_ahb_clk", "rot_axi_clk"; + }; + + smmu_sde_rot_sec: qcom,smmu_sde_rot_sec_cb { + compatible = "qcom,smmu_sde_rot_sec"; + iommus = <&mmss_smmu 0xe01>; + gdsc-mdss-supply = <&gdsc_bimc_smmu>; + clocks = <&clock_mmss clk_bimc_smmu_ahb_clk>, + <&clock_mmss clk_bimc_smmu_axi_clk>; + clock-names = "rot_ahb_clk", "rot_axi_clk"; + }; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-vfe.txt b/Documentation/devicetree/bindings/media/video/msm-vfe.txt new file mode 100644 index 000000000000..aaf13442fcf1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-vfe.txt @@ -0,0 +1,208 @@ +* Qualcomm Technologies, Inc. MSM VFE + +Required properties for parent node: +- compatible : + - "qcom,vfe" +- #address-cells : Number of address related values in the reg field +- #size-cells : Number of size related values in the reg field +- ranges: How the register offsets for child translate to parent. + +Required properties for child node: +- cell-index: vfe hardware core index +- compatible : + - "qcom,vfe32" + - "qcom,vfe40" + - "qcom,vfe44" + - "qcom,vfe46" + - "qcom,vfe47" + - "qcom,vfe48" +- reg : offset and length of the register set for the device + for the vfe operating in compatible mode. For parent node, add union of + all registers for both vfe. +- reg-names : should specify relevant names to each reg property defined. + Only needed for child node. + - "vfe" - Required. + - "vfe_vbif" - Optional for "vfe32". Required for "vfe40". + - "vfe_fuse" - Optional. +- interrupts : should contain the vfe interrupt. +- interrupt-names : should specify relevant names to each interrupts + property defined. + - "vfe" - Required. +- vdd-supply: phandle to GDSC regulator controlling VFE core. +- qos-entries: number of QoS registers to program +- qos-regs: relative address offsets of QoS registers +- qos-settings: QoS values to be written to QoS registers +- vbif-entries - number of VBIF registers to program (optional) +- vbif-regs: relative address offsets of VBIF registers (optional) +- vbif-settings: VBIF values to be written to VBIF registers (optional) +- ds-entries: number danger/safe registers to program (optional) +- ds-regs: relative address offsets of danger/safe registers (optional) +- ds-settings: danger/safe values to be written to registers (optional) + NOTE: For all qos*, vbif*, ds* parameters, same SoC can have different + hardware versions with different entries/registers/settings. They can be + specified by adding version to the string e.g. qos-v2-settings. Also + different SoC can have same hardware version and still different QOS, VBIF, + and DS parameters. In this case they are exported if separate SoC version + specific dts files. +- max-svs-clk: svs rate of the VFE clock in Hertz. +- max-nominal-clk: nominal rate of the VFE clock in Hertz. +- max-turbo-clk: turbo/high rate of the VFE clock in Hertz. + +Example: + +vfe0: qcom,vfe0@fda10000 { + cell-index = <0>; + compatible = "qcom,vfe44"; + reg = <0xfda10000 0x1000>, + <0xfda40000 0x200>, + <0x7801a4 0x8>; + reg-names = "vfe", "vfe_vbif", "vfe_fuse"; + interrupts = <0 57 0>; + interrupt-names = "vfe"; + vdd-supply = <&gdsc_vfe>; + qos-entries = <8>; + qos-regs = <0x2c4 0x2c8 0x2cc 0x2d0 0x2d4 0x2d8 + 0x2dc 0x2e0>; + qos-settings = <0xaaaaaaaa 0xaaaaaaaa 0xaaaaaaaa + 0xaaaaaaaa 0xaaaaaaaa 0xaaaaaaaa + 0xaaaaaaaa 0x0002aaaa>; + qos-v2-settings = <0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0x0001aaa9>; + qos-v3-settings = <0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0x0001aaa9>; + vbif-entries = <17>; + vbif-regs = <0x4 0xb0 0xb4 0xb8 0xc0 0xc4 0xc8 0xd0 + 0xd4 0xd8 0xdc 0xf0 0x178 0x17c 0x124 0x160 + 0x164>; + vbif-settings = <0x1 0x01010101 0x01010101 0x10010110 + 0x10101010 0x10101010 0x10101010 0x00001010 + 0x00001010 0x00000707 0x00000707 0x00000030 + 0x00000fff 0x0fff0fff 0x00000001 0x22222222 + 0x00002222>; + vbif-v2-entries = <16>; + vbif-v2-regs = <0x4 0xb0 0xb4 0xb8 0xc0 0xc4 0xc8 0xd0 + 0xd4 0xd8 0xf0 0x178 0x17c 0x124 0x160 + 0x164>; + vbif-v2-settings = <0x1 0x10101010 0x10101010 0x10101010 + 0x10101010 0x10101010 0x10101010 0x00000010 + 0x00000010 0x00000707 0x00000010 0x00000fff + 0x0fff0fff 0x00000003 0x22222222 0x00002222>; + ds-entries = <17>; + ds-regs = <0x988 0x98c 0x990 0x994 0x998 + 0x99c 0x9a0 0x9a4 0x9a8 0x9ac 0x9b0 + 0x9b4 0x9b8 0x9bc 0x9c0 0x9c4 0x9c8>; + ds-settings = <0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x00000103>; + max-clk-svs = <300000000>; + max-clk-nominal = <465000000>; + max-clk-turbo = <600000000>; +}; + +vfe1: qcom,vfe1@fda14000 { + cell-index = <1>; + compatible = "qcom,vfe44"; + reg = <0xfda14000 0x1000>, + <0xfda40000 0x200>, + <0x7801a4 0x8>; + reg-names = "vfe", "vfe_vbif", "vfe_fuse"; + interrupts = <0 58 0>; + interrupt-names = "vfe"; + vdd-supply = <&gdsc_vfe>; + qos-entries = <8>; + qos-regs = <0x2c4 0x2c8 0x2cc 0x2d0 0x2d4 0x2d8 + 0x2dc 0x2e0>; + qos-settings = <0xaaaaaaaa 0xaaaaaaaa 0xaaaaaaaa + 0xaaaaaaaa 0xaaaaaaaa 0xaaaaaaaa + 0xaaaaaaaa 0x0002aaaa>; + qos-v2-settings = <0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0x0001aaa9>; + qos-v3-settings = <0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0xaaa9aaa9 0xaaa9aaa9 + 0xaaa9aaa9 0x0001aaa9>; + vbif-entries = <17>; + vbif-regs = <0x4 0xb0 0xb4 0xb8 0xc0 0xc4 0xc8 0xd0 + 0xd4 0xd8 0xdc 0xf0 0x178 0x17c 0x124 0x160 + 0x164>; + vbif-settings = <0x1 0x01010101 0x01010101 0x10010110 + 0x10101010 0x10101010 0x10101010 0x00001010 + 0x00001010 0x00000707 0x00000707 0x00000030 + 0x00000fff 0x0fff0fff 0x00000001 0x22222222 + 0x00002222>; + vbif-v2-entries = <16>; + vbif-v2-regs = <0x4 0xb0 0xb4 0xb8 0xc0 0xc4 0xc8 0xd0 + 0xd4 0xd8 0xf0 0x178 0x17c 0x124 0x160 + 0x164>; + vbif-v2-settings = <0x1 0x10101010 0x10101010 0x10101010 + 0x10101010 0x10101010 0x10101010 0x00000010 + 0x00000010 0x00000707 0x00000010 0x00000fff + 0x0fff0fff 0x00000003 0x22222222 0x00002222>; + ds-entries = <17>; + ds-regs = <0x988 0x98c 0x990 0x994 0x998 + 0x99c 0x9a0 0x9a4 0x9a8 0x9ac 0x9b0 + 0x9b4 0x9b8 0x9bc 0x9c0 0x9c4 0x9c8>; + ds-settings = <0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x44441111 0x44441111 + 0x44441111 0x00000103>; + max-clk-svs = <300000000>; + max-clk-nominal = <465000000>; + max-clk-turbo = <600000000>; +}; + +qcom,vfe { + compatible = "qcom,vfe"; + num_child = <2>; +}; + +In version specific file one needs to move only entries that differ between +SoC versions with same VFE HW version: + + &vfe0 { + qos-entries = <8>; + qos-regs = <0x378 0x37C 0x380 0x384 0x388 0x38C + 0x390 0x394>; + qos-settings = <0xAAA9AAA9 + 0xAAA9AAA9 + 0xAAA9AAA9 + 0xAAA9AAA9 + 0xAAA9AAA9 + 0xAAA9AAA9 + 0xAAA9AAA9 + 0x0001AAA9>; + vbif-entries = <1>; + vbif-regs = <0x124>; + vbif-settings = <0x3>; + ds-entries = <17>; + ds-regs = <0xBD8 0xBDC 0xBE0 0xBE4 0xBE8 + 0xBEC 0xBF0 0xBF4 0xBF8 0xBFC 0xC00 + 0xC04 0xC08 0xC0C 0xC10 0xC14 0xC18>; + ds-settings = <0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x44441111 + 0x00000103>; + max-clk-svs = <300000000>; + max-clk-nominal = <465000000>; + max-clk-turbo = <600000000>; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-vidc-bus.txt b/Documentation/devicetree/bindings/media/video/msm-vidc-bus.txt new file mode 100644 index 000000000000..1d4056fa91c1 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-vidc-bus.txt @@ -0,0 +1,49 @@ +* Qualcomm Technologies Inc MSM VIDC BUS + +Required properties: +- compatible : "qcom,msm-vidc,governor,table" +- name : name of the governor. +- qcom,bus-table : node containing individual domain nodes, each with: + - qcom,codec-mask: a bitmap of supported codec types, every two bits + represents a codec type. + - qcom,load-busfreq-tbl: load (in macroblocks/sec) and the corresponding + bus frequency (in KBps) table. + +Optional properties: +- qcom,low-power-mode: a boolean which indicates whether bus profile need + to be used when client enables low-power mode. +- qcom,ubwc-mode: a boolean which indicates whether the bus profile need + to be used when client enables UBWC mode. + +Example: + +venus-bus-gov { + compatible = "qcom,msm-vidc,governor,table"; + name = "qcom,venus-gov"; + qcom,bus-freq-table { + qcom,profile-dec { + qcom,codec-mask = <0xffffffff>; + qcom,ubwc-mode; + qcom,load-busfreq-tbl = + <489600 1205248>, /* 1080p60D */ + <244800 618496>, /* 1080p30D */ + <216000 618496>, /* 720p60D */ + <108000 314368>, /* 720p30D */ + <72000 233472>, /* VGA60D */ + <36000 118784>, /* VGA30D */ + <0 0>; + }; + qcom,profile-enc { + qcom,codec-mask = <0x55555555>; + qcom,low-power-mode; + qcom,load-busfreq-tbl = + <244800 787456>, /* 1080p30E */ + <216000 350208>, /* 720p60E */ + <108000 350208>, /* 720p30E */ + <72000 350208>, /* VGA60E */ + <36000 136806>, /* VGA30E */ + <0 0>; + }; + }; +}; + diff --git a/Documentation/devicetree/bindings/media/video/msm-vidc-vmem.txt b/Documentation/devicetree/bindings/media/video/msm-vidc-vmem.txt new file mode 100644 index 000000000000..5b5323ee786a --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-vidc-vmem.txt @@ -0,0 +1,42 @@ +* Qualcomm Technologies Inc MSM VIDC VMEM + +Required properties: +- compatible : "qcom,msm-vmem" +- interrupts : Contains the interrupt that maps to the VMEM module +- reg : A set of 2 start address and size pairs that describe the hardware +register address space and mappable memory address space. +- reg-names : Strings that describe the pairs in "reg". The register address +space should be called "reg-base" and the memory space should be called "mem-base". +- clocks : A set of clocks that correspond to the AHB and MAXI clocks that the +hardware uses. +- clock-names : A string that describes the "clocks" property. The AHB clock +should be named "ahb" and the MAXI clock should be named "maxi". +- qcom,bank-size : The size of each memory bank, in bytes. +- vdd-supply: phandle to a regulator that is considered to be the footswitch for vmem. +- qcom,msm-bus,(name|num-cases,num-paths,vectors-KBps) - Bus to be voted for prior to + issuing any IO transactions to vmem. Refer to Documentation/devicetree/bindings/arm/\ + msm/msm_bus_adhoc.txt for further details. + +Example: + +qcom,vmem@880000 { + compatible = "qcom,msm-vmem"; + interrupts = <0 429 0>; + reg = <0x880000 0x800>, + <0x6800000 0x100000>; + reg-names = "reg-base", "mem-base"; + + vdd-supply = <&gdsc_mmagic_video>; + clocks = <&clock_mmss clk_vmem_ahb_clk>, + <&clock_mmss clk_vmem_maxi_clk>; + clock-names = "ahb", "maxi"; + + qcom,bank-size = <131072>; + + qcom,msm-bus,name = "vmem"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <MSM_BUS_MASTER_AMPSS_M0 MSM_BUS_SLAVE_VMEM_CFG 0 0>, + <MSM_BUS_MASTER_AMPSS_M0 MSM_BUS_SLAVE_VMEM_CFG 500 800>; +}; diff --git a/Documentation/devicetree/bindings/media/video/msm-vidc.txt b/Documentation/devicetree/bindings/media/video/msm-vidc.txt new file mode 100644 index 000000000000..c26e9fb456e3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-vidc.txt @@ -0,0 +1,299 @@ +* Qualcomm MSM VIDC + +[Root level node] +Venus +===== +Required properties: +- compatible : one of: + - "qcom,msm-vidc" +- qcom,max-hw-load: The maximum load the hardware can support expressed in units + of macroblocks per second. The load is a reflection of hardware capability + rather than a performance guarantee. Performance is guaranteed only up to + advertised capability of the chipset. +- qcom,firmware-name : firmware file name to be downloaded. + +Optional properties: +- reg : offset and length of the register set for the device. +- interrupts : should contain the vidc interrupt. +- qcom,platform-version : mask and shift of the platform version bits + in efuse register. +- qcom,load-freq-tbl : load (in macroblocks/sec) and corresponding vcodec + clock required along with codec's config, which is a bitmap that describes + what the clock is used for. The bitmaps are as follows: + supports mvc encoder = 0x00000001 + supports mvc decoder = 0x00000003 + supports h264 encoder = 0x00000004 + supports h264 decoder = 0x0000000c + supports h263 encoder = 0x00000010 + supports h263 decoder = 0x00000030 + supports mpeg1 encoder = 0x00000040 + supports mpeg1 decoder = 0x000000c0 + supports mpeg2 encoder = 0x00000100 + supports mpeg2 decoder = 0x00000300 + supports mpeg4 encoder = 0x00000400 + supports mpeg4 decoder = 0x00000c00 + supports divx_311 encoder = 0x00001000 + supports divx_311 decoder = 0x00003000 + supports divx encoder = 0x00004000 + supports divx decoder = 0x0000c000 + supports vc1 encoder = 0x00010000 + supports vc1 decoder = 0x00030000 + supports spark encoder = 0x00040000 + supports spark decoder = 0x000c0000 + supports vp6 encoder = 0x00100000 + supports vp6 decoder = 0x00300000 + supports vp7 encoder = 0x00400000 + supports vp7 decoder = 0x00c00000 + supports vp8 encoder = 0x01000000 + supports vp8 decoder = 0x03000000 + supports hevc encoder = 0x04000000 + supports hevc decoder = 0x0c000000 + supports hevc_hybrid encoder = 0x10000000 + supports hevc_hybrid decoder = 0x30000000 +- qcom,dcvs-tbl : specifies the parameter to configure DCVS algorithm. Video + instance load (in mbs/sec) and corresponding low and high threshold DCVS + load for supported codec formats. +- qcom,dcvs-limit : specifies the minimum specifications required to kick in + DCVS algorithm. Min MBs per frame and the fps for encoder and decoder to + kick in DCVS. +- qcom,imem-ab-tbl : video core frequency in Hz and corresponding imem ab value + in kbps. The imem ab value corresponds to the clock frequency at which imem + should operate for a particular video core frequency. +- qcom,reg-presets : list of offset-value pairs for registers to be written. + The offsets are from the base offset specified in 'reg'. This is mainly + used for QoS, VBIF, etc. presets for video. +- qcom,qdss-presets : list of physical address and memory allocation size pairs. + when fw_debug_mode is set as HFI_DEBUG_MODE_QDSS, all firmware messages will be + written to QDSS memory. +- qcom,imem-size: imem size required by hardware for optimum performance. + If imem is not present then there is no need to specify this property. +- *-supply: A phandle pointing to the appropriate regulator. Number of + regulators vary across targets. +- clock-names: an array of clocks that the driver is supposed to be + manipulating. The clocks names here correspond to the clock names used in + clk_get(<name>). +- qcom,clock-configs = an array of bitmaps of clocks' configurations. The index + of the bitmap corresponds to the clock at the same index in qcom,clock-names. + The bitmaps describes the actions that the device needs to take regarding the + clock (i.e. scale it based on load). + + The bitmap is defined as: + scalable = 0x1 (if the driver should vary the clock's frequency based on load) +- qcom,allowed-clock-rates = an array of supported clock rates by the chipset. +- qcom,clock-freq-tbl = node containing individual domain nodes, each with: + - qcom,codec-mask: a bitmap of supported codec types, every two bits + represents a codec type. + - qcom,cycles-per-mb: number of cycles required to process each macro + block. + - qcom,low-power-mode-factor: the factor which needs to be multiple with + the required frequency to get the final frequency, the factor is + represented in Q16 format. +- qcom,sw-power-collapse = A bool indicating if video hardware core can be + power collapsed in idle state. +- qcom,slave-side-cp = A bool indicating the content protection mode for an + ongoing video session. It is true for targets where the mode is slave side. +- qcom,never-unload-fw = A bool indicating if video firmware should be not be + unloaded after all active sessions have closed. Once a new session starts up + after this, the firmware will be ready to go. This should be set on platforms + that desire low-latency video startup and don't mind "leakage" of some memory. +- qcom,use-non-secure-pil = A bool indicating which type of pil to use to load + the fw. +- qcom,fw-bias = The address at which venus fw is loaded (manually). +- qcom,enable-idle-indicator = A bool to enable video hardware to generate + idle message when it is in idle state. +- qcom,enable-thermal-mitigation = A bool to enable thermal mitigation when + thermal run away occurs. +- qcom,hfi-version = The hfi packetization version supported by venus firmware. + If hfi version is not specified, then packetization type will default to + legacy. +- qcom,vidc-iommu-domains = node containing individual domain nodes, each with: + - a unique domain name for the domain node (e.g vidc,domain-ns) + - qcom,vidc-domain-phandle: phandle for the domain as defined in + <target>-iommu-domains.dtsi (e.g msm8974-v1-iommu-domains.dtsi) + - qcom,vidc-buffer-types: bitmap of buffer types that can be mapped into each + IOMMU domain. + - Buffer types are defined as the following: + input = 0x1 + output = 0x2 + output2 = 0x4 + extradata input = 0x8 + extradata output = 0x10 + extradata output2 = 0x20 + internal scratch = 0x40 + internal scratch1 = 0x80 + internal scratch2 = 0x100 + internal persist = 0x200 + internal persist1 = 0x400 + internal cmd queue = 0x800 +- qcom,pm-qos-latency-us = The latency used to vote for QOS power manager. This + value is typically max(latencies of every cluster at all power levels) + 1 +- qcom,max-secure-instances = An int containing max number of concurrent secure + instances supported, accounting for venus and system wide limitations like + memory, performance etc. +- qcom,debug-timeout = A bool indicating that FW errors such as SYS_ERROR, + SESSION_ERROR and timeouts will be treated as Fatal. +- qcom,power-conf = Indicates the value at which or beyond, a video session + is configured in low power mode to have power benefits. Value is defined + interms of HxW of the video session beyond which power benefit is desired. +- qcom,cx-ipeak-data : phandle of cx_ipeak device node and bit position on + the cx register where venus is supposed to vote +- qcom,clock-freq-threshold : Operating threshold frequency of venus which + video driver uses to check against the frequency voted. Whenever venus + clock frequency crosses this mark, driver intimates cx ipeak driver on + supported targets. + +[Second level nodes] +Context Banks +============= +Required properties: +- compatible : one of: + - "qcom,msm-vidc,context-bank" +- iommus : A phandle parsed by smmu driver. Number of entries will vary + across targets. + +Optional properties: +- label - string describing iommu domain usage. +- buffer-types : bitmap of buffer types that can be mapped into the current + IOMMU domain. + - Buffer types are defined as the following: + input = 0x1 + output = 0x2 + output2 = 0x4 + extradata input = 0x8 + extradata output = 0x10 + extradata output2 = 0x20 + internal scratch = 0x40 + internal scratch1 = 0x80 + internal scratch2 = 0x100 + internal persist = 0x200 + internal persist1 = 0x400 + internal cmd queue = 0x800 +- virtual-addr-pool : offset and length of virtual address pool. +- qcom,fw-context-bank : bool indicating firmware context bank. +- qcom,secure-context-bank : bool indicating secure context bank. + +Buses +===== +Required properties: +- compatible : one of: + - "qcom,msm-vidc,bus" +- label : an arbitrary name +- qcom,bus-master : an integer descriptor of the bus master. Refer to arch/arm/\ + boot/dts/include/dt-bindings/msm/msm-bus-ids.h for list of acceptable masters +- qcom,bus-slave : an integer descriptor of the bus slave. Refer to arch/arm/\ + boot/dts/include/dt-bindings/msm/msm-bus-ids.h for list of acceptable slaves + +Optional properties: +- qcom,bus-governor : governor to use when scaling bus, generally any commonly + found devfreq governor might be used. In addition to those governors, the + custom Venus governors, "msm-vidc-ddr" or "msm-vidc-vmem" are also + acceptable values. + In the absence of this property the "performance" governor is used. +- qcom,bus-rage-kbps : an array of two items (<min max>) that indicate the + minimum and maximum acceptable votes for the bus. + In the absence of this property <0 INT_MAX> is used. +- qcom,ubwc-10bit : UBWC 10 bit content has different bus requirements, + this tag will be used to pick the appropriate bus as per the session profile + as shown below in example. + +Example: + + + qcom,vidc@fdc00000 { + compatible = "qcom,msm-vidc"; + reg = <0xfdc00000 0xff000>; + interrupts = <0 44 0>; + venus-supply = <&gdsc>; + venus-core0-supply = <&gdsc1>; + venus-core1-supply = <&gdsc2>; + qcom,load-freq-tbl = + <489600 266670000 0x030fcfff>, /* Legacy decoder 1080p 60fps */ + <108000 133330000 0x030fcfff>, /* Legacy decoder 720p 30fps */ + <108000 200000000 0x01000414>, /* Legacy encoder 720p 30fps */ + <72000 133330000 0x0c000000>, /* HEVC decoder VGA 60fps */ + <36000 133330000 0x0c000000>, /* HEVC VGA 30 fps */ + <36000 133330000 0x01000414>; /* Legacy encoder VGA 30 fps */ + qcom,dcvs-tbl = + <972000 972000 19944000 0xffffffff>, /* Legacy decoder UHD 30fps */ + <489600 489600 972000 0xffffffff>, /* Legacy decoder 1080p 60fps */ + <244800 244800 489600 0xffffffff>, /* Legacy decoder 1080p 30fps */ + <829440 489600 972000 0x55555555>; /* Legacy encoder DCI 24fps + qcom,dcvs-limit = + <32400 30>, /* Encoder UHD */ + <14400 30>; /* Decoder WQHD */ + qcom,imem-ab-tbl = + <75000000 1500000>, /* imem clk @ 75 Mhz */ + <150000000 1500000>, /* imem clk @ 75 Mhz */ + <355333333 2500000>, /* imem clk @ 170 Mhz */ + <533000000 6000000>; /* imem clk @ 320 Mhz */ + + qcom,imem-size = <4096>; + qcom,firmware-name = "venus"; + qcom,hfi-version = "3xx"; + qcom,reg-presets = <0x80004 0x1>, + <0x80178 0x00001FFF>; + qcom,qdss-presets = <0xFC307000 0x1000>, + <0xFC322000 0x1000>; + qcom,max-hw-load = <1224450>; /* 4k @ 30 + 1080p @ 30*/ + qcom,power-conf = <8294400>; /* WxH - 3840*2160 */ + qcom,never-unload-fw; + clock-names = "foo_clk", "bar_clk", "baz_clk"; + qcom,clock-configs = <0x3 0x1 0x0>; + qcom,sw-power-collapse; + qcom,enable-idle-indicator; + qcom,buffer-type-tz-usage-table = <0x1 0x1>, + <0x1fe 0x2>; + qcom,enable-thermal-mitigation; + qcom,use-non-secure-pil; + qcom,slave-side-cp; + qcom,use_dynamic_bw_update; + qcom,fw-bias = <0xe000000>; + msm_vidc_cb1: msm_vidc_cb1 { + compatible = "qcom,msm-vidc,context-bank"; + label = "venus_ns"; + iommus = <&venus_smmu 0x0a>, + <&venus_smmu 0x0b>, + <&venus_smmu 0x0c>; + buffer-types = <0xfff>; + virtual-addr-pool = <0x5dc00000 0x80000000>; + qcom,secure-context-bank; + }; + + msm_vidc_cb2: msm_vidc_cb2 { + compatible = "qcom,msm-vidc,context-bank"; + qcom,fw-context-bank; + iommus = <&venus_smmu 0x100>, + <&venus_smmu 0x106>; + }; + + bus_cnoc { + compatible = "qcom,msm-vidc,bus"; + label = "venus-cnoc"; + qcom,bus-master = <MSM_BUS_MASTER_AMPSS_M0>; + qcom,bus-slave = <MSM_BUS_SLAVE_VENUS_CFG>; + qcom,bus-governor = "performance"; + qcom,bus-range-kbps = <1 1>; + }; + + venus_bus_ddr { + compatible = "qcom,msm-vidc,bus"; + label = "venus-ddr"; + qcom,bus-master = <MSM_BUS_MASTER_VIDEO_P0>; + qcom,bus-slave = <MSM_BUS_SLAVE_EBI_CH0>; + qcom,bus-governor = "msm-vidc-ddr"; + qcom,bus-range-kbps = <1000 3388000>; + }; + qcom,profile-dec-ubwc-10bit { + qcom,codec-mask = <0xffffffff>; + qcom,ubwc-10bit; + qcom,load-busfreq-tbl = + <979200 2446336>, /* UHD30D */ + <864000 2108416>, /* 720p240D */ + <489600 1207296>, /* 1080p60D */ + <432000 1058816>, /* 720p120D */ + <244800 616448>, /* 1080p30D */ + <216000 534528>, /* 720p60D */ + <108000 271360>, /* 720p30D */ + <0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/video/msm-vpu.txt b/Documentation/devicetree/bindings/media/video/msm-vpu.txt new file mode 100644 index 000000000000..6aea66b500dc --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/msm-vpu.txt @@ -0,0 +1,60 @@ +* Qualcomm Technologies, Inc. MSM VPU + +VPU (Video Processing Unit) applies high quality video post-processing +functions like noise reduction, deinterlacing, scaling, etc in real-time +on streaming video. + + +Required properties: +- compatible: + - "qcom,vpu" +- reg: Specify offset and length of the device register sets. +- reg-names: Names corresponding to the defined register sets. + - "vpu_csr": CSR registers + - "vpu_smem": Shared memory + - "vpu_vbif": VBIF registers (optional) +- interrupts: Specify the vpu interrupts. +- interrupt-names: Names corresponding to the defined interrupts list. + - "vpu_wdog": Watchdog interrupt + - "vpu_hfi": Firmware to Host interrupt +- clock-names: Array of clocks that the driver requires for the device. + The names here correspond to the clock names used in clk_get(<name>). +- qcom,bus-load-vector-tbl: Vectors of <load, ab, ib>. The (ab,ib) pairs are + ddr bus bandwidths to be requested at corresponding video processing load. + Vectors should be in ascending order of load, and their number is variable. +- vdd-supply: regulator that supplies the vpu. + +Optional properties: +- qcom,enabled-iommu-maps: List of IOMMU maps to be enabled, defined by name. + If this property is not defined or invalid, then device assumes contiguous + buffers. Valid iommu names are: + - "vpu_nonsecure": IOMMU for accessing non-secure video buffers. + - "vpu_secure": IOMMU for accessing secure video buffers. + - "vpu_firmware": IOMMU for loading firmware image. +- qcom,vbif-reg-presets: List of offset-value pairs for VBIF registers to be + programmed. The offsets are from the base register specified in 'vpu_vbif'. + This is used to program default register values for QoS settings, etc. + +Example: + qcom,vpu@fdc00000 { + compatible = "qcom,vpu"; + reg = <0xfdc00000 0xff000>, + <0xbfe00000 0x100000>; + reg-names = "vpu_csr", "vpu_smem"; + interrupts = <0 44 0>, <0 45 0>; + interrupt-names = "vpu_wdog", "vpu_hfi"; + clock-names = "core_clk", "bus_clock", "iface_clk"; + qcom,maple-clk-load-freq-tbl = <100000 50000000>, + <500000 400000000>; + qcom,vdp-clk-load-freq-tbl = <200000 100000000>, + <400000 320000000>; + qcom,bus-clk-load-freq-tbl = <100000 40000000>, + <200000 80000000>; + qcom,bus-load-vector-tbl = <0 0 0>, + <489600 536000 1600000>, + <979200 2024000 1600000>; + qcom,enabled-iommu-maps = "vpu_nonsecure", "vpu_secure"; + qcom,vbif-reg-presets = <0xb0138 0x43ff>, + <0xb0178 0xff12350e>; + vdd-supply = <&gdsc_vpu>; + }; diff --git a/Documentation/devicetree/bindings/media/video/ovti-image-sensor.txt b/Documentation/devicetree/bindings/media/video/ovti-image-sensor.txt new file mode 100644 index 000000000000..cef9cf5fcee5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/video/ovti-image-sensor.txt @@ -0,0 +1,9 @@ +OmniVision Image Sensor Device Tree Bindings. +======================================== + +Boards with the OmniVision Image Sensor shall have the following properties: + +Required root node properties: + - compatible: + - "ovti,ov8865" : OmniVision OV8865 8 megapixel Image Sensor. + - "ovti,ov5648" : OmniVision OV5648 5 megapixel Image Sensor. diff --git a/Documentation/devicetree/bindings/mfd/qcom-i2c-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom-i2c-pmic.txt new file mode 100644 index 000000000000..7e9aee1a96b3 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom-i2c-pmic.txt @@ -0,0 +1,98 @@ +Qualcomm Technologies, Inc. I2C PMIC Interrupt Controller +Platform Independent Bindings + +The I2C PMIC Controller is used by multi-function PMIC devices which communicate +over the I2C bus. An I2C PMIC controller node typically contains one or more +child nodes representing the device's peripherals. Each of the peripherals +typically has its own driver on the platform bus and will be enumerated by this +controller. The controller exposes a regmap to the peripherals to communicate +over the I2C bus. + +The controller also controls interrupts for all of the peripherals on the bus. +The controller takes a summary interrupt, deciphers which peripheral triggered +the interrupt, and which of the peripheral's interrupts were triggered. Finally, +it calls the handlers for each of the virtual interrupts that were registered. + +This document describes the common platform independent bindings that apply +to all I2C PMIC interrupt controllers. + +======================================== +First Level Nodes - I2C PMIC Controllers +======================================== + +Platform independent properties: +- compatible + Usage: required + Value type: <string> + Definition: Must be "qcom,i2c-pmic". + +- reg + Usage: required + Value type: <u32> + Definition: 7-bit I2C address of the device. + +- interrupt-parent + Usage: optional + Value type: <phandle> + Definition: phandle of the interrupt controller which services the + summary interrupt. + +- interrupts + Usage: optional + Value type: <prop-encoded-array> + Definition: Summary interrupt specifier. + +- interrupt-controller + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates this device node is an + interrupt controller. + +- #interrupt-cells + Usage: optional + Value type: <u32> + Definition: Number of cells to encode an interrupt source. + +- qcom,periph-map + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of u32 arrays. This provides a mapping between the + summary status register bits and peripheral addresses. + + The number of arrays should match the number of summary + registers with up to 8 elements each. One element per bit + of the summary status register in order from the least + sigificant bit to the most significant bit. + +- pinctrl-names + Usage: optional + Value type: <string-list> + Definition: Should be "default". + Please refer to pinctrl-bindings.txt + +- pinctrl-0 + Usage: optional + Value type: <phandle-list> + Definition: phandle of the pin configuration. + Please refer to pinctrl-bindings.txt + +======= +Example +======= + +&i2c_3 { + status = "ok"; + qcom,smb138x@8 { + compatible = "qcom,i2c-pmic"; + reg = <0x8>; + interrupt-parent = <&tlmm_pinmux>; + interrupts = <83 0>; + interrupt-controller; + #interrupt-cells = <3>; + pinctrl-names = "default"; + pinctrl-0 = <&smb_stat_active>; + #address-cells = <1>; + #size-cells = <0>; + qcom,periph-map = <0x10 0x11 0x12 0x13 0x14 0x16 0x36>; + }; +}; diff --git a/Documentation/devicetree/bindings/mhi/msm_mhi.txt b/Documentation/devicetree/bindings/mhi/msm_mhi.txt new file mode 100644 index 000000000000..5f950604d186 --- /dev/null +++ b/Documentation/devicetree/bindings/mhi/msm_mhi.txt @@ -0,0 +1,152 @@ +MSM MHI + +MSM MHI enables communication with a device over a PCIe link using the +Modem Host Interface protocol. The bindings referred to below, enable +the correct configuration of the interface and required sideband +signals. + +============== +Node Structure +============== + +Main node properties: + +- compatible + Usage: required + Value type: <string> + Definition: "qcom,mhi" + +- qcom,pci-dev_id + Usage: required + Value type: <u32> + Definition: Device id reported by modem + +- qcom,pci-domain + Usage: required + Value type: <u32> + Definition: PCIE root complex device connected to + +- qcom,pci-bus + Usage: required + Value type: <u32> + Definition: PCIE bus device connected to + +- qcom,pci-slot + Usage: required + Value type: <u32> + Definition: PCIE slot (dev_id/function) device connected to + +- esoc-names + Usage: optional + Value type: <string> + Definition: esoc name for the device + +- esoc-0 + Usage: required if "esoc-names" is defined + Value type: phandle + Definition: A phandle pointing to the esoc node. + +- qcom,msm-bus,name + Usage: required if MHI is bus master + Value type: string + Definition: string representing the client name + +- qcom,msm-bus,num-cases + Usage: required if MHI is bus master + Value type: <u32> + Definition: Number of use cases MHI support. Must be set to 2. + +- qcom,msm-bus,num-paths + Usage: required if MHI is bus master + Value type: <u32> + Definition: Total number of master-slave pairs. Must be set to one. + +- qcom,msm-bus,vectors-KBps + Usage: required if MHI is bus master + Value type: Array of <u32> + Definition: Array of tuples which define the bus bandwidth requirements. + Each tuple is of length 4, values are master-id, slave-id, + arbitrated bandwidth in KBps, and instantaneous bandwidth in + KBps. + +- mhi-chan-cfg-# + Usage: required + Value type: Array of <u32> + Definition: mhi channel configuration parameters for platform + defined as below <A B C D>: + A = chan number + B = maximum descriptors + C = event ring associated with channel + D = flags defined by mhi_macros.h GET_CHAN_PROPS + +- mhi-event-rings + Usage: required + Value type: <u32> + Definition: Number of event rings device support + +- mhi-event-cfg-# + Usage: required + Value type: Array of <u32> + Definition: mhi event ring configuration parameters for platform + defined as below <A B C D E F>: + A = maximum event descriptors + B = MSI associated with event + C = interrupt moderation (see MHI specification) + D = Associated channel + E = priority of the event ring. 0 being the highest. + F = flags defined by mhi_macros.h GET_EV_PROPS + +- qcom,mhi-address-window + Usage: required + Value type: Array of <u64> + Definition: start DDR address and ending DDR address device can access. + +- qcom,mhi-manage-boot + Usage: optional + Value type: bool + Definition: Determine whether MHI host manages firmware download to device. + +- qcom,mhi-fw-image + Usage: required if MHI host managing firmware download process + Value type: string + Definition: firmware image name + +- qcom,mhi-max-sbl + Usage: required if MHI host managing firmware download process + Value type: <u32> + Definition: Maximum size in bytes SBL image device support. + +- qcom,mhi-sg-size + Usage: required if MHI host managing firmware download process + Value type: <u32> + Definition: Segment size in bytes for each segment in bytes. + +- qcom,mhi-bb-required + Usage: optional + Value type: bool + Definition: Determine whether MHI device require bounce buffer + during active transfer. If true, during channel open host + will pre-allocate transfer buffers. + +======== +Example: +======== +mhi: qcom,mhi { + compatible = "qcom,mhi"; + qcom,pci-dev_id = <0x0301>; + qcom,pci-domain = <2>; + qcom,pci-bus = <4>; + qcom,pci-slot = <0>; + qcom,mhi-address-window = <0x0 0x80000000 0x0 0xbfffffff>; + esoc-names = "mdm"; + esoc-0 = <&mdm1>; + qcom,msm-bus,name = "mhi"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <100 512 0 0>, + <100 512 1200000000 1200000000>; + mhi-event-rings = <1>; + mhi-chan-cfg-102 = <0x66 0x80 0x5 0x62>; + mhi-event-cfg-0 = <0x80 0x0 0x0 0x0 0 1 0x11>; +}; diff --git a/Documentation/devicetree/bindings/mhi/msm_mhi_dev.txt b/Documentation/devicetree/bindings/mhi/msm_mhi_dev.txt new file mode 100644 index 000000000000..49d33a3c4440 --- /dev/null +++ b/Documentation/devicetree/bindings/mhi/msm_mhi_dev.txt @@ -0,0 +1,34 @@ +MSM MHI DEV + +MSM MHI DEV enables communication with the host over a PCIe link using the +Modem Host Interface protocol. The driver interfaces with the IPA for +enabling the HW acceleration channel path and provides interface for +software channels to communicate between Host and device. + +Required properties: + - compatible: should be "qcom,msm-mhi-dev" for MHI device driver. + - reg: MHI MMIO physical register space. + - reg-names: resource names used for the MHI MMIO physical address region, + IPA uC command and event ring doorbell mail box address. + Should be "mhi_mmio_base" for MHI MMIO physical address, + "ipa_uc_mbox_crdb" for IPA uC Command Ring doorbell, + "ipa_uc_mbox_erdb" for IPA uC Event Ring doorbell passed to + the IPA driver. + - qcom,mhi-ifc-id: ID of HW interface via which MHI on device side + communicates with host side. + - qcom,mhi-ep-msi: End point MSI number. + - qcom,mhi-version: MHI specification version supported by the device. + +Example: + + mhi: qcom,msm-mhi-dev { + compatible = "qcom,msm-mhi-dev"; + reg = <0xfc527000 0x1000>, + <0xfd4fa000 0x1>, + <0xfd4fa080 0x1>; + reg-names = "mhi_mmio_base", "ipa_uc_mbox_crdb", + "ipa_uc_mbox_erdb"; + qcom,mhi-ifc-id = <0x030017cb>; + qcom,mhi-ep-msi = <1>; + qcom,mhi-version = <0x1000000>; + }; diff --git a/Documentation/devicetree/bindings/misc/memory-state-time.txt b/Documentation/devicetree/bindings/misc/memory-state-time.txt new file mode 100644 index 000000000000..c99a506c030d --- /dev/null +++ b/Documentation/devicetree/bindings/misc/memory-state-time.txt @@ -0,0 +1,8 @@ +Memory bandwidth and frequency state tracking + +Required properties: +- compatible : should be: + "memory-state-time" +- freq-tbl: Should contain entries with each frequency in Hz. +- bw-buckets: Should contain upper-bound limits for each bandwidth bucket in Mbps. + Must match the framework power_profile.xml for the device. diff --git a/Documentation/devicetree/bindings/misc/qpnp-misc.txt b/Documentation/devicetree/bindings/misc/qpnp-misc.txt new file mode 100644 index 000000000000..a34cbde456e4 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/qpnp-misc.txt @@ -0,0 +1,25 @@ +QPNP-MISC + +QPNP-MISC provides a way to read the PMIC part number and revision. + +Required properties: +- compatible : should be "qcom,qpnp-misc" +- reg : offset and length of the PMIC peripheral register map. + +Optional properties: +- qcom,pwm-sel: Select PWM source. Possible values: + 0: LOW + 1: PWM1_in + 2: PWM2_in + 3: PWM1_in & PWM2_in +- qcom,enable-gp-driver: Enable the GP driver. Should only be specified + if a non-zero PWM source is specified under + "qcom,pwm-sel" property. + +Example: + qcom,misc@900 { + compatible = "qcom,qpnp-misc"; + reg = <0x900 0x100>; + qcom,pwm-sel = <2>; + qcom,enable-gp-driver; + }; diff --git a/Documentation/devicetree/bindings/misc/ramoops.txt b/Documentation/devicetree/bindings/misc/ramoops.txt new file mode 100644 index 000000000000..5a475fae4aab --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ramoops.txt @@ -0,0 +1,43 @@ +Ramoops oops/panic logger +========================= + +ramoops provides persistent RAM storage for oops and panics, so they can be +recovered after a reboot. + +Parts of this storage may be set aside for other persistent log buffers, such +as kernel log messages, or for optional ECC error-correction data. The total +size of these optional buffers must fit in the reserved region. + +Any remaining space will be used for a circular buffer of oops and panic +records. These records have a configurable size, with a size of 0 indicating +that they should be disabled. + + +Required properties: + +- compatible: must be "ramoops" + +- memory-region: phandle to a region of memory that is preserved between reboots + + +Optional properties: + +- ecc-size: enables ECC support and specifies ECC buffer size in bytes + (defaults to no ECC) + +- record-size: maximum size in bytes of each dump done on oops/panic + (defaults to 0) + +- console-size: size in bytes of log buffer reserved for kernel messages + (defaults to 0) + +- ftrace-size: size in bytes of log buffer reserved for function tracing and + profiling (defaults to 0) + +- pmsg-size: size in bytes of log buffer reserved for userspace messages + (defaults to 0) + +- unbuffered: if present, use unbuffered mappings to map the reserved region + (defaults to buffered mappings) + +- no-dump-oops: if present, only dump panics (defaults to panics and oops) diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 485483a63d8c..0b46fd3d8ebf 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -1,55 +1,190 @@ -* Qualcomm SDHCI controller (sdhci-msm) +Qualcomm Technologies, Inc. Standard Secure Digital Host Controller (SDHC) -This file documents differences between the core properties in mmc.txt -and the properties used by the sdhci-msm driver. +Secure Digital Host Controller provides standard host interface to SD/MMC/SDIO cards. Required properties: -- compatible: Should contain "qcom,sdhci-msm-v4". -- reg: Base address and length of the register in the following order: - - Host controller register map (required) - - SD Core register map (required) -- interrupts: Should contain an interrupt-specifiers for the interrupts: - - Host controller interrupt (required) -- pinctrl-names: Should contain only one value - "default". -- pinctrl-0: Should specify pin control groups used for this controller. -- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock-names. -- clock-names: Should contain the following: - "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) - "core" - SDC MMC clock (MCLK) (required) - "bus" - SDCC bus voter clock (optional) + - compatible : should be "qcom,sdhci-msm" + For SDCC version 5.0.0, MCI registers are removed from SDCC interface + and some registers are moved to HC. New compatible string is added to + support this change - "qcom,sdhci-msm-v5". + - reg : should contain SDHC, SD Core register map. + - reg-names : indicates various resources passed to driver (via reg proptery) by name. + Required "reg-names" are "hc_mem" and "core_mem" + optional ones are "tlmm_mem" + - interrupts : should contain SDHC interrupts. + - interrupt-names : indicates interrupts passed to driver (via interrupts property) by name. + Required "interrupt-names" are "hc_irq" and "pwr_irq". + - <supply-name>-supply: phandle to the regulator device tree node + Required "supply-name" are "vdd" and "vdd-io". + - qcom,ice-clk-rates: this is an array that specifies supported Inline + Crypto Engine (ICE) clock frequencies, Units - Hz. + - sdhc-msm-crypto: phandle to SDHC ICE node + +Required alias: +- The slot number is specified via an alias with the following format + 'sdhc{n}' where n is the slot number. + +Optional Properties: + - interrupt-names - "status_irq". This status_irq will be used for card + detection. + - qcom,bus-width - defines the bus I/O width that controller supports. + Units - number of bits. The valid bus-width values are + 1, 4 and 8. + - qcom,nonremovable - specifies whether the card in slot is + hot pluggable or hard wired. + - qcom,nonhotplug - specifies the card in slot is not hot pluggable. + if card lost or removed manually at runtime, don't retry + to redetect it until next reboot probe. + - qcom,bus-speed-mode - specifies supported bus speed modes by host. + The supported bus speed modes are : + "HS200_1p8v" - indicates that host can support HS200 at 1.8v. + "HS200_1p2v" - indicates that host can support HS200 at 1.2v. + "DDR_1p8v" - indicates that host can support DDR mode at 1.8v. + "DDR_1p2v" - indicates that host can support DDR mode at 1.2v. + - qcom,devfreq,freq-table - specifies supported frequencies for clock scaling. + Clock scaling logic shall toggle between these frequencies based + on card load. In case the defined frequencies are over or below + the supported card frequencies, they will be overridden + during card init. In case this entry is not supplied, + the driver will construct one based on the card + supported max and min frequencies. + The frequencies must be ordered from lowest to highest. + - qcom,pm-qos-irq-type - the PM QoS request type to be used for IRQ voting. + Can be either "affine_cores" or "affine_irq". If not specified, will default + to "affine_cores". Use "affine_irq" setting in case an IRQ balancer is active, + and IRQ affinity changes during runtime. + - qcom,pm-qos-irq-cpu - specifies the CPU for which IRQ voting shall be done. + If "affine_cores" was specified for property 'qcom,pm-qos-irq-type' + then this property must be defined, and is not relevant otherwise. + - qcom,pm-qos-irq-latency - a tuple defining two latency values with which + PM QoS IRQ voting shall be done. The first value is the latecy to be used + when load is high (performance mode) and the second is for low loads + (power saving mode). + - qcom,pm-qos-cpu-groups - defines cpu groups mapping. + Each cell represnets a group, which is a cpu bitmask defining which cpus belong + to that group. + - qcom,pm-qos-<mode>-latency-us - where <mode> is either "cmdq" or "legacy". + An array of latency value tuples, each tuple corresponding to a cpu group in the order + defined in property 'qcom,pm-qos-cpu-groups'. The first value is the latecy to be used + when load is high (performance mode) and the second is for low loads + (power saving mode). These values will be used for cpu group voting for + command-queueing mode or legacy respectively. + - qcom,core_3_0v_support: an optional property that is used to fake + 3.0V support for SDIO devices. + - qcom,scaling-lower-bus-speed-mode: specifies the lower bus speed mode to be used + during clock scaling. If this property is not + defined, then it falls back to the default HS + bus speed mode to maintain backward compatibility. + +In the following, <supply> can be vdd (flash core voltage) or vdd-io (I/O voltage). + - qcom,<supply>-always-on - specifies whether supply should be kept "on" always. + - qcom,<supply>-lpm_sup - specifies whether supply can be kept in low power mode (lpm). + - qcom,<supply>-voltage_level - specifies voltage levels for supply. Should be + specified in pairs (min, max), units uV. + - qcom,<supply>-current_level - specifies load levels for supply in lpm or + high power mode (hpm). Should be specified in + pairs (lpm, hpm), units uA. + + - gpios - specifies gpios assigned for sdhc slot. + - qcom,gpio-names - a list of strings that map in order to the list of gpios + + A slot has either gpios or dedicated tlmm pins as represented below. + - qcom,pad-pull-on - Active pull configuration for sdc tlmm pins + - qcom,pad-pull-off - Suspend pull configuration for sdc tlmm pins. + - qcom,pad-drv-on - Active drive strength configuration for sdc tlmm pins. + - qcom,pad-drv-off - Suspend drive strength configuration for sdc tlmm pins. + Tlmm pins are specified as <clk cmd data> and starting with eMMC5.0 as + <clk cmd data rclk> + + - Refer to "Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt" + for following optional properties: + - pinctrl-names + - pinctrl-0, pinctrl-1,.. pinctrl-n + + - qcom,large-address-bus - specifies whether the soc is capable of + supporting larger than 32 bit address bus width. + + - qcom,wakeup-on-idle: if configured, the mmcqd thread will call + set_wake_up_idle(), thereby voting for it to be called on idle CPUs. Example: - sdhc_1: sdhci@f9824900 { - compatible = "qcom,sdhci-msm-v4"; - reg = <0xf9824900 0x11c>, <0xf9824000 0x800>; - interrupts = <0 123 0>; - bus-width = <8>; - non-removable; + aliases { + sdhc1 = &sdhc_1; + sdhc2 = &sdhc_2; + }; + + sdhc_1: qcom,sdhc@f9824900 { + compatible = "qcom,sdhci-msm"; + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>; + reg-names = "hc_mem", "core_mem"; + interrupts = <0 123 0>, <0 138 0>; + interrupt-names = "hc_irq", "pwr_irq"; + sdhc-msm-crypto = <&sdcc1_ice>; - vmmc-supply = <&pm8941_l20>; - vqmmc-supply = <&pm8941_s3>; + vdd-supply = <&pm8941_l21>; + vdd-io-supply = <&pm8941_l13>; + qcom,vdd-voltage-level = <2950000 2950000>; + qcom,vdd-current-level = <9000 800000>; - pinctrl-names = "default"; - pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>; + qcom,vdd-io-always-on; + qcom,vdd-io-lpm-sup; + qcom,vdd-io-voltage-level = <1800000 2950000>; + qcom,vdd-io-current-level = <6 22000>; - clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; - clock-names = "core", "iface"; + qcom,devfreq,freq-table = <52000000 200000000>; + + pinctrl-names = "active", "sleep"; + pinctrl-0 = <&sdc1_clk_on &sdc1_cmd_on &sdc1_data_on>; + pinctrl-1 = <&sdc1_clk_off &sdc1_cmd_on &sdc1_data_on>; + + + qcom,bus-width = <4>; + qcom,nonremovable; + qcom,large-address-bus; + qcom,bus-speed-mode = "HS200_1p8v", "DDR_1p8v"; + qcom,ice-clk-rates = <300000000>; + + qcom,scaling-lower-bus-speed-mode = "DDR52"; + + gpios = <&msmgpio 40 0>, /* CLK */ + <&msmgpio 39 0>, /* CMD */ + <&msmgpio 38 0>, /* DATA0 */ + <&msmgpio 37 0>, /* DATA1 */ + <&msmgpio 36 0>, /* DATA2 */ + <&msmgpio 35 0>; /* DATA3 */ + qcom,gpio-names = "CLK", "CMD", "DAT0", "DAT1", "DAT2", "DAT3"; + + qcom,pm-qos-irq-type = "affine_cores"; + qcom,pm-qos-irq-cpu = <0>; + qcom,pm-qos-irq-latency = <500 100>; + qcom,pm-qos-cpu-groups = <0x03 0x0c>; + qcom,pm-qos-cmdq-latency-us = <50 100>, <50 100>; + qcom,pm-qos-legacy-latency-us = <50 100>, <50 100>; }; - sdhc_2: sdhci@f98a4900 { - compatible = "qcom,sdhci-msm-v4"; - reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>; - interrupts = <0 125 0>; - bus-width = <4>; - cd-gpios = <&msmgpio 62 0x1>; + sdhc_2: qcom,sdhc@f98a4900 { + compatible = "qcom,sdhci-msm"; + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>; + reg-names = "hc_mem", "core_mem"; + interrupts = <0 123 0>, <0 138 0>; + interrupt-names = "hc_irq", "pwr_irq"; + + vdd-supply = <&pm8941_l21>; + vdd-io-supply = <&pm8941_l13>; + + pinctrl-names = "active", "sleep"; + pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on>; + pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_on &sdc2_data_on>; + - vmmc-supply = <&pm8941_l21>; - vqmmc-supply = <&pm8941_l13>; + qcom,bus-width = <4>; - pinctrl-names = "default"; - pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>; + qcom,pad-pull-on = <0x0 0x3 0x3>; /* no-pull, pull-up, pull-up */ + qcom,pad-pull-off = <0x0 0x3 0x3>; /* no-pull, pull-up, pull-up */ + qcom,pad-drv-on = <0x7 0x4 0x4>; /* 16mA, 10mA, 10mA */ + qcom,pad-drv-off = <0x0 0x0 0x0>; /* 2mA, 2mA, 2mA */ - clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>; - clock-names = "core", "iface"; + qcom,pm-qos-irq-type = "affine_irq"; + qcom,pm-qos-irq-latency = <120 200>; }; diff --git a/Documentation/devicetree/bindings/net/can/rh850-can.txt b/Documentation/devicetree/bindings/net/can/rh850-can.txt new file mode 100644 index 000000000000..f16171e5b855 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/rh850-can.txt @@ -0,0 +1,21 @@ +* Renesas RH850 CAN * + +This driver implements spi slave protocol for rh850 can controller + +Required properties: + - compatible: Should be "renesas,rh850" + - reg: Should contain spi chip select + - interrupt-parent: Should specify interrupt controller for the interrupt + - interrupts: Should contain IRQ line for the CAN controller + - spi-max-frequency: Should contain maximum spi clock frequency for + slave device + +Example: + + can-controller@0 { + compatible = "renesas,rh850"; + reg = <0>; + interrupt-parent = <&tlmm>; + interrupts = <127 0>; + spi-max-frequency = <5000000>; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,wcn3990-wifi.txt b/Documentation/devicetree/bindings/net/wireless/qcom,wcn3990-wifi.txt new file mode 100644 index 000000000000..acc850773210 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn3990-wifi.txt @@ -0,0 +1,34 @@ +* Qualcomm Technologies, Inc. WCN3990 chipset WLAN platform Driver + +This driver adds support for the Integrated WCN3990 WLAN module, WCN3990 +is integrated 802.11ac chipset with SNOC bus interface. It also add support +for SNOC bus registration, copy engine configuration for the WCN3990 chipset, +shadow register configuration, create host to target communication interface +to interact with WLAN firmware, WLAN module interface control and data +receive(RX)/transmit(TX) control. + +Required properties: + - compatible: "qcom,wcn3990-wifi"; + - reg: Memory regions defined as starting address and size + - reg-names: Names of the memory regions defined in reg entry + - interrupts: Copy engine interrupt table + +Example: + msm_ath10k_wlan: qcom,msm_ath10k_wlan@18800000 { + compatible = "qcom,wcn3990-wifi"; + reg = <0x18800000 0x800000>; + reg-names = "membase"; + interrupts = + <0 130 0 /* CE0 */ >, + <0 131 0 /* CE1 */ >, + <0 132 0 /* CE2 */ >, + <0 133 0 /* CE3 */ >, + <0 134 0 /* CE4 */ >, + <0 135 0 /* CE5 */ >, + <0 136 0 /* CE6 */ >, + <0 137 0 /* CE7 */ >, + <0 138 0 /* CE8 */ >, + <0 139 0 /* CE9 */ >, + <0 140 0 /* CE10 */ >, + <0 141 0 /* CE11 */ >; + }; diff --git a/Documentation/devicetree/bindings/nfc/nq-nci.txt b/Documentation/devicetree/bindings/nfc/nq-nci.txt new file mode 100644 index 000000000000..b85e0701bbae --- /dev/null +++ b/Documentation/devicetree/bindings/nfc/nq-nci.txt @@ -0,0 +1,49 @@ +Qualcomm Technologies, Inc NQxxxx NFC NCI device + +Near Field Communication (NFC) device is based on NFC Controller Interface (NCI) + +Required properties: + +- compatible: "qcom,nq-nci" +- reg: NCI i2c slave address. +- qcom,nq-ven: specific gpio for hardware reset. +- qcom,nq-irq: specific gpio for read interrupt. +- qcom,nq-firm: gpio for firmware download +- qcom,nq-clkreq: gpio for clock +- interrupt-parent: Should be phandle for the interrupt controller + that services interrupts for this device. +- interrupts: Nfc read interrupt,gpio-clk-req interrupt + + +Recommended properties: + +- interrupt-names: names of interrupts, should include "nfc_irq", used for reference + + +Optional properties: + +- pinctrl-names, pinctrl-0, pincntrl-1: references to our pincntrl settings +- clocks, clock-names: must contain the NQxxxx's core clock. +- qcom,nq-esepwr: gpio to control power of secure element + +Example: + + nq-nci@2b { + compatible = "qcom,nq-nci"; + reg = <0x2b>; + qcom,nq-irq = <&tlmm 29 0x00>; + qcom,nq-ven = <&tlmm 30 0x00>; + qcom,nq-firm = <&tlmm 93 0x00>; + qcom,nq-clkreq = <&pm8998_gpios 21 0x00>; + qcom,nq-esepwr = <&tlmm 116 0x00>; + qcom,clk-src = "BBCLK2"; + interrupt-parent = <&tlmm>; + interrupts = <29 0>; + interrupt-names = "nfc_irq"; + pinctrl-names = "nfc_active","nfc_suspend"; + pinctrl-0 = <&nfc_int_active &nfc_disable_active>; + pinctrl-1 = <&nfc_int_suspend &nfc_disable_suspend>; + qcom,clk-gpio = <&pm8916_gpios 2 0>; + clocks = <&clock_rpm clk_bb_clk2_pin>; + clock-names = "ref_clk"; + }; diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 0cb44dc21f97..601256fe8c0d 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -45,21 +45,10 @@ Devices supporting OPPs must set their "operating-points-v2" property with phandle to a OPP table in their DT node. The OPP core will use this phandle to find the operating points for the device. -Devices may want to choose OPP tables at runtime and so can provide a list of -phandles here. But only *one* of them should be chosen at runtime. This must be -accompanied by a corresponding "operating-points-names" property, to uniquely -identify the OPP tables. - If required, this can be extended for SoC vendor specfic bindings. Such bindings should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt and should have a compatible description like: "operating-points-v2-<vendor>". -Optional properties: -- operating-points-names: Names of OPP tables (required if multiple OPP - tables are present), to uniquely identify them. The same list must be present - for all the CPUs which are sharing clock/voltage rails and hence the OPP - tables. - * OPP Table Node This describes the OPPs belonging to a device. This node can have following @@ -100,6 +89,14 @@ Optional properties: Entries for multiple regulators must be present in the same order as regulators are specified in device's DT node. +- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to + the above opp-microvolt property, but allows multiple voltage ranges to be + provided for the same OPP. At runtime, the platform can pick a <name> and + matching opp-microvolt-<name> property will be enabled for all OPPs. If the + platform doesn't pick a specific <name> or the <name> doesn't match with any + opp-microvolt-<name> properties, then opp-microvolt property shall be used, if + present. + - opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process, aging, maximum operating temperature range etc.) as necessary. This may be used to @@ -112,6 +109,9 @@ Optional properties: for few regulators, then this should be marked as zero for them. If it isn't required for any regulator, then this property need not be present. +- opp-microamp-<name>: Named opp-microamp property. Similar to + opp-microvolt-<name> property, but for microamp instead. + - clock-latency-ns: Specifies the maximum possible transition latency (in nanoseconds) for switching to this OPP from any other OPP. @@ -123,6 +123,26 @@ Optional properties: - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in the table should have this. +- opp-supported-hw: This enables us to select only a subset of OPPs from the + larger OPP table, based on what version of the hardware we are running on. We + still can't have multiple nodes with the same opp-hz value in OPP table. + + It's an user defined array containing a hierarchy of hardware version numbers, + supported by the OPP. For example: a platform with hierarchy of three levels + of versions (A, B and C), this field should be like <X Y Z>, where X + corresponds to Version hierarchy A, Y corresponds to version hierarchy B and Z + corresponds to version hierarchy C. + + Each level of hierarchy is represented by a 32 bit value, and so there can be + only 32 different supported version per hierarchy. i.e. 1 bit per version. A + value of 0xFFFFFFFF will enable the OPP for all versions for that hierarchy + level. And a value of 0x00000000 will disable the OPP completely, and so we + never want that to happen. + + If 32 values aren't sufficient for a version hierarchy, than that version + hierarchy can be contained in multiple 32 bit values. i.e. <X Y Z1 Z2> in the + above example, Z1 & Z2 refer to the version hierarchy Z. + - status: Marks the node enabled/disabled. Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. @@ -157,20 +177,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together. compatible = "operating-points-v2"; opp-shared; - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000 975000 985000>; opp-microamp = <70000>; clock-latency-ns = <300000>; opp-suspend; }; - opp01 { + opp@1100000000 { opp-hz = /bits/ 64 <1100000000>; opp-microvolt = <980000 1000000 1010000>; opp-microamp = <80000>; clock-latency-ns = <310000>; }; - opp02 { + opp@1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <1025000>; clock-latency-ns = <290000>; @@ -236,20 +256,20 @@ independently. * independently. */ - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000 975000 985000>; opp-microamp = <70000>; clock-latency-ns = <300000>; opp-suspend; }; - opp01 { + opp@1100000000 { opp-hz = /bits/ 64 <1100000000>; opp-microvolt = <980000 1000000 1010000>; opp-microamp = <80000>; clock-latency-ns = <310000>; }; - opp02 { + opp@1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <1025000>; opp-microamp = <90000; @@ -312,20 +332,20 @@ DVFS state together. compatible = "operating-points-v2"; opp-shared; - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000 975000 985000>; opp-microamp = <70000>; clock-latency-ns = <300000>; opp-suspend; }; - opp01 { + opp@1100000000 { opp-hz = /bits/ 64 <1100000000>; opp-microvolt = <980000 1000000 1010000>; opp-microamp = <80000>; clock-latency-ns = <310000>; }; - opp02 { + opp@1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <1025000>; opp-microamp = <90000>; @@ -338,20 +358,20 @@ DVFS state together. compatible = "operating-points-v2"; opp-shared; - opp10 { + opp@1300000000 { opp-hz = /bits/ 64 <1300000000>; opp-microvolt = <1045000 1050000 1055000>; opp-microamp = <95000>; clock-latency-ns = <400000>; opp-suspend; }; - opp11 { + opp@1400000000 { opp-hz = /bits/ 64 <1400000000>; opp-microvolt = <1075000>; opp-microamp = <100000>; clock-latency-ns = <400000>; }; - opp12 { + opp@1500000000 { opp-hz = /bits/ 64 <1500000000>; opp-microvolt = <1010000 1100000 1110000>; opp-microamp = <95000>; @@ -378,7 +398,7 @@ Example 4: Handling multiple regulators compatible = "operating-points-v2"; opp-shared; - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000>, /* Supply 0 */ <960000>, /* Supply 1 */ @@ -391,7 +411,7 @@ Example 4: Handling multiple regulators /* OR */ - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000 975000 985000>, /* Supply 0 */ <960000 965000 975000>, /* Supply 1 */ @@ -404,7 +424,7 @@ Example 4: Handling multiple regulators /* OR */ - opp00 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; opp-microvolt = <970000 975000 985000>, /* Supply 0 */ <960000 965000 975000>, /* Supply 1 */ @@ -417,7 +437,8 @@ Example 4: Handling multiple regulators }; }; -Example 5: Multiple OPP tables +Example 5: opp-supported-hw +(example: three level hierarchy of versions: cuts, substrate and process) / { cpus { @@ -426,40 +447,73 @@ Example 5: Multiple OPP tables ... cpu-supply = <&cpu_supply> - operating-points-v2 = <&cpu0_opp_table_slow>, <&cpu0_opp_table_fast>; - operating-points-names = "slow", "fast"; + operating-points-v2 = <&cpu0_opp_table_slow>; }; }; - cpu0_opp_table_slow: opp_table_slow { + opp_table { compatible = "operating-points-v2"; status = "okay"; opp-shared; - opp00 { + opp@600000000 { + /* + * Supports all substrate and process versions for 0xF + * cuts, i.e. only first four cuts. + */ + opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF> opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <900000 915000 925000>; ... }; - opp01 { + opp@800000000 { + /* + * Supports: + * - cuts: only one, 6th cut (represented by 6th bit). + * - substrate: supports 16 different substrate versions + * - process: supports 9 different process versions + */ + opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0> opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <900000 915000 925000>; ... }; }; +}; + +Example 6: opp-microvolt-<name>, opp-microamp-<name>: +(example: device with two possible microvolt ranges: slow and fast) - cpu0_opp_table_fast: opp_table_fast { +/ { + cpus { + cpu@0 { + compatible = "arm,cortex-a7"; + ... + + operating-points-v2 = <&cpu0_opp_table>; + }; + }; + + cpu0_opp_table: opp_table0 { compatible = "operating-points-v2"; - status = "okay"; opp-shared; - opp10 { + opp@1000000000 { opp-hz = /bits/ 64 <1000000000>; - ... + opp-microvolt-slow = <900000 915000 925000>; + opp-microvolt-fast = <970000 975000 985000>; + opp-microamp-slow = <70000>; + opp-microamp-fast = <71000>; }; - opp11 { - opp-hz = /bits/ 64 <1100000000>; - ... + opp@1200000000 { + opp-hz = /bits/ 64 <1200000000>; + opp-microvolt-slow = <900000 915000 925000>, /* Supply vcc0 */ + <910000 925000 935000>; /* Supply vcc1 */ + opp-microvolt-fast = <970000 975000 985000>, /* Supply vcc0 */ + <960000 965000 975000>; /* Supply vcc1 */ + opp-microamp = <70000>; /* Will be used for both slow/fast */ }; }; }; diff --git a/Documentation/devicetree/bindings/pci/msm_ep_pcie.txt b/Documentation/devicetree/bindings/pci/msm_ep_pcie.txt new file mode 100644 index 000000000000..caaf2d6e321c --- /dev/null +++ b/Documentation/devicetree/bindings/pci/msm_ep_pcie.txt @@ -0,0 +1,113 @@ +MSM PCI express endpoint + +Required properties: + - compatible: should be "qcom,pcie-ep". + - reg: should contain PCIe register maps. + - reg-names: indicates various resources passed to driver by name. + Should be "msi", "dm_core", "elbi", "parf", "phy", "mmio". + These correspond to different modules within the PCIe domain. + - #address-cells: Should provide a value of 0. + - interrupt-parent: Should be the PCIe device node itself here. + - interrupts: Should be in the format <0 1 2> and it is an index to the + interrupt-map that contains PCIe related interrupts. + - #interrupt-cells: Should provide a value of 1. + - #interrupt-map-mask: should provide a value of 0xffffffff. + - interrupt-map: Must create mapping for the number of interrupts + that are defined in above interrupts property. + For PCIe device node, it should define 6 mappings for + the corresponding PCIe interrupts supporting the + specification. + - interrupt-names: indicates interrupts passed to driver by name. + Should be "int_pm_turnoff", "int_dstate_change", + "int_l1sub_timeout", "int_link_up", + "int_link_down", "int_bridge_flush_n". + - perst-gpio: PERST GPIO specified by PCIe spec. + - wake-gpio: WAKE GPIO specified by PCIe spec. + - clkreq-gpio: CLKREQ GPIO specified by PCIe spec. + - <supply-name>-supply: phandle to the regulator device tree node. + Refer to the schematics for the corresponding voltage regulators. + vreg-1.8-supply: phandle to the analog supply for the PCIe controller. + vreg-0.9-supply: phandle to the analog supply for the PCIe controller. + +Optional Properties: + - qcom,<supply-name>-voltage-level: specifies voltage levels for supply. + Should be specified in pairs (max, min, optimal), units uV. + - clock-names: list of names of clock inputs. + Should be "pcie_0_pipe_clk", + "pcie_0_aux_clk", "pcie_0_cfg_ahb_clk", + "pcie_0_mstr_axi_clk", "pcie_0_slv_axi_clk", + "pcie_0_ldo"; + - max-clock-frequency-hz: list of the maximum operating frequencies stored + in the same order of clock names; + - qcom,pcie-phy-ver: version of PCIe PHY. + - qcom,pcie-link-speed: generation of PCIe link speed. The value could be + 1, 2 or 3. + - qcom,pcie-active-config: boolean type; active configuration of PCIe + addressing. + - qcom,pcie-aggregated-irq: boolean type; interrupts are aggregated. + - mdm2apstatus-gpio: GPIO used by PCIe endpoint side to notify the host side. + - Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + +Example: + + pcie_ep: qcom,pcie@bfffd000 { + compatible = "qcom,pcie-ep"; + + reg = <0xbfffd000 0x1000>, + <0xbfffe000 0x1000>, + <0xbffff000 0x1000>, + <0xfc520000 0x2000>, + <0xfc526000 0x1000>, + <0xfc527000 0x1000>; + reg-names = "msi", "dm_core", "elbi", "parf", "phy", "mmio"; + + #address-cells = <0>; + interrupt-parent = <&pcie_ep>; + interrupts = <0 1 2 3 4 5>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xffffffff>; + interrupt-map = <0 &intc 0 44 0 + 1 &intc 0 46 0 + 2 &intc 0 47 0 + 3 &intc 0 50 0 + 4 &intc 0 51 0 + 5 &intc 0 52 0>; + interrupt-names = "int_pm_turnoff", "int_dstate_change", + "int_l1sub_timeout", "int_link_up", + "int_link_down", "int_bridge_flush_n"; + + perst-gpio = <&msmgpio 65 0>; + wake-gpio = <&msmgpio 61 0>; + clkreq-gpio = <&msmgpio 64 0>; + mdm2apstatus-gpio = <&tlmm_pinmux 16 0>; + + gdsc-vdd-supply = <&gdsc_pcie_0>; + vreg-1.8-supply = <&pmd9635_l8>; + vreg-0.9-supply = <&pmd9635_l4>; + + qcom,vreg-1.8-voltage-level = <1800000 1800000 1000>; + qcom,vreg-0.9-voltage-level = <950000 950000 24000>; + + clock-names = "pcie_0_pipe_clk", + "pcie_0_aux_clk", "pcie_0_cfg_ahb_clk", + "pcie_0_mstr_axi_clk", "pcie_0_slv_axi_clk", + "pcie_0_ldo"; + max-clock-frequency-hz = <62500000>, <1000000>, + <0>, <0>, <0>, <0>; + + qcom,msm-bus,name = "pcie-ep"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <45 512 0 0>, + <45 512 500 800>; + + qcom,pcie-link-speed = <1>; + qcom,pcie-active-config; + qcom,pcie-aggregated-irq; + }; diff --git a/Documentation/devicetree/bindings/pci/msm_pcie.txt b/Documentation/devicetree/bindings/pci/msm_pcie.txt new file mode 100644 index 000000000000..a50e0c2b2c35 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/msm_pcie.txt @@ -0,0 +1,288 @@ +MSM PCIe + +MSM PCI express root complex + +Required properties: + - compatible: should be "qcom,pci-msm" + - cell-index: defines root complex ID. + - #address-cells: Should provide a value of 0. + - reg: should contain PCIe register maps. + - reg-names: indicates various resources passed to driver by name. + Should be "parf", "phy", "dm_core", "elbi", "conf", "io", "bars". + These correspond to different modules within the PCIe core. + - ranges: For details of ranges properties, please refer to: + "Documentation\devicetree\bindings\pci\pci.txt" + - interrupts: Should be in the format <0 1 2> and it is an index to the + interrupt-map that contains PCIe related interrupts. + - #interrupt-cells: Should provide a value of 1. + - #interrupt-map-mask: should provide a value of 0xffffffff. + - interrupt-map: Must create mapping for the number of interrupts + that are defined in above interrupts property. + For PCIe device node, it should define 12 mappings for + the corresponding PCIe interrupts supporting the specification. + - interrupt-names: indicates interrupts passed to driver by name. + Should be "int_msi", "int_a", "int_b", "int_c", "int_d", + "int_pls_pme", "int_pme_legacy", "int_pls_err", + "int_aer_legacy", "int_pls_link_up", + "int_pls_link_down", "int_bridge_flush_n", + "msi_0", "msi_1", "msi_2", "msi_3", + "msi_4", "msi_5", "msi_6", "msi_7", + "msi_8", "msi_9", "msi_10", "msi_11", + "msi_12", "msi_13", "msi_14", "msi_15", + "msi_16", "msi_17", "msi_18", "msi_19", + "msi_20", "msi_21", "msi_22", "msi_23", + "msi_24", "msi_25", "msi_26", "msi_27", + "msi_28", "msi_29", "msi_30", "msi_31" + These correspond to the standard PCIe specification to support + MSIs, virtual IRQ's (INT#), link state notifications. + - perst-gpio: PERST GPIO specified by PCIe spec. + - wake-gpio: WAKE GPIO specified by PCIe spec. + - <supply-name>-supply: phandle to the regulator device tree node. + Refer to the schematics for the corresponding voltage regulators. + vreg-1.8-supply: phandle to the analog supply for the PCIe controller. + vreg-3.3-supply: phandle to the analog supply for the PCIe controller. + vreg-0.9-supply: phandle to the analog supply for the PCIe controller. + +Optional Properties: + - qcom,<supply-name>-voltage-level: specifies voltage levels for supply. + Should be specified in pairs (max, min, optimal), units uV. + - clkreq-gpio: CLKREQ GPIO specified by PCIe spec. + - qcom,ep-gpio: GPIO which enables a certain type of endpoint for link training. + - pinctrl-names: The state name of the pin configuration. + supports: "default", "sleep" + - pinctrl-0: For details of pinctrl properties, please refer to: + "Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt" + - pinctrl-1: For details of pinctrl properties, please refer to: + "Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt" + - clocks: list of clock phandles + - clock-names: list of names of clock inputs. + Should be "pcie_0_pipe_clk", "pcie_0_ref_clk_src", + "pcie_0_aux_clk", "pcie_0_cfg_ahb_clk", + "pcie_0_mstr_axi_clk", "pcie_0_slv_axi_clk", + "pcie_0_ldo"; + - max-clock-frequency-hz: list of the maximum operating frequencies stored + in the same order of clock names; + - qcom,l0s-supported: L0s is supported. + - qcom,l1-supported: L1 is supported. + - qcom,l1ss-supported: L1 sub-states (L1ss) is supported. + - qcom,aux-clk-sync: The AUX clock is synchronous to the Core clock to + support L1ss. + - qcom,common-clk-en: Enables the common clock configuration for the endpoint. + - qcom,clk-power-manage-en: Enables the clock power management for the + endpoint. + - qcom,n-fts: The number of fast training sequences sent when the link state + is changed from L0s to L0. + - qcom,pcie-phy-ver: version of PCIe PHY. + - qcom,phy-sequence: The initialization sequence to bring up the PCIe PHY. + Should be specified in groups (offset, value, delay). + - qcom,port-phy-sequence: The initialization sequence to bring up the + PCIe port PHY. + Should be specified in groups (offset, value, delay). + - qcom,use-19p2mhz-aux-clk: The frequency of PCIe AUX clock is 19.2MHz. + - qcom,ep-wakeirq: The endpoint will issue wake signal when it is up, and the + root complex has the capability to enumerate the endpoint for this case. + - qcom,msi-gicm-addr: MSI address for GICv2m. + - qcom,msi-gicm-base: MSI IRQ base for GICv2m. + - qcom,ext-ref-clk: The reference clock is external. + - iommus: the phandle and stream IDs for the SMMU used by this root + complex. This should be used in separate nodes from the main root + complex nodes, and is the only property needed in that case. + - qcom,common-phy: There is a common phy for all the Root Complexes. + - qcom,smmu-exist: PCIe uses a SMMU. + - qcom,smmu-sid-base: The base SMMU SID that PCIe bus driver will use to calculate + and assign for each endpoint. + - qcom,ep-latency: The time (unit: ms) to wait for the PCIe endpoint to become + stable after power on, before de-assert the PERST to the endpoint. + - qcom,wr-halt-size: With base 2, this exponent determines the size of the + data that PCIe core will halt on for each write transaction. + - qcom,cpl-timeout: Completion timeout value. This value specifies the time range + which the root complex will send out a completion packet if there is no response + from the endpoint. + - linux,pci-domain: For details of pci-domains properties, please refer to: + "Documentation/devicetree/bindings/pci/pci.txt" + - qcom,perst-delay-us-min: The minimum allowed time (unit: us) to sleep after + asserting or de-asserting PERST GPIO. + - qcom,perst-delay-us-max: The maximum allowed time (unit: us) to sleep after + asserting or de-asserting PERST GPIO. + - qcom,tlp-rd-size: The max TLP read size (Calculation: 128 times 2 to the + tlp-rd-size power). + - Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + below optional properties: + - qcom,msm-bus,name + - qcom,msm-bus,num-cases + - qcom,msm-bus,num-paths + - qcom,msm-bus,vectors-KBps + - qcom,scm-dev-id: If present then device id value is passed to secure channel + manager(scm) driver. scm driver uses this device id to restore PCIe + controller related security configuration after coming out of the controller + power collapse. + - resets: reset specifier pair consists of phandle for the reset controller + and reset lines used by this controller. + - reset-names: reset signal name strings sorted in the same order as the resets + property. + +Example: + + pcie0: qcom,pcie@fc520000 { + compatible = "qcom,msm_pcie"; + cell-index = <0>; + #address-cells = <0>; + reg = <0xfc520000 0x2000>, + <0xfc526000 0x1000>, + <0xff000000 0x1000>, + <0xff001000 0x1000>, + <0xff100000 0x1000>, + <0xff200000 0x100000>, + <0xff300000 0xd00000>; + reg-names = "parf", "dm_core", "elbi", + "conf", "io", "bars"; + ranges = <0x01000000 0x0 0x0c200000 0x0c200000 0x0 0x100000>, + <0x02000000 0x0 0x0c300000 0x0c300000 0x0 0xd00000>; + interrupt-parent = <&pcie0>; + interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 + 12 13 14 15 16 17 18 19 20 + 21 22 23 24 25 26 27 28 29 + 30 31 32 33 34 35 36 37 38 + 39 40 41 42 43>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xffffffff>; + interrupt-map = <0x0 0x0 0x0 0 &intc 0 405 0 + 0x0 0x0 0x0 1 &intc 0 244 0 + 0x0 0x0 0x0 2 &intc 0 245 0 + 0x0 0x0 0x0 3 &intc 0 247 0 + 0x0 0x0 0x0 4 &intc 0 248 0 + 0x0 0x0 0x0 5 &intc 0 249 0 + 0x0 0x0 0x0 6 &intc 0 250 0 + 0x0 0x0 0x0 7 &intc 0 251 0 + 0x0 0x0 0x0 8 &intc 0 252 0 + 0x0 0x0 0x0 9 &intc 0 253 0 + 0x0 0x0 0x0 10 &intc 0 254 0 + 0x0 0x0 0x0 11 &intc 0 255 0 + 0x0 0x0 0x0 12 &intc 0 448 0 + 0x0 0x0 0x0 13 &intc 0 449 0 + 0x0 0x0 0x0 14 &intc 0 450 0 + 0x0 0x0 0x0 15 &intc 0 451 0 + 0x0 0x0 0x0 16 &intc 0 452 0 + 0x0 0x0 0x0 17 &intc 0 453 0 + 0x0 0x0 0x0 18 &intc 0 454 0 + 0x0 0x0 0x0 19 &intc 0 455 0 + 0x0 0x0 0x0 20 &intc 0 456 0 + 0x0 0x0 0x0 21 &intc 0 457 0 + 0x0 0x0 0x0 22 &intc 0 458 0 + 0x0 0x0 0x0 23 &intc 0 459 0 + 0x0 0x0 0x0 24 &intc 0 460 0 + 0x0 0x0 0x0 25 &intc 0 461 0 + 0x0 0x0 0x0 26 &intc 0 462 0 + 0x0 0x0 0x0 27 &intc 0 463 0 + 0x0 0x0 0x0 28 &intc 0 464 0 + 0x0 0x0 0x0 29 &intc 0 465 0 + 0x0 0x0 0x0 30 &intc 0 466 0 + 0x0 0x0 0x0 31 &intc 0 467 0 + 0x0 0x0 0x0 32 &intc 0 468 0 + 0x0 0x0 0x0 33 &intc 0 469 0 + 0x0 0x0 0x0 34 &intc 0 470 0 + 0x0 0x0 0x0 35 &intc 0 471 0 + 0x0 0x0 0x0 36 &intc 0 472 0 + 0x0 0x0 0x0 37 &intc 0 473 0 + 0x0 0x0 0x0 38 &intc 0 474 0 + 0x0 0x0 0x0 39 &intc 0 475 0 + 0x0 0x0 0x0 40 &intc 0 476 0 + 0x0 0x0 0x0 41 &intc 0 477 0 + 0x0 0x0 0x0 42 &intc 0 478 0 + 0x0 0x0 0x0 43 &intc 0 479 0>; + interrupt-names = "int_msi", "int_a", "int_b", "int_c", "int_d", + "int_pls_pme", "int_pme_legacy", "int_pls_err", + "int_aer_legacy", "int_pls_link_up", + "int_pls_link_down", "int_bridge_flush_n", + "msi_0", "msi_1", "msi_2", "msi_3", + "msi_4", "msi_5", "msi_6", "msi_7", + "msi_8", "msi_9", "msi_10", "msi_11", + "msi_12", "msi_13", "msi_14", "msi_15", + "msi_16", "msi_17", "msi_18", "msi_19", + "msi_20", "msi_21", "msi_22", "msi_23", + "msi_24", "msi_25", "msi_26", "msi_27", + "msi_28", "msi_29", "msi_30", "msi_31"; + + qcom,phy-sequence = <0x804 0x01 0x00 + 0x034 0x14 0x00 + 0x138 0x30 0x00 + 0x048 0x0f 0x00 + 0x15c 0x06 0x00 + 0x090 0x01 0x00 + 0x808 0x03 0x00>; + qcom,port-phy-sequence = <0x804 0x01 0x00 + 0x034 0x14 0x00 + 0x138 0x30 0x00 + 0x048 0x0f 0x00 + 0x15c 0x06 0x00 + 0x090 0x01 0x00 + 0x808 0x03 0x00>; + perst-gpio = <&msmgpio 70 0>; + wake-gpio = <&msmgpio 69 0>; + clkreq-gpio = <&msmgpio 68 0>; + qcom,ep-gpio = <&tlmm 94 0>; + + gdsc-vdd-supply = <&gdsc_pcie_0>; + vreg-1.8-supply = <&pma8084_l12>; + vreg-0.9-supply = <&pma8084_l4>; + vreg-3.3-supply = <&wlan_vreg>; + + qcom,vreg-1.8-voltage-level = <1800000 1800000 1000>; + qcom,vreg-0.9-voltage-level = <950000 950000 24000>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&pcie0_clkreq_default &pcie0_perst_default &pcie0_wake_default>; + pinctrl-1 = <&pcie0_clkreq_sleep &pcie0_perst_sleep &pcie0_wake_sleep>; + + clocks = <&clock_gcc clk_gcc_pcie_0_pipe_clk>, + <&clock_rpm clk_ln_bb_clk>, + <&clock_gcc clk_gcc_pcie_0_aux_clk>, + <&clock_gcc clk_gcc_pcie_0_cfg_ahb_clk>, + <&clock_gcc clk_gcc_pcie_0_mstr_axi_clk>, + <&clock_gcc clk_gcc_pcie_0_slv_axi_clk>, + <&clock_gcc clk_pcie_0_phy_ldo>; + + clock-names = "pcie_0_pipe_clk", "pcie_0_ref_clk_src", + "pcie_0_aux_clk", "pcie_0_cfg_ahb_clk", + "pcie_0_mstr_axi_clk", "pcie_0_slv_axi_clk", + "pcie_0_ldo"; + + resets = <&clock_gcc GCC_PCIE_PHY_BCR>, + <&clock_gcc GCC_PCIE_PHY_COM_BCR>, + <&clock_gcc GCC_PCIE_PHY_NOCSR_COM_PHY_BCR>, + <&clock_gcc GCC_PCIE_0_PHY_BCR>; + + reset-names = "pcie_phy_reset", "pcie_phy_com_reset", + "pcie_phy_nocsr_com_phy_reset","pcie_0_phy_reset"; + + max-clock-frequency-hz = <125000000>, <0>, <1000000>, + <0>, <0>, <0>, <0>; + qcom,l0s-supported; + qcom,l1-supported; + qcom,l1ss-supported; + qcom,aux-clk-sync; + qcom,n-fts = <0x50>; + qcom,pcie-phy-ver = <1>; + qcom,ep-wakeirq; + qcom,msi-gicm-addr = <0xf9040040>; + qcom,msi-gicm-base = <0x160>; + qcom,ext-ref-clk; + qcom,tlp-rd-size = <0x5>; + qcom,common-phy; + qcom,smmu-exist; + qcom,smmu-sid-base = <0x1480>; + qcom,ep-latency = <100>; + qcom,wr-halt-size = <0xa>; /* 1KB */ + qcom,cpl-timeout = <0x2>; + + iommus = <&anoc0_smmu>; + + qcom,msm-bus,name = "pcie0"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <45 512 0 0>, + <45 512 500 800>; + + qcom,scm-dev-id = <11>; + }; diff --git a/Documentation/devicetree/bindings/pil/inrush-current-mitigation.txt b/Documentation/devicetree/bindings/pil/inrush-current-mitigation.txt new file mode 100644 index 000000000000..110b4ae37d67 --- /dev/null +++ b/Documentation/devicetree/bindings/pil/inrush-current-mitigation.txt @@ -0,0 +1,25 @@ +In Rush Current Mitigation driver: + +On recent targets, APSS L2 memories are moved to APC domain which were +earlier on Mx domain. Analysis suggests that on current targets APSS L2 +memories provide reverse capacitance on Mx and this used to provide buffer +while powering ON Q6 L2. Now due to L2s moving to APC, the cushion is not +available. So there is a chance of droop when Q6 L2 memories are being +powered up. + +During Q6 low power modes L2 is kept in retention only and never collapsed. So +the cases where it needs to be taken care is during PIL(modem and adsp bringup +during boot). So in cold boot path before bringing up modem or adsp, turn on MM +memories. Hence providing a intermediate load. + +Required properties: +- compatible: Must be qcom,msm-inrush-current-mitigation +- qcom,dependent-subsystems: List of subsystems which need the intermediate load +- vdd-supply: gdsc handle to switch on memory. + +Example: + qcom,inrush-current { + compatible = "qcom,msm-inrush-current-mitigation"; + qcom,dependent-subsystems = "modem", "adsp"; + vdd-supply = <&gdsc_mdss>; + }; diff --git a/Documentation/devicetree/bindings/pil/pil-q6v5-mss.txt b/Documentation/devicetree/bindings/pil/pil-q6v5-mss.txt new file mode 100644 index 000000000000..47a6fdd300ca --- /dev/null +++ b/Documentation/devicetree/bindings/pil/pil-q6v5-mss.txt @@ -0,0 +1,143 @@ +Qualcomm MSS QDSP6v5 Peripheral Image Loader + +pil-qdsp6v5-mss is a peripheral image loader (PIL) driver. It is used for +loading QDSP6v5 (Hexagon) firmware images for modem subsystems into memory and +preparing the subsystem's processor to execute code. It's also responsible for +shutting down the processor when it's not needed. + +Required properties: +- compatible: Must be "qcom,pil-q6v5-mss" or "qcom,pil-q6v55-mss" or + "pil-q6v56-mss". +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. "qdsp6_base", + "rmb_base", "restart_reg" or "restart_reg_sec"(optional + for secure mode) are expected. + If "halt_base" is in same 4K pages this register then + this will be defined else "halt_q6", "halt_modem", + "halt_nc" is required. + "cxip_lm_vote_clear" needs to defined , in case PIL has to + clear the CX Ipeak bit if it was set by MSS. +- interrupts: The modem watchdog interrupt +- vdd_cx-supply: Reference to the regulator that supplies the vdd_cx domain. +- vdd_cx-voltage: Voltage corner/level(max) for cx rail. +- vdd_mx-supply: Reference to the regulator that supplies the memory rail. +- vdd_mx-uV: Voltage setting for the mx rail. +- qcom,firmware-name: Base name of the firmware image. Ex. "mdsp" + +Optional properties: +- vdd_mss-supply: Reference to the regulator that supplies the processor. + This may be a shared regulator that is already voted + on in the PIL proxy voting code (and also managed by the + modem on its own), hence we mark it as as optional. +- vdd_pll-supply: Reference to the regulator that supplies the PLL's rail. +- qcom,vdd_pll: Voltage to be set for the PLL's rail. +- reg-names: "cxrail_bhs_reg" - control register for modem power + domain. +- clocks: Array of <clock_controller_phandle clock_reference> listing + all the clocks that are accesed by this subsystem. +- qcom,proxy-clock-names: Names of the clocks that need to be turned on/off during + proxy voting/unvoting. +- qcom,active-clock-names: Names of the clocks that need to be turned on for the + subsystem to run. Turned off when the subsystem is shutdown. +- clock-names: Names of all the clocks that are accessed by the subsystem. +- qcom,is-not-loadable: Boolean- Present if the image does not need to + be loaded. +- qcom,pil-self-auth: Boolean- True if authentication is required. +- qcom,mem-protect-id: Virtual ID used by PIL to call into TZ/HYP to protect/unprotect + subsystem related memory. +- qcom,gpio-err-fatal: GPIO used by the modem to indicate error fatal to the apps. +- qcom,gpio-err-ready: GPIO used by the modem to indicate error ready to the apps. +- qcom,gpio-proxy-unvote: GPIO used by the modem to trigger proxy unvoting in + the apps. +- qcom,gpio-force-stop: GPIO used by the apps to force the modem to shutdown. +- qcom,gpio-stop-ack: GPIO used by the modem to ack force stop or a graceful stop + to the apps. +- qcom,gpio-ramdump-disable: GPIO used by the modem to inform the apps that ramdump + collection should be disabled. +- qcom,gpio-shutdown-ack: GPIO used by the modem to indicate that it has done the + necessary cleanup and that the apps can move forward with + the shutdown sequence. +- qcom,restart-group: List of subsystems that will need to restart together. +- qcom,mba-image-is-not-elf: Boolean- Present if MBA image doesnt use the ELF + format. +- qcom,ssctl-instance-id: Instance id used by the subsystem to connect with the SSCTL + service. +- qcom,sysmon-id: platform device id that sysmon is probed with for the subsystem. +- qcom,override-acc: Boolean- Present if we need to override the default ACC settings +- qcom,ahb-clk-vote: Boolean- Present if we need to remove the vote for the mss_cfg_ahb + clock after the modem boots up +- qcom,pnoc-clk-vote: Boolean- Present if the modem needs the PNOC bus to be + clocked before it boots up +- qcom,qdsp6v56-1-3: Boolean- Present if the qdsp version is v56 1.3 +- qcom,qdsp6v56-1-5: Boolean- Present if the qdsp version is v56 1.5 +- qcom,edge: GLINK logical name of the remote subsystem +- qcom,pil-force-shutdown: Boolean. If set, the SSR framework will not trigger graceful shutdown + on behalf of the subsystem driver. +- qcom,pil-mss-memsetup: Boolean - True if TZ need to be informed of modem start address and size. +- qcom,pas-id: pas_id of the subsystem. +- qcom,qdsp6v56-1-8: Boolean- Present if the qdsp version is v56 1.8 +- qcom,qdsp6v56-1-8-inrush-current: Boolean- Present if the qdsp version is V56 1.8 and has in-rush + current issue. +- qcom,qdsp6v61-1-1: Boolean- Present if the qdsp version is v61 1.1 +- qcom,qdsp6v62-1-2: Boolean- Present if the qdsp version is v62 1.2 +- qcom,qdsp6v62-1-5: Boolean- Present if the qdsp version is v62 1.5 +- qcom,mx-spike-wa: Boolean- Present if we need to assert QDSP6 I/O clamp, memory + wordline clamp, and compiler memory clamp during MSS restart. +- qcom,qdsp6v56-1-10: Boolean- Present if the qdsp version is v56 1.10 +- qcom,override-acc-1: Override the default ACC settings with this value if present. +- qcom,cx-ipeak-vote: Boolean- Present if we need to set bit 5 of cxip_lm_vote_clear + during modem shutdown + +One child node to represent the MBA image may be specified, when the MBA image +needs to be loaded in a specifically carved out memory region. + +Required properties: +- compatible: Must be "qcom,pil-mba-mem" +- memory-region: A phandle that points to a reserved memory where the MBA image will be loaded. + +Example: + qcom,mss@fc880000 { + compatible = "qcom,pil-q6v5-mss"; + reg = <0xfc880000 0x100>, + <0xfd485000 0x400>, + <0xfc820000 0x020>, + <0xfc401680 0x004>; + reg-names = "qdsp6_base", "halt_base", "rmb_base", + "restart_reg"; + interrupts = <0 24 1>; + vdd_mss-supply = <&pm8841_s3>; + vdd_cx-supply = <&pm8841_s2>; + vdd_cx-voltage = <7>; + vdd_mx-supply = <&pm8841_s1>; + vdd_mx-uV = <105000>; + + clocks = <&clock_rpm clk_xo_pil_mss_clk>, + <&clock_gcc clk_gcc_mss_cfg_ahb_clk>, + <&clock_gcc clk_gcc_mss_q6_bimc_axi_clk>, + <&clock_gcc clk_gcc_boot_rom_ahb_clk>; + clock-names = "xo", "iface_clk", "bus_clk", "mem_clk"; + qcom,proxy-clock-names = "xo"; + qcom,active-clock-names = "iface_clk", "bus_clk", "mem_clk"; + + qcom,is-not-loadable; + qcom,firmware-name = "mba"; + qcom,pil-self-auth; + qcom,mba-image-is-not-elf; + qcom,override-acc; + + /* GPIO inputs from mss */ + qcom,gpio-err-fatal = <&smp2pgpio_ssr_smp2p_1_in 0 0>; + qcom,gpio-err-ready = <&smp2pgpio_ssr_smp2p_1_in 1 0>; + qcom,gpio-proxy-unvote = <&smp2pgpio_ssr_smp2p_1_in 2 0>; + + /* GPIO output to mss */ + qcom,gpio-force-stop = <&smp2pgpio_ssr_smp2p_1_out 0 0>; + qcom,ssctl-instance-id = <12>; + qcom,sysmon-id = <0>; + + qcom,mba-mem@0 { + compatible = "qcom,pil-mba-mem"; + memory-region = <&peripheral_mem>; + }; + }; diff --git a/Documentation/devicetree/bindings/pil/subsys-pil-tz.txt b/Documentation/devicetree/bindings/pil/subsys-pil-tz.txt new file mode 100644 index 000000000000..d7edafc9a46b --- /dev/null +++ b/Documentation/devicetree/bindings/pil/subsys-pil-tz.txt @@ -0,0 +1,135 @@ +* Generic Subsystem Peripheral Image Loader + +subsys-pil-tz is a generic peripheral image loader (PIL) driver. It is +used for loading the firmware images of the subsystems into memory and +preparing the subsystem's processor to execute code. It's also responsible +for shutting down the processor when it's not needed. + +Required properties: +- compatible: Must be "qcom,pil-tz-generic" +- qcom,firmware-name: Base name of the firmware image. + +Optional properties: +- reg: Pairs of physical base addresses and region sizes of + memory mapped registers. +- reg-names: Names of the bases for the above registers. Not required for + PIL usage. Ex. "wrapper_base", "vbif_base". +- interrupts: Subsystem to Apps watchdog bite interrupt. +- vdd_'reg'-supply: Reference to the regulator that supplies the corresponding + 'reg' domain. +- qcom,proxy-reg-names: Names of the regulators that need to be turned on/off + during proxy voting/unvoting. +- qcom,active-reg-names: Names of the regulators that need to be turned on for the + subsystem to run. Turned off when the subsystem is shutdown. +- qcom,vdd_'reg'-uV-uA: Voltage and current values for the 'reg' regulator. +- qcom,proxy-clock-names: Names of the clocks that need to be turned on/off during + proxy voting/unvoting. +- qcom,active-clock-names: Names of the clocks that need to be turned on for the + subsystem to run. Turned off when the subsystem is shutdown. +- clock-names: Names of all the clocks that are accessed by the subsystem. +- qcom,<clock-name>-freq: Frequency to be set for that clock in Hz. If the property + isn't added for a clock, then the default clock frequency + would be set to 19200000 Hz. +- qcom,msm-bus,name: Name of the bus client for the subsystem. +- qcom,msm-bus,num-cases: Number of use-cases. +- qcom,msm-bus,num-paths: Number of paths. +- qcom,msm-bus,active-only: If not set, uses the dual context by default. +- qcom,msm-bus,vectors-KBps: Vector array of master id, slave id, arbitrated + bandwidth and instantaneous bandwidth. +- qcom,pas-id: pas_id of the subsystem. +- qcom,proxy-timeout-ms: Proxy vote timeout value for the subsystem. +- qcom,smem-id: ID of the SMEM item for the subsystem. +- qcom,is-not-loadable: Boolean. Present if the subsystem's firmware image does not + need to be loaded. +- qcom,pil-no-auth: Boolean. Present if the subsystem is not authenticated and brought + out of reset by using the PIL ops. +- qcom,mem-protect-id: Virtual ID used by PIL to call into TZ/HYP to protect/unprotect + subsystem related memory. +- qcom,gpio-err-fatal: GPIO used by the subsystem to indicate error fatal to the apps. +- qcom,gpio-err-ready: GPIO used by the subsystem to indicate error ready to the apps. +- qcom,gpio-proxy-unvote: GPIO used by the subsystem to trigger proxy unvoting in + the apps. +- qcom,gpio-force-stop: GPIO used by the apps to force the subsystem to shutdown. +- qcom,gpio-stop-ack: GPIO used by the subsystem to ack force stop or a graceful stop + to the apps. +- qcom,restart-group: List of subsystems that will need to restart together. +- qcom,keep-proxy-regs-on: Boolean. Present if during proxy unvoting, PIL needs to leave + the regulators enabled after removing the voltage/current votes. +- qcom,edge: GLINK logical name of the remote subsystem +- qcom,ssctl-instance-id: Instance id used by the subsystem to connect with the SSCTL + service. +- qcom,sysmon-id: platform device id that sysmon is probed with for the subsystem. +- qcom,pil-force-shutdown: Boolean. If set, the SSR framework will not trigger graceful shutdown + on behalf of the subsystem driver. +- qcom,pil-generic-irq-handler: generic interrupt handler used for communication with subsytem + based on bit values in scsr registers. +- qcom,spss-scsr-bits: array of bit positions into the scsr registers used in generic handler. +- qcom,complete-ramdump: Boolean. If set, complete ramdump i.e. region between start address of + first segment to end address of last segment will be collected without + leaving any hole in between. + +Example: + qcom,venus@fdce0000 { + compatible = "qcom,pil-tz-generic"; + reg = <0xfdce0000 0x4000>, + <0xfdc80000 0x400>; + + vdd-supply = <&gdsc_venus>; + qcom,proxy-reg-names = "vdd"; + clock-names = "core_clk", "iface_clk", "bus_clk", "mem_clk", + "scm_core_clk", "scm_iface_clk", "scm_bus_clk", + "scm_core_clk_src"; + qcom,proxy-clock-names = "core_clk", "iface_clk", "bus_clk", + "mem_clk", "scm_core_clk", + "scm_iface_clk", "scm_bus_clk", + "scm_core_clk_src"; + qcom,scm_core_clk_src-freq = <50000000>; + + qcom,msm-bus,name = "pil-venus"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,active-only = <0>; + qcom,msm-bus,vectors-KBps = + <63 512 0 0>, + <63 512 0 304000>; + + qcom,pas-id = <9>; + qcom,proxy-timeout-ms = <2000>; + qcom,firmware-name = "venus"; + }; + + qcom,lpass@fe200000 { + compatible = "qcom,pil-tz-generic"; + reg = <0xfe200000 0x00100>, + <0xfd485100 0x00010>, + <0xfc4016c0 0x00004>; + + interrupts = <0 162 1>; + + vdd_cx-supply = <&pm8841_s2_corner>; + qcom,proxy-reg-names = "vdd_cx"; + qcom,vdd_cx-uV-uA = <7 100000>; + clock-names = "bus_clk", "xo", "scm_core_clk", "scm_iface_clk", + "scm_bus_clk", "scm_core_clk_src"; + qcom,active-clock-names = "bus_clk"; + qcom,proxy-clock-names = "xo", "scm_core_clk", "scm_iface_clk", + "scm_bus_clk", "scm_core_clk_src"; + qcom,scm_core_clk_src-freq = <50000000>; + + qcom,smem-id = <423>; + qcom,pas-id = <1>; + qcom,proxy-timeout-ms = <10000>; + qcom,firmware-name = "adsp"; + qcom,edge = "lpass"; + + /* GPIO inputs from lpass */ + qcom,gpio-err-fatal = <&smp2pgpio_ssr_smp2p_2_in 0 0>; + qcom,gpio-proxy-unvote = <&smp2pgpio_ssr_smp2p_2_in 2 0>; + qcom,gpio-err-ready = <&smp2pgpio_ssr_smp2p_2_in 1 0>; + qcom,gpio-stop-ack = <&smp2pgpio_ssr_smp2p_2_in 3 0>; + + /* GPIO output to lpass */ + qcom,gpio-force-stop = <&smp2pgpio_ssr_smp2p_2_out 0 0>; + qcom,ssctl-instance-id = <14>; + qcom,sysmon-id = <1>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,lpi-pinctrl.txt new file mode 100644 index 000000000000..57510ec13d03 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpi-pinctrl.txt @@ -0,0 +1,154 @@ +Qualcomm Technologies, Inc. LPI GPIO controller driver + +This DT bindings describes the GPIO controller driver +being added for supporting LPI (Low Power Island) TLMM +from QTI chipsets. + +Following properties are for LPI GPIO controller device main node. +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,lpi-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: Register base of the GPIO controller and length. + +- qcom,num-gpios: + Usage: required + Value type: <u32> + Definition: Number of GPIOs supported by the controller. + +- gpio-controller: + Usage: required + Value type: <none> + Definition: Used to mark the device node as a GPIO controller. + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: Must be 2; + The first cell will be used to define gpio number and the + second denotes the flags for this gpio. + +Please refer to ../gpio/gpio.txt for general description of GPIO bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin or a list of pins. This configuration can include the +mux function to select on those pin(s), and various pin configuration +parameters, as listed below. + +SUBNODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: gpio0-gpio31 for LPI. + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Valid values are: + "gpio", + "func1", + "func2", + "func3", + "func4", + "func5" + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as pull down. + +- bias-bus-hold: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as bus-keeper mode. + +- bias-pull-up: + Usage: optional + Value type: <empty> + Definition: The specified pins should be configured as pull up. + +- input-enable: + Usage: optional + Value type: <none> + Definition: The specified pins are put in input mode. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + +- qcom,drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins. + +Example: + + lpi_tlmm: lpi_pinctrl@152c000 { + compatible = "qcom,lpi-pinctrl"; + qcom,num-gpios = <32>; + reg = <0x152c000 0>; + gpio-controller; + #gpio-cells = <2>; + + hph_comp_active: hph_comp_active { + mux { + pins = "gpio22"; + function = "func1"; + }; + + config { + pins = "gpio22"; + output-high; + qcom,drive-strength = <8>; + }; + }; + + hph_comp_sleep: hph_comp_sleep { + mux { + pins = "gpio22"; + function = "func1"; + }; + + config { + pins = "gpio22"; + qcom,drive-strength = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt new file mode 100644 index 000000000000..d343b9242ca0 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8996-pinctrl.txt @@ -0,0 +1,199 @@ +Qualcomm Technologies, Inc. MSM8996 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8960 platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,apq8084-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio149, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data + sdc1_rclk, + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, + atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6, + atest_usb20, atest_char0, dac_calib10, qdss_stm10, + qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6, + blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11, + qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1, + qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11, + dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6, + qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, + dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, + dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, + dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, + dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25, + sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, + qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, + uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9, + blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7, + qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11, + blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0, + cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4, + blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4, + qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus, + isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s, + qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b, + sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b, + gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12, + qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29, + tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27, + qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk, + sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b, + sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b, + ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b, + blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt, + pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11, + qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, + qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3, + gpio + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@01010000 { + compatible = "qcom,msm8996-pinctrl"; + reg = <0x01010000 0x300000>; + interrupts = <0 208 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + uart_console_active: uart_console_active { + mux { + pins = "gpio4", "gpio5"; + function = "blsp_uart8"; + }; + + config { + pins = "gpio4", "gpio5"; + drive-strength = <2>; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msmhamster-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msmhamster-pinctrl.txt new file mode 100644 index 000000000000..6f3451618909 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msmhamster-pinctrl.txt @@ -0,0 +1,199 @@ +Qualcomm Technologies, Inc. MSMHAMSTER TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSMHAMSTER platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,hamster-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio149, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data + sdc1_rclk, + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, + atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6, + atest_usb20, atest_char0, dac_calib10, qdss_stm10, + qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6, + blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11, + qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1, + qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11, + dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6, + qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, + dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, + dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, + dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, + dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25, + sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, + qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, + uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9, + blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7, + qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11, + blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0, + cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4, + blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4, + qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus, + isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s, + qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b, + sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b, + gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12, + qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29, + tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27, + qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk, + sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b, + sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b, + ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b, + blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt, + pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11, + qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, + qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3, + gpio + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@01010000 { + compatible = "qcom,msmhamster-pinctrl"; + reg = <0x01010000 0x300000>; + interrupts = <0 208 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + uart_console_active: uart_console_active { + mux { + pins = "gpio4", "gpio5"; + function = "blsp_uart8"; + }; + + config { + pins = "gpio4", "gpio5"; + drive-strength = <2>; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 1ae63c0acd40..8198a13081b8 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -16,6 +16,9 @@ PMIC's from Qualcomm. "qcom,pm8941-gpio" "qcom,pma8084-gpio" + And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" + if the device is on an spmi bus or an ssbi bus respectively + - reg: Usage: required Value type: <prop-encoded-array> @@ -86,14 +89,18 @@ to specify in a pin configuration subnode: Value type: <string> Definition: Specify the alternative function to be configured for the specified pins. Valid values are: - "normal", - "paired", - "func1", - "func2", - "dtest1", - "dtest2", - "dtest3", - "dtest4" + "normal", + "paired", + "func1", + "func2", + "dtest1", + "dtest2", + "dtest3", + "dtest4", + And following values are supported by LV/MV GPIO subtypes: + "func3", + "func4", + "analog" - bias-disable: Usage: optional @@ -178,10 +185,33 @@ to specify in a pin configuration subnode: Value type: <none> Definition: The specified pins are configured in open-source mode. +- qcom,atest: + Usage: optional + Value type: <u32> + Definition: Selects ATEST rail to route to GPIO when it's configured + in analog-pass-through mode by specifying "analog" function. + Valid values are 0-3 corresponding to PMIC_GPIO_AOUT_ATESTx + defined in <dt-bindings/pinctrl/qcom,pmic-gpio.h>. + +- qcom,dtest-buffer: + Usage: optional + Value type: <u32> + Definition: Selects DTEST rail to route to GPIO when it's configured + as a digital input. + For LV/MV GPIO subtypes, the valid values are 0-3 + corresponding to PMIC_GPIO_DIN_DTESTx defined in + <dt-bindings/pinctrl/qcom,pmic-gpio.h>. Only one + DTEST rail can be selected at a time. + For 4CH/8CH GPIO subtypes, supported values are 1-15. + 4 DTEST rails are supported in total and more than 1 DTEST + rail can be selected simultaneously. Each bit of the + 4 LSBs represent one DTEST rail, such as [3:0] = 0101 + means both DTEST1 and DTEST3 are selected. + Example: pm8921_gpio: gpio@150 { - compatible = "qcom,pm8921-gpio"; + compatible = "qcom,pm8921-gpio", "qcom,ssbi-gpio"; reg = <0x150 0x160>; interrupts = <192 1>, <193 1>, <194 1>, <195 1>, <196 1>, <197 1>, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt index d7803a2a94e9..42e504a27fa0 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt @@ -17,6 +17,9 @@ of PMIC's from Qualcomm. "qcom,pm8941-mpp", "qcom,pma8084-mpp", + And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" + if the device is on an spmi bus or an ssbi bus respectively. + - reg: Usage: required Value type: <prop-encoded-array> @@ -139,7 +142,7 @@ to specify in a pin configuration subnode: - qcom,dtest: Usage: optional Value type: <u32> - Definition: Selects which dtest rail to be routed in the various functions. + Definition: Selects which dtest rail to be routed for digital output. Valid values are 1-4 - qcom,amux-route: @@ -153,10 +156,20 @@ to specify in a pin configuration subnode: Value type: <none> Definition: Indicates that the pin should be operating in paired mode. +- qcom,dtest-buffer: + Usage: optional + Value type: <u32> + Definition: Selects which dtest rail to be routed for digital input. + It's also valid when the pin is configured as digital + input and output. + 4 dtest rails supported in total and more than one rail + could be selected simultaneously. Each bit of the 4 LSBs + represent one dtest rail, such as [3:0] = 0101 means both + dtest1 and dtest3 are selected. Valid values are 1-15. Example: mpps@a000 { - compatible = "qcom,pm8841-mpp"; + compatible = "qcom,pm8841-mpp", "qcom,spmi-mpp"; reg = <0xa000>; gpio-controller; #gpio-cells = <2>; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt new file mode 100644 index 000000000000..dbd4baf0825a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm660-pinctrl.txt @@ -0,0 +1,199 @@ +Qualcomm Technologies, Inc. SDM660 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +SDM660 platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,sdm660-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio149, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data + sdc1_rclk, + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, + atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6, + atest_usb20, atest_char0, dac_calib10, qdss_stm10, + qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6, + blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11, + qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1, + qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11, + dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6, + qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, + dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, + dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, + dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, + dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25, + sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, + qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, + uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9, + blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7, + qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11, + blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0, + cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4, + blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4, + qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus, + isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s, + qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b, + sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b, + gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12, + qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29, + tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27, + qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk, + sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b, + sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b, + ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b, + blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt, + pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11, + qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, + qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3, + gpio + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + tlmm: pinctrl@01010000 { + compatible = "qcom,sdm660-pinctrl"; + reg = <0x01010000 0x300000>; + interrupts = <0 208 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + uart_console_active: uart_console_active { + mux { + pins = "gpio4", "gpio5"; + function = "blsp_uart8"; + }; + + config { + pins = "gpio4", "gpio5"; + drive-strength = <2>; + bias-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,wcd-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,wcd-pinctrl.txt new file mode 100644 index 000000000000..add8b7d688a8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,wcd-pinctrl.txt @@ -0,0 +1,138 @@ +Qualcomm Technologies, Inc. WCD GPIO block + +This binding describes the GPIO block found in the WCD934X series of +audio codec's from QTI. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,wcd-pinctrl" + +- qcom,num-gpios: + Usage: required + Value type: <u32> + Definition: Number of GPIO's supported by the controller + +- gpio-controller: + Usage: required + Value type: <none> + Definition: Mark the device node as a GPIO controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: Must be 2; + the first cell will be used to define gpio number and the + second denotes the flags for this gpio + +Please refer to ../gpio/gpio.txt for a general description of GPIO bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin or a list of pins. This configuration can include the +mux function to select on those pin(s), and various pin configuration +parameters, as listed below. + + +SUBNODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio1-gpio5 for wcd9340 + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configured as pull down. + +- bias-pull-up: + Usage: optional + Value type: <empty> + Definition: The specified pins should be configured as pull up. + +- qcom,pull-up-strength: + Usage: optional + Value type: <u32> + Definition: Specifies the strength to use for pull up, if selected. + +- bias-high-impedance: + Usage: optional + Value type: <none> + Definition: The specified pins will put in high-Z mode and disabled. + +- input-enable: + Usage: optional + Value type: <none> + Definition: The specified pins are put in input mode. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + +- qcom,drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins. + +Example: + + wcd: wcd_pinctrl@5 { + compatible = "qcom,wcd-pinctl"; + qcom,num-gpios = <5> + gpio-controller; + #gpio-cells = <2>; + + spkr_1_wcd_en_active: spkr_1_wcd_en_active { + mux { + pins = "gpio2"; + }; + + config { + pins = "gpio2"; + output-high; + }; + }; + + spkr_1_wcd_en_sleep: spkr_1_wcd_en_sleep { + mux { + pins = "gpio2"; + }; + + config { + pins = "gpio2"; + input-enable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/platform/msm/gpio-usbdetect.txt b/Documentation/devicetree/bindings/platform/msm/gpio-usbdetect.txt new file mode 100644 index 000000000000..5bb85a4860ab --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/gpio-usbdetect.txt @@ -0,0 +1,25 @@ +GPIO USB VBUS Detection + +Discrete USB VBUS detection circuitry can be connected to the AP or PMICs. +Such circuits can be used to detect the when a USB cable is connected to +an upstream port such as a standard host or a wall charger by detecting +the presence of VBUS voltage. The GPIO can be configured to trigger an +interrupt, and allow the software driver to in turn notify the USB +subsytem using the power_supply framework. + +Required Properties: + - compatible: must be "qcom,gpio-usbdetect" + - qcom,vbus-det-gpio: GPIO from which VBUS detection can be read from. + - interrupts: an interrupt triggered by the output of the detection circuit + - interrupt-names: must be "vbus_det_irq" + +Optional Properties: + - vin-supply: phandle to a regulator that powers this circuit, if needed + +Example: + + usb_detect { + compatible = "qcom,gpio-usbdetect"; + qcom,vbus-det-gpio = <&pm8084 2 0>; + vin-supply = <&vbus_det_reg>; + }; diff --git a/Documentation/devicetree/bindings/platform/msm/ipa.txt b/Documentation/devicetree/bindings/platform/msm/ipa.txt new file mode 100644 index 000000000000..ed784f7f58a5 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/ipa.txt @@ -0,0 +1,228 @@ +Qualcomm Internet Packet Accelerator + +Internet Packet Accelerator (IPA) is a programmable protocol +processor HW block. It is designed to support generic HW processing +of UL/DL IP packets for various use cases independent of radio technology. + +Required properties: + +IPA node: + +- compatible : "qcom,ipa" +- reg: Specifies the base physical addresses and the sizes of the IPA + registers. +- reg-names: "ipa-base" - string to identify the IPA CORE base registers. + "bam-base" - string to identify the IPA BAM base registers. + "a2-bam-base" - string to identify the A2 BAM base registers. +- interrupts: Specifies the interrupt associated with IPA. +- interrupt-names: "ipa-irq" - string to identify the IPA core interrupt. + "bam-irq" - string to identify the IPA BAM interrupt. + "a2-bam-irq" - string to identify the A2 BAM interrupt. +- qcom,ipa-hw-ver: Specifies the IPA hardware version. +- qcom,ipa-ram-mmap: An array of unsigned integers representing addresses and + sizes which are used by the driver to access IPA RAM. + +Optional: + +- qcom,wan-rx-ring-size: size of WAN rx ring, default is 1000 +- qcom,lan-rx-ring-size: size of LAN rx ring, default is 1000 +- qcom,arm-smmu: SMMU is present and ARM SMMU driver is used +- qcom,msm-smmu: SMMU is present and QSMMU driver is used +- qcom,smmu-s1-bypass: Boolean context flag to set SMMU to S1 bypass +- qcom,smmu-fast-map: Boolean context flag to set SMMU to fastpath mode +- ipa_smmu_ap: AP general purpose SMMU device + compatible "qcom,ipa-smmu-ap-cb" +- ipa_smmu_wlan: WDI SMMU device + compatible "qcom,ipa-smmu-wlan-cb" +- ipa_smmu_uc: uc SMMU device + compatible "qcom,ipa-smmu-uc-cb" +- qcom,use-a2-service: determine if A2 service will be used +- qcom,use-ipa-tethering-bridge: determine if tethering bridge will be used +- qcom,use-ipa-bamdma-a2-bridge: determine if a2/ipa hw bridge will be used +- qcom,ee: which EE is assigned to (non-secure) APPS from IPA-BAM POV. This +is a number +- qcom,ipa-hw-mode: IPA hardware mode - Normal, Virtual memory allocation, +memory allocation over a PCIe bridge +- qcom,msm-bus,name: String representing the client-name +- qcom,msm-bus,num-cases: Total number of usecases +- qcom,msm-bus,active-only: Boolean context flag for requests in active or + dual (active & sleep) contex +- qcom,msm-bus,num-paths: Total number of master-slave pairs +- qcom,msm-bus,vectors-KBps: Arrays of unsigned integers representing: + master-id, slave-id, arbitrated bandwidth + in KBps, instantaneous bandwidth in KBps +- qcom,ipa-bam-remote-mode: Boolean context flag to determine if ipa bam + is in remote mode. +- qcom,modem-cfg-emb-pipe-flt: Boolean context flag to determine if modem + configures embedded pipe filtering rules +- qcom,skip-uc-pipe-reset: Boolean context flag to indicate whether + a pipe reset via the IPA uC is required +- qcom,ipa-wdi2: Boolean context flag to indicate whether + using wdi-2.0 or not +- qcom,use-64-bit-dma-mask: Boolean context flag to indicate whether + using 64bit dma mask or not +- qcom,use-dma-zone: Boolean context flag to indicate whether memory + allocations controlled by IPA driver that do not + specify a struct device * should use GFP_DMA to + workaround IPA HW limitations +- qcom,use-gsi: Boolean context flag to indicate if the + transport protocol is GSI +- qcom,use-rg10-limitation-mitigation: Boolean context flag to activate + the mitigation to register group 10 + AP access limitation +- qcom,do-not-use-ch-gsi-20: Boolean context flag to activate + software workaround for IPA limitation + to not use GSI physical channel 20 +- qcom,tethered-flow-control: Boolean context flag to indicate whether + apps based flow control is needed for tethered + call. +- qcom,rx-polling-sleep-ms: Receive Polling Timeout in millisecond, + default is 1 millisecond. +- qcom,ipa-polling-iteration: IPA Polling Iteration Count,default is 40. +- qcom,ipa-tz-unlock-reg: Register start addresses and ranges which + need to be unlocked by TZ. +- qcom,ipa-uc-monitor-holb: Boolean context flag to indicate whether + monitoring of holb via IPA uc is required. + +IPA pipe sub nodes (A2 static pipes configurations): + +-label: two labels are supported, a2-to-ipa and ipa-to-a2 which +supply static configuration for A2-IPA connection. +-qcom,src-bam-physical-address: The physical address of the source BAM +-qcom,ipa-bam-mem-type:The memory type: + 0(Pipe memory), 1(Private memory), 2(System memory) +-qcom,src-bam-pipe-index: Source pipe index +-qcom,dst-bam-physical-address: The physical address of the + destination BAM +-qcom,dst-bam-pipe-index: Destination pipe index +-qcom,data-fifo-offset: Data fifo base offset +-qcom,data-fifo-size: Data fifo size (bytes) +-qcom,descriptor-fifo-offset: Descriptor fifo base offset +-qcom,descriptor-fifo-size: Descriptor fifo size (bytes) + +Optional properties: +-qcom,ipa-pipe-mem: Specifies the base physical address and the + size of the IPA pipe memory region. + Pipe memory is a feature which may be supported by the + target (HW platform). The Driver support using pipe + memory instead of system memory. In case this property + will not appear in the IPA DTS entry, the driver will + use system memory. +- clocks: This property shall provide a list of entries each of which + contains a phandle to clock controller device and a macro that is + the clock's name in hardware.This should be "clock_rpm" as clock + controller phandle and "clk_ipa_clk" as macro for "iface_clk" +- clock-names: This property shall contain the clock input names used + by driver in same order as the clocks property.This should be "iface_clk" + +IPA SMMU sub nodes + +-compatible: "qcom,ipa-smmu-ap-cb" - represents the AP context bank. + +-compatible: "qcom,ipa-smmu-wlan-cb" - represents IPA WLAN context bank. + +-compatible: "qcom,ipa-smmu-uc-cb" - represents IPA uC context bank (for uC + offload scenarios). +- iommus : the phandle and stream IDs for the SMMU used by this root + +- qcom,iova-mapping: specifies the start address and size of iova space. + +- qcom,additional-mapping: specifies any addtional mapping needed for this + context bank. The format is <iova pa size> + +IPA SMP2P sub nodes + +-compatible: "qcom,smp2pgpio-map-ipa-1-out" - represents the out gpio from + ipa driver to modem. + +-compatible: "qcom,smp2pgpio-map-ipa-1-in" - represents the in gpio to + ipa driver from modem. + +-gpios: Binding to the gpio defined in XXX-smp2p.dtsi + + +Example: + +qcom,ipa@fd4c0000 { + compatible = "qcom,ipa"; + reg = <0xfd4c0000 0x26000>, + <0xfd4c4000 0x14818>; + <0xfc834000 0x7000>; + reg-names = "ipa-base", "bam-base"; "a2-bam-base"; + interrupts = <0 252 0>, + <0 253 0>; + <0 29 1>; + interrupt-names = "ipa-irq", "bam-irq"; "a2-bam-irq"; + qcom,ipa-hw-ver = <1>; + clocks = <&clock_rpm clk_ipa_clk>; + clock-names = "iface_clk"; + + qcom,msm-bus,name = "ipa"; + qcom,msm-bus,num-cases = <3>; + qcom,msm-bus,num-paths = <2>; + qcom,msm-bus,vectors-KBps = + <90 512 0 0>, <90 585 0 0>, /* No vote */ + <90 512 100000 800000>, <90 585 100000 800000>, /* SVS */ + <90 512 100000 1200000>, <90 585 100000 1200000>; /* PERF */ + qcom,bus-vector-names = "MIN", "SVS", "PERF"; + + qcom,pipe1 { + label = "a2-to-ipa"; + qcom,src-bam-physical-address = <0xfc834000>; + qcom,ipa-bam-mem-type = <0>; + qcom,src-bam-pipe-index = <1>; + qcom,dst-bam-physical-address = <0xfd4c0000>; + qcom,dst-bam-pipe-index = <6>; + qcom,data-fifo-offset = <0x1000>; + qcom,data-fifo-size = <0xd00>; + qcom,descriptor-fifo-offset = <0x1d00>; + qcom,descriptor-fifo-size = <0x300>; + }; + + qcom,pipe2 { + label = "ipa-to-a2"; + qcom,src-bam-physical-address = <0xfd4c0000>; + qcom,ipa-bam-mem-type = <0>; + qcom,src-bam-pipe-index = <7>; + qcom,dst-bam-physical-address = <0xfc834000>; + qcom,dst-bam-pipe-index = <0>; + qcom,data-fifo-offset = <0x00>; + qcom,data-fifo-size = <0xd00>; + qcom,descriptor-fifo-offset = <0xd00>; + qcom,descriptor-fifo-size = <0x300>; + }; + + /* smp2p gpio information */ + qcom,smp2pgpio_map_ipa_1_out { + compatible = "qcom,smp2pgpio-map-ipa-1-out"; + gpios = <&smp2pgpio_ipa_1_out 0 0>; + }; + + qcom,smp2pgpio_map_ipa_1_in { + compatible = "qcom,smp2pgpio-map-ipa-1-in"; + gpios = <&smp2pgpio_ipa_1_in 0 0>; + }; + + ipa_smmu_ap: ipa_smmu_ap { + compatible = "qcom,ipa-smmu-ap-cb"; + iommus = <&anoc2_smmu 0x30>; + qcom,iova-mapping = <0x20000000 0x40000000>; + qcom,additional-mapping = + /* modem tables in IMEM */ + <0x146BD000 0x146BD000 0x2000>; + }; + + ipa_smmu_wlan: ipa_smmu_wlan { + compatible = "qcom,ipa-smmu-wlan-cb"; + iommus = <&anoc2_smmu 0x31>; + qcom,additional-mapping = + /* ipa-uc ram */ + <0x1E60000 0x1E60000 0x80000>; + }; + + ipa_smmu_uc: ipa_smmu_uc { + compatible = "qcom,ipa-smmu-uc-cb"; + iommus = <&anoc2_smmu 0x32>; + qcom,iova-mapping = <0x40000000 0x20000000>; + }; +}; diff --git a/Documentation/devicetree/bindings/platform/msm/msm_gsi.txt b/Documentation/devicetree/bindings/platform/msm/msm_gsi.txt new file mode 100644 index 000000000000..0cf1458c1ae7 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/msm_gsi.txt @@ -0,0 +1,11 @@ +* Qualcomm Technologies, Inc. GSI driver module + +This module enables GSI driver. + +Required properties: +- compatible: Must be "qcom,msm_gsi" + +Example: + qcom,msm-gsi { + compatible = "qcom,msm_gsi"; + } diff --git a/Documentation/devicetree/bindings/platform/msm/msm_mhi_uci.txt b/Documentation/devicetree/bindings/platform/msm/msm_mhi_uci.txt new file mode 100644 index 000000000000..5c255b19ea5a --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/msm_mhi_uci.txt @@ -0,0 +1,55 @@ +MSM MHI UCI interface device + +MHI userpace control interface (UCI) enables userspace software clients to +communicate with device using MHI protocol. + +============== +Node Structure +============== + +Main node properties: + +- compatible + Usage: required + Value type: <string> + Definition: "qcom,mhi-uci" + +- qcom,mhi-uci-channels + Usage: required + Value type: Array of <u32> + Definition: Array tuples which define the channel configuration + parameters. Each tuple is of length 2, 1st value + represent channel, and 2nd value represent maximum + payload supported. Maximum payload supported is 64 + bytes. Number of tuples must be even value. Max # of + tuples is 46. + +- qcom,mhi-uci-ctrlchan + Usage: optional + Value type: <u32> + Definition: Channel that will be handling flow control (DTR/RTS) signals. + +======= +Example +======= +qcom,mhi-uci@0 { + compatible = "qcom,mhi-uci"; + qcom,mhi-uci-channels = <0 0x1000>, + <1 0x1000>, + <2 0x1000>, + <3 0xffff>, + <10 0x1000>, + <11 0x1000>, + <14 0x1000>, + <15 0x1000>, + <16 0x1000>, + <17 0x1000>, + <18 0x1000>, + <19 0x1000>, + <24 0x1000>, + <25 0x1000>, + <32 0x1000>, + <33 0x1000>; + qcom,mhi-uci-ctrlchan = <18>; + status = "ok"; +}; diff --git a/Documentation/devicetree/bindings/platform/msm/msm_rmnet_mhi.txt b/Documentation/devicetree/bindings/platform/msm/msm_rmnet_mhi.txt new file mode 100644 index 000000000000..f19dfa4b69c6 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/msm_rmnet_mhi.txt @@ -0,0 +1,59 @@ +MSM MHI RMNET interface device + +MHI RMNET provides a network interface over PCIe to transfer IP packets +between modem and apps. + +============== +Node Structure +============== + +Main node properties: + +- compatible + Usage: required + Value type: <string> + Definition: "qcom,mhi-rmnet" + +- qcom,mhi-rx-channel + Usage: optional if mhi-tx-channel is defined. + Value type: <u32> + Definition: MHI channel number for incoming data + +- qcom,mhi-tx-channel + Usage: optional if mhi-rx-channel is defined. + Value type: <u32> + Definition: MHI channel number for outgoing data + +- qcom,mhi-mru + Usage: required + Value type: <u32> + Definition: Default payload size for receive path. + +- qcom,mhi-max-mru + Usage: optional + Value type: <u32> + Definition: Maximum payload interface support on receive path. If + not defined MHI_MAX_MRU is used. + +- qcom,mhi-max-mtu + Usage: optional + Value type: <u32> + Definition: Maximum payload interface support on transmit path. If + not defined MHI_MAX_MTU is used. + +- qcom,interface-name + Usage: optional + Value type: <string> + Definition: optional string to overwrite default interface name. If + not defined string RMNET_MHI_DRIVER_NAME is used. + +======== +Example: +======== +mhi_rmnet_0: qcom,mhi-rmnet@0 { + compatible = "qcom,mhi-rmnet"; + qcom,mhi-rx-channel = <101>; + qcom,mhi-tx-channel = <100>; + qcom,mhi-mru = <8000>; + status = "okay"; +}; diff --git a/Documentation/devicetree/bindings/platform/msm/qpnp-coincell.txt b/Documentation/devicetree/bindings/platform/msm/qpnp-coincell.txt new file mode 100644 index 000000000000..4d55f0cecefe --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/qpnp-coincell.txt @@ -0,0 +1,44 @@ +Qualcomm Technologies, Inc. QPNP Coincell - coincell battery charger devices + +Required properties: +- compatible: Must be "qcom,qpnp-coincell". +- reg: Specifies the SPMI address and size for this coincell device. + +Required structure: +- A qcom,qpnp-coincell node must be a child of an SPMI node that has specified + the spmi-slave-container property. + +Optional properties: +- qcom,rset-ohms: Specifies the resistance of the current limiting + resistor in ohms. Four values are supported: + 800, 1200, 1700, and 2100. +- qcom,vset-millivolts: Specifies the coincell charging voltage in millivolts. + Four values are supported: 2500, 3000, 3100, and 3200. +- qcom,charge-enable: Specifies if coincell charging should be enabled or not. + 0 = disable charging, 1 = enabled charging + +If any of the optional properties are not specified, then the hardware default +values for the unspecified properties will be used instead. + +Example: + qcom,spmi@fc4c0000 { + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <3>; + + qcom,pm8941@1 { + spmi-slave-container; + reg = <0x1>; + #address-cells = <1>; + #size-cells = <1>; + + qcom,coincell@2800 { + compatible = "qcom,qpnp-coincell"; + reg = <0x2800 0x100>; + qcom,rset-ohms = <800>; + qcom,vset-millivolts = <3100>; + qcom,charge-enable = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/platform/msm/qpnp-revid.txt b/Documentation/devicetree/bindings/platform/msm/qpnp-revid.txt new file mode 100644 index 000000000000..babc4523a29a --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/qpnp-revid.txt @@ -0,0 +1,17 @@ +QPNP-REVID + +QPNP-REVID provides a way to read the PMIC part number and revision. + +Required properties: +- compatible : should be "qcom,qpnp-revid" +- reg : offset and length of the PMIC peripheral register map. + +Optional property: +- qcom,fab-id-valid: Use this property when support to read Fab + identification from REV ID peripheral is available. + +Example: + qcom,revid@100 { + compatible = "qcom,qpnp-revid"; + reg = <0x100 0x100>; + }; diff --git a/Documentation/devicetree/bindings/platform/msm/rmnet_ipa.txt b/Documentation/devicetree/bindings/platform/msm/rmnet_ipa.txt new file mode 100644 index 000000000000..d8934c01cc71 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/rmnet_ipa.txt @@ -0,0 +1,22 @@ +* Qualcomm Technologies, Inc. RmNet IPA driver module + +This module enables embedded data calls using IPA HW. + +Required properties: +- compatible: Must be "qcom,rmnet-ipa" + +Optional: +- qcom,rmnet-ipa-ssr: determine if modem SSR is supported +- qcom,ipa-loaduC: indicate that ipa uC should be loaded +- qcom,ipa-advertise-sg-support: determine how to respond to a query +regarding scatter-gather capability +- qcom,ipa-napi-enable: Boolean context flag to indicate whether + to enable napi framework or not +- qcom,wan-rx-desc-size: size of WAN rx desc fifo ring, default is 256 + +Example: + qcom,rmnet-ipa { + compatible = "qcom,rmnet-ipa"; + qcom,wan-rx-desc-size = <256>; + } + diff --git a/Documentation/devicetree/bindings/platform/msm/rmnet_ipa3.txt b/Documentation/devicetree/bindings/platform/msm/rmnet_ipa3.txt new file mode 100644 index 000000000000..e9575f150c5e --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/rmnet_ipa3.txt @@ -0,0 +1,22 @@ +* Qualcomm Technologies, Inc. RmNet IPA driver module + +This module enables embedded data calls using IPA v3 HW. + +Required properties: +- compatible: Must be "qcom,rmnet-ipa3" + +Optional: +- qcom,rmnet-ipa-ssr: determine if modem SSR is supported +- qcom,ipa-loaduC: indicate that ipa uC should be loaded +- qcom,ipa-advertise-sg-support: determine how to respond to a query +regarding scatter-gather capability +- qcom,ipa-napi-enable: Boolean context flag to indicate whether + to enable napi framework or not +- qcom,wan-rx-desc-size: size of WAN rx desc fifo ring, default is 256 + +Example: + qcom,rmnet-ipa3 { + compatible = "qcom,rmnet-ipa3"; + qcom,wan-rx-desc-size = <256>; + } + diff --git a/Documentation/devicetree/bindings/platform/msm/ssm.txt b/Documentation/devicetree/bindings/platform/msm/ssm.txt new file mode 100644 index 000000000000..7df3efd66577 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/ssm.txt @@ -0,0 +1,13 @@ +* Qualcomm Technologies, Inc. Secure Service Module driver + +This module enables framework to which a client can register itself +specifying different attributes and defining various permission levels +associated with different combination of attribute values and mode of the system. + +Required properties: +- compatible: Must be "qcom,ssm" + +Example: + qcom,ssm { + compatible = "qcom,ssm"; + };
\ No newline at end of file diff --git a/Documentation/devicetree/bindings/platform/msm/usb-bam.txt b/Documentation/devicetree/bindings/platform/msm/usb-bam.txt new file mode 100644 index 000000000000..7d2e31ec84f5 --- /dev/null +++ b/Documentation/devicetree/bindings/platform/msm/usb-bam.txt @@ -0,0 +1,114 @@ +MSM USB Bus Access Manager (BAM) + +This describes the device used to interface the USB controller +with the Smart Peripheral Subsystem (SPS). The BAM serves to +connect USB directly with other peer peripherals in the system +and is statically configured with a number of unidirectional pipes. + +Required properties: +- compatible: should be "qcom,usb-bam-msm" +- reg : pair of physical base addresses and region size of BAM device +- interrupts: IRQ line for BAM device +- qcom,usb-bam-num-pipes: max number of pipes that can be used +- qcom,bam-type: BAM type can be one of + 0 - SSUSB_BAM + 1 - HSUSB_BAM + 2 - HSIC_BAM + +Optional properties: +- qcom,usb-bam-fifo-baseaddr: base address for bam pipe's data and descriptor + fifos. This can be on chip memory (ocimem). This + property is required if sub-node's mem-type is ocimem or usb private mem. +- qcom,ignore-core-reset-ack: If present then BAM ignores ACK from USB core + while performing PIPE RESET +- qcom,disable-clk-gating: If present then disable BAM clock gating. +- qcom,usb-bam-override-threshold: If present then the default 512 byte threshold + is overridden. This threshold configures the threshold value for Read/Write + event generation by the BAM towards another BAM. +- qcom,usb-bam-max-mbps-highspeed: max mbps in high speed connection + for either rx or tx direction. +- qcom,usb-bam-max-mbps-superspeed: max mbps in super speed connection + for either rx or tx direction. +- qcom,bam-mode: BAM mode can be one of. + 0 - BAM_MODE_DEVICE + 1 - BAM_MODE_HOST + (If not set will be set by default to BAM_MODE_DEVICE) +- qcom,reset-bam-on-connect: If present then BAM is RESET before connecting + pipe. This may be required if BAM peripheral is also reset before connect. +- qcom,reset-bam-on-disconnect: If present then BAM is RESET after disconnecting pipes. +- qcom,enable-hsusb-bam-on-boot: If present then BAM is enabled at bootup itself. + +A number of USB BAM pipe parameters are represented as sub-nodes: + +Subnode Required: +- label: a string describing uniquely the usb bam pipe. The string can be + constracted as follows: <core>-<peer>-<direction>-<pipe num>. + core options: hsusb, ssusb/dwc3, hsic + peer options: qdss, ipa + direction options: in (from peer to usb), out (from usb to peer) + pipe num options: 0..127 +- qcom,usb-bam-mem-type: Type of memory used by this PIPE. Can be one of + 0 - Uses SPS's dedicated pipe memory + 1 - System RAM allocated by driver + 2 - OCI memory residing @ 'qcom,usb-bam-fifo-baseaddr' +- qcom,dir: pipe direction + 0 - from usb (out) + 1 - to usb (in) +- qcom,pipe-num: pipe number +- qcom,peer-bam: peer BAM can be one of + 0 - QDSS_P_BAM + 1 - IPA_P_BAM +- qcom,data-fifo-size: data fifo size +- qcom,descriptor-fifo-size: descriptor fifo size + +Optional Properties for Subnode: +- qcom,peer-bam-physical-address: peer BAM's physical address. + Not specified for IPA and used only for qdss connection +- qcom,dst-bam-pipe-index: destination BAM pipe index +- qcom,src-bam-pipe-index: source BAM pipe index +- qcom,data-fifo-offset: data fifo offset address +- qcom,descriptor-fifo-offset: descriptor fifo offset address +- qcom,pipe-connection-type: type of pipe connection. Can be one of + 0 - BAM2BAM (default if not specified) + 1 - SYS2BAM (only supported on UL) + +Example USB BAM controller device node: + + qcom,usbbam@f9a44000 { + compatible = "qcom,usb-bam-msm"; + reg = <0xf9a44000 0x11000>; + interrupts = <0 135 0>; + qcom,usb-bam-num-pipes = <16>; + qcom,ignore-core-reset-ack; + qcom,disable-clk-gating; + qcom,usb-bam-max-mbps-highspeed = <400>; + qcom,usb-bam-max-mbps-superspeed = <3600>; + qcom,bam-type = <1>; + qcom,bam-mode = <0>; + + qcom,pipe0 { + label = "hsusb-ipa-out-0"; + qcom,usb-bam-mem-type = <0>; + qcom,dir = <0>; + qcom,pipe-num = <0>; + qcom,peer-bam = <2>; + qcom,src-bam-pipe-index = <1>; + qcom,data-fifo-offset = <0x2200>; + qcom,data-fifo-size = <0x1e00>; + qcom,descriptor-fifo-offset = <0x2100>; + qcom,descriptor-fifo-size = <0x100>; + }; + qcom,pipe1 { + label = "hsusb-ipa-in-0"; + qcom,usb-bam-mem-type = <0>; + qcom,dir = <1>; + qcom,pipe-num = <0>; + qcom,peer-bam = <2>; + qcom,dst-bam-pipe-index = <0>; + qcom,data-fifo-offset = <0x300>; + qcom,data-fifo-size = <0x1e00>; + qcom,descriptor-fifo-offset = <0>; + qcom,descriptor-fifo-size = <0x300>; + }; + }; + diff --git a/Documentation/devicetree/bindings/power/apm.txt b/Documentation/devicetree/bindings/power/apm.txt new file mode 100644 index 000000000000..fa03edfbb83c --- /dev/null +++ b/Documentation/devicetree/bindings/power/apm.txt @@ -0,0 +1,73 @@ +MSM Array Power Mux (msm-apm) + +In some MSM designs, the CPU and caches contain logic which can be powered by +multiple rails. The APM controller exists to enable the selection of the power +rail supplying these arrays. Since a given supply may drop below the array +SRAM minimum operating voltage, the APM controller can be used to request a +switch to a power supply that will guarantee logic state retention. + +Required properties +- compatible: "qcom,msm-apm", "qcom,msm8996pro-apm", "qcom,msm8953-apm" +- reg: Specifies physical base address and size of memory mapped regions + containing the APM controller, APCS CSR, APC PLL controller, and + SPM event registers. +- reg-names: List of strings identifying the reg property entries. This list must + contain: "pm-apcc-glb", "apcs-csr", "apc0-pll-ctl", "apc1-pll-ctl", + "apc0-cpu0-spm", "apc0-cpu1-spm", "apc1-cpu0-spm", "apc1-cpu1-spm", + "apc0-l2-spm", and "apc1-l2-spm". + +Optional properties +- qcom,clock-source-override: Specify this property to request a switch of the APC0 and APC1 + clock sources to GPLL0 before the APM switch begins and to + switch back to the original clock source after the APM switch + completes. +- qcom,apm-post-halt-delay: The APM controller post halt delay counter value that SW needs + to program one time before starting the APM HW controller for + msm8953 target. +- qcom,apm-halt-clk-delay: The APM controller halt clock delay counter value that SW + needs to program one time before starting the APM HW controller + for msm8953 target. +- qcom,apm-resume-clk-delay: The APM controller resume clock delay counter value that SW + needs to program one time before starting the APM HW controller + for msm8953 target. +- qcom,apm-sel-switch-delay: The APM controller switch selection delay counter value that SW + needs to program one time before starting the APM HW controller + for msm8953 target. + +MSM APM Users + +Required properties: +- qcom,apm-ctrl: phandle of APM controller device node + +Example: + apc_apm: apm@099e0000 { + compatible = "qcom,msm-apm"; + reg = <0x099e0000 0x1000>, + <0x09820000 0x10000>, + <0x06400050 0x8>, + <0x06480050 0x8>, + <0x09981068 0x8>, + <0x09991068 0x8>, + <0x099b1068 0x8>, + <0x099c1068 0x8>, + <0x099a1068 0x8>, + <0x099d1068 0x8>; + reg-names = "pm-apcc-glb", + "apcs-csr", + "apc0-pll-ctl", + "apc1-pll-ctl", + "apc0-cpu0-spm", + "apc0-cpu1-spm", + "apc1-cpu0-spm", + "apc1-cpu1-spm", + "apc0-l2-spm", + "apc1-l2-spm"; + qcom,apm-post-halt-delay = <0x2>; + qcom,apm-halt-clk-delay = <0x11>; + qcom,apm-resume-clk-delay = <0x10>; + qcom,apm-sel-switch-delay = <0x01>; + + foo_user { + ... + qcom,apm-ctrl = <&apc_apm>; + }; diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt new file mode 100644 index 000000000000..de34f27d509e --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt @@ -0,0 +1,25 @@ +Generic reboot mode core map driver + +This driver get reboot mode arguments and call the write +interface to store the magic value in special register +or ram. Then the bootloader can read it and take different +action according to the argument stored. + +All mode properties are vendor specific, it is a indication to tell +the bootloader what to do when the system reboots, and should be named +as mode-xxx = <magic> (xxx is mode name, magic should be a none-zero value). + +For example modes common on Android platform: +- mode-normal: Normal reboot mode, system reboot with command "reboot". +- mode-recovery: Android Recovery mode, it is a mode to format the device or update a new image. +- mode-bootloader: Android fastboot mode, it's a mode to re-flash partitions on the Android based device. +- mode-loader: A bootloader mode, it's a mode used to download image on Rockchip platform, + usually used in development. + +Example: + reboot-mode { + mode-normal = <BOOT_NORMAL>; + mode-recovery = <BOOT_RECOVERY>; + mode-bootloader = <BOOT_FASTBOOT>; + mode-loader = <BOOT_BL_DOWNLOAD>; + } diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt new file mode 100644 index 000000000000..f7ce1d8af04a --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt @@ -0,0 +1,35 @@ +SYSCON reboot mode driver + +This driver gets reboot mode magic value form reboot-mode driver +and stores it in a SYSCON mapped register. Then the bootloader +can read it and take different action according to the magic +value stored. + +This DT node should be represented as a sub-node of a "syscon", "simple-mfd" +node. + +Required properties: +- compatible: should be "syscon-reboot-mode" +- offset: offset in the register map for the storage register (in bytes) + +Optional property: +- mask: bits mask of the bits in the register to store the reboot mode magic value, + default set to 0xffffffff if missing. + +The rest of the properties should follow the generic reboot-mode description +found in reboot-mode.txt + +Example: + pmu: pmu@20004000 { + compatible = "rockchip,rk3066-pmu", "syscon", "simple-mfd"; + reg = <0x20004000 0x100>; + + reboot-mode { + compatible = "syscon-reboot-mode"; + offset = <0x40>; + mode-normal = <BOOT_NORMAL>; + mode-recovery = <BOOT_RECOVERY>; + mode-bootloader = <BOOT_FASTBOOT>; + mode-loader = <BOOT_BL_DOWNLOAD>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/qpnp-fg-gen3.txt b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-fg-gen3.txt new file mode 100644 index 000000000000..9638888ebc9e --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-fg-gen3.txt @@ -0,0 +1,422 @@ +Qualcomm Techonologies, Inc. QPNP PMIC Fuel Gauge Gen3 Device + +QPNP PMIC FG Gen3 device provides interface to the clients to read properties +related to the battery. Its main function is to retrieve the State of Charge +(SOC), in percentage scale representing the amount of charge left in the +battery. + +======================= +Required Node Structure +======================= + +FG Gen3 device must be described in two levels of device nodes. The first +level describes the FG Gen3 device. The second level describes one or more +peripherals managed by FG Gen3 driver. All the peripheral specific parameters +such as base address, interrupts etc., should be under second level node. + +==================================== +First Level Node - FG Gen3 device +==================================== + +- compatible + Usage: required + Value type: <string> + Definition: Should be "qcom,fg-gen3". + +- qcom,pmic-revid + Usage: required + Value type: <phandle> + Definition: Should specify the phandle of PMIC revid module. This is + used to identify the PMIC subtype. + +- io-channels +- io-channel-names + Usage: required + Value type: <phandle> + Definition: For details about IIO bindings see: + Documentation/devicetree/bindings/iio/iio-bindings.txt + +- qcom,rradc-base + Usage: required + Value type: <u32> + Definition: Should specify the base address of RR_ADC peripheral. This + is used for reading certain peripheral registers under it. + +- qcom,fg-cutoff-voltage + Usage: optional + Value type: <u32> + Definition: The voltage (in mV) where the fuel gauge will steer the SOC + to be zero. For example, if the cutoff voltage is set to + 3400mv, the fuel gauge will try to count SoC so that the + battery SOC will be 0 when it is 3400mV. If this property + is not specified, then the default value used will be + 3200mV. + +- qcom,fg-empty-voltage + Usage: optional + Value type: <u32> + Definition: The voltage threshold (in mV) based on which the empty soc + interrupt will be triggered. When the empty soc interrupt + fires, battery soc will be set to 0 and the userspace will + be notified via the power supply framework. The userspace + will read 0% soc and immediately shutdown. If this property + is not specified, then the default value used will be + 2800mV. + +- qcom,fg-vbatt-low-thr + Usage: optional + Value type: <u32> + Definition: The voltage threshold (in mV) which upon set will be used + for configuring the low battery voltage threshold. + +- qcom,fg-recharge-voltage + Usage: optional + Value type: <u32> + Definition: The voltage threshold (in mV) based on which the charging + will be resumed once the charging is complete. If this + property is not specified, then the default value will be + 4250mV. + +- qcom,fg-chg-term-current + Usage: optional + Value type: <u32> + Definition: Battery current (in mA) at which the fuel gauge will issue + an end of charge if the charger is configured to use the + fuel gauge ADC for end of charge detection. If this + property is not specified, then the default value used + will be 100mA. + +- qcom,fg-sys-term-current + Usage: optional + Value type: <u32> + Definition: Battery current (in mA) at which the fuel gauge will try to + scale towards 100%. When the charge current goes above this + the SOC should be at 100%. If this property is not + specified, then the default value used will be -125mA. + This value has to be specified in negative values for + the charging current. + +- qcom,fg-delta-soc-thr + Usage: optional + Value type: <u32> + Definition: Percentage of SOC increase upon which the delta monotonic & + battery SOC interrupts will be triggered. If this property + is not specified, then the default value will be 1. + Possible values are in the range of 0 to 12. + +- qcom,fg-recharge-soc-thr + Usage: optional + Value type: <u32> + Definition: Percentage of monotonic SOC upon which the charging will + will be resumed once the charging is complete. If this + property is not specified, then the default value will be + 95. + +- qcom,fg-rsense-sel + Usage: optional + Value type: <u32> + Definition: Specifies the source of sense resistor. + Allowed values are: + 0 - Rsense is from Battery FET + 2 - Rsense is Battery FET and SMB + Option 2 can be used only when a parallel charger is + present. If this property is not specified, then the + default value will be 2. + +- qcom,fg-jeita-thresholds + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which holds the jeita thresholds (degC) + in the following order. Allowed size is 4. + Element 0 - JEITA cold threshold + Element 1 - JEITA cool threshold + Element 2 - JEITA warm threshold + Element 3 - JEITA hot threshold + If these parameters are not specified, then the default + values used will be 0, 5, 45, 50. + +- qcom,fg-esr-timer-charging + Usage: optional + Value type: <u32> + Definition: Number of cycles between ESR pulses while the battery is + charging. + +- qcom,fg-esr-timer-awake + Usage: optional + Value type: <u32> + Definition: Number of cycles between ESR pulses while the system is + awake and the battery is discharging. + +- qcom,fg-esr-timer-asleep + Usage: optional + Value type: <u32> + Definition: Number of cycles between ESR pulses while the system is + asleep and the battery is discharging. This option requires + qcom,fg-esr-timer-awake to be defined. + +- qcom,cycle-counter-en + Usage: optional + Value type: <empty> + Definition: Enables the cycle counter feature. + +- qcom,fg-force-load-profile + Usage: optional + Value type: <empty> + Definition: If set, battery profile will be force loaded if the profile + loaded earlier by bootloader doesn't match with the profile + available in the device tree. + +- qcom,cl-start-capacity + Usage: optional + Value type: <u32> + Definition: Battery SOC threshold to start the capacity learning. + If this is not specified, then the default value used + will be 15. + +- qcom,cl-min-temp + Usage: optional + Value type: <u32> + Definition: Lower limit of battery temperature to start the capacity + learning. If this is not specified, then the default value + used will be 150. Unit is in decidegC. + +- qcom,cl-max-temp + Usage: optional + Value type: <u32> + Definition: Upper limit of battery temperature to start the capacity + learning. If this is not specified, then the default value + used will be 450 (45C). Unit is in decidegC. + +- qcom,cl-max-increment + Usage: optional + Value type: <u32> + Definition: Maximum capacity increment allowed per capacity learning + cycle. If this is not specified, then the default value + used will be 5 (0.5%). Unit is in decipercentage. + +- qcom,cl-max-decrement + Usage: optional + Value type: <u32> + Definition: Maximum capacity decrement allowed per capacity learning + cycle. If this is not specified, then the default value + used will be 100 (10%). Unit is in decipercentage. + +- qcom,cl-min-limit + Usage: optional + Value type: <u32> + Definition: Minimum limit that the capacity cannot go below in a + capacity learning cycle. If this is not specified, then + the default value is 0. Unit is in decipercentage. + +- qcom,cl-max-limit + Usage: optional + Value type: <u32> + Definition: Maximum limit that the capacity cannot go above in a + capacity learning cycle. If this is not specified, then + the default value is 0. Unit is in decipercentage. + +- qcom,battery-thermal-coefficients + Usage: optional + Value type: <u8> + Definition: Byte array of battery thermal coefficients. + This should be exactly 3 bytes in length. + +- qcom,fg-jeita-hyst-temp + Usage: optional + Value type: <u32> + Definition: Hysteresis applied to Jeita temperature comparison. + Possible values are: + 0 - No hysteresis + 1,2,3 - Value in Celsius. + +- qcom,fg-batt-temp-delta + Usage: optional + Value type: <u32> + Definition: Battery temperature delta interrupt threshold. Possible + values are: 2, 4, 6 and 10. Unit is in Kelvin. + +- qcom,hold-soc-while-full + Usage: optional + Value type: <empty> + Definition: A boolean property that when defined holds SOC at 100% when + the battery is full. + +- qcom,ki-coeff-soc-dischg + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of monotonic SOC threshold values to change the ki + coefficient for medium discharge current during discharge. + This should be defined in the ascending order and in the + range of 0-100. Array limit is set to 3. + +- qcom,ki-coeff-med-dischg + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of ki coefficient values for medium discharge current + during discharge. These values will be applied when the + monotonic SOC goes below the SOC threshold specified under + qcom,ki-coeff-soc-dischg. Array limit is set to 3. This + property should be specified if qcom,ki-coeff-soc-dischg + is specified to make it fully functional. Value has no + unit. Allowed range is 0 to 62200 in micro units. + +- qcom,ki-coeff-hi-dischg + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of ki coefficient values for high discharge current + during discharge. These values will be applied when the + monotonic SOC goes below the SOC threshold specified under + qcom,ki-coeff-soc-dischg. Array limit is set to 3. This + property should be specified if qcom,ki-coeff-soc-dischg + is specified to make it fully functional. Value has no + unit. Allowed range is 0 to 62200 in micro units. + +- qcom,fg-rconn-mohms + Usage: optional + Value type: <u32> + Definition: Battery connector resistance (Rconn) in milliohms. If Rconn + is specified, then ESR to Rslow scaling factors will be + updated to account it for an accurate ESR. + +- qcom,fg-esr-clamp-mohms + Usage: optional + Value type: <u32> + Definition: Equivalent series resistance (ESR) in milliohms. If this + is specified, then ESR will be clamped to this value when + ESR is found to be dropping below this. Default value is + 20. + +- qcom,fg-esr-filter-switch-temp + Usage: optional + Value type: <u32> + Definition: Battery temperature threshold below which low temperature + ESR filter coefficients will be switched to normal + temperature ESR filter coefficients. If this is not + specified, then the default value used will be 100. Unit is + in decidegC. + +- qcom,fg-esr-tight-filter-micro-pct + Usage: optional + Value type: <u32> + Definition: Value in micro percentage for ESR tight filter. If this is + not specified, then a default value of 3907 (0.39 %) will + be used. Lowest possible value is 1954 (0.19 %). + +- qcom,fg-esr-broad-filter-micro-pct + Usage: optional + Value type: <u32> + Definition: Value in micro percentage for ESR broad filter. If this is + not specified, then a default value of 99610 (9.96 %) will + be used. Lowest possible value is 1954 (0.19 %). + +- qcom,fg-esr-tight-lt-filter-micro-pct + Usage: optional + Value type: <u32> + Definition: Value in micro percentage for low temperature ESR tight + filter. If this is not specified, then a default value of + 48829 (4.88 %) will be used. Lowest possible value is 1954 + (0.19 %). + +- qcom,fg-esr-broad-lt-filter-micro-pct + Usage: optional + Value type: <u32> + Definition: Value in micro percentage for low temperature ESR broad + filter. If this is not specified, then a default value of + 148438 (14.84 %) will be used. Lowest possible value is + 1954 (0.19 %). + +- qcom,fg-auto-recharge-soc + Usage: optional + Value type: <empty> + Definition: A boolean property when defined will configure automatic + recharge SOC threshold. If not specified, automatic + recharge voltage threshold will be configured. This has + to be configured in conjunction with the charger side + configuration for proper functionality. + +- qcom,slope-limit-temp-threshold + Usage: optional + Value type: <u32> + Definition: Battery temperature threshold to decide when slope limit + coefficients should be applied along with charging status. + Unit is in decidegC. + +- qcom,slope-limit-coeffs + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which holds the slope limit coefficients + in the following order. Allowed size is 4. Possible values + are from 0 to 31. Unit is in decipercentage. + Element 0 - Low temperature discharging + Element 1 - Low temperature charging + Element 2 - High temperature discharging + Element 3 - High temperature charging + These coefficients have to be specified along with the + property "qcom,slope-limit-temp-threshold" to make dynamic + slope limit adjustment functional. + +========================================================== +Second Level Nodes - Peripherals managed by FG Gen3 driver +========================================================== +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the specified peripheral + +- interrupts + Usage: optional + Value type: <prop-encoded-array> + Definition: Interrupt mapping as per the interrupt encoding + +- interrupt-names + Usage: optional + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. + +======== +Example +======== + +pmi8998_fg: qpnp,fg { + compatible = "qcom,fg-gen3"; + #address-cells = <1>; + #size-cells = <1>; + qcom,pmic-revid = <&pmi8998_revid>; + io-channels = <&pmi8998_rradc 3>; + io-channel-names = "rradc_batt_id"; + qcom,rradc-base = <0x4500>; + qcom,ki-coeff-soc-dischg = <30 60 90>; + qcom,ki-coeff-med-dischg = <800 1000 1400>; + qcom,ki-coeff-hi-dischg = <1200 1500 2100>; + qcom,slope-limit-temp-threshold = <100>; + qcom,slope-limit-coeffs = <10 11 12 13>; + qcom,battery-thermal-coefficients = [9d 50 ff]; + status = "okay"; + + qcom,fg-batt-soc@4000 { + status = "okay"; + reg = <0x4000 0x100>; + interrupts = <0x2 0x40 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x40 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x40 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x2 0x40 0x3 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "soc-update", + "soc-ready", + "bsoc-delta", + "msoc-delta"; + + }; + + qcom,fg-batt-info@4100 { + status = "okay"; + reg = <0x4100 0x100>; + interrupts = <0x2 0x41 0x3 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "batt-missing"; + }; + + qcom,fg-memif@4400 { + status = "okay"; + reg = <0x4400 0x100>; + }; +}; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/qpnp-qnovo.txt b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-qnovo.txt new file mode 100644 index 000000000000..96b7dd517231 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-qnovo.txt @@ -0,0 +1,32 @@ +QPNP Qnovo pulse engine + +QPNP Qnovo is a pulse charging engine which works in tandem with the QPNP SMB2 +Charger device. It configures the QPNP SMB2 charger to charge/discharge as per +pulse characteristics. + +The QPNP Qnovo pulse engine has a single peripheral assigned to it. + +Required properties: +- compatible: Must be "qcom,qpnp-qnovo" +- qcom,pmic-revid: Should specify the phandle of PMIC + revid module. This is used to identify + the PMIC subtype. + +- reg: The address for this peripheral +- interrupts: Specifies the interrupt associated with the peripheral. +- interrupt-names: Specifies the interrupt name for the peripheral. Qnovo + peripheral has only one interrupt "ptrain-done". + +Optional Properties: +- qcom,external-rsense: To indicate whether the platform uses external or + internal rsense for measuring battery current. + +Example: + + qcom,qpnp-qnovo@1500 { + compatible = "qcom,qpnp-qnovo"; + reg = <0x1500 0x100>; + interrupts = <0x2 0x15 0x0 IRQ_TYPE_NONE>; + interrupt-names = "ptrain-done"; + qcom,pmic-revid = <&pmi8998_revid>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/qpnp-smb2.txt b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-smb2.txt new file mode 100644 index 000000000000..5a2c3ecd3d1e --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/qpnp-smb2.txt @@ -0,0 +1,315 @@ +Qualcomm Technologies, Inc. SMB2 Charger Specific Bindings + +SMB2 Charger is an efficient programmable battery charger capable of charging a +high-capacity lithium-ion battery over micro-USB or USB Type-C ultrafast with +Quick Charge 2.0, Quick Charge 3.0, and USB Power Delivery support. Wireless +charging features full A4WP Rezence 1.2, WPC 1.2, and PMA support. + +======================= +Required Node Structure +======================= + +SMB2 Charger must be described in two levels of devices nodes. + +=============================== +First Level Node - SMB2 Charger +=============================== + +Charger specific properties: +- compatible + Usage: required + Value type: <string> + Definition: "qcom,qpnp-smb2". + +- qcom,pmic-revid + Usage: required + Value type: phandle + Definition: Should specify the phandle of PMI's revid module. This is used to + identify the PMI subtype. + +- qcom,batteryless-platform + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the platform does not have a + battery, and therefore charging should be disabled. In + addition battery properties will be faked such that the device + assumes normal operation. + +- qcom,external-vconn + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates VCONN is sourced externally. + +- qcom,fcc-max-ua + Usage: optional + Value type: <u32> + Definition: Specifies the maximum fast charge current in micro-amps. + If the value is not present, 1Amp is used as default. + +- qcom,fv-max-uv + Usage: optional + Value type: <u32> + Definition: Specifies the maximum float voltage in micro-volts. + If the value is not present, 4.35V is used as default. + +- qcom,usb-icl-ua + Usage: optional + Value type: <u32> + Definition: Specifies the USB input current limit in micro-amps. + If the value is not present, 1.5Amps is used as default. + +- qcom,usb-ocl-ua + Usage: optional + Value type: <u32> + Definition: Specifies the OTG output current limit in micro-amps. + If the value is not present, 1.5Amps is used as default + +- qcom,dc-icl-ua + Usage: optional + Value type: <u32> + Definition: Specifies the DC input current limit in micro-amps. + +- qcom,boost-threshold-ua + Usage: optional + Value type: <u32> + Definition: Specifies the boost current threshold in micro-amps. + If the value is not present, 100mA is used as default. + +- qcom,wipower-max-uw + Usage: optional + Value type: <u32> + Definition: Specifies the DC input power limit in micro-watts. + If the value is not present, 8W is used as default. + +- qcom,thermal-mitigation + Usage: optional + Value type: Array of <u32> + Definition: Array of fast charge current limit values for + different system thermal mitigation levels. + This should be a flat array that denotes the + maximum charge current in mA for each thermal + level. + +- qcom,step-soc-thresholds + Usage: optional + Value type: Array of <u32> + Definition: Array of SOC threshold values, size of 4. This should be a + flat array that denotes the percentage ranging from 0 to 100. + If the array is not present, step charging is disabled. + +- qcom,step-current-deltas + Usage: optional + Value type: Array of <s32> + Definition: Array of delta values for charging current, size of 5, with + FCC as base. This should be a flat array that denotes the + offset of charging current in uA, from -3100000 to 3200000. + If the array is not present, step charging is disabled. + +- io-channels + Usage: optional + Value type: List of <phandle u32> + Definition: List of phandle and IIO specifier pairs, one pair + for each IIO input to the device. Note: if the + IIO provider specifies '0' for #io-channel-cells, + then only the phandle portion of the pair will appear. + +- io-channel-names + Usage: optional + Value type: List of <string> + Definition: List of IIO input name strings sorted in the same + order as the io-channels property. Consumer drivers + will use io-channel-names to match IIO input names + with IIO specifiers. + +- qcom,float-option + Usage: optional + Value type: <u32> + Definition: Configures how the charger behaves when a float charger is + detected by APSD + 1 - Treat as a DCP + 2 - Treat as a SDP + 3 - Disable charging + 4 - Suspend USB input + +- qcom,hvdcp-disable + Usage: optional + Value type: <empty> + Definition: Specifies if hvdcp charging is to be enabled or not. + If this property is not specified hvdcp will be enabled. + If this property is specified, hvdcp 2.0 detection will still + happen but the adapter won't be asked to switch to a higher + voltage point. + +- qcom,chg-inhibit-threshold-mv + Usage: optional + Value type: <u32> + Definition: Charge inhibit threshold in milli-volts. Charging will be + inhibited when the battery voltage is within this threshold + from Vfloat at charger insertion. If this is not specified + then charge inhibit will be disabled by default. + Allowed values are: 50, 100, 200, 300. + +- qcom,auto-recharge-soc + Usage: optional + Value type: <empty> + Definition: Specifies if automatic recharge needs to be based off battery + SOC. If this property is not specified, then auto recharge will + be based off battery voltage. For both SOC and battery voltage, + charger receives the signal from FG to resume charging. + +- qcom,micro-usb + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the platform only support + micro usb port. + +- qcom,suspend-input-on-debug-batt + Usage: optional + Value type: <empty> + Definition: Boolean flag which when present enables intput suspend for + debug battery. + +============================================= +Second Level Nodes - SMB2 Charger Peripherals +============================================= + +Peripheral specific properties: +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Address and size of the peripheral's register block. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: Peripheral interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. + +======= +Example +======= + +pmi8998_charger: qcom,qpnp-smb2 { + compatible = "qcom,qpnp-smb2"; + #address-cells = <1>; + #size-cells = <1>; + + io-channels = <&pmic_rradc 0>; + io-channel-names = "rradc_batt_id"; + + dpdm-supply = <&qusb_phy0>; + + qcom,step-soc-thresholds = <60 70 80 90>; + qcom,step-current-deltas = <500000 250000 150000 0 (-150000)>; + + qcom,chgr@1000 { + reg = <0x1000 0x100>; + interrupts = <0x2 0x10 0x0 IRQ_TYPE_NONE>, + <0x2 0x10 0x1 IRQ_TYPE_NONE>, + <0x2 0x10 0x2 IRQ_TYPE_NONE>, + <0x2 0x10 0x3 IRQ_TYPE_NONE>, + <0x2 0x10 0x4 IRQ_TYPE_NONE>; + + interrupt-names = "chg-error", + "chg-state-change", + "step-chg-state-change", + "step-chg-soc-update-fail", + "step-chg-soc-update-request"; + }; + + qcom,otg@1100 { + reg = <0x1100 0x100>; + interrupts = <0x2 0x11 0x0 IRQ_TYPE_NONE>, + <0x2 0x11 0x1 IRQ_TYPE_NONE>, + <0x2 0x11 0x2 IRQ_TYPE_NONE>, + <0x2 0x11 0x3 IRQ_TYPE_NONE>; + + interrupt-names = "otg-fail", + "otg-overcurrent", + "otg-oc-dis-sw-sts", + "testmode-change-detect"; + }; + + qcom,bat-if@1200 { + reg = <0x1200 0x100>; + interrupts = <0x2 0x12 0x0 IRQ_TYPE_NONE>, + <0x2 0x12 0x1 IRQ_TYPE_NONE>, + <0x2 0x12 0x2 IRQ_TYPE_NONE>, + <0x2 0x12 0x3 IRQ_TYPE_NONE>, + <0x2 0x12 0x4 IRQ_TYPE_NONE>, + <0x2 0x12 0x5 IRQ_TYPE_NONE>; + + interrupt-names = "bat-temp", + "bat-ocp", + "bat-ov", + "bat-low", + "bat-therm-or-id-missing", + "bat-terminal-missing"; + }; + + qcom,usb-chgpth@1300 { + reg = <0x1300 0x100>; + interrupts = <0x2 0x13 0x0 IRQ_TYPE_NONE>, + <0x2 0x13 0x1 IRQ_TYPE_NONE>, + <0x2 0x13 0x2 IRQ_TYPE_NONE>, + <0x2 0x13 0x3 IRQ_TYPE_NONE>, + <0x2 0x13 0x4 IRQ_TYPE_NONE>, + <0x2 0x13 0x5 IRQ_TYPE_NONE>, + <0x2 0x13 0x6 IRQ_TYPE_NONE>, + <0x2 0x13 0x7 IRQ_TYPE_NONE>; + + interrupt-names = "usbin-collapse", + "usbin-lt-3p6v", + "usbin-uv", + "usbin-ov", + "usbin-plugin", + "usbin-src-change", + "usbin-icl-change", + "type-c-change"; + }; + + qcom,dc-chgpth@1400 { + reg = <0x1400 0x100>; + interrupts = <0x2 0x14 0x0 IRQ_TYPE_NONE>, + <0x2 0x14 0x1 IRQ_TYPE_NONE>, + <0x2 0x14 0x2 IRQ_TYPE_NONE>, + <0x2 0x14 0x3 IRQ_TYPE_NONE>, + <0x2 0x14 0x4 IRQ_TYPE_NONE>, + <0x2 0x14 0x5 IRQ_TYPE_NONE>, + <0x2 0x14 0x6 IRQ_TYPE_NONE>; + + interrupt-names = "dcin-collapse", + "dcin-lt-3p6v", + "dcin-uv", + "dcin-ov", + "dcin-plugin", + "div2-en-dg", + "dcin-icl-change"; + }; + + qcom,chgr-misc@1600 { + reg = <0x1600 0x100>; + interrupts = <0x2 0x16 0x0 IRQ_TYPE_NONE>, + <0x2 0x16 0x1 IRQ_TYPE_NONE>, + <0x2 0x16 0x2 IRQ_TYPE_NONE>, + <0x2 0x16 0x3 IRQ_TYPE_NONE>, + <0x2 0x16 0x4 IRQ_TYPE_NONE>, + <0x2 0x16 0x5 IRQ_TYPE_NONE>, + <0x2 0x16 0x6 IRQ_TYPE_NONE>, + <0x2 0x16 0x7 IRQ_TYPE_NONE>; + + interrupt-names = "wdog-snarl", + "wdog-bark", + "aicl-fail", + "aicl-done", + "high-duty-cycle", + "input-current-limiting", + "temperature-change", + "switcher-power-ok"; + }; +}; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/smb1351-charger.txt b/Documentation/devicetree/bindings/power/supply/qcom/smb1351-charger.txt new file mode 100644 index 000000000000..c200f9423384 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/smb1351-charger.txt @@ -0,0 +1,115 @@ +Summit smb1351 battery charger + +SMB1351 is a single-cell battery charger. It can charge +the battery and power the system via the USB/AC adapter input. + +The smb1351 interface is via I2C bus. + +Required Properties: +- compatible Must be "qcom,smb1351-charger". +- reg The device 7-bit I2C address. + +Required Properties for standalone charger: +- regulator-name A string used as a descriptive name for OTG regulator. +- pinctrl-names The state name of the pin configuration. Only + support "default". +- pinctrl-0 The phandle of the pin configuration node in + pinctrl for smb_int_pin. + +Optional Properties: + +- interrupts This indicates the IRQ number of the GPIO + connected to the STAT pin. +- qcom,fastchg-current-max-ma Fast Charging current in mA. Supported range is + from 1000mA to 4500mA. +- qcom,chg-autonomous-mode This is a bool property and it indicates that the + charger is configured for autonomous operation and + does not require any software configuration. +- qcom,disable-apsd This is a bool property which disables automatic + power source detection (APSD). If this is set + charger detection is done by DCIN UV irq. +- qcom,charging-disabled This is a bool property which disables charging. +- qcom,using-pmic-therm This property indicates thermal pin connected to pmic or smb. +- qcom,bms-psy-name This is a string and it points to the bms + power supply name. +- qcom,iterm-ma Specifies the termination current to indicate end-of-charge. + Possible values in mA - 70, 100, 200, 300, 400, 500, 600, 700. +- qcom,iterm-disabled Disables the termination current feature. This is a bool + property. +- qcom,float-voltage-mv Float Voltage in mV - the maximum voltage up to which + the battery is charged. Supported range 3500mV to 4500mV +- qcom,recharge-mv Recharge threshold in mV - the offset from the float-volatge + as which the charger restarts charging. Possible + values are 50mV and 100mV. +- qcom,recharge-disabled Boolean value which disables the auto-recharge. +- qcom,bms-controlled-charging This property enables BMS to control EOC and + recharge. BMS and charger communicates with each + other via power_supply framework. This + property should be used with 'qcom,iterm-disabled' + to ensure EOC detection in charger is disabled. +- qcom,force-hvdcp-2p0 Boolean value which allows to force hvdcp working on 2.0 mode. +- qcom,parallel-charger Boolean value which enables the parallel charger. +- qcom,chg-vadc Corresponding VADC device's phandle. +- qcom,chg-adc_tm phandle to the corresponding VADC device to read the ADC channels. +- qcom,batt-cold-decidegc Cold battery temperature in decidegC. +- qcom,batt-hot-decidegc Hot battery temperature in decidegC. +- qcom,batt-missing-decidegc This is a property indicating battery missing temperature, if + higher than it, battery should exist. +- qcom,batt-warm-decidegc: Warm battery temperature in decidegC. After hitting this threshold, + "qcom,warm-bat-ma" defines maximum charging current and + "qcom,warm-bat-mv" defines maximum target voltage. +- qcom,batt-cool-decidegc: Cool battery temperature in decidegC. After hitting this threshold, + "qcom,cool-bat-ma" defines maximum charging current and + "qcom,cool-bat-mv" defines maximum target voltage. +- qcom,batt-warm-ma: Maximum warm battery charge current in milli-amps. +- qcom,batt-cool-ma: Maximum cool battery charge current in milli-amps. +- qcom,batt-warm-mv: Maximum warm battery target voltage in milli-volts. +- qcom,batt-cool-mv: Maximum cool battery target voltage in milli-volts. +- qcom,parallel-en-pin-polarity Specify the polarity of enable signal controlled + via pin in a parallel-charger configuration. + 0 - Active low and 1 - Active high. + If not specified the default value is active-low. +- qcom,parallel-external-current-sense If present specifies external rsense is + used for charge current sensing. + +Example for standalone charger: + +&i2c_4 { + smb1351_otg_supply: smb1351-charger@57 { + compatible = "qcom,smb1351-charger"; + reg = <0x57>; + interrupt-parent = <&msm_gpio>; + interrupts = <62 2>; + pinctrl-names = "default"; + pinctrl-0 = <&smb_int_default>; + qcom,float-voltage-mv = <4350>; + qcom,iterm-ma = <100>; + qcom,recharge-mv = <100>; + qcom,bms-psy-name = "bms"; + regulator-name = "smb1351_otg_vreg"; + qcom,using-pmic-therm; + qcom,chg-adc_tm = <&pm8916_adc_tm>; + qcom,chg-vadc = <&pm8916_vadc>; + qcom,batt-hot-decidegc = <550>; + qcom,batt-cold-decidegc = <0>; + qcom,batt-missing-decidegc = <(-200)>; + qcom,batt-warm-decidegc = <500>; + qcom,batt-cool-decidegc = <50>; + qcom,batt-warm-ma = <350>; + qcom,batt-cool-ma = <350>; + qcom,batt-warm-mv = <4200>; + qcom,batt-cool-mv = <4200>; + }; +}; + +Example for parallel charger: + +&i2c_11 { + smb1351-charger@1d { + compatible = "qcom,smb1351-charger"; + reg = <0x1d>; + qcom,parallel-charger; + qcom,float-voltage-mv = <4400>; + qcom,recharge-mv = <100>; + }; +}; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/smb135x-charger.txt b/Documentation/devicetree/bindings/power/supply/qcom/smb135x-charger.txt new file mode 100644 index 000000000000..3eff91a1d112 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/smb135x-charger.txt @@ -0,0 +1,101 @@ +SMB135x battery charger + +SMB135x is a single-cell switching mode battery charger. It can charge +the battery and power the system via the USB and AC adapter input. + +The smb135x interface is via I2C bus. + +Required Properties: +- compatible: Must be "qcom,smb1357-charger", "qcom,smb1358-charger" + or "qcom,smb1359-charger". +- reg: The device 7-bit I2C address. + +Optional Properties: + +- interrupts This indicates the IRQ number of the GPIO + connected to the STAT pin. +- qcom,bms-psy-name the psy name to use for reporting battery capacity. If left + unspecified it uses a preprogrammed default value. +- qcom,float-voltage-mv Float Voltage in mV - the maximum voltage up to which + the battery is charged. Supported range 3600mV to 4500mV +- qcom,charging-timeout Maximum duration in minutes that a single charge + cycle may last. Supported values are: 0, 192, 384, + 768, and 1536. A value of 0 means that no + charge cycle timeout is used and charging can + continue indefinitely. +- qcom,dc-psy-type The type of charger connected to the DC path. + Can be "Mains" or "Wireless" +- qcom,dc-psy-ma The current in mA dc path can support. Must be specified if + dc-psy-type is specified. Valid range 300mA to 2000mA. +- qcom,charging-disabled Set this if charging should be disabled in the build + by default. Useful in usecases where battery current + needs to be profiled even when USB is present. +- qcom,recharge-thresh-mv Specifies the minimum voltage drop in millivolts + below the float voltage that is required in + order to initiate a new charging cycle. + Supported values are: 50, 100, 200 and 300mV. +- qcom,bmd-algo-disabled Indicates if the battery missing detection algorithm + is disabled. If this node is present SMB uses + the THERM pin for battery missing detection. +- qcom,iterm-ma Specifies the termination current to indicate end-of-charge. + Possible values in mA - 50, 100, 150, 200, 250, 300, 500, 600. +- qcom,iterm-disabled Disables the termination current feature. This is a bool + property. +- qcom,soft-vfloat-comp-disabled Set this property when the battery is powered via external + source and could go above the float voltage. smb135x chips + go in to unintentional reverse boost in such a situation and + the float voltage compensation needs to be disabled to avoid + that reverse boost. +- qcom,soft-current-comp-disabled Set this property to disable charging current compensation + if battery temperature exceeds soft JEITA thresholds. +- qcom,gamma-setting Array of gamma values for JEITA. The sequence is + <"Cold Hard" "Hot Hard" "Cold Soft" "Hot Soft">. Gamma value + indicates the ratio of the pull up resistors and NTC + resistor in battery pack. There are 4 options refering to + the graphic user interface. +- qcom,thermal-mitigation: Array of input current limit values for different + system thermal mitigation level. +- regulator-name A string used as a descriptive name for OTG regulator. +- therm-bias-supply The supply that provides bias voltage to the battery + thermistor. This is useful in designs that do not use the SYSON + pin to bias the thermistor. +- usb-pullup-supply The supply regulator that act as pull-up for USB data lines. +- qcom,parallel-charger: A flag to indicate if the charger merely assists for USB + charging. In this case the input current from USB is split + between a main charger and smb135x for reducing thermal impact + of high current charging from USB path. +- qcom,inhibit-disabled: Disables the charger-inhibit function. +- qcom,bms-controlled-charging: This property enables BMS to control EOC and + recharge. BMS and charger communicates with each + other via power_supply framework. This + property should be used with 'qcom,iterm-disabled' + to ensure EOC detection in charger is + disabled. +- qcom,fastchg-ma: Specifies the maximum fastcharge current. + The possible range for fastcharge current is + from 300mA to 3000mA. +- qcom,id-line-not-connected: Specifies if smb135x charger is not monitoring the USB_ID line. +- qcom,parallel-en-pin-polarity Specify the polarity of enable signal controlled + via pin in a parallel-charger configuration. + 0 - Active low and 1 - Active high. + If not specified the default value is active-low. + +Example: + i2c@f9967000 { + smb1357-charger@1b { + compatible = "qcom,smb1357-charger"; + reg = <0x1b>; + interrupt-parent = <&spmi_bus>; + interrupts = <0x00 0xCD 0>; + qcom,float-voltage-mv = <4200>; + qcom,iterm-ma = <100>; + qcom,dc-psy-type = <8>; + qcom,dc-psy-ma = <800>; + qcom,charging-disabled; + qcom,recharge-thresh-mv = <100>; + regulator-name = "smb1357-otg"; + qcom,thermal-mitigation = <1500 700 600 325>; + qcom,gamma-setting = <3 2 0 2>; + qcom,fastchg-ma = <3000>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/qcom/smb138x-charger.txt b/Documentation/devicetree/bindings/power/supply/qcom/smb138x-charger.txt new file mode 100644 index 000000000000..c8f2a5a8e496 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/qcom/smb138x-charger.txt @@ -0,0 +1,234 @@ +Qualcomm Technologies, Inc. SMB138X Charger Specific Bindings + +SMB138X Charger is an efficient programmable battery charger capable of charging +a high-capacity lithium-ion battery over micro-USB or USB Type-C ultrafast with +Quick Charge 2.0, Quick Charge 3.0 support. Wireless charging features full +A4WP Rezence 1.2, WPC 1.2, and PMA support. + +======================= +Required Node Structure +======================= + +SMB138X Charger must be described in two levels of devices nodes. + +================================== +First Level Node - SMB138X Charger +================================== + +Charger specific properties: +- compatible + Usage: required + Value type: <string> + Definition: String which indicates the charging mode. Can be one of the + following: + Standalone/Parallel Master - "qcom,smb138x-charger" + Parallel Slave - "qcom,smb138x-parallel-slave" + +- qcom,pmic-revid + Usage: required + Value type: phandle + Definition: Should specify the phandle of SMB's + revid module. This is used to identify + the SMB subtype. + +- qcom,suspend-input + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the charger should not draw + current from any of its input sources (USB, DC). + +- qcom,fcc-max-ua + Usage: optional + Value type: <u32> + Definition: Specifies the maximum fast charge current in micro-amps. + +- qcom,usb-icl-ua + Usage: optional + Value type: <u32> + Definition: Specifies the USB input current limit in micro-amps. + +- qcom,dc-icl-ua + Usage: optional + Value type: <u32> + Definition: Specifies the DC input current limit in micro-amps. + +- qcom,charger-temp-max-mdegc + Usage: optional + Value type: <u32> + Definition: Specifies the maximum charger temperature in milli-degrees + Celsius. If unspecified a default of 80000 will be used. + +- qcom,connector-temp-max-mdegc + Usage: optional + Value type: <u32> + Definition: Specifies the maximum connector temperature in milli-degrees + Celsius. If unspecified a default value of 105000 will be used. + +- io-channels + Usage: optional + Value type: List of <phandle u32> + Definition: List of phandle and IIO specifier pairs, one pair + for each IIO input to the device. Note: if the + IIO provider specifies '0' for #io-channel-cells, + then only the phandle portion of the pair will appear. + +- io-channel-names + Usage: optional + Value type: List of <string> + Definition: List of IIO input name strings sorted in the same + order as the io-channels property. Consumer drivers + will use io-channel-names to match IIO input names + with IIO specifiers. + +================================================ +Second Level Nodes - SMB138X Charger Peripherals +================================================ + +Peripheral specific properties: +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Address and size of the peripheral's register block. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: Peripheral interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. + +======================================= +Second Level Nodes - SMB138X Regulators +======================================= + +The following regulator nodes are supported: +"qcom,smb138x-vbus" - Regulator for enabling VBUS +"qcom,smb138x-vconn" - Regulator for enabling VCONN + +- regulator-name + Usage: required + Value type: <string> + Definition: Specifies the name for this regulator. + +======= +Example +======= + +smb138x_charger: qcom,smb138x-charger { + compatible = "qcom,qpnp-smb138x-charger"; + #address-cells = <1>; + #size-cells = <1>; + + qcom,suspend-input; + dpdm-supply = <&qusb_phy0>; + + qcom,chgr@1000 { + reg = <0x1000 0x100>; + interrupts = <0x10 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x10 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x10 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x10 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x10 0x4 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "chg-error", + "chg-state-change", + "step-chg-state-change", + "step-chg-soc-update-fail", + "step-chg-soc-update-request"; + }; + + qcom,otg@1100 { + reg = <0x1100 0x100>; + interrupts = <0x11 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x11 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x11 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x11 0x3 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "otg-fail", + "otg-overcurrent", + "otg-oc-dis-sw-sts", + "testmode-change-detect"; + }; + + qcom,bat-if@1200 { + reg = <0x1200 0x100>; + interrupts = <0x12 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x12 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x12 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x12 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x12 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x12 0x5 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "bat-temp", + "bat-ocp", + "bat-ov", + "bat-low", + "bat-therm-or-id-missing", + "bat-terminal-missing"; + }; + + qcom,usb-chgpth@1300 { + reg = <0x1300 0x100>; + interrupts = <0x13 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x5 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x6 IRQ_TYPE_EDGE_BOTH>, + <0x13 0x7 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "usbin-collapse", + "usbin-lt-3p6v", + "usbin-uv", + "usbin-ov", + "usbin-plugin", + "usbin-src-change", + "usbin-icl-change", + "type-c-change"; + }; + + qcom,dc-chgpth@1400 { + reg = <0x1400 0x100>; + interrupts = <0x14 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x5 IRQ_TYPE_EDGE_BOTH>, + <0x14 0x6 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "dcin-collapse", + "dcin-lt-3p6v", + "dcin-uv", + "dcin-ov", + "dcin-plugin", + "div2-en-dg", + "dcin-icl-change"; + }; + + qcom,chgr-misc@1600 { + reg = <0x1600 0x100>; + interrupts = <0x16 0x0 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x1 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x2 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x3 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x4 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x5 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x6 IRQ_TYPE_EDGE_BOTH>, + <0x16 0x7 IRQ_TYPE_EDGE_BOTH>; + + interrupt-names = "wdog-snarl", + "wdog-bark", + "aicl-fail", + "aicl-done", + "high-duty-cycle", + "input-current-limiting", + "temperature-change", + "switcher-power-ok"; + }; +}; diff --git a/Documentation/devicetree/bindings/power_supply/msm-poweroff.txt b/Documentation/devicetree/bindings/power_supply/msm-poweroff.txt index ce44ad357565..f19a92d765ef 100644 --- a/Documentation/devicetree/bindings/power_supply/msm-poweroff.txt +++ b/Documentation/devicetree/bindings/power_supply/msm-poweroff.txt @@ -8,6 +8,19 @@ settings. Required Properties: -compatible: "qcom,pshold" -reg: Specifies the physical address of the ps-hold register + This value must correspond to "pshold-base" as defined in reg-names +-reg-names: must contain "pshold-base" + may also contain "tcsr-boot-misc-detect" + +Optional Properties: +-reg: A secondary reg address/size pair may be provided, to specify the address + of the TCSR_BOOT_MISC_DETECT register. This address is typically used to + configure the type of reset desired. Omitting this address implies that + the reset type shall be configured by means of a call to the secure + environment. This value must correspond to "tcsr-boot-misc-detect" as + defined in reg-names +-reg-names: must contain "tcsr-boot-misc-detect" if the secondary address/size + pair described above is defined. Example: diff --git a/Documentation/devicetree/bindings/prng/msm-rng.txt b/Documentation/devicetree/bindings/prng/msm-rng.txt new file mode 100644 index 000000000000..917c2fb58a3f --- /dev/null +++ b/Documentation/devicetree/bindings/prng/msm-rng.txt @@ -0,0 +1,18 @@ +* RNG (Random Number Generator) + +Required properties: +- compatible : Should be "qcom,msm-rng" +- reg : Offset and length of the register set for the device + +Optional property: +- qcom,msm-rng-iface-clk : If the device uses iface-clk. +- qcom,no-qrng-config : Flag to decide whether the driver do the hardware configuration or not. + +Example: + + qcom,msm-rng@f9bff000 { + compatible = "qcom,msm-rng"; + reg = <0xf9bff000 0x200>; + qcom,msm-rng-iface-clk; + qcom,no-qrng-config; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-qpnp.txt b/Documentation/devicetree/bindings/pwm/pwm-qpnp.txt new file mode 100644 index 000000000000..8cb513b5605f --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-qpnp.txt @@ -0,0 +1,219 @@ +Qualcomm Technologies, Inc. QPNP PWM/LPG controller + +qpnp-pwm driver supports Pulse Width Module (PWM) functionality. PWM feature is +used in range of applications such as varying Display brightness, LED dimming, +etc. QTI PMICs have a physical device called Light Pulse Generator (LPG). In +addition to support PWM functionality, the LPG module provides a rich set of +user defined PWM pattern configurations, such as sawtooth, linear up, linear +down, triangular patterns etc. The PWM patterns are used in applications such as +charger driver where the driver uses these patterns to indicate various states +of charging. + +Required device bindings: +- compatible: should be "qcom,qpnp-pwm" +- reg: Offset and length of the controller's LPG channel register. +- reg-names: Name for the above register. + "qpnp-lpg-channel-base" = physical base address of the + controller's LPG channel register. +- qcom,lpg-lut-size: LPG LUT size. +- qcom,channel-id: channel Id for the PWM. +- qcom,supported-sizes: Supported PWM sizes. + Following three pwm sizes lists are supported by PWM/LPG controllers. + <6>, <9>; + <7>, <8>; + <6>, <7>, <9>; +- qcom,ramp-index: Ramp index in LUT ramp control register. + Each LPG has an index in the LUT ramp control register. + One exception is that, if LPG does not support LUT mode + and supports only PWM mode then there is no need to + provide the ramp-index. + +Optional device bindings: +- qcom,force-pwm-size: For certain LPG channels, PWM size can be forced. + Possible values 6, 7, 8 and 9. +- qcom,channel-owner: A string value to supply owner information. +- qcom,mode-select: 0 = PWM mode + 1 = LPG mode +- qcom,dtest-line: indicates which DTEST line to be configured for LPG + or PWM output. For LPG subtypes, possible values are 1, + 2, 3 and 4. For PWM subtype, possibe values are 1 and 2. +- qcom,dtest-output: indicates the output configuration for DTEST line. + For LPG subtypes, possible output values are: + 0 = Disabled + 1 = LPG output low + 2 = LPG output high + 3,4,5 = DTEST line specific configuration + 6,7 = Not used + For PWM subtype, possible output values are: + 0 = Disabled + 1 = pwm_out for DTEST1 or reserved + 2 = pwm_out for DTEST2 or reserved + 3 = Not used +If this binding is specified along with the required bindings of PWM/LPG then +in addition to configure PWM/LPG the qpnp-pwm driver also enables the feature +at the probe time. In the case where the binding is not specified the qpnp-pwm +driver does not enable the feature. Also, it is considered an error to specify +a particular mode using this binding but not the respective feature subnode. + +All PWM devices support both PWM and LPG features within the same device. +To support each feature, there are some required and optional bindings passed +through device tree. + +The PWM device can enable one feature (either PWM or LPG) at any given time. +Therefore, the qpnp-pwm driver applies the last PWM or LPG feature configuration +and enables that feature. + +Required bindings to support PWM feature: +- qcom,period: PWM period time in microseconds. +- qcom,duty: PWM duty time in microseconds. +- label: "pwm" + +Required bindings to support LPG feature: +The following bindings are needed to configure LPG mode, where a list of +duty cycle percentages is populated. The size of the list cannot exceed +the size of the LPG look-up table. + +- reg: Offset and length of LPG look-up table (LUT). The LPG look-up table is a + contiguous address space that is populated with PWM values. + The size of PWM value is 9 bit and the size of each + entry of the table is 8 bit. Thus, two entries are used + to fill each PWM value. The lower entry is used for PWM + LSB byte and higher entry is used for PWM MSB bit. +- reg-names: Name for the above register. + "qpnp-lpg-lut-base" = physical base address of LPG LUT. +- qcom,period: PWM period time in microseconds. +- qcom,duty-percents: List of entries for look-up table +- cell-index: Index of look-up table that should be used to start + filling up the duty-pct list. start-idx + size of list + cannot exceed the size of look-up table. +- label: "lpg" + + +Optional bindings to support LPG feature: +- qcom,ramp-step-duration: Time (in ms) to wait before loading next entry of LUT +- qcom,lpg-lut-pause-hi: Time (in ms) to wait once pattern reaches to hi + index. +- qcom,lpg-lut-pause-lo: Time (in ms) to wait once pattern reaches to lo + index. +- qcom,lpg-lut-ramp-direction: 1 = Start the pattern from lo index to hi index. + 0 = Start the pattern from hi index to lo index. +- qcom,lpg-lut-pattern-repeat: 1 = Repeat the pattern after the pause once it + reaches to last duty cycle. + 0 = Do not repeat the pattern. +- qcom,lpg-lut-ramp-toggle: 1 = Toggle the direction of the pattern. + 0 = Do not toggle the direction. +- qcom,lpg-lut-enable-pause-hi: 1 = Enable pause time at hi index. + 0 = Disable pause time at hi index. +- qcom,lpg-lut-enable-pause-lo: 1 = Enable pause time at lo index. + 0 = Disable pause time at lo index. + + +Example: + qcom,spmi@fc4c0000 { + #address-cells = <1>; + #size-cells = <0>; + + qcom,pm8941@1 { + spmi-slave-container; + reg = <0x1>; + #address-cells = <1>; + #size-cells = <1>; + + pwm@b100 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qpnp-pwm"; + reg = <0xb100 0x100>, <0xb040 0x80>; + reg-names = "qpnp-lpg-channel-base", "qpnp-lpg-lut-base"; + qcom,channel-id = <0>; + qcom,supported-sizes = <6>, <7>, <9>; + qcom,ramp-index = <0>; + status = "okay"; + }; + + pwm@b200 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qpnp-pwm"; + reg = <0xb200 0x100>, <0xb040 0x80>; + reg-names = "qpnp-lpg-channel-base", "qpnp-lpg-lut-base"; + qcom,channel-id = <1>; + qcom,supported-sizes = <6>, <7>, <9>; + qcom,ramp-index = <1>; + qcom,force-pwm-size = <9>; + qcom,period = <6000000>; + status = "okay"; + + qcom,pwm { + qcom,duty = <4000000>; + label = "pwm"; + }; + }; + + pwm@b500 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qpnp-pwm" + reg = <0xb500 0x100>, <0xb040 0x80>; + reg-names = "qpnp-lpg-channel-base", "qpnp-lpg-lut-base"; + qcom,channel-id = <4>; + qcom,supported-sizes = <6>, <7>, <9>; + qcom,ramp-index = <4>; + qcom,period = <6000000>; + qcom,mode-select = <0>; + qcom,channel-owner = "RGB-led"; + status = "okay"; + + qcom,pwm { + qcom,duty = <4000000>; + label = "pwm"; + }; + + qcom,lpg { + qcom,duty-percents = <1 14 28 42 56 84 100 + 100 84 56 42 28 14 1>; + cell-index = <0>; + qcom,ramp-step-duration = <20>; + label = "lpg"; + }; + }; + + pwm@b300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qpnp-pwm"; + reg = <0xb200 0x100>, <0xb040 0x80>; + reg-names = "qpnp-lpg-channel-base", "qpnp-lpg-lut-base"; + qcom,channel-id = <2>; + qcom,supported-sizes = <6>, <7>, <9>; + qcom,ramp-index = <1>; + qcom,force-pwm-size = <9>; + qcom,period = <6000000>; + qcom,dtest-line = <3>; + qcom,dtest-output = <1>; + status = "okay"; + + qcom,pwm { + qcom,duty = <4000000>; + label = "pwm"; + }; + }; + }; + }; + +There are couple of ways to configure PWM device channels as shown in above +example, +1. The PWM device channel #0 is configured with only required device bindings. +In this case, the qpnp-pwm driver does not configure any mode by default. + +2. The qpnp-pwm driver configures PWM device channel #1 with PWM feature +configuration, but does not enable the channel since "qcom,mode-select" binding +is not specified in the devicetree. + +3. Both the PWM and LPG configurations are provided for PWM device channel #4. +The qpnp-pwm driver configures both the modes, but enables PWM mode at the probe +time. It also sets the channel owner information for the channel. + +4. This configuration is pretty similar to #2 above except in this case channel +#3 is configured for PWM mode. Also it's DTEST3 line is configured to output +LPG OUT low. diff --git a/Documentation/devicetree/bindings/qbt1000/qbt1000.txt b/Documentation/devicetree/bindings/qbt1000/qbt1000.txt new file mode 100644 index 000000000000..4a18b79e9ba1 --- /dev/null +++ b/Documentation/devicetree/bindings/qbt1000/qbt1000.txt @@ -0,0 +1,54 @@ +Qualcomm Technologies, Inc. QBT1000 Specific Bindings + +QBT is a fingerprint sensor ASIC capable of performing fingerprint image scans +and detecting finger presence on the sensor using programmable firmware. + +======================= +Required Node Structure +======================= + +- compatible + Usage: required + Value type: <string> + Definition: "qcom,qbt1000". + +- clock-names + Usage: required + Value type: <stringlist> + Definition: List of clock names that need to be voted on/off. + +- clocks + Usage: required + Value type: <prop_encoded-array> + Definition: Property pair that represents the clock controller and the clock + id. This in combination with the clock-name is used to obtain + the handle for the clock that needs to be voted on/off. + +- clock-frequency + Usage: required + Value type: <u32> + Definition: Frequency of clock in Hz. + +- qcom,ipc-gpio + Usage: required + Value type: <phandle> + Definition: phandle for GPIO to be used for IPC. + +- qcom,finger-detect-gpio + Usage: required + Value type: <phandle> + Definition: phandle for GPIO to be used for finger detect. + +======= +Example +======= + +qcom,qbt1000 { + compatible = "qcom,qbt1000"; + clock-names = "core", "iface"; + clocks = <&clock_gcc clk_gcc_blsp2_qup6_spi_apps_clk>, + <&clock_gcc clk_gcc_blsp2_ahb_clk>; + clock-frequency = <15000000>; + qcom,ipc-gpio = <&tlmm 121 0>; + qcom,finger-detect-gpio = <&pm8998_gpios 2 0>; +}; diff --git a/Documentation/devicetree/bindings/qdsp/msm-cdsp-loader.txt b/Documentation/devicetree/bindings/qdsp/msm-cdsp-loader.txt new file mode 100644 index 000000000000..33adc661448a --- /dev/null +++ b/Documentation/devicetree/bindings/qdsp/msm-cdsp-loader.txt @@ -0,0 +1,16 @@ +Qualcomm Technologies, Inc. CDSP Loader Driver + +msm-cdsp-loader driver implements the mechanism that allows to load CDSP firmware images. + +Required properties: + + - compatible: This must be "qcom,msm-cdsp-loader". + - qcom,proc-img-to-load: CDSP firmware name, must be "cdsp". + +Example: + The following for sdm660. + + qcom,msm-cdsp-loader { + compatible = "qcom,cdsp-loader"; + qcom,proc-img-to-load = "cdsp"; + }; diff --git a/Documentation/devicetree/bindings/qdsp/msm-fastrpc.txt b/Documentation/devicetree/bindings/qdsp/msm-fastrpc.txt new file mode 100644 index 000000000000..f419655722d4 --- /dev/null +++ b/Documentation/devicetree/bindings/qdsp/msm-fastrpc.txt @@ -0,0 +1,76 @@ +Qualcomm Technologies, Inc. FastRPC Driver + +The MSM FastRPC driver implements an IPC (Inter-Processor Communication) +mechanism that allows for clients to transparently make remote method +invocations across DSP and APPS boundaries. This enables developers +to offload tasks to the DSP and free up the application processor for +other tasks. + +Required properties: +- compatible : Must be "qcom,msm-fastrpc-adsp" + +Optional properties: +- qcom,fastrpc-glink: Flag to use glink instead of smd for IPC + +Optional subnodes: +- qcom,msm_fastrpc_compute_cb : Child nodes representing the compute context + banks +Subnode Required properties: +- compatible : Must be "qcom,msm-fastrpc-compute-cb" +- label: Label describing the channel this context bank belongs to +- iommus : A list of phandle and IOMMU specifier pairs that describe the + IOMMU master interfaces of the device + +Example: + qcom,msm_fastrpc { + compatible = "qcom,msm-fastrpc-adsp"; + qcom,fastrpc-glink; + + qcom,msm_fastrpc_compute_cb_1 { + compatible = "qcom,msm-fastrpc-compute-cb"; + label = "adsprpc-smd"; + iommus = <&lpass_q6_smmu 8>, + }; + qcom,msm_fastrpc_compute_cb_2 { + compatible = "qcom,msm-fastrpc-compute-cb"; + label = "adsprpc-smd"; + iommus = <&lpass_q6_smmu 9>, + }; + }; + +Legacy SMMU v1/v2: + +Required properties: +- compatible : Must be "qcom,msm-fastprc-legacy-compute-cb" + +Required subnode: +- qcom,msm_fastrpc_compute_cb : Child nodes representing the compute context + banks + +Required subnode properties: +- qcom,adsp-shared-phandle: phandle that describe the context bank handle +- qcom,adsp-shared-sids : A list of SID associated with the context bank +- qcom,virtual-addr-pool : Virtual address range that the context bank + will be using + +Example: + qcom,adsprpc_domains { + compatible = "qcom,msm-fastrpc-legacy-compute-cb"; + qcom,msm_fastrpc_compute_cb { + qcom,adsp-shared-phandle = <&adsp_shared>; + qcom,adsp-shared-sids = <0x8 0x9>; + qcom,virtual-addr-pool = <0x80000000 0x7FFFFFFF>; + }; + }; + +Remote Heap: + +Required properties: +- compatible : Must be "qcom,msm-adsprpc-mem-region" +- memory-region : CMA region which is owned by this device + +Example: + qcom,adsprpc-mem { + compatible = "qcom,msm-adsprpc-mem-region"; + memory-region = <&adsp_mem>; + }; diff --git a/Documentation/devicetree/bindings/qdsp/msm-ssc-sensors.txt b/Documentation/devicetree/bindings/qdsp/msm-ssc-sensors.txt new file mode 100644 index 000000000000..c4b69d734880 --- /dev/null +++ b/Documentation/devicetree/bindings/qdsp/msm-ssc-sensors.txt @@ -0,0 +1,21 @@ +Qualcomm Technologies, Inc. SSC Driver + +msm-ssc-sensors driver implements the mechanism that allows to load SLPI firmware images. + +Required properties: + + - compatible: This must be "qcom,msm-ssc-sensors" + +Optional properties: + + - qcom,firmware-name: SLPI firmware name, must be "slpi_v1" or "slpi_v2" + Firmware name is not required, if sensors driver is sharing processor for execution. + + +Example: + The following for msm8998 version 1. + + qcom,msm-ssc-sensors { + compatible = "qcom,msm-ssc-sensors"; + qcom,firmware-name = "slpi_v1"; + }; diff --git a/Documentation/devicetree/bindings/qseecom/qseecom.txt b/Documentation/devicetree/bindings/qseecom/qseecom.txt new file mode 100644 index 000000000000..dfc62b78f58d --- /dev/null +++ b/Documentation/devicetree/bindings/qseecom/qseecom.txt @@ -0,0 +1,85 @@ +* QSEECOM (Qualcomm Secure Execution Environment Communicator) + +Required properties: +- compatible : Should be "qcom,qseecom" +- reg : should contain memory region address reserved for loading secure apps. +- qcom,disk-encrypt-pipe-pair : indicates what CE HW pipe pair is used for disk encryption +- qcom,file-encrypt-pipe-pair : indicates what CE HW pipe pair is used for file encryption +- qcom,support-multiple-ce-hw-instance : indicates if multicore CE support is supported. +- qcom,hlos-num-ce-hw-instances : indicates number of CE HW instances hlos can use. +- qcom,hlos-ce-hw-instance : indicates what CE HW is used by HLOS crypto driver +- qcom,qsee-ce-hw-instance : indicates what CE HW is used by secure domain (TZ) crypto driver +- qcom, msm_bus,name: Should be "qseecom-noc" +- qcom, msm_bus,num_cases: Depends on the use cases for bus scaling +- qcom, msm_bus,num_paths: The paths for source and destination ports +- qcom, msm_bus,vectors: Vectors for bus topology. +- qcom,ce-opp-freq: indicates the CE operating frequency in Hz, changes from target to target. +- qcom,full-disk-encrypt-info : Vectors defining full disk encryption unit, crypto engine, pipe pair configuration in <unit#, ce#, pipe-pair#> +- qcom,per-file-encrypt-info : Vectors defining per file encryption unit, crypto engine, pipe pair configuration in <unit#, ce#, pipe-pair#> + +Optional properties: + - qcom,support-bus-scaling : indicates if driver support scaling the bus for crypto operation. + - qcom,support-fde : indicates if driver support key managing for full disk encryption feature. + - qcom,support-pfe : indicates if driver support key managing for per file encryption feature. + - qcom,no-clock-support : indicates clocks are not handled by qseecom (could be handled by RPM) + - qcom,appsbl-qseecom-support : indicates if there is qseecom support in appsbootloader + - vdd-hba-supply : handle for fixed power regulator + - qcom,qsee-reentrancy-support: indicates the qsee reentrancy phase supported by the target + - qcom,commonlib64-loaded-by-uefi: indicates commonlib64 is loaded by uefi already + - qcom,fde-key-size: indicates which FDE key size is used in device. + +Example: + qcom,qseecom@fe806000 { + compatible = "qcom,qseecom"; + reg = <0x7f00000 0x500000>; + reg-names = "secapp-region"; + qcom,disk-encrypt-pipe-pair = <2>; + qcom,file-encrypt-pipe-pair = <0>; + qcom,support-multiple-ce-hw-instance; + qcom,hlos-num-ce-hw-instances = <2>; + qcom,hlos-ce-hw-instance = <1 2>; + qcom,qsee-ce-hw-instance = <0>; + qcom,support-fde; + qcom,support-pfe; + qcom,msm_bus,name = "qseecom-noc"; + qcom,msm_bus,num_cases = <4>; + qcom,msm_bus,active_only = <0>; + qcom,msm_bus,num_paths = <1>; + qcom,no-clock-support; + qcom,appsbl-qseecom-support; + qcom,fde-key-size; + qcom,msm_bus,vectors = + <55 512 0 0>, + <55 512 3936000000 393600000>, + <55 512 3936000000 393600000>, + <55 512 3936000000 393600000>; + qcom,ce-opp-freq = <100000000>; + vdd-hba-supply = <&gdsc_ufs>; + }; + +Example: The following dts setup is the same as the example above. + + qcom,qseecom@fe806000 { + compatible = "qcom,qseecom"; + reg = <0x7f00000 0x500000>; + reg-names = "secapp-region"; + qcom,support-fde; + qcom,full-disk-encrypt-info = <0 1 2>, <0 2 2>; + qcom,support-pfe; + qcom,per-file-encrypt-info = <0 1 0>, <0 2 0>; + qcom,qsee-ce-hw-instance = <0>; + qcom,msm_bus,name = "qseecom-noc"; + qcom,msm_bus,num_cases = <4>; + qcom,msm_bus,active_only = <0>; + qcom,msm_bus,num_paths = <1>; + qcom,no-clock-support; + qcom,appsbl-qseecom-support; + qcom,fde-key-size; + qcom,msm_bus,vectors = + <55 512 0 0>, + <55 512 3936000000 393600000>, + <55 512 3936000000 393600000>, + <55 512 3936000000 393600000>; + qcom,ce-opp-freq = <100000000>; + vdd-hba-supply = <&gdsc_ufs>; + }; diff --git a/Documentation/devicetree/bindings/regulator/cpr-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr-regulator.txt new file mode 100644 index 000000000000..1c4dfbf58795 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr-regulator.txt @@ -0,0 +1,978 @@ +QTI CPR (Core Power Reduction) Regulator + +CPR regulator device is for QTI RBCPR (RapidBridge CPR) on + application processor core. It takes voltage corner level + as input and converts it to actual voltage based on the + suggestions from factory production process. When CPR is + enabled for application processer core, it will suggest + scaling the voltage up or down for best performance and + power of the core. The scaling based on factory production + process is called PVS (Process Voltage Scaling) with efuse + bits to indicate what bin (and voltage range) a chip is in. + +Required properties: +- compatible: Must be "qcom,cpr-regulator" +- reg: Register addresses for RBCPR, RBCPR clock + select, PVS and CPR eFuse address +- reg-names: Register names. Must be "rbcpr" and "efuse_addr". + "rbcpr_clk" is optional. +- regulator-name: A string used to describe the regulator +- interrupts: Interrupt line from RBCPR to interrupt controller. +- qcom,cpr-fuse-corners: Number of fuse corners present. Many other properties + are sized based upon this value. +- regulator-min-microvolt: Minimum corner value which should be 1 to + represent the lowest supported corner. +- regulator-max-microvolt: Maximum corner value which should be equal to + qcom,cpr-fuse-corners if consumers request fuse + corners or the length of qcom,cpr-corner-map if + consumers request virtual corners. +- qcom,cpr-voltage-ceiling: Array of ceiling voltages in microvolts for fuse + corners ordered from lowest voltage corner to highest + voltage corner. This property must be of length + defined by qcom,cpr-fuse-corners. +- qcom,cpr-voltage-floor: Array of floor voltages in microvolts for fuse + corners ordered from lowest voltage corner to highest + voltage corner. This property must be of length + defined by qcom,cpr-fuse-corners. +- vdd-apc-supply: Regulator to supply VDD APC power +- qcom,vdd-apc-step-up-limit: Limit of vdd-apc-supply steps for scaling up. +- qcom,vdd-apc-step-down-limit: Limit of vdd-apc-supply steps for scaling down. +- qcom,cpr-ref-clk: The reference clock in kHz. +- qcom,cpr-timer-delay: The delay in microseconds for the timer interval. +- qcom,cpr-timer-cons-up: Consecutive number of timer interval (qcom,cpr-timer-delay) + occurred before issuing UP interrupt. +- qcom,cpr-timer-cons-down: Consecutive number of timer interval (qcom,cpr-timer-delay) + occurred before issuing DOWN interrupt. +- qcom,cpr-irq-line: Internal interrupt route signal of RBCPR, one of 0, 1 or 2. +- qcom,cpr-step-quotient: Defines the number of CPR quotient (i.e. Ring Oscillator(RO) + count) per vdd-apc-supply output voltage step. A single + integer value may be specified which is to be used for all + RO's. Alternatively, 8 integer values may be specified which + define the step quotients for RO0 to RO7 in order. +- qcom,cpr-up-threshold: The threshold for CPR to issue interrupt when + error_steps is greater than it when stepping up. +- qcom,cpr-down-threshold: The threshold for CPR to issue interrupt when + error_steps is greater than it when stepping down. +- qcom,cpr-idle-clocks: Idle clock cycles RO can be in. +- qcom,cpr-gcnt-time: The time for gate count in microseconds. +- qcom,cpr-apc-volt-step: The voltage in microvolt per CPR step, such as 5000uV. +- qcom,cpr-fuse-row: Array of row number of CPR fuse and method to read that row. It should have + index and value like this: + [0] => the fuse row number + [1] => fuse reading method, 0 for direct reading or 1 for SCM reading +- qcom,cpr-fuse-target-quot: Array of bit positions in the primary CPR fuse row defined + by qcom,cpr-fuse-row for the target quotients of each + fuse corner. Each bit position corresponds to the LSB + of the quotient parameter. The elements in the array + are ordered from lowest voltage corner to highest voltage + corner. This property must be of length defined by + qcom,cpr-fuse-corners. +- qcom,cpr-fuse-ro-sel: Array of bit positions in the primary CPR fuse row defined + by qcom,cpr-fuse-row for the ring oscillator selection for each + fuse corner. Each bit position corresponds to the LSB + of the RO select parameter. The elements in the array + are ordered from lowest voltage corner to highest voltage + corner. This property must be of length defined by + qcom,cpr-fuse-corners. + +Optional properties: +- vdd-mx-supply: Regulator to supply memory power as dependency + of VDD APC. +- qcom,vdd-mx-vmax: The maximum voltage in uV for vdd-mx-supply. This + is required when vdd-mx-supply is present. +- qcom,vdd-mx-vmin-method: The method to determine the minimum voltage for + vdd-mx-supply, which can be one of following + choices compared with VDD APC: + 0 => equal to the voltage(vmin) of VDD APC + 1 => equal to PVS corner ceiling voltage + 2 => equal to slow speed corner ceiling + 3 => equal to qcom,vdd-mx-vmax + 4 => equal to VDD_APC fuse corner mapped vdd-mx voltage + 5 => equal to VDD_APC virtual corner mapped vdd-mx voltage + This is required when vdd-mx-supply is present. +- qcom,vdd-mx-corner-map: Array of integers which defines the mapping from VDD_APC + voltage corners to vdd-mx-supply voltages. + Each element is a voltage to request from vdd-mx for the + corresponding fuse corner or virtual corner. The elements + in the array are ordered from lowest voltage corner + to highest voltage corner. The length of this property + depends on the value of qcom,vdd-mx-vmin-method property. + When qcom,vdd-mx-vmin-method property has a value of 4, the length + of this property must be equal to the value defined by qcom,cpr-fuse-corners. + When qcom,vdd-mx-vmin-method property has a value of 5, the length of + this property must be equal to the number of elements in the qcom,cpr-corner-map + property. +- qcom,pvs-voltage-table: Array of N-tuples in which each tuple specifies the + initial voltage in microvolts of the PVS bin for each + fuse voltage corner. The location or 0-based index + of a tuple in the list corresponds to the PVS bin number. + Each tuple must be of length defined by qcom,cpr-fuse-corners. + A given cpr-regulator device must have either + qcom,pvs-voltage-table specified or + qcom,cpr-fuse-init-voltage (and its associated properties). +- qcom,pvs-fuse-redun-sel: Array of 5 elements to indicate where to read the bits, what value to + compare with in order to decide if the redundant PVS fuse bits would be + used instead of the original bits and method to read fuse row, reading + register through SCM or directly. The 5 elements with index [0..4] are: + [0] => the fuse row number of the selector + [1] => LSB bit position of the bits + [2] => number of bits + [3] => the value to indicate redundant selection + [4] => fuse reading method, 0 for direct reading or 1 for SCM reading + When the value of the fuse bits specified by first 3 elements equals to + the value in 4th element, redundant PVS fuse bits should be selected. + Otherwise, the original PVS bits should be selected. If the 5th + element is 0, read the fuse row from register directly. Otherwise, + read it through SCM. + This property is required if qcom,pvs-voltage-table is present. +- qcom,pvs-fuse: Array of 4 elements to indicate the bits for PVS fuse and read method. + The array should have index and value like this: + [0] => the PVS fuse row number + [1] => LSB bit position of the bits + [2] => number of bits + [3] => fuse reading method, 0 for direct reading or 1 for SCM reading + This property is required if qcom,pvs-voltage-table is present. +- qcom,pvs-fuse-redun: Array of 4 elements to indicate the bits for redundant PVS fuse. + The array should have index and value like this: + [0] => the redundant PVS fuse row number + [1] => LSB bit position of the bits + [2] => number of bits + [3] => fuse reading method, 0 for direct reading or 1 for SCM reading + This property is required if qcom,pvs-voltage-table is present. +- qcom,cpr-fuse-redun-sel: Array of 5 elements to indicate where to read the bits, what value to + compare with in order to decide if the redundant CPR fuse bits would be + used instead of the original bits and method to read fuse row, using SCM + to read or read register directly. The 5 elements with index [0..4] are: + [0] => the fuse row number of the selector + [1] => LSB bit position of the bits + [2] => number of bits + [3] => the value to indicate redundant selection + [4] => fuse reading method, 0 for direct reading or 1 for SCM reading + When the value of the fuse bits specified by first 3 elements equals to + the value in 4th element, redundant CPR fuse bits should be selected. + Otherwise, the original CPR bits should be selected. If the 5th element + is 0, read the fuse row from register directly. Otherwise, read it through + SCM. +- qcom,cpr-fuse-redun-row: Array of row number of redundant CPR fuse and method to read that + row. It should have index and value like this: + [0] => the redundant fuse row number + [1] => the value to indicate reading the fuse row directly or using SCM + This property is required if qcom,cpr-fuse-redun-sel is present. +- qcom,cpr-fuse-redun-target-quot: Array of bit positions in the redundant CPR fuse row defined + by qcom,cpr-fuse-redun-row for the target quotients of each + fuse corner. Each bit position corresponds to the LSB + of the quotient parameter. The elements in the array + are ordered from lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,cpr-fuse-corners. + This property is required if qcom,cpr-fuse-redun-sel is present. +- qcom,cpr-fuse-redun-ro-sel: Array of bit positions in the redundant CPR fuse row defined + by qcom,cpr-fuse-redun-row for the ring oscillator select of each + fuse corner. Each bit position corresponds to the LSB of the RO + select parameter. The elements in the array are ordered from + lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,cpr-fuse-corners. + This property is required if qcom,cpr-fuse-redun-sel is present. +- qcom,cpr-fuse-redun-bp-cpr-disable: Redundant bit position of the bit to indicate if CPR should be disable +- qcom,cpr-fuse-redun-bp-scheme: Redundant bit position of the bit to indicate if it's a global/local scheme + This property is required if cpr-fuse-redun-bp-cpr-disable + is present, and vise versa. +- qcom,cpr-fuse-bp-cpr-disable: Bit position of the bit to indicate if CPR should be disabled +- qcom,cpr-fuse-bp-scheme: Bit position of the bit to indicate if it's a global/local scheme +- qcom,cpr-fuse-revision: Array of 4 integer elements which define the location of the bits for + the CPR fusing revision fuse parameter. The 4 elements are: + [0]: => the fuse row number of the bits + [1]: => LSB bit position of the bits + [2]: => the number of bits + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading + The fusing revision value is used to determine which specific adjustments + are required on some chips. +- qcom,cpr-fuse-target-quot-size: Array of target quotient parameter bit sizes in the primary + or redundant CPR fuse row for each fuse corner. The elements in the + array are ordered from lowest voltage corner to highest voltage corner. + If this property is not present, then all target quotient fuse values + are assumed to be the default length of 12 bits. +- qcom,cpr-fuse-target-quot-scale: Array of doubles which defines the scaling coefficients to decode + the target quotients of each fuse corner. The first element in each + double represents the offset to add to the scaled quotient. The second + element represents the multiplier to scale the quotient by. For example, + given a tuple <A B>, quot_decoded = A + (B * quot_raw). + The doubles in the array are ordered from lowest voltage corner to highest + voltage corner. This property must contain a number of doubles equal to + the value of qcom,cpr-fuse-corners. If this property is not present, + then all target quotient parameters are assumed to have an offset of 0 + and a multiplier of 1 (i.e. no decoding needed). +- qcom,cpr-enable: Present: CPR enabled by default. + Not Present: CPR disable by default. +- qcom,cpr-fuse-cond-min-volt-sel: Array of 5 elements to indicate where to read the bits, what value to + compare with in order to decide if the conditional minimum apc voltage needs + to be applied and the fuse reading method. + The 5 elements with index[0..4] are: + [0] => the fuse row number; + [1] => LSB bit position of the bits; + [2] => number of the bits; + [3] => the expected data to read; + [4] => fuse reading method, 0 for direct reading or 1 for SCM reading; + When the value of the fuse bits specified by first 3 elements is not equal to + the value in 4th element, then set the apc voltage for all parts running + at each voltage corner to be not lower than the voltage defined + using "qcom,cpr-cond-min-voltage". +- qcom,cpr-cond-min-voltage: Minimum voltage in microvolts allowed for cpr-regulator output if the fuse bits + defined in qcom,cpr-fuse-cond-min-volt-sel have not been programmed with the + expected data. This is required if cpr-fuse-cond-min-volt-sel is present. +- qcom,cpr-fuse-uplift-sel: Array of 5 elements to indicate where to read the bits, what value to + compare with in order to enable or disable the pvs voltage uplift workaround, + and the fuse reading method. + The 5 elements with index[0..4] are: + [0]: => the fuse row number of the selector; + [1]: => LSB bit position of the bits; + [2]: => number of the bits; + [3]: => the value to indicate if the apc pvs voltage uplift workaround will + be enabled; + [4]: => fuse reading method, 0 for direct reading or 1 for SCM reading. + When the value of the fuse bits specified by first 3 elements equals to the + value in 4th element, the pvs voltage uplift workaround will be enabled. +- qcom,speed-bin-fuse-sel: Array of 4 elements to indicate where to read the speed bin of the processor, + and the fuse reading method. + The 4 elements with index[0..3] are: + [0]: => the fuse row number of the selector; + [1]: => LSB bit position of the bits; + [2]: => number of the bits; + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading. + This is required if cpr-fuse-uplift-disable-sel is present. +- qcom,cpr-uplift-voltage: Uplift in microvolts used for increasing pvs init voltage. If this property is present, + This is required if cpr-fuse-uplift-disable-sel is present. +- qcom,cpr-uplift-max-volt: Maximum voltage in microvolts used for pvs voltage uplift workaround to limit + the maximum pvs voltage. + This is required if cpr-fuse-uplift-disable-sel is present. +- qcom,cpr-uplift-quotient: Array of target quotient increments to add to the fused quotients of each + fuse corner as part of the PVS voltage uplift workaround. + The elements in the array are ordered from lowest voltage + corner to highest voltage corner. This property must be of + length defined by qcom,cpr-fuse-corners. This is required + if cpr-fuse-uplift-disable-sel is present. +- qcom,cpr-uplift-speed-bin: The speed bin value corresponding to one type of processor which needs to apply the + pvs voltage uplift workaround. + This is required if cpr-fuse-uplift-disable-sel is present. +- qcom,cpr-fuse-version-map: Array of integer tuples which each match to a given combination of CPR + fuse parameter values. Each tuple consists of N + 3 elements. Where + N is the number of fuse corners defined by the qcom,cpr-fuse-corners + property. The elements in one tuple are: + [0]: => the speed bin of the CPU + [1]: => the PVS version of the CPU + [2]: => the CPR fuse revision + [3 - N+2]: => the ring oscillator select value of each fuse corner + ordered from lowest to highest + Any element in a tuple may use the value 0xffffffff as a wildcard + which will match against any fuse parameter value. The first tuple + that matches against the fuse values read from hardware will be used. + This property is used by several properties to provide an index into + their lists. +- qcom,cpr-allowed: Integer values that specifies whether the closed loop CPR is allowed or + not for a particular fuse revision. If the qcom,cpr-fuse-version-map + property is specified, then qcom,cpr-allowed must contain the same number + of integers as that of the number of tuples in qcom,cpr-fuse-version-map. + If the integer value has a value 0 for a particular fuse revision, then it + is treated as if the closed loop operation is disabled in the fuse. If the + integer value has a value 1 for a particular fuse revision, then the closed + loop operation is enabled for that fuse revision. If nothing is specified + for a particular fuse revision, then the closed loop operation is enabled + for that fuse revision by default. +- qcom,cpr-quotient-adjustment: Array of integer tuples of target quotient adjustments to add to the fused + quotients of each fuse corner. The elements in a tuple are ordered from + lowest voltage corner to highest voltage corner. Each tuple must be of + length defined by qcom,cpr-fuse-corners. If the qcom,cpr-fuse-version-map + property is specified, then qcom,cpr-quotient-adjustment must contain the + same number of tuples as qcom,cpr-fuse-version-map. These tuples are then + mapped one-to-one in the order specified. E.g. if the second + qcom,cpr-fuse-version-map tuple matches for a given device, then the quotient + adjustments defined in the second qcom,cpr-quotient-adjustment tuple will + be applied. If the qcom,cpr-fuse-version-map property is not specified, + then qcom,cpr-quotient-adjustment must contain a single tuple which is then + applied unconditionally. If this property is specified, then the quotient + adjustment values are added to the target quotient values read from fuses + before writing them into the CPR GCNT target control registers. + This property can be used to add or subtract static voltage margin from the + regulator managed by the CPR controller. +- qcom,cpr-init-voltage-adjustment: Array of integer tuples of initial voltage adjustments in microvolts to + add to the fused initial voltage values of each fuse corner. The elements + in a tuple are ordered from lowest voltage corner to highest voltage corner. + Each tuple must be of the length defined by qcom,cpr-fuse-corners. If the + qcom,cpr-fuse-version-map property is specified, then + qcom,cpr-init-voltage-adjustment must contain the same number of tuples as + qcom,cpr-fuse-version-map. These tuples are then mapped one-to-one in the + order specified. E.g. if the second qcom,cpr-fuse-version-map tuple matches + for a given device, then the initial voltage adjustments defined in the + second qcom,cpr-init-voltage-adjustment tuple will be applied. If the + qcom,cpr-fuse-version-map property is not specified, then + qcom,cpr-init-voltage-adjustment must contain a single tuple which is then + applied unconditionally. This property can be used to add or subtract + static initial voltage margin from the regulator managed by the CPR + controller. +- qcom,cpr-quot-offset-adjustment: Array of integer tuples of target quotient offset adjustments to add + to the fused quotient offsets of each fuse corner. The elements in a tuple + are ordered from lowest voltage corner to highest voltage corner. Each tuple + must be of length defined by qcom,cpr-fuse-corners. If the qcom,cpr-fuse-version-map + property is specified, then qcom,cpr-quot-offset-adjustment must contain the + same number of tuples as qcom,cpr-fuse-version-map. These tuples are then + mapped one-to-one in the order specified. E.g. if the second + qcom,cpr-fuse-version-map tuple matches for a given device, then the quotient + offset adjustments defined in the second qcom,cpr-quot-offset-adjustment tuple + will be applied. If the qcom,cpr-fuse-version-map property is not specified, + then qcom,cpr-quot-offset-adjustment must contain a single tuple which is then + applied unconditionally. If this property is specified, then the quotient + offset adjustment values are added to the target quotient offset values read + from fuses. + This property can be used to add or subtract static quotient offset margin from + the regulator managed by the CPR controller. +- qcom,cpr-clamp-timer-interval: The number of 64 reference clock cycle blocks to delay for whenever + the clamp signal, sensor mask registers or sensor bypass registers + change. The CPR controller loop is disabled during this delay. + Supported values are 0 to 255. If this property is not specified, + then a value of 0 is assumed. Note that if this property has a + value greater than 0, then software cannot accurately determine the + error_steps value that corresponds to a given CPR measurement + unless processor power collapsing is disabled. If this property + has a value of 0, then the CPR controller loop is not disabled and + re-enabled while idle if the clamp signal changes. Instead, it + will remain idle until software issues an ACK or NACK command. + This ensures that software can read the error_steps value which + resulted in the CPR up or down interrupt. Setting this property to + a value greater than 0 is useful for resetting the CPR sensors of a + processor that uses BHS type voltage switches in order to avoid + anomalous CPR up interrupts when exiting from power collapse. +- vdd-apc-optional-prim-supply: Present: Regulator of highest priority to supply VDD APC power + Not Present: No such regulator. +- vdd-apc-optional-sec-supply: Present: Regulator of second highest priority to supply VDD APC power. + Not Present: No such regulator. +- qcom,cpr-speed-bin-max-corners: Array of (N+2)-tuples in which each tuple maps a CPU speed bin and PVS version to + the maximum virtual voltage corner corresponding to each fuse corner. The value N + corresponds to the number of fuse corners specified by qcom,cpr-fuse-corners. + The elements in one tuple are: + [0]: => the speed bin of the CPU. It may use the value 0xffffffff as a + wildcard to match any speed bin values. + [1]: => the PVS version of the CPU. It may use the value 0xffffffff as + a wildcard to match any PVS version values. + [2 - N+1]: => the max virtual voltage corner value corresponding to each fuse corner + for this speed bin, ordered from lowest voltage corner to highest + voltage corner. + No CPR target quotient scaling is applied on chips which have a speed bin + PVS version + pair that does not appear in one of the tuples in this property. If the property is + specified, then quotient scaling is enabled for the highest voltage corner. If this property is + not specified, then no quotient scaling can take place. +- qcom,cpr-corner-map: Array of elements of fuse corner value for each virtual corner. + The location or 1-based index of an element in the list corresponds to + the virtual corner value. For example, the first element in the list is the fuse corner + value that virtual corner 1 maps to. + This property is required if qcom,cpr-speed-bin-max-corners is present. +- qcom,cpr-corner-frequency-map: Array of tuples in which a tuple describes a corner to application processor frequency + mapping. + The 2 elements in one tuple are: + [0]: => a virtual voltage corner. + [1]: => the application processor frequency in Hz corresponding to the virtual corner. + This property is required if qcom,cpr-speed-bin-max-corners is present. +- qcom,pvs-version-fuse-sel: Array of 4 elements to indicate where to read the pvs version of the processor, + and the fuse reading method. + The 4 elements with index[0..3] are: + [0]: => the fuse row number of the selector; + [1]: => LSB bit position of the bits; + [2]: => the number of bits; + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading. +- qcom,cpr-voltage-ceiling-override: Array of (N+2)-tuples in which each tuple maps a CPU speed bin and PVS version + to the ceiling voltage to apply for each virtual voltage corner. The value N + corresponds to the number of virtual corners as specified by the number of elements + in the qcom,cpr-corner-map property. + The elements in one tuple are: + [0]: => the speed bin of the CPU. It may use the value 0xffffffff as a + wildcard to match any speed bin values. + [1]: => the PVS version of the CPU. It may use the value 0xffffffff as a + wildcard to match any PVS version values. + [2 - N+1]: => the ceiling voltage value in microvolts corresponding to each virtual + corner for this speed bin, ordered from lowest voltage corner to + highest voltage corner. + No ceiling override is applied on chips which have a speed bin + PVS version + pair that does not appear in one of the tuples in this property. If the property is + specified and the speed bin + PVS version matches, then the per-virtual-corner ceiling + voltages will be used in place of the per-fuse-corner ceiling voltages defined in the + qcom,cpr-voltage-ceiling property. If this property is not specified, then the + per-fuse-corner ceiling voltages will always be used. +- qcom,cpr-voltage-floor-override: Array of (N+2)-tuples in which each tuple maps a CPU speed bin and PVS version + to the floor voltage to apply for each virtual voltage corner. The value N + corresponds to the number of virtual corners as specified by the number of elements + in the qcom,cpr-corner-map property. + The elements in one tuple are: + [0]: => the speed bin of the CPU. It may use the value 0xffffffff as a + wildcard to match any speed bin values. + [1]: => the PVS version of the CPU. It may use the value 0xffffffff as a + wildcard to match any PVS version values. + [2 - N+1]: => the floor voltage value in microvolts corresponding to each virtual + corner for this speed bin, ordered from lowest voltage corner to + highest voltage corner. + No floor override is applied on chips which have a speed bin + PVS version + pair that does not appear in one of the tuples in this property. If the property is + specified and the speed bin + PVS version matches, then the per-virtual-corner floor + voltages will be used in place of the per-fuse-corner floor voltages defined in the + qcom,cpr-voltage-floor property. If this property is not specified, then the + per-fuse-corner floor voltages will always be used. +- qcom,cpr-floor-to-ceiling-max-range: Array of integer tuples of floor-to-ceiling max range values in microvolts + to be subtracted from the ceiling voltage values of each virtual corner. + Supported values are those greater than or equal 0, or (-1). The value 0 for a corner + implies that the floor value for that corner has to equal to its ceiling value. + The value (-1) for a corner implies that no modification to the default floor voltage + is required. The elements in a tuple are ordered from lowest voltage corner to highest + voltage corner. Each tuple must be of the length equal to the number of virtual corners + as specified by the number of elements in the qcom,cpr-corner-map property. If the + qcom,cpr-fuse-version-map property is specified, then + qcom,cpr-dynamic-floor-override-adjustment must contain the same number of + tuples as qcom,cpr-fuse-version-map. These tuples are then mapped one-to-one in the + order specified. E.g. if the second qcom,cpr-fuse-version-map tuple matches + for a given device, then voltage adjustments defined in the second + qcom,cpr-dynamic-floor-override-adjustment tuple will be applied. If the + qcom,cpr-fuse-version-map property is not specified, then + qcom,cpr-dynamic-floor-override-adjustment must contain a single tuple which + is then applied unconditionally. +- qcom,cpr-virtual-corner-init-voltage-adjustment: Array of integer tuples of voltage adjustments in microvolts to be + added to the initial voltage values of each virtual corner. The elements + in a tuple are ordered from lowest voltage corner to highest voltage corner. + Each tuple must be of the length equal to the number of virtual corners as + specified by the number of elements in the qcom,cpr-corner-map property. If the + qcom,cpr-fuse-version-map property is specified, then + qcom,cpr-virtual-corner-init-voltage-adjustment must contain the same number of + tuples as qcom,cpr-fuse-version-map. These tuples are then mapped one-to-one in the + order specified. E.g. if the second qcom,cpr-fuse-version-map tuple matches + for a given device, then voltage adjustments defined in the second + qcom,cpr-virtual-corner-init-voltage-adjustment tuple will be applied. If the + qcom,cpr-fuse-version-map property is not specified, then + qcom,cpr-virtual-corner-init-voltage-adjustment must contain a single tuple which + is then applied unconditionally. +- qcom,cpr-virtual-corner-quotient-adjustment: Array of integer tuples of quotient offsets to be added to + the scaled target quotient of each virtual corner. The elements + in a tuple are ordered from lowest voltage corner to highest voltage corner. + Each tuple must be of the length equal to the number of virtual corners as + specified by the number of elements in the qcom,cpr-corner-map property. + If the qcom,cpr-fuse-version-map property is specified, then + qcom,cpr-virtual-corner-quotient-adjustment must contain the same number of tuples as + qcom,cpr-fuse-version-map. These tuples are then mapped one-to-one in the + order specified. E.g. if the second qcom,cpr-fuse-version-map tuple matches + for a given device, then quotient adjustments defined in the second + qcom,cpr-virtual-corner-quotient-adjustment tuple will be applied. If the + qcom,cpr-fuse-version-map property is not specified, then + qcom,cpr-virtual-corner-quotient-adjustment must contain a single tuple which is then + applied unconditionally. +- qcom,cpr-cpus: Array of CPU phandles which correspond to the cores that this cpr-regulator + device must monitor when adjusting the voltage and/or target quotient based + upon the number of online cores or make sure that one of them must be online + when performing de-aging measurements. This property must be specified in order to + utilize the qcom,cpr-online-cpu-virtual-corner-init-voltage-adjustment or + qcom,cpr-online-cpu-virtual-corner-quotient-adjustment or qcom,cpr-aging-sensor-id properties. +- qcom,cpr-online-cpu-virtual-corner-init-voltage-adjustment: Array of tuples where each tuple specifies + the voltage adjustment for each corner. These adjustments apply to the + initial voltage of each corner. The size of each tuple must be equal + to qcom,cpr-fuse-corners if consumers request fuse corners or the length of + qcom,cpr-corner-map if consumers request virtual corners. In each tuple, the + value corresponds to the voltage adjustment when running at that corner at + init, from lowest to highest. The tuples must be organized into 1 group if + qcom,cpr-fuse-version-map is not specified or the same number of groups as + the number of tuples in qcom,cpr-fuse-version-map. The i-th group of tuples + corresponds to the voltage adjustments for i-th fuse version map tuple. In + each group, there are 1 plus length of qcom,cpr-cpus tuples, each tuple + corresponds to the number of cores online, from 0 to the number of elements + in qcom,cpr-cpus. +- qcom,cpr-online-cpu-init-voltage-as-ceiling: Boolean which indicates that the ceiling voltage used for a + given virtual corner may be reduced to the per number of cores online, + per-virtual corner ceiling voltage value. This property takes precedence + over qcom,cpr-scaled-init-voltage-as-ceiling if both are specified. +- qcom,cpr-online-cpu-virtual-corner-quotient-adjustment: Array of tuples where each tuple specifies + the quotient adjustment for each corner. These adjustments will be applied + to each corner at run time. The size of each tuple must be equal to + qcom,cpr-fuse-corners if consumers request fuse corners or the length of + qcom,cpr-corner-map if consumers request virtual corners. In each tuple, + the value corresponds to the quotient adjustment when running at that corner, + from lowest to highest. The tuples must be organized into 1 group if + qcom,cpr-fuse-version-map is not specified or the same number of groups + as the number of tuples in qcom,cpr-fuse-version-map. The i-th group of + tuples corresponds to the quotient adjustments for i-th fuse version map + tuple. In each group, there are 1 plus length of qcom,cpr-cpus tuples, + each tuple corresponds to the number of cores online, from 0 to the + number of elements in qcom,cpr-cpus. +- qcom,cpr-init-voltage-as-ceiling: Boolean which indicates that the ceiling voltage used for a given virtual + corner may be reduced to the per-fuse-corner initial voltage fuse value. +- qcom,cpr-scaled-init-voltage-as-ceiling: Boolean which indicates that the ceiling voltage used for a given + virtual corner may be reduced to the interpolated, per-virtual-corner initial + voltage value. Note that if both qcom,cpr-init-voltage-as-ceiling and + qcom,cpr-scaled-init-voltage-as-ceiling are specified, then + qcom,cpr-scaled-init-voltage-as-ceiling will take precedence since the interpolated + voltages are necessarily less than or equal to the fused initial voltage values. +- qcom,cpr-voltage-scaling-factor-max: Array of values which define the maximum allowed scaling factor to apply + when calculating per-corner initial voltage values for each fuse corner. The + array must be of length equal to the value of the qcom,cpr-fuse-corners property. + Each element in the array maps to the fuse corners in increasing order. + The elements have units of uV/MHz. Each element corresponds to 'max_factor' in + the following equation: + init_voltage_min(f) = fuse_init_voltage(f) - (fuse_f_max - f) * max_factor + If this property is not specified, then the initial voltage for each virtual + corner will be set to the initial voltage of the associated fuse corner. +- qcom,cpr-quot-adjust-scaling-factor-max: Array of values which define the maximum allowed scaling factor to + apply when calculating per-virtual-corner target quotients for each fuse + corner. Two data formats are allowed for this property. The primary one + requires that the array be of length equal to the value of the + qcom,cpr-fuse-corners property. When using this format, each element in the + array maps to the fuse corners in increasing order. The second depreciated + format allows for only a single element to be specified which defines the + maximum scaling factor for the highest fuse corner. In this case, a value of + 0 is assumed for the lower fuse corners. The elements of this property have + units of QUOT/GHz. Each element corresponds to 'max_factor' in the following + equation: + quot_min(f) = fuse_quot(f) - (fuse_f_max - f) * max_factor / 1000 + where f and fuse_f_max have units of MHz. + This property is required if qcom,cpr-speed-bin-max-corners is present. +- qcom,cpr-fuse-init-voltage: Array of quadruples in which each quadruple specifies a fuse location to + read in order to get an initial voltage for a fuse corner. The fuse values + are encoded as voltage steps higher or lower than the voltages defined in + qcom,cpr-voltage-ceiling. Each step corresponds to the voltage defined by + the qcom,cpr-init-voltage-step property. + The 4 elements in one quadruple are: + [0]: => the fuse row number of the bits + [1]: => LSB bit position of the bits + [2]: => number of the bits + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading + The quadruples are ordered from the lowest voltage fuse corner to the + highest voltage fuse corner. + A given cpr-regulator device must have either qcom,cpr-fuse-init-voltage + specified or qcom,pvs-voltage-table (and its associated properties). +- qcom,cpr-fuse-redun-init-voltage: Array of quadruples in which each quadruple specifies a fuse location + to read in order to get the redundant initial voltage for a fuse corner. + This property is the same as qcom,cpr-fuse-init-voltage except that it is + only utilized if a chip is configured to use the redundant set of fuse + values. This property is required if qcom,cpr-fuse-redun-sel and + qcom,cpr-fuse-init-voltage are specified. +- qcom,cpr-init-voltage-ref: Array of reference voltages in microvolts used when decoding the initial + voltage fuse values. The elements in the array are ordered from lowest + voltage corner to highest voltage corner. This property must be of length + defined by qcom,cpr-fuse-corners. + This property is required if qcom,cpr-fuse-init-voltage is present. +- qcom,cpr-init-voltage-step: The voltage step size in microvolts of the CPR initial voltage fuses described by the + qcom,cpr-fuse-init-voltage property. + This property is required if qcom,cpr-fuse-init-voltage is present. +- mem-acc-supply: Regulator to vote for the memory accelerator configuration. + Not Present: memory accelerator configuration not supported. +- qcom,mem-acc-corner-map: Array of integer which defines the mapping from mem-acc corner value for each + virtual corner. Each element is a mem-acc state for the corresponding virtual corner. + The elements in the array are ordered from lowest voltage corner to highest voltage corner. +- qcom,fuse-remap-source: Array of quadruples in which each quadruple specifies a fuse location to + remap. The 4 elements in one quadruple are: + [0]: => the fuse row number of the bits + [1]: => LSB bit position of the bits + [2]: => the number of bits + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading + The fuse bits for all quadruples are packed together in the order specified + into 64-bit virtual fuse rows beginning at the row number defined in the + qcom,fuse-remap-base-row property. The remapped rows may be used by any + other properties. + Example: + qcom,fuse-remap-base-row = <1000>; + qcom,fuse-remap-source = + <13 57 2 0>, + <14 30 3 0>, + <20 1 7 0>, + <40 47 120 0>; + + This results in the following bit remapping: + + Row Bits Remap Row Remap Bits + 13 57..58 --> 1000 0..1 + 14 30..32 --> 1000 2..4 + 20 1..7 --> 1000 5..11 + 40 47..63 --> 1000 12..28 + 41 0..34 --> 1000 29..63 + 41 35..63 --> 1001 0..28 + 42 0..34 --> 1001 29..63 + 42 35..38 --> 1002 0..3 + + A tuple like this could then be used to reference some of the + concatenated bits from rows 13, 14, and 20: + + qcom,cpr-fuse-init-voltage = <1000 0 6 0>; +- qcom,fuse-remap-base-row: Integer which defines the virtual row number to use as a base when remapping + fuse bits. The remap base row number can be any value as long as it is + greater than all of the real row numbers addressed in other properties of + the cpr-regulator device node. This property is required if + qcom,fuse-remap-source is specified. +- qcom,cpr-quot-min-diff: Integer which defines the minimum target-quotient difference between + the highest and (highest - 1) fuse corner to keep CPR enabled. If this + property is not specified a default value of 50 is used. +- qcom,cpr-fuse-quot-offset: Array of quadruples in which each quadruple specifies a fuse location to + read in order to get the quotient offset for a fuse corner. The fuse values + are encoded as the difference between quotients of that fuse corner and its + adjacent lower fuse corner divided by an unpacking multiplier value defined + under qcom,cpr-fuse-quot-offset-scale property. + The 4 elements in one quadruple are: + [0]: => the fuse row number of the bits + [1]: => LSB bit position of the bits + [2]: => number of the bits + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading + The quadruples are ordered from the lowest fuse corner to the highest + fuse corner. + Quotient offset read from the fuse locations above can be overridden with + the property qcom,cpr-quot-adjust-scaling-factor-max. +- qcom,cpr-fuse-quot-offset-scale: Array of integer values which defines the multipliers to decode the quotient offsets + of each fuse corner. The elements in the array are ordered from the lowest voltage fuse corner + to the highest voltage fuse corner. If this property is not present, then all target quotient + parameters are assumed to have a multiplier of 1 (i.e. no decoding needed). +- qcom,cpr-redun-fuse-quot-offset: Array of quadruples in which each quadruple specifies a fuse location to + read in order to get the redundant quotient offset for a fuse corner. This + property is the same as qcom,cpr-fuse-quot-offset except that it is only + utilized if a chip is configured to use the redundant set of fuse values. +- qcom,cpr-fuse-min-quot-diff: Array of values which define the minimum difference allowed between the adjusted + quotients of the fuse corners. The length of the array should be equal to the value + of the qcom,cpr-fuse-corners property. Where each element in the array maps to the + fuse corners in increasing order. +- qcom,cpr-min-quot-diff-adjustment: Array of integer tuples of target quotient offsets to be added to + the adjusted target quotients of each fuse corner. When the quotient difference + between two adjacent fuse corners is insufficient, the quotient for the higher fuse corner is + replaced with that of the lower fuse corner plus the adjustment value. + The elements in a tuple are ordered from lowest voltage corner to highest voltage corner. + Each tuple must be of the length defined by qcom,cpr-fuse-corners. + If the qcom,cpr-fuse-version-map property is specified, then qcom,cpr-min-quot-diff-adjustment + must contain the same number of tuples as qcom,cpr-fuse-version-map. These tuples are then mapped + one-to-one in the order specified. E.g. if the second qcom,cpr-fuse-version-map tuple matches + for a given device, then the quotient adjustments defined in the + second qcom,cpr-min-quot-diff-adjustment tuple will be applied. If the + qcom,cpr-fuse-version-map property is not specified, then + qcom,cpr-min-quot-diff-adjustment must contain a single tuple which is then + applied unconditionally. The qcom,cpr-min-quot-diff-adjustment property must be specified + if the qcom,cpr-fuse-min-quot-diff property is specified. +- qcom,cpr-skip-voltage-change-during-suspend: Boolean property which indicates that the CPR voltage + should not be adjusted based upon the number of online cores while + entering or exiting system suspend. +- rpm-apc-supply: Regulator to notify RPM of the APC operating + corner +- qcom,rpm-apc-corner-map: Array of integers which define the mapping of + the RPM corner to the corresponding APC virtual + corner. This property must be defined if + 'rpm-apc-supply' is present. +- qcom,vsens-corner-map: Array of integers which define the mapping of the VSENS corner to the + corresponding APC fuse corner. The qcom,vsens-corner-map and + vdd-vsense-corner-supply properties must both be specified for a given + cpr-regulator device or neither must be specified. +- vdd-vsens-corner-supply: Regulator to specify the current operating fuse corner to the Voltage Sensor. +- vdd-vsens-voltage-supply: Regulator to specify the corner floor/ceiling voltages to the Voltage Sensor. +- qcom,cpr-aging-sensor-id: Array of CPR sensor IDs to be used in the CPR de-aging algorithm. The number + of values should be equal to number of sensors selected for age calibration. + If this property is not specified, then the de-aging procedure is not enabled. +- qcom,cpr-de-aging-allowed: Integer values that specify whether the CPR de-aging procedure is allowed or + not for a particular fuse revision. If the qcom,cpr-fuse-version-map + property is specified, then qcom,cpr-de-aging-allowed must contain the same number + of elements as there are tuples in qcom,cpr-fuse-version-map. If qcom,cpr-fuse-version-map + is not specified, then qcom,cpr-de-aging-allowed must contain a single value that + is used unconditionally. An element value of 1 means that the CPR de-aging procedure + can be performed for parts with the corresponding fuse revision. An element value of 0 + means that CPR de-aging cannot be performed. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-aging-ref-corner: The vdd-apc-supply reference virtual voltage corner to be set during the CPR de-aging + measurements. This corner value is needed to set appropriate voltage on + the dependent voltage rails such as vdd-mx and mem-acc. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-aging-ref-voltage: The vdd-apc-supply reference voltage in microvolts to be set during the + CPR de-aging measurements. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-max-aging-margin: The maximum allowed aging voltage margin in microvolts. This is used to limit + the calculated aging voltage margin. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-non-collapsible-sensors: Array of CPR sensor IDs which are in non-collapsible domain. The sensor IDs not + specified in the array should be bypassed for the de-aging procedure. The number of + elements should be less than or equal to 32. The values of the array elements should + be greater than or equal to 0 and less than or equal to 31. + This property is required for power-domains with bypass mux present in HW. + This property can be required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-aging-ro-scaling-factor: The aging ring oscillator (RO) scaling factor with units of QUOT/V. + This value is used for calculating a voltage margin from RO measurements. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-ro-scaling-factor: Array of scaling factors with units of QUOT/V for each ring oscillator ordered + from the lowest to the highest RO. These values are used to calculate + the aging voltage margin adjustment for all of the ROs. Since CPR2 supports + exactly 8 ROs, the array must contain 8 elements corresponding to RO0 through RO7 in order. + If a given RO is unused for a fuse corner, then its scaling factor may be specified as 0. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-aging-derate: Array of scaling factors which define the amount of derating to apply to the reference + aging voltage margin adjustment for each of the fuse corners. Each element has units + of uV/mV. This property must be of length defined by qcom,cpr-fuse-corners. + The elements are ordered from the lowest to the highest fuse corner. + This property is required if the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-fuse-aging-init-quot-diff: Array of quadruples in which each quadruple specifies a fuse location to read in + order to get an initial quotient difference. The difference between quot min and quot max + is fused as the initial quotient difference. + The 4 elements in one quadruple are: + [0]: => the fuse row number of the bits + [1]: => LSB bit position of the bits + [2]: => number of the bits + [3]: => fuse reading method, 0 for direct reading or 1 for SCM reading + The number of quadruples should be equal to the number of values specified in + the qcom,cpr-aging-sensor-id property. This property is required if + the qcom,cpr-aging-sensor-id property has been specified. +- qcom,cpr-thermal-sensor-id: TSENS hardware sensor-id of the sensor which + needs to be monitored. +- qcom,cpr-disable-temp-threshold: The TSENS temperature threshold in degrees Celsius at which CPR + closed-loop is disabled. CPR closed-loop will stay disabled as long as the + temperature is below this threshold. This property is required + only if 'qcom,cpr-thermal-sensor-id' is present. +- qcom,cpr-enable-temp-threshold: The TSENS temperature threshold in degrees Celsius at which CPR + closed-loop is enabled. CPR closed-loop will stay enabled above this + temperature threshold. This property is required only if + 'qcom,cpr-thermal-sensor-id' is present. +- qcom,disable-closed-loop-in-pc: Bool property to disable closed-loop CPR during + power-collapse. This can be enabled only for single core + designs. The property 'qcom,cpr-cpus' is required to enable this logic. +Example: + apc_vreg_corner: regulator@f9018000 { + status = "okay"; + compatible = "qcom,cpr-regulator"; + reg = <0xf9018000 0x1000>, <0xfc4b8000 0x1000>; + reg-names = "rbcpr", "efuse_addr"; + interrupts = <0 15 0>; + regulator-name = "apc_corner"; + qcom,cpr-fuse-corners = <3>; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <12>; + + qcom,pvs-fuse = <22 6 5 1>; + qcom,pvs-fuse-redun-sel = <22 24 3 2 1>; + qcom,pvs-fuse-redun = <22 27 5 1>; + + qcom,pvs-voltage-table = + <1050000 1150000 1350000>, + <1050000 1150000 1340000>, + <1050000 1150000 1330000>, + <1050000 1150000 1320000>, + <1050000 1150000 1310000>, + <1050000 1150000 1300000>, + <1050000 1150000 1290000>, + <1050000 1150000 1280000>, + <1050000 1150000 1270000>, + <1050000 1140000 1260000>, + <1050000 1130000 1250000>, + <1050000 1120000 1240000>, + <1050000 1110000 1230000>, + <1050000 1100000 1220000>, + <1050000 1090000 1210000>, + <1050000 1080000 1200000>, + <1050000 1070000 1190000>, + <1050000 1060000 1180000>, + <1050000 1050000 1170000>, + <1050000 1050000 1160000>, + <1050000 1050000 1150000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>, + <1050000 1050000 1140000>; + qcom,cpr-voltage-ceiling = <1050000 1150000 1280000>; + qcom,cpr-voltage-floor = <1050000 1050000 1100000>; + vdd-apc-supply = <&pm8226_s2>; + vdd-apc-optional-prim-supply = <&ncp6335d>; + vdd-apc-optional-sec-supply = <&fan53555>; + vdd-mx-supply = <&pm8226_l3_ao>; + qcom,vdd-mx-vmax = <1350000>; + qcom,vdd-mx-vmin-method = <1>; + qcom,vdd-apc-step-up-limit = <1>; + qcom,vdd-apc-step-down-limit = <1>; + qcom,cpr-ref-clk = <19200>; + qcom,cpr-timer-delay = <5000>; + qcom,cpr-timer-cons-up = <1>; + qcom,cpr-timer-cons-down = <2>; + qcom,cpr-irq-line = <0>; + qcom,cpr-step-quotient = <15>; + qcom,cpr-up-threshold = <1>; + qcom,cpr-down-threshold = <2>; + qcom,cpr-idle-clocks = <5>; + qcom,cpr-gcnt-time = <1>; + qcom,cpr-clamp-timer-interval = <1>; + qcom,cpr-apc-volt-step = <5000>; + + qcom,vsens-corner-map = <1 2 2>; + vdd-vsens-corner-supply = <&vsens_apc0_corner>; + vdd-vsens-voltage-supply = <&vsens_apc0_voltage>; + + rpm-apc-supply = <&rpm_apc_vreg>; + qcom,rpm-apc-corner-map = <4 4 5 5 7 7 7 7 7 7 7 7>; + + qcom,cpr-fuse-row = <138 1>; + qcom,cpr-fuse-bp-cpr-disable = <36>; + qcom,cpr-fuse-bp-scheme = <37>; + qcom,cpr-fuse-target-quot = <24 12 0>; + qcom,cpr-fuse-target-quot-size = <12 12 12>; + qcom,cpr-fuse-ro-sel = <54 38 41>; + qcom,cpr-fuse-revision = <140 26 2 0>; + qcom,cpr-fuse-redun-sel = <138 57 1 1 1>; + qcom,cpr-fuse-redun-row = <139 1>; + qcom,cpr-fuse-redun-target-quot = <24 12 0>; + qcom,cpr-fuse-redun-ro-sel = <46 36 39>; + qcom,cpr-fuse-cond-min-volt-sel = <54 42 6 7 1>; + qcom,cpr-cond-min-voltage = <1140000>; + qcom,cpr-fuse-uplift-sel = <22 53 1 0 0>; + qcom,cpr-uplift-voltage = <50000>; + qcom,cpr-uplift-quotient = <0 0 120>; + qcom,cpr-uplift-max-volt = <1350000>; + qcom,cpr-uplift-speed-bin = <1>; + qcom,speed-bin-fuse-sel = <22 0 3 0>; + qcom,cpr-corner-map = <1 1 2 2 3 3 3 3 3 3 3 3>; + qcom,cpr-corner-frequency-map = + <1 300000000>, + <2 384000000>, + <3 600000000>, + <4 787200000>, + <5 998400000>, + <6 1094400000>, + <7 1190400000>, + <8 1305600000>, + <9 1344000000>, + <10 1401600000>, + <11 1497600000>, + <12 1593600000>; + qcom,pvs-version-fuse-sel = <22 4 2 0>; + qcom,cpr-speed-bin-max-corners = + <0 1 2 4 7>, + <1 1 2 4 12>, + <2 1 2 4 10>, + <5 1 2 4 14>; + qcom,cpr-fuse-target-quot-scale = + <0 1>, + <0 1>, + <0 1>; + qcom,cpr-quot-adjust-scaling-factor-max = <0 650 650>; + qcom,cpr-fuse-quot-offset = + <138 53 5 0>, + <138 53 5 0>, + <138 48 5 0>, + <138 58 5 0>; + qcom,cpr-fuse-redun-quot-offset = + <200 53 5 0>, + <200 53 5 0>, + <200 48 5 0>, + <200 58 5 0>; + qcom,cpr-fuse-init-voltage = + <27 36 6 0>, + <27 18 6 0>, + <27 0 6 0>; + qcom,cpr-fuse-redun-init-voltage = + <140 36 6 0>, + <140 18 6 0>, + <140 0 6 0>; + qcom,cpr-init-voltage-ref = <1050000 1150000 1280000>; + qcom,cpr-init-voltage-step = <10000>; + qcom,cpr-voltage-ceiling-override = + <1 1 1050000 1050000 1150000 1150000 1280000 + 1280000 1280000 1280000 1280000 1280000 + 1280000 1280000>; + qcom,cpr-voltage-floor-override = + <1 1 1050000 1050000 1050000 1050000 1060000 + 1070000 1080000 1090000 1100000 1100000 + 1100000 1100000>; + qcom,cpr-scaled-init-voltage-as-ceiling; + + qcom,cpr-fuse-version-map = + <0xffffffff 0xffffffff 2 4 4 4>, + <0xffffffff 0xffffffff 2 6 6 6>, + <0xffffffff 0xffffffff 3 4 4 4>; + qcom,cpr-quotient-adjustment = + <0 0 (-210)>, + <0 0 (-60)>, + <0 0 (-94)>; + qcom,cpr-quot-offset-adjustment = + <0 0 (-5)>; + qcom,cpr-init-voltage-adjustment = + <0 0 (-100000)>, + <0 0 (-100000)>, + <0 0 (-45000)>; + qcom,cpr-fuse-min-quot-diff = <0 0 40>; + qcom,cpr-min-quot-diff-adjustment = + <0 0 0>, + <0 0 72>, + <0 0 104>; + qcom,cpr-floor-to-ceiling-max-range = + <(-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1)>, + <(-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1) (-1)>, + <(-1) (-1) (-1) (-1) (-1) (-1) (-1) 50000 50000 50000 50000 50000>; + qcom,cpr-virtual-corner-init-voltage-adjustment = + <0 0 0 (-10000) 0 0 0 0 0 0 0 0>, + <0 0 0 0 0 0 0 0 0 0 0 (-20000)>, + <0 0 0 0 0 0 0 0 0 0 0 (-30000)>; + qcom,cpr-virtual-corner-quotient-adjustment = + <0 0 0 100 0 0 0 0 0 0 0 0>, + <0 0 0 0 0 0 0 0 0 0 0 (-300)>, + <0 0 0 (-60) 0 0 0 0 0 0 0 0>; + qcom,cpr-cpus = <&CPU0 &CPU1 &CPU2 &CPU3>; + qcom,cpr-online-cpu-virtual-corner-init-voltage-adjustment = + /* 1st fuse version tuple matched */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 0 CPUs online */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 1 CPUs online */ + <0 0 0 (-5000) (-5000) (-5000) (-5000) (-5000) (-10000) 0 (-10000) (-10000) >, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 4 CPUs online */ + /* 2nd fuse version tuple matched */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 0 CPUs online */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 1 CPUs online */ + <0 0 0 (-5000) (-5000) (-5000) (-5000) (-5000) (-10000) 0 (-10000) (-10000) >, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 4 CPUs online */ + /* 3rd fuse version tuple matched */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 0 CPUs online */ + <0 0 0 (-10000) (-10000) (-10000) (-15000) (-15000) (-20000) 0 (-20000) (-30000) >, /* 1 CPUs online */ + <0 0 0 (-5000) (-5000) (-5000) (-5000) (-5000) (-10000) 0 (-10000) (-10000) >, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>; /* 4 CPUs online */ + qcom,cpr-online-cpu-virtual-corner-quotient-adjustment = + /* 1st fuse version tuple matched */ + <0 0 0 (-6) (-6) (-6) (-9) (-9) (-12) 0 (-12) (-18)>, /* 0 CPUs online */ + <0 0 0 (-6) (-6) (-6) (-9) (-9) (-12) 0 (-12) (-18)>, /* 1 CPUs online */ + <0 0 0 (-3) (-3) (-3) (-3) (-3) (-6) 0 (-6) (-6)>, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 4 CPUs online */ + /* 2nd fuse version tuple matched */ + <0 0 0 (-6) (-6) (-6) (-9) (-9) (-12) 0 (-12) (-18)>, /* 0 CPUs online */ + <0 0 0 (-6) (-6) (-6) (-9) (-9) (-12) 0 (-12) (-18)>, /* 1 CPUs online */ + <0 0 0 (-3) (-3) (-3) (-3) (-3) (-6) 0 (-6) (-6)>, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 4 CPUs online */ + /* 3rd fuse version tuple matched */ + <0 0 0 (-21) (-21) (-21) (-32) (-32) (-42) 0 (-42) (-63)>, /* 0 CPUs online */ + <0 0 0 (-21) (-21) (-21) (-32) (-32) (-42) 0 (-42) (-63)>, /* 1 CPUs online */ + <0 0 0 (-11) (-11) (-11) (-11) (-11) (-21) 0 (-21) (-21)>, /* 2 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>, /* 3 CPUs online */ + <0 0 0 0 0 0 0 0 0 0 0 0>; /* 4 CPUs online */ + qcom,cpr-allowed = + <0>, + <1>, + <1>; + + qcom,fuse-remap-base-row = <1000>; + qcom,fuse-remap-source = + <140 7 3 0>, + <138 45 5 0>; + qcom,cpr-fuse-quot-offset-scale = <5 5 5>; + + qcom,cpr-aging-sensor-id = <17, 18>; + qcom,cpr-aging-ref-corner = <4>; + qcom,cpr-aging-ref-voltage = <1050000>; + qcom,cpr-max-aging-margin = <15000>; + qcom,cpr-de-aging-allowed = + <0>, + <0>, + <1>; + qcom,cpr-non-collapsible-sensors= <7 12 17 22>; + qcom,cpr-aging-ro-scaling-factor = <3500>; + qcom,cpr-ro-scaling-factor = <0 2500 2500 2500 0 0 0 0>; + qcom,cpr-aging-derate = <1000 1000 1250>; + qcom,cpr-fuse-aging-init-quot-diff = + <101 0 8 0>, + <101 8 8 0>; + + qcom,cpr-thermal-sensor-id = <9>; + qcom,cpr-disable-temp-threshold = <5>; + qcom,cpr-enable-temp-threshold = <10>; + }; diff --git a/Documentation/devicetree/bindings/regulator/cpr2-gfx-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr2-gfx-regulator.txt new file mode 100644 index 000000000000..0ffd80c0740f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr2-gfx-regulator.txt @@ -0,0 +1,395 @@ +Qualcomm Technologies, Inc. CPR regulator for Graphics + +GFX CPR controller monitors the voltage of the graphics processor(GPU) +power rail. The CPR open-loop voltages are stored in hardware fuses +for GFX CPR controller. However, the CPR target quotients must be defined +in device tree. This driver supports CPR version 2 controller. + +This document describes the bindings that apply for GFX CPR controller. + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,cpr2-gfx-regulator" + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of the CPR + controller and the first fuse row. + +- reg-names + Usage: required + Value type: <stringlist> + Definition: Address names. Must be "rbcpr" and "efuse_addr". Must be + specified in the same order as the corresponding addresses + are specified in the reg property. + +- regulator-name + Usage: required + Value type: <string> + Definition: A string used to describe the regulator. + +- clocks + Usage: required + Value type: <prop-encoded-array> + Definition: Array of clock tuples in which each tuple consists of a + phandle to a clock device and a clock ID number. The + following clocks must be specified: GFX RBCPR, GFX RBCPR + AHB. + +- clock-names + Usage: required + Value type: <stringlist> + Definition: Clock names. This list must match up 1-to-1 with the clocks + specified in the 'clocks' property. "core_clk" and "iface_clk" + must be specified. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: CPR interrupt specifier. + +- vdd-gfx-supply + Usage: required + Value type: <phandle> + Definition: phandle of the underlying regulator device that is managed + by this CPR controller. + +- qcom,cpr-corners + Usage: required + Value type: <u32> + Definition: Number of voltage corners present. Many other + properties are sized based upon this value. + +- regulator-min-microvolt + Usage: required + Value type: <u32> + Definition: Minimum corner value which should be 1 to represent the + lowest supported corner. + +- regulator-max-microvolt + Usage: required + Value type: <u32> + Definition: Maximum corner value which should be equal to largest value + listed in qcom,cpr-corners. + +- qcom,cpr-voltage-ceiling + Usage: required + Value type: <prop-encoded-array> + Definition: Array of ceiling voltages in microvolts for voltage corners + ordered from lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,cpr-corners. + +- qcom,cpr-voltage-floor + Usage: required + Value type: <prop-encoded-array> + Definition: Array of floor voltages in microvolts for voltage corners + ordered from lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,cpr-corners. + +- qcom,vdd-gfx-step-up-limit + Usage: required + Value type: <u32> + Definition: Limit of vdd-gfx-supply steps for scaling up. + +- qcom,vdd-gfx-step-down-limit + Usage: required + Value type: <u32> + Definition: Limit of vdd-gfx-supply steps for scaling down. + +- qcom,cpr-ref-clk + Usage: required + Value type: <u32> + Definition: The reference clock rate in kHz. + +- qcom,cpr-timer-delay + Usage: required + Value type: <u32> + Definition: The delay in microseconds for the timer interval. + +- qcom,cpr-timer-cons-up + Usage: required + Value type: <u32> + Definition: The number of consecutive CPR step up events needed to + to trigger a up interrupt. Supported values: 0 - 15. + +- qcom,cpr-timer-cons-down + Usage: required + Value type: <u32> + Definition: The number of consecutive CPR step down events needed to + to trigger a down interrupt. Supported values: 0 - 15. + +- qcom,cpr-irq-line + Usage: required + Value type: <u32> + Definition: Internal interrupt route signal of RBCPR, one of 0, 1 or 2. + +- qcom,cpr-step-quotient + Usage: required + Value type: <u32> + Definition: Defines the number of CPR quotient (i.e. Ring Oscillator(RO) + count) per vdd-gfx-supply output voltage step. A single + integer value to be used for all RO's. + +- qcom,cpr-gfx-volt-step + Usage: required + Value type: <u32> + Definition: The voltage in microvolts of a single step of the VDD supply + regulator being controlled by CPR. + +- qcom,cpr-up-threshold + Usage: required + Value type: <u32> + Definition: The number CPR error steps required to generate an up event. + Supported values: 0 - 31. + +- qcom,cpr-down-threshold + Usage: required + Value type: <u32> + Definition: The number CPR error steps required to generate a down + event. Supported values: 0 - 31. + +- qcom,cpr-idle-clocks + Usage: required + Value type: <u32> + Definition: The number of CPR core clock cycles for the CPR controller + to wait in transitional states. Supported values: 0 - 31. + +- qcom,cpr-gcnt-time + Usage: required + Value type: <u32> + Definition: The time for gate count in microseconds. + +- qcom,cpr-fuse-init-voltage + Usage: required + Value type: <prop-encoded-array> + Definition: Array of quadruples in which each quadruple specifies a fuse + location to read in order to get an initial voltage for a + voltage corner. The fuse values are encoded as voltage steps + higher or lower than the voltages defined in + qcom,cpr-init-voltage-ref. Each step corresponds to the + voltage defined by the qcom,cpr-init-voltage-step property. + The 3 elements in one quadruple are: + [0] => fuse row number + [1] => bit offset within the row + [2] => number of bits in the fuse parameter + The quadruples are ordered from the lowest voltage corner to + the highest voltage corner. The number for quadruples must be + equal to the value specified in qcom,cpr-corners property. + +- qcom,cpr-init-voltage-ref + Usage: required + Value type: <prop-encoded-array> + Definition: Array of reference voltages in microvolts used when decoding + the initial voltage fuse values. The elements in the array + are ordered from lowest voltage corner to highest voltage + corner. This property must be of length defined by + qcom,cpr-corners. + +- qcom,cpr-init-voltage-step + Usage: required if qcom,cpr-fuse-init-voltage is specified. + Value type: <u32> + Definition: The voltage step size in microvolts of the CPR initial + voltage fuses described by the qcom,cpr-fuse-init-voltage + property. + +- qcom,cpr-ro-count + Usage: required + Value type: <u32> + Definition: Defines the number of Ring Oscillator(RO)s present. + +- qcom,cpr-target-quotients + Usage: required + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists. Each tuple defines the CPR + target quotient for each ring oscillator (RO) for a given corner. + Each tuple must be of the length defined by qcom,cpr-ro-count. + If a given RO is unused for a corner, then its target quotient + should be specified as 0. Each tuple list must contain the + number of tuples defined by the qcom,cpr-corners property. + The tuples in a given list are ordered from the lowest corner + to the highest corner. The tuple list grouping must contain + exactly 1 list if qcom,cpr-fuse-version-map is not specified or + the number of tuple lists must be equal to the number of tuples + in qcom,cpr-fuse-version-map. + +- vdd-mx-supply + Usage: optional + Value type: <phandle> + Definition: Regulator to supply memory power as dependency of VDD_GFX. + +- qcom,vdd-mx-corner-map + Usage: required if vdd-mx-supply is specified. + Value type: <prop-encoded-array> + Definition: Array of integers which define the mapping of the VDD_MX corner + to the corresponding GFX voltage corner. The elements in + the array are ordered from lowest voltage corner to highest + voltage corner. The length of this property must be equal to + the value defined by qcom,cpr-corners. + +- mem-acc-supply + Usage: optional + Value type: <phandle> + Definition: Regulator to vote for the memory accelerator configuration. + Not Present: memory accelerator configuration not supported. + +- qcom,cpr-fuse-revision + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of 3 integer elements which define the location of the + bits for the CPR fusing revision fuse parameter. + The 3 elements are: + [0] => fuse row number + [1] => bit offset within the row + [2] => number of bits in the fuse parameter + The fusing revision value is used to determine specific + adjustments that maybe required on some chips. + +- qcom,process-id-fuse + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of 3 integer elements which define the location of the + bits for the process node id fuse parameter. + The 3 elements are: + [0] => fuse row number + [1] => bit offset within the row + [2] => number of bits in the fuse parameter + This value is used to determine the specific adjustments that + may be required on some chips. + +- qcom,foundry-id-fuse + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of 3 integer elements which define the location of the + bits for the foundry identification fuse parameter. + The 3 elements are: + [0] => fuse row number + [1] => bit offset within the row + [2] => number of bits in the fuse parameter + This value is used to determine the specific adjustments that + may be required on some chips. + +- qcom,cpr-fuse-version-map + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of integer tuples which each match to a given + combination of CPR fuse parameter values. Each tuple + consists of 3 elements. The elements in one tuple are: + [0] => the foundry identification + [1] => the CPR fuse revision + [2] => the process node id + Any element in a tuple may use the value 0xffffffff as a + wild card which will match against any fuse parameter value. + The first tuple that matches against the fuse values read + from hardware will be used. This property is used by several + properties to provide an index into their lists. + +- qcom,cpr-init-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of integer tuples of initial voltage adjustments in + microvolts to add to the fused initial voltage values of + each fuse corner. The elements in a tuple are ordered from + lowest voltage corner to highest voltage corner. Each tuple + must be of the length defined by qcom,cpr-corners. + If the qcom,cpr-fuse-version-map property is specified, then + qcom,cpr-init-voltage-adjustment must contain the same + number of tuples as qcom,cpr-fuse-version-map. These tuples + are then mapped one-to-one in the order specified. E.g. if + the second qcom,cpr-fuse-version-map tuple matches for a + given device, then the initial voltage adjustments defined + in the second qcom,cpr-init-voltage-adjustment tuple will be + applied. If the qcom,cpr-fuse-version-map property is not + specified, then qcom,cpr-init-voltage-adjustment must contain + a single tuple which is then applied unconditionally. This + property can be used to add or subtract static initial voltage + margin from the regulator managed by the CPR controller. + +- qcom,cpr-init-voltage-as-ceiling + Usage: optional + Value type: <empty> + Definition: Boolean which indicates that the ceiling voltage used for + a given virtual corner may be reduced to the initial voltage + value. + + - qcom,cpr-enable + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the CPR controller + should operate in closed-loop mode (i.e. CPR sensing loop + enabled) as opposed to open-loop mode (i.e. CPR sensing loop + disabled) by default. +======= +Example +======= +gfx_vreg_corner: regulator@98000 { + compatible = "qcom,cpr2-gfx-regulator"; + reg = <0x98000 0x1000>, <0xa4000 0x1000>; + reg-names = "rbcpr", "efuse_addr"; + clocks = <&clock_gcc clk_gcc_rbcpr_gfx_clk>, + <&clock_gcc clk_gcc_rbcpr_gfx_ahb_clk>; + clock-names = "core_clk", "iface_clk"; + interrupts = <0 150 0>; + + regulator-name = "gfx_corner"; + qcom,cpr-corners = <8>; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <8>; + + qcom,cpr-voltage-ceiling = <810000 865000 900000 950000 1010000 1050000 1110000 1165000>; + qcom,cpr-voltage-floor = <755000 755000 755000 795000 835000 855000 920000 945000>; + vdd-gfx-supply = <&pm8004_s5>; + + vdd-mx-supply = <&pm8950_s6_level_ao>; + qcom,vdd-mx-vmax = <RPM_SMD_REGULATOR_LEVEL_TURBO>; + qcom,vdd-mx-corner-map = <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS_PLUS>, + <RPM_SMD_REGULATOR_LEVEL_NOM>, + <RPM_SMD_REGULATOR_LEVEL_NOM_PLUS>, + <RPM_SMD_REGULATOR_LEVEL_TURBO>; + + mem-acc-supply = <&mem_acc_gfx_vreg_corner>; + + qcom,cpr-ref-clk = <19200>; + qcom,cpr-timer-delay = <5000>; + qcom,cpr-timer-cons-up = <0>; + qcom,cpr-timer-cons-down = <2>; + qcom,cpr-irq-line = <0>; + qcom,cpr-step-quotient = <16>; + qcom,cpr-up-threshold = <2>; + qcom,cpr-down-threshold = <4>; + qcom,cpr-idle-clocks = <15>; + qcom,cpr-gcnt-time = <1>; + qcom,vdd-gfx-step-up-limit = <1>; + qcom,vdd-gfx-step-down-limit = <1>; + qcom,cpr-gfx-volt-step = <5000>; + + qcom,cpr-init-voltage-ref = <865000 865000 950000 950000 950000 1050000 1050000 1165000>; + qcom,cpr-fuse-init-voltage = + <72 50 5>, + <72 50 5>, + <72 45 5>, + <72 45 5>, + <72 45 5>, + <72 40 5>, + <72 40 5>, + <72 35 5>; + qcom,cpr-init-voltage-step = <12500>; + qcom,cpr-ro-count = <8>; + qcom,cpr-init-voltage-as-ceiling; + qcom,cpr-init-voltage-adjustment = + <(-55000) 0 (-60000) 0 (60000) 0 (65000) 0>; + qcom,cpr-target-quotients = + <513 489 620 574 237 272 144 177>, + <562 536 675 627 264 303 163 199>, + <631 606 744 699 315 356 205 245>, + <780 752 902 854 412 459 283 330>, + <879 847 1001 949 490 535 351 400>, + <1010 971 1138 1080 579 626 428 479>, + <1086 1039 1210 1146 643 684 489 538>, + <1238 1179 1367 1290 752 789 586 633>; +}; diff --git a/Documentation/devicetree/bindings/regulator/cpr3-hmss-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr3-hmss-regulator.txt new file mode 100644 index 000000000000..2af3cbfd0584 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr3-hmss-regulator.txt @@ -0,0 +1,556 @@ +Qualcomm Technologies, Inc. CPR3 Regulator - HMSS Specific Bindings + +HMSS CPR3 controllers each support two CPR threads that monitor the voltage of +a pair of application processor (HMSS) clusters that are powered by a shared +regulator supply. These controllers have a hardware aggregator to combine the +UP/DOWN requests from each CPR thread into a single unified request. They also +have a hardware channel to use these requests to directly change the supply +voltage at the PMIC via the SPM without software intervention. + +HMSS CPR3 controllers also have to take into account the state of the memory +array power mux (APM) when scaling voltage to ensure that memory always receives +a sufficiently high voltage. + +Both CPR open-loop voltages and CPR target quotients are stored in hardware +fuses for HMSS CPR3 controllers. + +This document describes the HMSS specific CPR3 bindings. + +======================= +Required Node Structure +======================= + +CPR3 regulators must be described in three levels of devices nodes. The first +level describes the CPR3 controller. The second level describes one or more +hardware threads managed by the controller. The third level describes one or +more logical regulators handled by each CPR thread. + +All platform independent cpr3-regulator binding guidelines defined in +cpr3-regulator.txt also apply to cpr3-hmss-regulator devices. + +==================================== +First Level Nodes - CPR3 Controllers +==================================== + +HMSS specific properties: +- compatible + Usage: required + Value type: <string> + Definition: should be one of the following: + "qcom,cpr3-msm8996-v1-hmss-regulator", + "qcom,cpr3-msm8996-v2-hmss-regulator", + "qcom,cpr3-msm8996-v3-hmss-regulator", + "qcom,cpr3-msm8996-hmss-regulator", + "qcom,cpr3-msm8996pro-hmss-regulator". + If the SoC revision is not specified, then it is assumed to + be the most recent revision of MSM8996, i.e. v3. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: CPR interrupt specifier and a hardware closed-loop ceiling + interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. "cpr" + and "ceiling" must be specified. + +- qcom,apm-ctrl + Usage: required on systems that need APM management + Value type: <phandle> + Definition: phandle of memory array power mux (APM) controller device + node for the APM that is used by the HMSS VDD supply + +- qcom,apm-threshold-voltage + Usage: required if qcom,apm-ctrl is specified + Value type: <u32> + Definition: Specifies the APM threshold voltage in microvolts. If the + vdd-supply voltage is greater than or equal to this level, + then the APM is switched to use the vdd-supply. If the + vdd-supply voltage is below this level, then the APM is + switched to use the system-supply. + +- qcom,apm-hysteresis-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the voltage delta in microvolts between the APM + threshold voltage and the highest corner open-loop voltage + which may be used as the ceiling for the corner. If this + property is not specified, then a value of 0 is assumed. + +- qcom,system-supply-max-voltage + Usage: required if qcom,vdd-threadN-ldo-supply is specified for any + CPR3 regulator managed by any CPR3 thread of this controller. + Value type: <u32> + Definition: Maximum voltage setpoint for the system-supply regulator. + +- qcom,mem-acc-supply-threshold-voltage + Usage: required if mem-acc-supply or mem-acc-threadN-supply is + specified and the CPR3 controller or any of the CPR3 regulators + it controls needs to manage mem-acc settings. + Value type: <u32> + Definition: Specifies the mem-acc-supply threshold voltage in microvolts. + If the vdd-supply voltage is greater than or equal to this + level, then the mem-acc-supply regulator is switched to the + high voltage corner setting. Conversely, if the vdd-supply + voltage is below this level, then the mem-acc-supply regulator + is switched to the low voltage corner setting. + +- qcom,mem-acc-supply-corner-map + Usage: required if mem-acc-supply or mem-acc-threadN-supply is + specified and the CPR3 controller or any of the CPR3 regulators + it controls needs to manage mem-acc settings. + Value type: <prop-encoded-array> + Definition: A tuple containing two integers which defines the mem-acc-supply + corner to use for low and high vdd-supply voltages, respectively. + +- qcom,cpr-up-down-delay-time + Usage: required + Value type: <u32> + Definition: The time to delay in nanoseconds between consecutive CPR + measurements when the last measurement recommended + increasing or decreasing the vdd-supply voltage. + +- qcom,cpr-hw-closed-loop + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the HMSS CPR3 controller + should operate in hardware closed-loop mode as opposed to + software closed-loop mode. + +- vdd-limit-supply + Usage: required + Value type: <phandle> + Definition: phandle of the VDD supply limit regulator which controls the + CPR ceiling and floor voltages when operating in hardware + closed-loop mode. + +- qcom,cpr-clock-throttling + Usage: optional + Value type: <u32> + Definition: Specifies the power domains for which CPR processor clock + throttling should be enabled. This feature reduces the + processor's clock frequency when it is resuming from a low + power mode until CPR is able to raise the supply voltage to + a final settled value. The following bits may be set: + BIT(0) - Power cluster L2 cache + BIT(1) - Power cluster core 1 + BIT(2) - Power cluster core 0 + BIT(5) - Performance cluster L2 cache + BIT(6) - Performance cluster core 1 + BIT(7) - Performance cluster core 0 + +- mem-acc-threadN-supply + Usage: optional + Value type: <phandle> + Definition: phandle of the regulator device which manages mem-acc + configuration for the clusters per CPR thread. 'N' must + match with the hardware thread ID of the thread it controls. + +- vdd-threadN-ldo-supply + Usage: optional + Value type: <phandle> + Definition: phandle of the regulator device which manages LDO and BHS + modes for the clusters per CPR thread. 'N' must match with + the hardware thread ID of the thread it controls. + +- vdd-threadN-ldo-ret-supply + Usage: required if vdd-threadN-ldo-supply is specified for + this CPR thread. + Value type: <phandle> + Definition: phandle of the regulator device which manages LDO retention + modes for the clusters per CPR thread. 'N' must match with + the hardware thread ID of the thread it controls. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +HMSS specific properties: +N/A + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +HMSS specific properties: +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. This value must be 5 + for HMSS. These fuse corners are: MinSVS, LowSVS, SVS, + Nominal, and Turbo. Note that a specific fused target + quotient is available for the LowSVS corner but a fused + open-loop voltage is not available. The LowSVS open-loop + voltage is calculated using linear interpolation between + the MinSVS and SVS values. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. For HMSS the maximum + supported value is 16. The first 8 fuse combos correspond + to speed bin fuse value 0 along with CPR revision fuse + values 0 to 7. The last 8 fuse combos correspond to speed + bin fuse value 1 along with CPR revision fuse values 0 to 7. + +- qcom,cpr-speed-bins + Usage: optional + Value type: <u32> + Definition: Specifies the number of speed bins being supported by the + device. This value is utilized by several other properties. + Supported values are 1 up to the maximum possible for a + given regulator type. For HMSS the maximum supported value + is 2. + +- qcom,is-cbf-regulator + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the CPR3 regulator + corresponds to the CBF clock domain. Special fuses are + defined for the CBF CPR3 regulator on MSM8996-Pro chips. + +- qcom,ldo-min-headroom-voltage + Usage: required if vdd-threadN-ldo-supply is specified for the + CPR3 thread containing this CPR3 regulator and this CPR3 + regulator needs to manage the cluster LDO state. + Value type: <u32> + Definition: Voltage in microvolts required between the VDD_APCC voltage + and the LDO output in order for the LDO to be operational. + +- qcom,ldo-max-headroom-voltage + Usage: required if vdd-threadN-ldo-supply is specified for the + CPR3 thread containing this CPR3 regulator and this CPR3 + regulator needs to manage the cluster LDO state. + Value type: <u32> + Definition: Maximum voltage difference in microvolts between the vdd-supply + voltage and the LDO output voltage in order for active LDO mode + to be operational. + +- qcom,ldo-adjust-voltage + Usage: optional + Value type: <u32> + Definition: Voltage in microvolts used to offset margins between PMIC + output and CPU. + +- qcom,ldo-max-voltage + Usage: required if qcom,ldo-min-headroom-voltage is specified for this + CPR3 regulator. + Value type: <u32> + Definition: Voltage in microvolts which represents the maximum + physically supported voltage output of the LDO hardware. + +- qcom,uses-mem-acc + Usage: required if mem-acc-threadN-supply is specified for the + CPR3 thread containing this CPR3 regulator and this CPR3 + regulator needs to manage mem-acc settings. + Value type: <empty> + Definition: Boolean flag which indicates that this CPR3 regulator must + manage mem-acc. + +- qcom,ldo-disable + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that LDO mode usage is + disallowed. If this flag is present, then the + vdd-threadN-ldo-supply mode will not be modified. + +- qcom,allow-quotient-interpolation + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that it is acceptable to use + interpolated CPR target quotient values. These values are + interpolated between the target quotient Fmax fuse values. + +- qcom,cpr-pd-bypass-mask + Usage: required + Value type: <u32> + Definition: Specifies the power domains associated with this CPR3 + regulator. The following bits may be set: + BIT(0) - Power cluster L2 cache + BIT(1) - Power cluster core 1 + BIT(2) - Power cluster core 0 + BIT(3) - CBF + BIT(4) - L3 cache + BIT(5) - Performance cluster L2 cache + BIT(6) - Performance cluster core 1 + BIT(7) - Performance cluster core 0 + +- qcom,cpr-dynamic-floor-corner + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which defines for each fuse combination + the CPR corner whose closed-loop voltage should be used as + a CPR floor voltage whenever the power domains for this CPR3 + regulator are bypassed. Supported values are 0 and 1 to N. + A value of 0 means that no dynamic floor is needed. N is + the number of corners defined for this fuse combination in + the qcom,cpr-corners property. + + The list must contain qcom,cpr-fuse-combos number of + elements in which case the elements are matched to fuse + combinations 1-to-1 or qcom,cpr-speed-bins number of + elements in which case the elements are matched to + speed bins 1-to-1 or exactly 1 element which is used + regardless of the fuse combination and speed bin found + on a given chip. + +======= +Example +======= + +apcc_cpr: cpr3-ctrl@99e8000 { + compatible = "qcom,cpr3-msm8996-hmss-regulator"; + reg = <0x099e8000 0x4000>, <0x00074000 0x1000>; + reg-names = "cpr_ctrl", "fuse_base"; + clocks = <&clock_gcc clk_gcc_hmss_rbcpr_clk>; + clock-names = "core_clk"; + interrupts = <0 48 0>, <0 47 0>; + interrupt-names = "cpr", "ceiling"; + qcom,cpr-interrupt-affinity = <&CPU0 &CPU1>; + qcom,cpr-ctrl-name = "apcc"; + + qcom,cpr-sensor-time = <1000>; + qcom,cpr-loop-time = <5000000>; + qcom,cpr-idle-cycles = <15>; + qcom,cpr-up-down-delay-time = <3000>; + qcom,cpr-step-quot-init-min = <13>; + qcom,cpr-step-quot-init-max = <13>; + qcom,cpr-count-mode = <2>; + + qcom,apm-ctrl = <&apc_apm>; + qcom,apm-threshold-voltage = <850000>; + qcom,apm-hysteresis-voltage = <5000>; + qcom,system-supply-max-voltage = <1015000>; + qcom,mem-acc-supply-threshold-voltage = <700000>; + qcom,mem-acc-supply-corner-map = <1 2>; + + vdd-supply = <&pm8994_s11>; + qcom,voltage-step = <5000>; + vdd-limit-supply = <&pm8994_s11_limit>; + mem-acc-thread0-supply = <&apc0_pwrcl_mem_acc_vreg>; + mem-acc-thread1-supply = <&apc1_perfcl_mem_acc_vreg>; + mem-acc-supply = <&apcc_l3_mem_acc_vreg>; + vdd-thread0-ldo-supply = <&kryo0_vreg>; + vdd-thread1-ldo-supply = <&kryo1_vreg>; + vdd-thread0-ldo-ret-supply = <&kryo0_retention_vreg>; + vdd-thread1-ldo-ret-supply = <&kryo1_retention_vreg>; + + qcom,cpr-enable; + qcom,cpr-hw-closed-loop; + qcom,cpr-clock-throttling = <0x20>; + + qcom,cpr-aging-ref-voltage = <905000>; + + thread@0 { + qcom,cpr-thread-id = <0>; + qcom,cpr-consecutive-up = <0>; + qcom,cpr-consecutive-down = <2>; + qcom,cpr-up-threshold = <0>; + qcom,cpr-down-threshold = <2>; + + apc0_pwrcl_vreg: regulator-pwrcl { + regulator-name = "apc0_pwrcl_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <19>; + + qcom,cpr-pd-bypass-mask = <0x07>; + qcom,cpr-fuse-corners = <5>; + qcom,cpr-fuse-combos = <1>; + qcom,cpr-corners = <19>; + + qcom,ldo-min-headroom-voltage = <150000>; + qcom,ldo-max-headroom-voltage = <470000>; + qcom,ldo-max-voltage = <805000>; + qcom,uses-mem-acc; + + qcom,cpr-corner-fmax-map = <1 2 6 11 19>; + + qcom,cpr-voltage-ceiling = + <670000 670000 745000 745000 745000 + 745000 905000 905000 905000 905000 + 905000 1015000 1015000 1015000 1015000 + 1015000 1015000 1015000 1015000>; + qcom,cpr-voltage-floor = + <520000 550000 555000 565000 585000 + 615000 635000 655000 690000 720000 + 740000 750000 760000 770000 780000 + 790000 815000 840000 850000>; + qcom,corner-frequencies = + <192000000 268800000 307200000 + 345600000 403200000 480000000 + 576000000 633600000 729600000 + 806400000 883200000 960000000 + 1017600000 1113600000 1190400000 + 1267200000 1344000000 1420800000 + 1459200000>; + + qcom,cpr-ro-scaling-factor = + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2147 2226 2310 2312 + 2450 2447 2603 2600 0 0 0 0>, + < 0 0 0 0 1989 2079 2066 2083 + 2193 2201 2283 2296 0 0 0 0>; + + qcom,cpr-open-loop-voltage-fuse-adjustment = + <0 0 0 0 0>; + qcom,cpr-closed-loop-voltage-fuse-adjustment = + <0 0 0 0 0>; + + qcom,allow-voltage-interpolation; + qcom,allow-quotient-interpolation; + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + + qcom,cpr-aging-max-voltage-adjustment = <25000>; + qcom,cpr-aging-ref-corner = <11>; + qcom,cpr-aging-ro-scaling-factor = <3200>; + qcom,cpr-aging-derate = + <1000 1000 1000 1000 1000 1000 1000 1000 + 1000 1000 1000 1000 1000 1000 1000 1000 + 1000 1000 1000>; + qcom,allow-aging-voltage-adjustment = <1>; + }; + + apc0_cbf_vreg: regulator-cbf { + regulator-name = "apc0_cbf_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <10>; + qcom,is-cbf-regulator; + + qcom,cpr-pd-bypass-mask = <0x18>; + qcom,cpr-fuse-corners = <5>; + qcom,cpr-fuse-combos = <1>; + qcom,cpr-corners = <10>; + + qcom,cpr-corner-fmax-map = <1 2 5 9 10>; + + qcom,cpr-voltage-ceiling = + <605000 670000 745000 745000 745000 + 905000 905000 905000 905000 1015000>; + qcom,cpr-voltage-floor = + <520000 545000 565000 595000 635000 + 660000 690000 730000 750000 850000>; + + qcom,corner-frequencies = + <150000000 307200000 384000000 + 499200000 595200000 691200000 + 787200000 883200000 960000000 + 1036800000>; + + qcom,cpr-ro-scaling-factor = + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2222 2275 2506 2491 + 2649 2640 2886 2866 0 0 0 0>, + < 0 0 0 0 2147 2226 2310 2312 + 2450 2447 2603 2600 0 0 0 0>, + < 0 0 0 0 1989 2079 2066 2083 + 2193 2201 2283 2296 0 0 0 0>; + + qcom,cpr-open-loop-voltage-fuse-adjustment = + <0 0 0 0 0>; + qcom,cpr-closed-loop-voltage-fuse-adjustment = + <0 0 0 0 0>; + + qcom,allow-voltage-interpolation; + qcom,allow-quotient-interpolation; + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + + qcom,cpr-aging-max-voltage-adjustment = <25000>; + qcom,cpr-aging-ref-corner = <9>; + qcom,cpr-aging-ro-scaling-factor = <3200>; + qcom,cpr-aging-derate = + <1000 1000 1000 1000 1000 1000 1000 1000 + 1000 1000>; + qcom,allow-aging-voltage-adjustment = <1>; + }; + }; + + thread@1 { + qcom,cpr-thread-id = <1>; + qcom,cpr-consecutive-up = <0>; + qcom,cpr-consecutive-down = <2>; + qcom,cpr-up-threshold = <0>; + qcom,cpr-down-threshold = <2>; + + apc1_vreg: regulator { + regulator-name = "apc1_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <18>; + + qcom,cpr-pd-bypass-mask = <0xe0>; + qcom,cpr-fuse-corners = <5>; + qcom,cpr-fuse-combos = <1>; + qcom,cpr-corners = <18>; + + qcom,ldo-min-headroom-voltage = <150000>; + qcom,ldo-max-headroom-voltage = <470000>; + qcom,ldo-max-voltage = <805000>; + qcom,uses-mem-acc; + + qcom,cpr-corner-fmax-map = <1 3 5 11 18>; + + qcom,cpr-voltage-ceiling = + <670000 670000 670000 745000 745000 + 905000 905000 905000 905000 905000 + 905000 1015000 1015000 1015000 1015000 + 1015000 1015000 1015000>; + qcom,cpr-voltage-floor = + <520000 530000 545000 590000 620000 + 635000 660000 685000 700000 730000 + 740000 750000 765000 790000 805000 + 815000 830000 850000>; + + qcom,corner-frequencies = + <307200000 345600000 403200000 + 480000000 576000000 633600000 + 729600000 806400000 883200000 + 960000000 1017600000 1113600000 + 1190400000 1267200000 1344000000 + 1420800000 1497600000 1593600000>; + + qcom,cpr-ro-scaling-factor = + < 0 0 0 0 2212 2273 2517 2506 + 2663 2650 2908 2891 0 0 0 0>, + < 0 0 0 0 2212 2273 2517 2506 + 2663 2650 2908 2891 0 0 0 0>, + < 0 0 0 0 2212 2273 2517 2506 + 2663 2650 2908 2891 0 0 0 0>, + < 0 0 0 0 2152 2237 2321 2337 + 2475 2469 2636 2612 0 0 0 0>, + < 0 0 0 0 2001 2102 2092 2090 + 2203 2210 2297 2297 0 0 0 0>; + + qcom,cpr-open-loop-voltage-fuse-adjustment = + <0 0 0 5000 0>; + qcom,cpr-closed-loop-voltage-fuse-adjustment = + <0 0 0 20000 0>; + + qcom,allow-voltage-interpolation; + qcom,allow-quotient-interpolation; + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + + qcom,cpr-aging-max-voltage-adjustment = <25000>; + qcom,cpr-aging-ref-corner = <11>; + qcom,cpr-aging-ro-scaling-factor = <3200>; + qcom,cpr-aging-derate = + <1000 1000 1000 1000 1000 1000 1000 1000 + 1000 1000 1000 1000 1000 1000 1000 1000 + 1000 1000>; + qcom,allow-aging-voltage-adjustment = <1>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/cpr3-mmss-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr3-mmss-regulator.txt new file mode 100644 index 000000000000..baa0cd2d6f1a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr3-mmss-regulator.txt @@ -0,0 +1,345 @@ +Qualcomm Technologies, Inc. CPR3 Regulator - MMSS Specific Bindings + +MMSS CPR3 controllers each support one CPR thread that monitors the voltage of +the graphics processor (MMSS) supply regulator. The CPR open-loop voltages are +stored in hardware fuses for MMSS CPR3 controllers. However, the CPR target +quotients must be defined in device tree. + +This document describes the MMSS specific CPR3 bindings. + +======================= +Required Node Structure +======================= + +CPR3 regulators must be described in three levels of devices nodes. The first +level describes the CPR3 controller. The second level describes exacly one +hardware thread managed by the controller. The third level describes one or +more logical regulators handled by the CPR thread. + +All platform independent cpr3-regulator binding guidelines defined in +cpr3-regulator.txt also apply to cpr3-hmss-regulator devices. + +==================================== +First Level Nodes - CPR3 Controllers +==================================== + +MMSS specific properties: +- compatible + Usage: required + Value type: <string> + Definition: should be one of the following: + "qcom,cpr3-msm8996-v1-mmss-regulator", + "qcom,cpr3-msm8996-v2-mmss-regulator", + "qcom,cpr3-msm8996-v3-mmss-regulator", + "qcom,cpr3-msm8996-mmss-regulator", + "qcom,cpr3-msm8996pro-mmss-regulator", + "qcom,cpr4-msm8998-v1-mmss-regulator", + "qcom,cpr4-msm8998-v2-mmss-regulator", + "qcom,cpr4-msm8998-mmss-regulator". + If the SoC revision is not specified, then it is assumed to + be the most recent revision (i.e v3 for MSM8996 and v2 + for MSM8998). + +- clocks + Usage: required + Value type: <prop-encoded-array> + Definition: Array of clock tuples in which each tuple consists of a + phandle to a clock device and a clock ID number. The + following clocks must be specified: MMSS RBCPR, MMSS RBCPR + AHB, and MMSS MMAGIC AHB. + +- clock-names + Usage: required + Value type: <stringlist> + Definition: Clock names. This list must match up 1-to-1 with the clocks + specified in the 'clocks' property. "core_clk", "iface_clk", + and "bus_clk" must be specified. Note that "iface_clk" is + not required for devices with compatible = + "qcom,cpr4-msm8998-mmss-regulator". + +- qcom,cpr-temp-point-map + Usage: Required if qcom,corner-allow-temp-adjustment is specified + for at least one of the CPR3 regulators. + Value type: <prop-encoded-array> + Definition: The temperature points in decidegrees Celsius which indicate + the range of temperature bands supported. If t1, t2, and t3 + are the temperature points, then the temperature bands are: + (-inf, t1], (t1, t2], (t2, t3], and (t3, inf). 1 to 3 + temperature points should be specified. + +- qcom,cpr-initial-temp-band + Usage: Required if qcom,cpr-temp-point-map is specified. + Value type: <u32> + Definition: The initial temp band considering 0-based index at which + the baseline target quotients are derived and fused. + Supported values: 0 to number of elements in + qcom,cpr-temp-point-map. + +- qcom,cpr-step-quot-fixed + Usage: Optional for controllers with compatible = + "qcom,cpr4-msm8998-mmss-regulator"; unsupported for + all others. + Value type: <u32> + Definition: Fixed step quotient value used by controller for applying + the SDELTA margin adjustments on the programmed target + quotient values. The step quotient is the number of + additional ring oscillator ticks observed for each + qcom,voltage-step increase in vdd-supply output voltage. + Supported values: 0 - 63. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +MMSS specific properties: +N/A + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +MMSS specific properties: +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. This value must be 4 + for MMSS. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. For MMSS the maximum + supported value is 8. These combos correspond to CPR + revision fuse values from 0 to 7 in order. + +- qcom,cpr-speed-bins + Usage: optional + Value type: <u32> + Definition: Specifies the number of speed bins being supported by the + device. This value is utilized by several other properties. + Supported values are 1 up to the maximum possible for a + given regulator type. For MMSS the maximum supported value + is 1. + +- qcom,mem-acc-voltage + Usage: required if mem-acc-supply is specified for the CPR3 controller + containing this CPR3 regulator + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the mem-acc-supply + corner for each voltage corner in order from lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,cpr-target-quotients + Usage: required + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists. Each tuple defines the + CPR target quotient for each ring oscillator (RO) for a + given corner. Since CPR3 supports exactly 16 ROs, each + tuple must contain 16 elements corresponding to RO0 through + RO15 in order. If a given RO is unused for a corner, then + its target quotient should be specified as 0. + + Each tuple list in the grouping must meet the same size + requirements as those specified for qcom,mem-acc-voltage + above. The tuples in a given list are ordered from the + lowest corner to the highest corner. + +- qcom,cpr-ro-scaling-factor + Usage: required if qcom,cpr-closed-loop-voltage-adjustment is + specified + Value type: <prop-encoded-array> + Definition: The common definition of this property in cpr3-regulator.txt + is accurate for MMSS CPR3 controllers except for this + modification: + + Each tuple list must contain the number of tuples defined in + the corresponding element of the qcom,cpr-corners property + or the qcom,cpr-speed-bins property as opposed to the value + of the qcom,cpr-fuse-corners property. + +- qcom,cpr-fused-closed-loop-voltage-adjustment-map + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR fused + corner closed-loop offset adjustment fuse to utilize for + each voltage corner in order from lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + + Each tuple element must be either 0 or in the range 1 to + qcom,cpr-fuse-corners. A value of 0 signifies that no fuse + based adjustment should be applied to the fuse corner. + Values 1 to qcom,cpr-fuse-corners denote the specific fuse + corner that should be used by a given voltage corner. + +- qcom,corner-allow-temp-adjustment + Usage: Optional for controllers with compatible = + "qcom,cpr4-msm8998-mmss-regulator"; unsupported for + all others. + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR + temperature adjustment feature enable state for each voltage + corner in order from lowest to highest. Each element in the + tuple should be either 0 (temperature adjustment not + allowed) or 1 (temperature adjustment allowed). + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bin-corners property. A single tuple may + only be specified if all of the corner counts in + qcom,cpr-corners are the same. + +- qcom,cpr-cornerX-temp-core-voltage-adjustment + Usage: Required if qcom,corner-allow-temp-adjustment is specified + for this CPR3 regulator. + Value type: <prop-encoded-array> + Definition: A list of integer tuples for cornerX. The possible values + for X are 1 to the max value specified in qcom,cpr-corners. + Each tuple defines the temperature based voltage adjustment + in microvolts for each temperature band from lowest to + highest. Each tuple must have a number of elements equal to + (the number of elements in qcom,cpr-ctrl-temp-point-map + 1) + + The tuple list must contain qcom,cpr-fuse-combos number of + tuples in which case the tuples are matched to fuse + combinations 1-to-1 or qcom,cpr-speed-bins number of tuples + in which case the tuples are matched to speed bins 1-to-1 or + exactly 1 list which is used regardless of the fuse + combination and speed bin found on a given chip. + +Note that the qcom,cpr-closed-loop-voltage-fuse-adjustment property is not +meaningful for MMSS CPR3 regulator nodes since target quotients are not defined +in fuses. + +======= +Example +======= + +gfx_cpr: cpr3-ctrl@838000 { + compatible = "qcom,cpr3-msm8996-mmss-regulator"; + reg = <0x00838000 0x4000>, <0x00074000 0x1000>; + reg-names = "cpr_ctrl", "fuse_base"; + clocks = <&clock_mmss clk_mmss_rbcpr_clk>, + <&clock_mmss clk_mmss_rbcpr_ahb_clk>, + <&clock_mmss clk_mmss_mmagic_ahb_clk>; + clock-names = "core_clk", "iface_clk", "bus_clk"; + interrupts = <0 166 0>; + interrupt-names = "cpr"; + qcom,cpr-ctrl-name = "gfx"; + + qcom,cpr-sensor-time = <1000>; + qcom,cpr-loop-time = <5000000>; + qcom,cpr-idle-cycles = <15>; + qcom,cpr-step-quot-init-min = <13>; + qcom,cpr-step-quot-init-max = <13>; + qcom,cpr-count-mode = <2>; + + vdd-supply = <&pmi8994_s2>; + qcom,voltage-step = <5000>; + + qcom,cpr-enable; + + qcom,cpr-aging-ref-voltage = <905000>; + + thread@0 { + qcom,cpr-thread-id = <0>; + qcom,cpr-consecutive-up = <0>; + qcom,cpr-consecutive-down = <2>; + qcom,cpr-up-threshold = <0>; + qcom,cpr-down-threshold = <2>; + + gfx_vreg: regulator { + regulator-name = "gfx_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <4>; + + qcom,cpr-fuse-corners = <4>; + qcom,cpr-fuse-combos = <1>; + qcom,cpr-corners = <4>; + + qcom,cpr-corner-fmax-map = <1 2 3 4>; + + qcom,cpr-voltage-ceiling = + <670000 745000 905000 1015000>; + qcom,cpr-voltage-floor = + <545000 625000 755000 855000>; + + qcom,mem-acc-voltage = <1 1 2 2>; + + qcom,corner-frequencies = + <120000000 205000000 360000000 + 480000000>; + + qcom,cpr-target-quotients = + < 0 0 0 0 249 232 0 394 + 0 422 0 0 0 0 0 0>, + < 0 0 0 0 400 363 0 565 + 0 603 0 0 0 0 0 0>, + < 0 0 0 0 669 601 0 851 + 0 905 0 0 0 0 0 0>, + < 0 0 0 0 899 806 0 1084 + 0 1149 0 0 0 0 0 0>; + + qcom,cpr-ro-scaling-factor = + < 0 0 0 0 2268 2004 0 2408 + 0 2539 0 0 0 0 0 0>, + < 0 0 0 0 2268 2004 0 2408 + 0 2539 0 0 0 0 0 0>, + < 0 0 0 0 2268 2004 0 2408 + 0 2539 0 0 0 0 0 0>, + < 0 0 0 0 2268 2004 0 2408 + 0 2539 0 0 0 0 0 0>; + + qcom,cpr-open-loop-voltage-fuse-adjustment = + <35000 0 0 0>; + qcom,cpr-closed-loop-voltage-adjustment = + <45000 0 0 0>; + + qcom,cpr-fused-closed-loop-voltage-adjustment-map = + <2 2 0 4>; + + qcom,allow-voltage-interpolation; + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + + qcom,cpr-aging-max-voltage-adjustment = <25000>; + qcom,cpr-aging-ref-corner = <3>; + qcom,cpr-aging-ro-scaling-factor = <2950>; + qcom,cpr-aging-derate = + <1000 1000 1000 1000>; + qcom,allow-aging-voltage-adjustment = <1>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/cpr3-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr3-regulator.txt new file mode 100644 index 000000000000..37e8391259c6 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr3-regulator.txt @@ -0,0 +1,631 @@ +Qualcomm Technologies, Inc. CPR3 Regulator - Platform Independent Bindings + +Core Power Reduction (CPR) version 3 controllers are used by some Qualcomm +Technologies, Inc. (QTI) SoCs to manage important voltage regulators. CPR3 +controllers are capable of monitoring several ring oscillator sensing loops +simultaneously. The CPR3 controller informs software when the silicon +conditions require the supply voltage to be increased or decreased. On certain +supply rails, the CPR3 controller is able to propagate the voltage increase +or decrease requests all the way to the PMIC without software involvement. + +This document describes the common platform independent bindings that apply +to all CPR3 controllers. + +======================= +Required Node Structure +======================= + +CPR3 regulators must be described in three levels of devices nodes. The first +level describes the CPR3 controller. The second level describes one or more +hardware threads managed by the controller. The third level describes one or +more logical regulators handled by each CPR thread. + +==================================== +First Level Nodes - CPR3 Controllers +==================================== + +Platform independent properties: +- compatible + Usage: required + Value type: <string> + Definition: The value to use for this property is defined in the + platform specific cpr3-regulator binding documentation + files. + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of the CPR3 controller, + the first fuse row, and optionally a register used to check + if aging measurements are possible. + +- reg-names + Usage: required + Value type: <stringlist> + Definition: Address names. Must include "cpr_ctrl" and "fuse_base". + "aging_allowed" may also be specified. The strings must be + specified in the same order as the corresponding addresses + are specified in the reg property. + +- qcom,cpr-ctrl-name + Usage: required + Value type: <string> + Definition: Name for this CPR controller + +- vdd-supply + Usage: required + Value type: <phandle> + Definition: phandle of the underlying regulator device that is managed + by this CPR controller. + +- system-supply + Usage: optional + Value type: <phandle> + Definition: phandle of the system-level regulator device which the + vdd-supply depends upon. Requests for this regulator must + be made before increasing the vdd-supply voltage and after + decreasing the vdd-supply voltage. + +- mem-acc-supply + Usage: optional + Value type: <phandle> + Definition: phandle of the mem-acc regulator device which is used to + configure memory array circuitry settings based upon + the performance operating point. Requests for this regulator + must be made before decreasing the vdd-supply voltage and + after increasing the vdd-supply voltage. + +- clocks + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of clock tuples in which each tuple consists of a + phandle to a clock device and a clock ID number. The CPR3 + core clock must be specified for some targets. See platform + specific cpr3-regulator binding documentation for additional + clocks that may also need to be specified. + +- clock-names + Usage: optional + Value type: <stringlist> + Definition: Clock names. This list must match up 1-to-1 with the clocks + specified in the 'clocks' property. "core_clk" must be + specified for some platforms. Other clocks may be required + for some platforms. + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: CPR interrupt specifier and optionally a hardware + closed-loop ceiling interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. "cpr" + must be specified. "ceiling" may be specified for some + platforms. + +- qcom,cpr-interrupt-affinity + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of CPU phandles which correspond to the cores that + the "cpr" interrupt should have affinity for. + +- qcom,cpr-sensor-time + Usage: required + Value type: <u32> + Definition: The time in nanoseconds that each CPR sensor within the + sensing loop takes to perform a measurement. + +- qcom,cpr-loop-time + Usage: required + Value type: <u32> + Definition: The time in nanoseconds between consecutive CPR + measurements. + +- qcom,cpr-idle-cycles + Usage: required + Value type: <u32> + Definition: The number of CPR core clock cycles for the CPR controller + to wait in transitional states. + Supported values: 0 - 31. + +- qcom,voltage-step + Usage: required + Value type: <u32> + Definition: The voltage in microvolts of a single step of the VDD supply + regulator being controlled by CPR. + +- qcom,cpr-step-quot-init-min + Usage: required + Value type: <u32> + Definition: The default minimum CPR step quotient value. The step + quotient is the number of additional ring oscillator ticks + observed for each qcom,voltage-step increase in vdd-supply + output voltage. Supported values: 0 - 63. + +- qcom,cpr-step-quot-init-max + Usage: required + Value type: <u32> + Definition: The default maximum CPR step quotient value. + Supported values: 0 - 63. + +- qcom,cpr-count-mode + Usage: required + Value type: <u32> + Definition: The CPR counting mode to use during CPR measurements. + Supported values: + 0 - Read all sensors at once and use the minimum + quotient value observed in repeated measurements. + 1 - Read all sensors at once and use the maximum + quotient value observed in repeated measurements. + 2 - Read each sensor once in a sequential, staggered + fashion. + +- qcom,cpr-count-repeat + Usage: optional + Value type: <u32> + Definition: The number of times to read CPR sensors during a single CPR + measurement when using one of the all-at-once count modes. + +- qcom,cpr-enable + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the CPR3 controller + should operate in closed-loop mode (i.e. CPR sensing loop + enabled) as opposed to open-loop mode (i.e. CPR sensing loop + disabled) by default. + +- qcom,cpr-aging-ref-voltage + Usage: required if qcom,allow-aging-voltage-adjustment is specified + for any third level nodes + Value type: <u32> + Definition: Specifies the CPR aging reference voltage in microvolts. + This is the voltage that vdd-supply must be set to when + performing an aging measurement. + +- qcom,cpr-aging-allowed-reg-mask + Usage: required if "aging_allowed" register is specified + Value type: <u32> + Definition: Bitmask used to mask off the "aging_allowed" register. + +- qcom,cpr-aging-allowed-reg-value + Usage: required if "aging_allowed" register is specified + Value type: <u32> + Definition: Value required in the masked off "aging_allowed" register + bits in order for a CPR aging measurement to be possible. + +- qcom,cpr-panic-reg-addr-list + Usage: optional + Value type: <prop-encoded-array> + Definition: Array of register addresses to be dumped when device resets. + +- qcom,cpr-panic-reg-name-list + Usage: optional, though only meaningful if + qcom,cpr-panic-reg-addr-list is specified + Value type: <prop-encoded-array> + Definition: Address names. Must be specified in the same order + as the corresponding addresses are specified in + the qcom,cpr-panic-reg-addr-list property. + +- qcom,cpr-reset-step-quot-loop-en + Usage: optional; only meaningful for CPR4 and CPRh controllers + Value type: <empty> + Definition: Boolean value which indicates that the CPR controller should + be configured to reset step_quot on each loop_en = 0 + transition. This configuration allows the CPR controller to + first use the default step_quot and then later switch to the + run-time calibrated step_quot. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +Platform independent properties: +- qcom,cpr-thread-id + Usage: required + Value type: <u32> + Definition: Specifies the hardware thread ID of this thread within the + CPR controller. + +- qcom,cpr-consecutive-up + Usage: required + Value type: <u32> + Definition: The number of consecutive CPR step up events needed to + to trigger an up interrupt. Supported values: 0 - 15. + +- qcom,cpr-consecutive-down + Usage: required + Value type: <u32> + Definition: The number of consecutive CPR step down events needed to + to trigger a down interrupt. Supported values: 0 - 15. + +- qcom,cpr-up-threshold + Usage: required + Value type: <u32> + Definition: The number CPR error steps required to generate an up event. + Supported values: 0 - 31. + +- qcom,cpr-down-threshold + Usage: required + Value type: <u32> + Definition: The number CPR error steps required to generate a down + event. Supported values: 0 - 31. + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +Platform independent properties: +- regulator-name + Usage: required + Value type: <string> + Definition: Specifies the name for this CPR3 regulator. + +- regulator-min-microvolt + Usage: required + Value type: <u32> + Definition: Minimum corner value which should be 1 to represent the + lowest supported corner. + +- regulator-max-microvolt + Usage: required + Value type: <u32> + Definition: Maximum corner value which should be equal to largest value + listed in qcom,cpr-corners. + +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. See platform specific + binding files for further requirements. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. See platform specific + binding files for further details. + +- qcom,cpr-speed-bins + Usage: optional + Value type: <u32> + Definition: Specifies the number of speed bins being supported by the + device. This value is utilized by several other properties. + Supported values are 1 up to the maximum possible for a + given regulator type. See platform specific binding files + for further details. + + This property can only be utilized if the number of corners + for all fuse combinations associated with a given speed bin + is the same. + +- qcom,cpr-corners + Usage: required + Value type: <prop-encoded-array> + Definition: A list of integers which defines how many voltage corners + are to be used for each fuse combination. The list must + contain either qcom,cpr-fuse-combos number of elements in + which case the corner counts are applied to fuse + combinations 1-to-1 or the list must contain exactly 1 + element which is used regardless of the fuse combination + found on a given chip. + +- qcom,cpr-speed-bin-corners + Usage: required if qcom,cpr-speed-bins is specified + Value type: <prop-encoded-array> + Definition: A list of integers which defines how many voltage corners + are to be used for each speed bin. The list must contain + qcom,cpr-speed-bins number of elements. + +- qcom,cpr-corner-fmax-map + Usage: required + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the highest + (i.e. maximum frequency) 1-based corner value associated + with each fuse-corner. + + Each tuple must have a number of elements equal to the value + of the qcom,cpr-fuse-corners property. The elements of a + tuple are ordered from lowest to highest fuse corner. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + +- qcom,cpr-voltage-ceiling + Usage: required + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR ceiling + voltage in microvolts for each voltage corner in order from + lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,cpr-voltage-floor + Usage: required + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR floor + voltage in microvolts for each voltage corner in order from + lowest to highest. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + +- qcom,cpr-floor-to-ceiling-max-range + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the maximum + allowed difference between the final floor voltage and the + final ceiling voltage in microvolts for each voltage corner + in order from lowest to highest. A negative value may be + specified for an element to indicate that there is no + limitation of the floor to ceiling voltage range for the + corresponding corner. + + In the case that the initial floor to ceiling voltage is + greater than the max range specified, the floor voltage will + be increased in order to satisfy the max range constraint. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + +- qcom,system-voltage + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the system-supply + voltage in microvolts or corners or levels for each voltage + corner in order from lowest to highest. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + +- qcom,corner-frequencies + Usage: required + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPU frequency + in Hertz corresponding to each voltage corner in order from + lowest to highest. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + +- qcom,allow-voltage-interpolation + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that it is acceptable to use + interpolated open-loop voltage values. These values are + interpolated between the open-loop voltage Fmax fuse values. + +- qcom,cpr-scaled-open-loop-voltage-as-ceiling + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that it is acceptable to use + the interpolated open-loop voltage for each corner as the + CPR ceiling voltage for each corner. + +- qcom,cpr-open-loop-voltage-fuse-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the open-loop + voltage adjustment in microvolts for each fused voltage + corner in order from lowest to highest. This adjustment is + applied to the values read from fuses before the values are + used in interpolation for intermediate corners. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-corner-fmax-map above. + + The open-loop voltage for a given fuse corner corresponds to + the voltage that is safe to use under all circumstances. + It is used as a starting voltage for CPR and may also be + specified as a ceiling voltage for CPR scaling. + +- qcom,cpr-open-loop-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the open-loop + voltage adjustment in microvolts for each voltage corner in + order from lowest to highest. This adjustment is applied to + the open-loop voltage values after they have been + interpolated for intermediate corners. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + +- qcom,cpr-open-loop-voltage-min-diff + Usage: optional; only meaningful if the + qcom,cpr-open-loop-voltage-adjustment property is specified + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the minimum + allowed open-loop voltage difference in microvolts between + each voltage corner and the one immediately preceding it. + The elements in a tuple are ordered from the lowest to the + highest corner. The value specified for the first corner is + ignored since there is no corner before it. + + Negative voltage values may be specified for this property. + A negative value means that the open-loop voltage of a + corner may be lower than that of the preceding corner. + + The minimum difference is enforced after the open-loop + voltage values have been interpolated for intermediate + corners and after adjustments have been applied. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + + If this property is not specified, then the minimum + difference is assumed to be 0 uV for all corners. + +- qcom,cpr-closed-loop-voltage-fuse-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the closed-loop + voltage adjustment in microvolts for each fused voltage + corner in order from lowest to highest. This adjustment is + applied to the values read from fuses before the values are + used in interpolation for intermediate corners. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-corner-fmax-map above. + + The qcom,cpr-ro-scaling-factor property must be specified in + order to utilize this property. + + The closed-loop voltage for a given fuse corner corresponds + to the voltage that the CPR controller settles the VDD + supply rail to based upon the programmed CPR target + quotients and the current silicon conditions. + +- qcom,cpr-closed-loop-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the closed-loop + voltage adjustment in microvolts for each voltage corner in + order from lowest to highest. This adjustment is applied to + target quotient values after they have been interpolated + for intermediate corners. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + + The qcom,cpr-ro-scaling-factor property must be specified in + order to utilize this property. + +- qcom,cpr-ro-scaling-factor + Usage: required if qcom,cpr-closed-loop-voltage-fuse-adjustment, + qcom,cpr-closed-loop-voltage-adjustment, or + qcom,allow-aging-voltage-adjustment is specified + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists. Each tuple defines the + CPR ring oscillator (RO) scaling factor with units of QUOT/V + for each RO for a given fuse corner. Since CPR3 supports + exactly 16 ROs, each tuple must contain 16 elements + corresponding to RO0 through RO15 in order. If a given RO + is unused for a fuse corner, then its scaling factor may be + specified as 0. + + Each tuple list must contain the number of tuples defined in + the qcom,cpr-fuse-corners property. The tuples in a given + list are ordered from the lowest fuse corner to the highest + fuse corner. + + The tuple list grouping must contain qcom,cpr-fuse-combos + number of tuple lists in which case the lists are matched to + fuse combinations 1-to-1 or qcom,cpr-speed-bins number of + tuple lists in which case the lists are matched to + speed bins 1-to-1 or exactly 1 list which is used regardless + of the fuse combination and speed bin found on a given chip. + + The target quotient adjustment to apply for each RO of a + given corner is determined by multiplying the adjustment + value in qcom,cpr-closed-loop-voltage-fuse-adjustment or + qcom,cpr-closed-loop-voltage-adjustment by the relevant RO + scaling factor in this property. + +- qcom,allow-aging-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which specifies if CPR aging adjustment + should be performed for each fuse combination. + Supported per-combo element values: + 0 - do not perform CPR aging adjustment + 1 - perform CPR aging adjustment + + The list must contain qcom,cpr-fuse-combos number of + elements in which case the elements are matched to fuse + combinations 1-to-1 or qcom,cpr-speed-bins number of + elements in which case the elements are matched to + speed bins 1-to-1 or exactly 1 element which is used + regardless of the fuse combination and speed bin found + on a given chip. + +- qcom,allow-aging-open-loop-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which specifies if CPR aging adjustment + should be applied to open-loop voltages for each fuse + combination. Note that aging adjustment must be allowed via + qcom,allow-aging-voltage-adjustment in order for this + property to have an effect. + Supported per-combo element values: + 0 - do not perform CPR aging adjustment + 1 - perform CPR aging adjustment + + The list must meet the same size requirements as those + specified for qcom,allow-aging-voltage-adjustment above. + +- qcom,cpr-aging-max-voltage-adjustment + Usage: required if qcom,allow-aging-voltage-adjustment is specified + Value type: <prop-encoded-array> + Definition: A list of integers which defines the maximum CPR aging + voltage margin adjustment in microvolts that may be added + for each fuse combination. If this property is specified + and the adjustment specified is greater than 0, then aging + adjustments are required for this regulator. + + The list must meet the same size requirements as those + specified for qcom,allow-aging-voltage-adjustment above. + +- qcom,cpr-aging-ref-corner + Usage: required if qcom,allow-aging-voltage-adjustment is specified + Value type: <prop-encoded-array> + Definition: A list of integers which defines the CPR reference corner + for this regulator to use during aging measurements for each + fuse combination. + + The list must meet the same size requirements as those + specified for qcom,allow-aging-voltage-adjustment above. + +- qcom,cpr-aging-ro-scaling-factor + Usage: required if qcom,allow-aging-voltage-adjustment is specified + Value type: <prop-encoded-array> + Definition: A list of integers which defines the CPR aging ring + oscillator (RO) scaling factor with units of QUOT/V to use + during aging measurements for each fuse combination. + + The list must meet the same size requirements as those + specified for qcom,allow-aging-voltage-adjustment above. + +- qcom,cpr-aging-derate + Usage: optional, though only meaningful if + qcom,allow-aging-voltage-adjustment is specified + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR aging + derating scaling factor to apply to the closed-loop voltage + margin adjustment for each corner. The individual scaling + factors have units of uV/mV and are ordered from lowest to + highest corner per tuple. For example, a value of 900 + specifies that the voltage adjustment for the corner should + be 90% (900/1000) of that for the reference corner. + + The list and tuples must meet the same size requirements as + those specified for qcom,cpr-voltage-ceiling above. + + If this property is not specified, then it is assumed that + no corners require derating (i.e. the scaling factor would + be 1000). + +All properties specified within the core regulator framework can also be used in +third level nodes. These bindings can be found in: +Documentation/devicetree/bindings/regulator/regulator.txt. + +See platform specific cpr3-regulator binding documentation files for examples. diff --git a/Documentation/devicetree/bindings/regulator/cpr4-apss-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr4-apss-regulator.txt new file mode 100644 index 000000000000..29bb2d32bf91 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr4-apss-regulator.txt @@ -0,0 +1,522 @@ +Qualcomm Technologies, Inc. CPR4 Regulator - APSS Specific Bindings + +APSS CPR4 controllers each support one CPR thread that monitors the voltage of +a pair of application processor (APSS) clusters that are powered by a shared +regulator supply. They also have a hardware channel to use these requests to +directly change the supply voltage at the PMIC via the SPM without software +intervention. + +APSS CPR4 controllers also have to take into account the state of the memory +array power mux (APM) when scaling voltage to ensure that memory always receives +a sufficiently high voltage. + +Both CPR open-loop voltages and CPR target quotients are stored in hardware +fuses for APSS CPR4 controllers. + +This document describes the APSS specific CPR4 bindings. + +======================= +Required Node Structure +======================= + +CPR4 regulators must be described in three levels of devices nodes. The first +level describes the CPR4 controller. The second level describes one or more +hardware threads managed by the controller. The third level describes one or +more logical regulators handled by each CPR thread. + +All platform independent cpr3-regulator binding guidelines defined in +cpr3-regulator.txt also apply to cpr4-apss-regulator devices. + +==================================== +First Level Nodes - CPR4 Controllers +==================================== + +APSS specific properties: +- compatible + Usage: required + Value type: <string> + Definition: should be one of the following: + "qcom,cpr4-msm8953-apss-regulator"; + +- interrupts + Usage: required + Value type: <prop-encoded-array> + Definition: CPR interrupt specifier. + +- interrupt-names + Usage: required + Value type: <stringlist> + Definition: Interrupt names. This list must match up 1-to-1 with the + interrupts specified in the 'interrupts' property. "cpr" + must be specified. + +- qcom,apm-ctrl + Usage: required on systems that need APM management + Value type: <phandle> + Definition: phandle of memory array power mux (APM) controller device + node for the APM that is used by the APSS VDD supply + +- qcom,apm-threshold-voltage + Usage: required if qcom,apm-ctrl is specified + Value type: <u32> + Definition: Specifies the APM threshold voltage in microvolts. If the + vdd-supply voltage is greater than or equal to this level, + then the APM is switched to use the vdd-supply. If the + vdd-supply voltage is below this level, then the APM is + switched to use the system-supply. + +- qcom,apm-hysteresis-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the voltage delta in microvolts between the APM + threshold voltage and the highest corner open-loop voltage + which may be used as the ceiling for the corner. If this + property is not specified, then a value of 0 is assumed. + +- qcom,cpr-hw-closed-loop + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the APSS CPR4 controller + should operate in hardware closed-loop mode as opposed to + software closed-loop mode. + +- vdd-limit-supply + Usage: required + Value type: <phandle> + Definition: phandle of the VDD supply limit regulator which controls the + CPR ceiling and floor voltages when operating in hardware + closed-loop mode. + +- qcom,cpr-down-error-step-limit + Usage: required + Value type: <u32> + Definition: CPR4 hardware closed-loop down error step limit which + defines the maximum number of vdd-supply regulator steps + that the voltage may be reduced as the result of a single + CPR measurement. + +- qcom,cpr-up-error-step-limit + Usage: required + Value type: <u32> + Definition: CPR4 hardware closed-loop up error step limit which defines + the maximum number of vdd-supply regulator steps that the + voltage may be increased as the result of a single + CPR measurement. + +- qcom,cpr-saw-use-unit-mV + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the unit used in SAW PVC + interface is mV. Use this for vdd-supply regulators which + do not use PMIC voltage control register LSBs per actually + unique PMIC regulator output voltage. + +- qcom,cpr-temp-point-map + Usage: required if qcom,corner-allow-temp-adjustment is specified + for at least one of the CPR3 regulators. + Value type: <prop-encoded-array> + Definition: The temperature points in decidegrees Celsius which indicate + the range of temperature bands supported. If t1, t2, and t3 + are the temperature points, then the temperature bands are: + (-inf, t1], (t1, t2], (t2, t3], and (t3, inf). + +- qcom,cpr-initial-temp-band + Usage: required if qcom,corner-allow-temp-adjustment is specified + for at least one of the CPR3 regulators. + Value type: <u32> + Definition: The initial temp band considering 0-based index at which + the baseline target quotients are derived and fused. + +- qcom,cpr-step-quot-fixed + Usage: optional + Value type: <u32> + Definition: Fixed step quotient value used by controller for applying + the SDELTA margin adjustments on the programmed target + quotient values. The step quotient is the number of + additional ring oscillator ticks observed for each + qcom,voltage-step increase in vdd-supply output voltage. + Supported values: 0 - 63. + +- qcom,cpr-voltage-settling-time + Usage: optional + Value type: <u32> + The time in nanoseconds that it takes for the vdd-supply + voltage to settle after being increased or decreased by + qcom,voltage-step microvolts. This is used as the wait + time after applying SDELTA voltage margin adjustments. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +APSS specific properties: +N/A + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +APSS specific properties: +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. This value must be 4 + for APSS. These fuse corners are: LowSVS, SVS, Nominal, + and Turbo. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. For APSS the maximum + supported value is 64. The first 8 fuse combos correspond + to speed bin fuse value 0 along with CPR revision fuse + values 0 to 7. The second 8 fuse combos correspond to speed + bin fuse value 1 along with CPR revision fuse values 0 to 7. + The last 8 fuse combos correspond to speed bin fuse value 7 + along with CPR revision fuse values 0 to 7. + +- qcom,cpr-speed-bins + Usage: optional + Value type: <u32> + Definition: Specifies the number of speed bins being supported by the + device. This value is utilized by several other properties. + Supported values are 1 up to the maximum possible for a + given regulator type. For APSS the maximum supported value + is 8. + +- qcom,mem-acc-voltage + Usage: required if mem-acc-supply is specified for the CPR4 controller + containing this regulator + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the mem-acc-supply + corner for each voltage corner in order from lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,allow-quotient-interpolation + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that it is acceptable to use + interpolated CPR target quotient values. These values are + interpolated between the target quotient Fmax fuse values. + +- qcom,corner-allow-core-count-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR core + count adjustment feature enable state for each voltage + corner in order from lowest to highest. Each element in + the tuple should be either 0 (per-core-count adjustment + not allowed) or 1 (per-core-count adjustment allowed). + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,max-core-count + Usage: required if qcom,corner-allow-core-count-adjustment is + specified for this CPR3 regulator. + Value type: <u32> + Definition: The maximum number of cores considered for core-count vmin + adjustments specified for this regulator voltage corners. + +- qcom,corner-allow-temp-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR + temperature adjustment feature enable state for each voltage + corner in order from lowest to highest. Each element in the + tuple should be either 0 (temperature adjustment not + allowed) or 1 (temperature adjustment allowed). + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,cpr-cornerX-temp-core-voltage-adjustment + Usage: required if qcom,corner-allow-core-count-adjustment + specified for this CPR3 regulator. + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists for cornerX. The possible + values for X are 1 to the max value specified in + qcom,cpr-corners. Each tuple defines the temperature based + voltage adjustment in microvolts for each temperature band + from lowest to highest for a given number of online cores. + Each tuple must have a number of elements equal to either + (the number of elements in qcom,cpr-ctrl-temp-point-map + + 1), if qcom,cpr-ctrl-temp-point-map is specified, or 1. + + Each tuple list must contain a number of tuples equal to + either qcom,max-core-count, if qcom,max-core-count is + specified, or 1. The tuples should be ordered from lowest + to highest core count. + + The tuple list grouping must contain qcom,cpr-fuse-combos + number of tuple lists in which case the lists are matched to + fuse combinations 1-to-1 or qcom,cpr-speed-bins number of + tuple lists in which case the lists are matched to + speed bins 1-to-1 or exactly 1 list which is used regardless + of the fuse combination and speed bin found on a given chip. + +- qcom,cpr-num-boost-cores + Usage: required if qcom,allow-boost specified for this CPR3 + regulator. + Value type: <u32> + Definition: Integer value indicates that voltage boost will be applied + when the number of online cores become this value. + +- qcom,cpr-boost-temp-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the temperature + based voltage adjustment to boost voltage in microvolts + for each temperature band in order from lowest to highest. + + The number of elements in each tuple should be equal to either + (the number of elements in qcom,cpr-ctrl-temp-point-map + + 1), if qcom,cpr-ctrl-temp-point-map is specified, or 1. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + +- qcom,allow-boost + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integers which specifies if the voltage boost + feature should be enabled for each fuse combination. + Supported per-combo element values: + 0 - voltage boost feature disabled + 1 - voltage boost feature enabled + + The list must contain qcom,cpr-fuse-combos number of + elements in which case the elements are matched to fuse + combinations 1-to-1 or qcom,cpr-speed-bins number of + elements in which case the elements are matched to + speed bins 1-to-1 or exactly 1 element which is used + regardless of the fuse combination and speed bin found + on a given chip. + +- qcom,cpr-boost-voltage-fuse-adjustment + Usage: optional + Value type: <u32> + Definition: A list of integers which defines the voltage adjustment + in microvolts for the fused boost voltage. This adjustment + is applied to the values read from boost fuses. + + The list must contain qcom,cpr-fuse-combos number of + elements in which case the elements are matched to fuse + combinations 1-to-1 or qcom,cpr-speed-bins number of + elements in which case the elements are matched to + speed bins 1-to-1 or exactly 1 element which is used + regardless of the fuse combination and speed bin found + on a given chip. + +- qcom,cpr-misc-fuse-voltage-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists where each tuple defines + the voltage adjustments in microvolts for each voltage + corner in order from lowest to highest. This adjustment is + applied to both open-loop and closed-loop voltages. + + Each tuple list must contain a number of tuples equal to + 2 to the power of the number of bits selected for misc + voltage adj fuse definition. For MSM8953 the tuple + list must contain 2 tuples for the 1-bit misc fuse. + Tuples in a list should be specified in ascending order + according to the misc fuse value assuming that the fuse + is treated like an unsigned integer. + + The tuple list grouping must contain qcom,cpr-speed-bins + number of tuple lists in which case the lists are matched to + speed bins 1-to-1 or exactly 1 list which is used regardless + of the speed bin found on a given chip. + +======= +Example +======= + +apc_cpr: cpr4-ctrl@b018000 { + compatible = "qcom,cpr4-msm8953-apss-regulator"; + reg = <0xb018000 0x4000>, <0xa4000 0x1000>; + reg-names = "cpr_ctrl", "fuse_base"; + interrupts = <GIC_SPI 15 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "cpr"; + + qcom,cpr-ctrl-name = "apc"; + + qcom,cpr-sensor-time = <1000>; + qcom,cpr-loop-time = <5000000>; + qcom,cpr-idle-cycles = <15>; + qcom,cpr-step-quot-init-min = <13>; + qcom,cpr-step-quot-init-max = <13>; + qcom,cpr-count-mode = <2>; /* Staggered */ + qcom,cpr-down-error-step-limit = <1>; + qcom,cpr-up-error-step-limit = <1>; + + qcom,apm-ctrl = <&apc_apm>; + qcom,apm-threshold-voltage = <848000>; + qcom,apm-hysteresis-voltage = <5000>; + + vdd-supply = <&pm8953_s5>; + qcom,voltage-step = <5000>; + vdd-limit-supply = <&pm8953_s5_limit>; + mem-acc-supply = <&apc_mem_acc_vreg>; + + qcom,cpr-enable; + qcom,cpr-hw-closed-loop; + + qcom,cpr-temp-point-map = <0 250 850>; + qcom,cpr-initial-temp-band = <3>; + qcom,cpr-step-quot-fixed = <16>; + qcom,cpr-voltage-settling-time = <1600>; + + qcom,cpr-panic-reg-addr-list = + <0xb1d2c18 0xb1d2900 0x0b1112b0 0xb018798>; + qcom,cpr-panic-reg-name-list = + "CCI_SAW4_PMIC_STS", "CCI_SAW4_VCTL", + "APCS_ALIAS0_APM_CTLER_STATUS", + "APCS0_CPR_CORE_ADJ_MODE_REG"; + + thread@0 { + qcom,cpr-thread-id = <0>; + qcom,cpr-consecutive-up = <1>; + qcom,cpr-consecutive-down = <1>; + qcom,cpr-up-threshold = <1>; + qcom,cpr-down-threshold = <1>; + + apc_vreg: regulator { + regulator-name = "apc_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <8>; + + qcom,cpr-fuse-corners = <4>; + qcom,cpr-fuse-combos = <8>; + qcom,cpr-speed-bins = <1>; + qcom,cpr-corners = <8>; + + qcom,cpr-corner-fmax-map = <1 2 4 8>; + + qcom,cpr-voltage-ceiling = + <645000 720000 790000 865000 920000 + 990000 1065000 1065000>; + + qcom,cpr-voltage-floor = + <590000 625000 690000 755000 800000 + 855000 920000 920000>; + + qcom,mem-acc-voltage = <1 1 2 2 2 2 2 2>; + + qcom,corner-frequencies = + <652800000 1036800000 1401600000 + 1689600000 1843200000 1958400000 + 2150400000 2208000000>; + + qcom,cpr-misc-fuse-voltage-adjustment = + /* Speed bin 0; misc fuse 0..1 */ + < 0 0 0 0 + 0 0 0 0>, + < 0 0 30000 0 + 0 0 0 0>; + + qcom,allow-voltage-interpolation; + qcom,allow-quotient-interpolation; + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + + qcom,corner-allow-temp-adjustment = + <0 0 0 1 0 1 1 1>; + + qcom,corner-allow-core-count-adjustment = + <0 0 0 0 1 1 1 1>; + qcom,max-core-count = <8>; + qcom,cpr-corner4-temp-core-voltage-adjustment = + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>, + <(-20000) (-10000) (-5000) 0>; + qcom,cpr-corner5-temp-core-voltage-adjustment = + <(-50000) (-50000) (-50000) (-50000)>, + <(-50000) (-50000) (-50000) (-50000)>, + <(-40000) (-40000) (-40000) (-40000)>, + <(-40000) (-40000) (-40000) (-40000)>, + <(-30000) (-30000) (-30000) (-30000)>, + <(-30000) (-30000) (-30000) (-30000)>, + <(-20000) (-20000) (-20000) (-20000)>, + <(-20000) (-20000) (-20000) (-20000)>; + qcom,cpr-corner6-temp-core-voltage-adjustment = + <(-50000) (-40000) (-30000) (-20000)>, + <(-50000) (-40000) (-30000) (-20000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-20000) (-10000) (-5000) 0 >, + <(-20000) (-10000) (-5000) 0 >; + qcom,cpr-corner7-temp-core-voltage-adjustment = + <(-50000) (-40000) (-30000) (-20000)>, + <(-50000) (-40000) (-30000) (-20000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-20000) (-10000) (-5000) 0 >, + <(-20000) (-10000) (-5000) 0 >; + qcom,cpr-corner8-temp-core-voltage-adjustment = + <(-50000) (-40000) (-30000) (-20000)>, + <(-50000) (-40000) (-30000) (-20000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-40000) (-30000) (-20000) (-10000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-30000) (-20000) (-10000) (-5000)>, + <(-20000) (-10000) (-5000) 0 >, + <(-20000) (-10000) (-5000) 0 >; + + qcom,cpr-num-boost-cores = <4>; + qcom,cpr-boost-voltage-fuse-adjustment = <(-10000)>; + qcom,cpr-boost-temp-adjustment = + <(-20000) (-15000) (-10000) 0>; + qcom,allow-boost = + <1>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/cpr4-mmss-ldo-regulator.txt b/Documentation/devicetree/bindings/regulator/cpr4-mmss-ldo-regulator.txt new file mode 100644 index 000000000000..4af9cd38d77d --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cpr4-mmss-ldo-regulator.txt @@ -0,0 +1,322 @@ +Qualcomm Technologies, Inc. CPR4 Regulator - MMSS LDO Specific Bindings + +MMSS LDO CPR4 controllers each support one CPR thread that monitors the voltage +of the graphics processor (MMSS) supply regulator. The CPR open-loop voltages +are stored in hardware fuses for MMSS CPR4 controllers. However, the CPR target +quotients must be defined in device tree. + +This document describes the MMSS LDO specific CPR4 bindings. + +======================= +Required Node Structure +======================= + +CPR3 regulators must be described in three levels of devices nodes. The first +level describes the CPR3 controller. The second level describes exacly one +hardware thread managed by the controller. The third level describes one or +more logical regulators handled by the CPR thread. + +All platform independent cpr3-regulator binding guidelines defined in +cpr3-regulator.txt also apply to cpr4-mmss-ldo-regulator devices. + +==================================== +First Level Nodes - CPR3 Controllers +==================================== + +MMSS LDO specific properties: +- compatible + Usage: required + Value type: <string> + Definition: should be the following: + "qcom,cpr4-sdm660-mmss-ldo-regulator" for SDM660, + "qcom,cpr4-sdm630-mmss-ldo-regulator" for SDM630. + +- clocks + Usage: required + Value type: <prop-encoded-array> + Definition: Array of clock tuples in which each tuple consists of a + phandle to a clock device and a clock ID number. The + following clocks must be specified: MMSS RBCPR and MMSS + RBCPR AHB. + +- clock-names + Usage: required + Value type: <stringlist> + Definition: Clock names. This list must match up 1-to-1 with the clocks + specified in the 'clocks' property. "core_clk", and "bus_clk" + must be specified. + +- qcom,cpr-step-quot-fixed + Usage: Optional + Value type: <u32> + Definition: Fixed step quotient value used by controller for applying + the SDELTA margin adjustments on the programmed target + quotient values. The step quotient is the number of + additional ring oscillator ticks observed for each + qcom,voltage-step increase in vdd-supply output voltage. + Supported values: 0 - 63. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +MMSS specific properties: +N/A + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +MMSS specific properties: +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. This value must be 6 + for sdm660/sdm630 GFX LDO. These fuse corners are: MinSVS, + LowSVS, SVS, SVSP, NOM and NOMP. The open-loop voltage fuses + are allocated for LowSVS, SVS, NOM and NOMP corners. The + open-loop voltages for MinSVS and SVSP are derived by + applying fixed offset from LowSVS and NOM open-loop voltages + respectively. The closed-loop offset voltage fuses are + allocated for LowSVS, SVS, NOM and NOMP corners. The MinSVS + and SVSP corners use the closed-loop offset voltage fuses of + LowSVS and NOM corners respectively. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. For MMSS the maximum + supported value is 8. These combos correspond to CPR + revision fuse values from 0 to 7 in order. + +- qcom,mem-acc-voltage + Usage: required if mem-acc-supply is specified for the CPR3 controller + containing this CPR3 regulator + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the mem-acc-supply + corner for each voltage corner in order from lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + +- qcom,cpr-target-quotients + Usage: required + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists. Each tuple defines the + CPR target quotient for each ring oscillator (RO) for a + given corner. Since CPR3 supports exactly 16 ROs, each + tuple must contain 16 elements corresponding to RO0 through + RO15 in order. If a given RO is unused for a corner, then + its target quotient should be specified as 0. + + Each tuple list in the grouping must meet the same size + requirements as those specified for qcom,mem-acc-voltage + above. The tuples in a given list are ordered from the + lowest corner to the highest corner. + +- qcom,cpr-ro-scaling-factor + Usage: required if qcom,cpr-closed-loop-voltage-adjustment is + specified + Value type: <prop-encoded-array> + Definition: The common definition of this property in cpr3-regulator.txt + is accurate for MMSS CPR3 controllers except for this + modification: + + Each tuple list must contain the number of tuples defined in + the corresponding element of the qcom,cpr-corners property + or the qcom,cpr-speed-bins property as opposed to the value + of the qcom,cpr-fuse-corners property. + +- qcom,cpr-fused-closed-loop-voltage-adjustment-map + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR fused + corner closed-loop offset adjustment fuse to utilize for + each voltage corner in order from lowest to highest. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bins property. A single tuple may only + be specified if all of the corner counts in qcom,cpr-corners + are the same. + + Each tuple element must be either 0 or in the range 1 to + qcom,cpr-fuse-corners. A value of 0 signifies that no fuse + based adjustment should be applied to the fuse corner. + Values 1 to qcom,cpr-fuse-corners denote the specific fuse + corner that should be used by a given voltage corner. + +- qcom,cpr-corner-allow-ldo-mode + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the LDO mode + allowed state for each voltage corner in order from lowest + to highest. Each element in the tuple should be either + 0 (LDO mode not allowed) or 1 (LDO mode allowed). + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bin-corners property. A single tuple may + only be specified if all of the corner counts in + qcom,cpr-corners are the same. + +- qcom,cpr-corner-allow-closed-loop + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR + closed-loop operation allowed state for each voltage corner + in order from lowest to highest. Each element in the tuple + should be either 0 (CPR closed-loop operation not allowed) + or 1 (CPR closed-loop operation allowed). + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the + corresponding element of the qcom,cpr-corners property or + the qcom,cpr-speed-bin-corners property. A single tuple may + only be specified if all of the corner counts in + qcom,cpr-corners are the same. + +Note that the qcom,cpr-closed-loop-voltage-fuse-adjustment property is not +meaningful for MMSS LDO CPR3 regulator nodes since target quotients are not +defined in fuses. + +======= +Example +======= + +gfx_cpr: cpr4-ctrl@05061000 { + compatible = "qcom,cpr4-sdm660-mmss-ldo-regulator"; + reg = <0x05061000 0x4000>, <0x00784000 0x1000>; + reg-names = "cpr_ctrl", "fuse_base"; + interrupts = <GIC_SPI 285 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "cpr"; + qcom,cpr-ctrl-name = "gfx"; + + qcom,cpr-sensor-time = <1000>; + qcom,cpr-loop-time = <5000000>; + qcom,cpr-idle-cycles = <15>; + qcom,cpr-step-quot-init-min = <8>; + qcom,cpr-step-quot-init-max = <12>; + qcom,cpr-count-mode = <0>; /* All at once */ + + vdd-supply = <&gfx_stub_vreg>; + mem-acc-supply = <&gfx_mem_acc_vreg>; + system-supply = <&pm660l_s3_level>; /* vdd_cx */ + qcom,voltage-step = <5000>; + vdd-thread0-ldo-supply = <&gfx_ldo_vreg>; + + qcom,cpr-enable; + + thread@0 { + qcom,cpr-thread-id = <0>; + qcom,cpr-consecutive-up = <0>; + qcom,cpr-consecutive-down = <2>; + qcom,cpr-up-threshold = <0>; + qcom,cpr-down-threshold = <2>; + + gfx_vreg_corner: regulator { + regulator-name = "gfx_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <7>; + + qcom,cpr-fuse-corners = <6>; + qcom,cpr-fuse-combos = <8>; + qcom,cpr-corners = <7>; + + qcom,cpr-corner-fmax-map = <1 2 3 4 5 6>; + + qcom,cpr-voltage-ceiling = + <584000 644000 724000 788000 + 868000 924000 1068000>; + qcom,cpr-voltage-floor = + <504000 504000 596000 652000 + 712000 744000 1068000>; + + qcom,mem-acc-voltage = <1 1 1 2 2 2 2>; + qcom,system-voltage = + <RPM_SMD_REGULATOR_LEVEL_MIN_SVS>, + <RPM_SMD_REGULATOR_LEVEL_LOW_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS_PLUS>, + <RPM_SMD_REGULATOR_LEVEL_NOM>, + <RPM_SMD_REGULATOR_LEVEL_NOM_PLUS>, + <RPM_SMD_REGULATOR_LEVEL_TURBO>; + + qcom,corner-frequencies = + <160000000 266000000 370000000 + 465000000 588000000 647000000 + 800000000>; + + qcom,cpr-target-quotients = + <0 0 0 0 0 0 185 179 + 291 299 304 319 0 0 0 0>, + <0 0 0 0 0 0 287 273 + 425 426 443 453 0 0 0 0>, + <0 0 0 0 0 0 414 392 + 584 576 608 612 0 0 0 0>, + <0 0 0 0 0 0 459 431 + 684 644 692 679 0 0 0 0>, + <0 0 0 0 0 0 577 543 + 798 768 823 810 0 0 0 0>, + <0 0 0 0 0 0 669 629 + 886 864 924 911 0 0 0 0>, + <0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0>; + + qcom,cpr-ro-scaling-factor = + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 2035 1917 + 1959 2131 2246 2253 0 0 0 0>, + < 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0>; + + qcom,cpr-scaled-open-loop-voltage-as-ceiling; + qcom,cpr-corner-ldo-mode-allowed = + <1 1 1 1 1 1 0>; + qcom,cpr-corner-use-closed-loop = + <1 1 1 1 1 1 0>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/cprh-kbss-regulator.txt b/Documentation/devicetree/bindings/regulator/cprh-kbss-regulator.txt new file mode 100644 index 000000000000..446046ced77e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/cprh-kbss-regulator.txt @@ -0,0 +1,460 @@ +Qualcomm Technologies, Inc. CPRh Regulator - KBSS Specific Bindings + +KBSS CPRh controllers each support one CPR thread that monitors the voltage +of a single Kryo-B CPU subystem (KBSS) cluster that is powered by a single +regulator supply. The DCVSh block interacts with the CPRh controller for full +hardware DCVS support. + +Both CPR open-loop voltages and CPR target quotients are stored in hardware +fuses for KBSS CPRh controllers. + +This document describes the KBSS specific CPRh bindings. + +======================= +Required Node Structure +======================= + +CPRh regulators must be described in three levels of devices nodes. The first +level describes the CPRh controller. The second level describes one hardware +thread managed by the controller. The third level describes one regulator +handled by the CPR thread. + +All platform independent cpr3-regulator binding guidelines defined in +cpr3-regulator.txt also apply to cprh-kbss-regulator devices. + +==================================== +First Level Nodes - CPR3 Controllers +==================================== + +KBSS specific properties: +- compatible + Usage: required + Value type: <string> + Definition: should be one of the following: + "qcom,cprh-msm8998-v1-kbss-regulator", + "qcom,cprh-msm8998-v2-kbss-regulator", + "qcom,cprh-msm8998-kbss-regulator", + "qcom,cprh-sdm660-kbss-regulator", + "qcom,cprh-sdm630-kbss-regulator". + If the SoC revision is not specified, then it is assumed to + be the most recent revision of MSM8998, i.e. v2. + +- qcom,cpr-controller-id + Usage: required + Value type: <u32> + Definition: Identifies the controller number for subsystems that are managed + by multiple CPR controllers. For KBSS, the supported values are 0 + and 1, corresponding to each cluster. + +- qcom,apm-threshold-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the APM threshold voltage in microvolts. The + floor to ceiling range for every corner is adjusted to ensure + it does not intersect this voltage. The value of this property + must match with the APM threshold voltage defined in the OSM + device to ensure that if the VDD_APCC supply voltage is above + this level, then the APM is switched to use VDD_APCC and if + VDD_APCC is below this level, then the APM is switched to use + VDD_MX. + +- qcom,apm-crossover-voltage + Usage: required if qcom,apm-threshold-voltage is specified + Value type: <u32> + Definition: Specifies the APM crossover voltage in microvolts which + corresponds to the voltage the VDD supply must be set at + during an APM switch transition. + +- qcom,apm-hysteresis-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the voltage in microvolts used to adjust floor + voltages with respect to the APM threshold voltage. This + voltage is used to reduce the number of corners whose floor + must be raised to ensure stable operation with manual APM + switching. If this property is not specified, then a value + of 0 is assumed. + +- qcom,mem-acc-threshold-voltage + Usage: optional + Value type: <u32> + Definition: Specifies the highest memory accelerator (MEM ACC) threshold + voltage in microvolts. The floor to ceiling voltage range + for every corner is adjusted to ensure that it does not + intersect this voltage. The value of this property must + match with the MEM ACC threshold voltage defined in the OSM + device to ensure that MEM ACC settings are switched + appropriately. + +- qcom,mem-acc-crossover-voltage + Usage: required if qcom,mem-acc-threshold-voltage is specified + Value type: <u32> + Definition: Specifies the MEM ACC crossover voltage in microvolts which + corresponds to the voltage the VDD supply must be set to + when switching the MEM ACC configuration. + +- qcom,voltage-base + Usage: required + Value type: <u32> + Definition: Specifies the voltage in microvolts used by the CRR controller + to resolve open-loop and floor voltages. In particular, this + voltage is added to the programmed open-loop and floor voltages + and it corresponds to the minimum supported setpoint of the + vdd-supply. + +- qcom,cpr-saw-use-unit-mV + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the unit used in SAW PVC + interface is mV. Use this for vdd-supply regulators which + do not use PMIC voltage control register LSBs per actually + unique PMIC regulator output voltage. + +- qcom,cpr-up-down-delay-time + Usage: required + Value type: <u32> + Definition: The time to delay in nanoseconds between consecutive CPR + measurements when the last measurement recommended + increasing or decreasing the vdd-supply voltage. + +- qcom,cpr-down-error-step-limit + Usage: required + Value type: <u32> + Definition: CPRh hardware closed-loop down error step limit which + defines the maximum number of vdd-supply regulator steps + that the voltage may be reduced as the result of a single + CPR measurement. + +- qcom,cpr-up-error-step-limit + Usage: required + Value type: <u32> + Definition: CPRh hardware closed-loop up error step limit which defines + the maximum number of vdd-supply regulator steps that the + voltage may be increased as the result of a single + CPR measurement. + +- qcom,cpr-step-quot-fixed + Usage: optional + Value type: <u32> + Definition: Fixed step quotient value used by controller for applying + the SDELTA margin adjustments on the programmed target + quotient values. The step quotient is the number of + additional ring oscillator ticks observed for each + qcom,voltage-step increase in vdd-supply output voltage. + Supported values: 0 - 63. + +- qcom,cpr-voltage-settling-time + Usage: optional + Value type: <u32> + The time in nanoseconds that it takes for the vdd-supply + voltage to settle after being increased or decreased by + qcom,voltage-step microvolts. This is used as the wait + time after applying SDELTA voltage margin adjustments. + +- qcom,cpr-corner-switch-delay-time + Usage: optional + Value type: <u32> + The time in nanoseconds that the CPR controller must delay + to allow voltage settling per 1 mV of voltage change after a + corner change. + +- qcom,cpr-hw-closed-loop + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that the KBSS CPRh controller + should operate in hardware closed-loop mode as opposed to + open-loop. + +- qcom,cpr-temp-point-map + Usage: required if qcom,corner-band-allow-temp-adjustment is specified + for at least one of the CPR3 regulators. + Value type: <prop-encoded-array> + Definition: The temperature points in decidegrees Celsius which indicate + the range of temperature bands supported. If t1, t2, and t3 + are the temperature points, then the temperature bands are: + (-inf, t1], (t1, t2], (t2, t3], and (t3, inf). A maximum of + three temperature points can be specified to define a total + of four different temperature bands. + +- qcom,cpr-initial-temp-band + Usage: required if qcom,corner-band-allow-temp-adjustment is specified + for at least one of the CPR3 regulators. + Value type: <u32> + Definition: The initial temp band considering 0-based index at which + the baseline target quotients are derived and fused. + +================================================= +Second Level Nodes - CPR Threads for a Controller +================================================= + +KBSS specific properties: +N/A + +=============================================== +Third Level Nodes - CPR Regulators for a Thread +=============================================== + +KBSS specific properties: +- qcom,cpr-fuse-corners + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse corners. This value must be 4 + for KBSS. These fuse corners are: LowSVS, SVS, Nominal, + and Turbo. + +- qcom,cpr-fuse-combos + Usage: required + Value type: <u32> + Definition: Specifies the number of fuse combinations being supported by + the device. This value is utilized by several other + properties. Supported values are 1 up to the maximum + possible for a given regulator type. For KBSS the maximum + supported value is 8. These combos correspond to CPR + revision fuse values 0 to 7 in order. + +- qcom,allow-quotient-interpolation + Usage: optional + Value type: <empty> + Definition: Boolean flag which indicates that it is acceptable to use + interpolated CPR target quotient values. These values are + interpolated between the target quotient Fmax fuse values. + +- qcom,cpr-corner-bands + Usage: required if qcom,corner-band-allow-core-count-adjustment + or qcom,corner-band-allow-temp-adjustment is specified + for this CPR3 regulator. + Value type: <prop-encoded-array> + Definition: A list of integers which defines how many corner bands + exist for each fuse combination. Supported values are 1 to 4. + The list must contain either qcom,cpr-fuse-combos number of + elements in which case the corner band counts are applied to + fuse combinations 1-to-1 or the list must contain exactly 1 + element which is used regardless of the fuse combination + found on a given chip. + +- qcom,cpr-speed-bin-corner-bands + Usage: required if qcom,cpr-speed-bins and + qcom,corner-band-allow-core-count-adjustment or + qcom,corner-band-allow-temp-adjustment are specified for + this CPR3 regulator. + Value type: <prop-encded-array> + Definition: A list of integers which defines how many corner bands + are to be used for each speed bin. The list must contain + qcom,cpr-speed-bins number of elements. + +- qcom,corner-band-allow-core-count-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the CPR core + count adjustment feature enable state for each corner band + in order from lowest to highest. Each element in the tuple + should be either 0 (per-core-count adjustment not allowed) + or 1 (per-core-count adjustment allowed). A maximum of four + corner bands may be used to partition the corner space into + contiguous corner ranges. For all corners within a corner band, + the same per-core-count adjustments are applied. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the corresponding + element of the qcom,cpr-corner-bands property. + +- qcom,max-core-count + Usage: required if qcom,corner-band-allow-core-count-adjustment is + specified for this CPR3 regulator. + Value type: <u32> + Definition: The maximum number of cores considered for core-count vmin + adjustments specified for this regulator's corner bands. + +- qcom,corner-band-allow-temp-adjustment + Usage: optional + Value type: <prop-encoded-array> + Definition: A list of integer tuples which each define the temperature + adjustment feature enable state for each corner band + in order from lowest to highest. Each element in the tuple + should be either 0 (temperature adjustment not allowed) + or 1 (temperature adjustment allowed). A maximum of four + corner bands may be used to partition the corner space into + contiguous corner ranges. For all corners within a corner band, + the same temperature adjustments are applied. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the corresponding + element of the qcom,cpr-corner-bands property. + +- qcom,cpr-corner-band-map + Usage: required if qcom,corner-band-allow-core-count-adjustment + or qcom,corner-band-allow-temp-adjustment is specified + for this CPR3 regulator. + Value type: <prop-encoded-array> + Definition: A list of integer tuples which correspond to corner numbers + and define the corner bands to be used for temperature or + per-core-count adjustments. The corner numbers must be specified + in increasing order to result in partitioning the corner space + into contiguous corner ranges. The supported tuple size is 1 + to 4 elements. For example, a tuple with corners defined as + c1, c2, c3, c4 results in the following corner band mapping: + + [c1, c2) -> Corner Band 1 + [c2, c3) -> Corner Band 2 + [c3, c4) -> Corner Band 3 + [c4, inf)-> Corner Band 4 + + Corners less than c1 will have no per-core-count or temperature + adjustments. Adjustments associated with each corner band X are + defined in the corresponding + qcom,cpr-corner-bandX-temp-core-voltage-adjustment property. + + The list must contain qcom,cpr-fuse-combos number of tuples + in which case the tuples are matched to fuse combinations + 1-to-1 or qcom,cpr-speed-bins number of tuples in which case + the tuples are matched to speed bins 1-to-1 or exactly 1 + tuple which is used regardless of the fuse combination and + speed bin found on a given chip. + + Each tuple must be of the length defined in the corresponding + element of the qcom,cpr-corner-bands property. + +- qcom,cpr-corner-bandX-temp-core-voltage-adjustment + Usage: required if qcom,corner-band-allow-core-count-adjustment + is specified for this CPR3 regulator. + Value type: <prop-encoded-array> + Definition: A grouping of integer tuple lists for corner bandX. The possible + values for X are 1 to 4. Each tuple defines the temperature based + voltage adjustment in microvolts for each temperature band + from lowest to highest for a given number of online cores. Each + tuple must have a number of elements equal to either (the number + of elements in qcom,cpr-temp-point-map + 1), if + qcom,cpr-temp-point-map is specified, or 1. + + Each tuple list must contain a number of tuples equal to + either qcom,max-core-count, if qcom,max-core-count is + specified, or 1. The tuples should be ordered from lowest + to highest core count. + + The tuple list grouping must contain qcom,cpr-fuse-combos + number of tuple lists in which case the lists are matched to + fuse combinations 1-to-1 or qcom,cpr-speed-bins number of + tuple lists in which case the lists are matched to + speed bins 1-to-1 or exactly 1 list which is used regardless + of the fuse combination and speed bin found on a given chip. + +======= +Example +======= + +apc0_cpr: cprh-ctrl@179c8000 { + compatible = "qcom,cprh-msm8998-kbss-regulator"; + reg = <0x179c8000 0x4000>, <0x00784000 0x1000>; + reg-names = "cpr_ctrl", "fuse_base"; + clocks = <&clock_gcc clk_gcc_hmss_rbcpr_clk>; + clock-names = "core_clk"; + qcom,cpr-ctrl-name = "apc0"; + qcom,cpr-controller-id = <0>; + + qcom,cpr-sensor-time = <1000>; + qcom,cpr-loop-time = <5000000>; + qcom,cpr-idle-cycles = <15>; + qcom,cpr-up-down-delay-time = <3000>; + qcom,cpr-step-quot-init-min = <11>; + qcom,cpr-step-quot-init-max = <13>; + qcom,cpr-count-mode = <2>; /* Staggered */ + qcom,cpr-down-error-step-limit = <1>; + qcom,cpr-up-error-step-limit = <1>; + qcom,cpr-corner-switch-delay-time = <1600>; + qcom,cpr-voltage-settling-time = <1600>; + + qcom,apm-threshold-voltage = <800000>; + qcom,apm-hysteresis-voltage = <4000>; + qcom,voltage-step = <4000>; + qcom,voltage-base = <352000>; + qcom,cpr-saw-use-unit-mV; + + qcom,cpr-enable; + qcom,cpr-hw-closed-loop; + + qcom,cpr-initial-temp-band = <3>; + qcom,cpr-temp-point-map = <0 25 85>; + + thread@0 { + qcom,cpr-thread-id = <0>; + qcom,cpr-consecutive-up = <2>; + qcom,cpr-consecutive-down = <2>; + qcom,cpr-up-threshold = <0>; + qcom,cpr-down-threshold = <0>; + + apc0_pwrcl_vreg: regulator-pwrcl { + regulator-name = "apc0_pwrcl_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <24>; + + qcom,cpr-fuse-corners = <4>; + qcom,cpr-fuse-combos = <1>; + qcom,cpr-corners = <23>; + + qcom,cpr-corner-fmax-map = <7 10 17 23>; + + qcom,cpr-voltage-ceiling = + <632000 632000 632000 632000 632000 + 632000 632000 700000 700000 700000 + 828000 828000 828000 828000 828000 + 828000 828000 1024000 1024000 1024000 + 1024000 1024000 1024000>; + + qcom,cpr-voltage-floor = + <572000 572000 572000 572000 572000 + 572000 572000 568000 568000 568000 + 684000 684000 684000 684000 684000 + 684000 684000 856000 856000 856000 + 856000 856000 856000>; + + qcom,corner-frequencies = + <300000000 345600000 422400000 + 499200000 576000000 633600000 + 710400000 806400000 883200000 + 960000000 1036800000 1113600000 + 1190400000 1248000000 1324800000 + 1401600000 1478400000 1497600000 + 1574400000 1651200000 1728000000 + 1804800000 1881600000>; + }; + + qcom,cpr-corner-bands = <4>; + qcom,corner-band-allow-core-count-adjustment = <1 1 1 1>; + qcom,corner-band-allow-temp-adjustment = <1 0 0 0>; + qcom,cpr-corner-band-map = <7 14 18 20>; + qcom,max-core-count = <4>; + qcom,cpr-corner-band1-temp-core-voltage-adjustment = + <(-24000) (-20000) (-20000) (-16000)>, + <(-16000) (-16000) (-12000) (-8000)>, + <(-8000) (-8000) (-4000) (-4000)>, + <0 0 0 0>; + qcom,cpr-corner-band2-temp-core-voltage-adjustment = + <(-36000) 0 0 0>, + <(-32000) 0 0 0>, + <(-24000) 0 0 0>, + < 0 0 0 0>; + qcom,cpr-corner-band3-temp-core-voltage-adjustment = + <(-40000) 0 0 0>, + <(-36000) 0 0 0>, + <(-32000) 0 0 0>, + < 0 0 0 0>; + qcom,cpr-corner-band4-temp-core-voltage-adjustment = + <(-44000) 0 0 0>, + <(-32000) 0 0 0>, + <(-24000) 0 0 0>, + < 0 0 0 0>; + }; + }; +} diff --git a/Documentation/devicetree/bindings/regulator/fan53555.txt b/Documentation/devicetree/bindings/regulator/fan53555.txt index 54a3f2c80e3a..90ca0b70d555 100644 --- a/Documentation/devicetree/bindings/regulator/fan53555.txt +++ b/Documentation/devicetree/bindings/regulator/fan53555.txt @@ -1,7 +1,8 @@ Binding for Fairchild FAN53555 regulators Required properties: - - compatible: one of "fcs,fan53555", "silergy,syr827", "silergy,syr828" + - compatible: one of "fcs,fan53555", "silergy,syr827", "silergy,syr828" or + "halo,hl7509" - reg: I2C address Optional properties: @@ -10,6 +11,10 @@ Optional properties: voltage. The other one is used for the runtime voltage setting Possible values are either <0> or <1> - vin-supply: regulator supplying the vin pin + - fcs,disable-suspend: Boolean flag which specifies if suspend voltage + configuration should be avoided. If this property is present, + then the voltage selector register defined by + fcs,suspend-voltage-selector should not be modified at runtime. Example: @@ -21,3 +26,12 @@ Example: vin-supply = <&parent_reg>; fcs,suspend-voltage-selector = <1>; }; + + regulator@60 { + compatible = "halo,hl7509"; + regulator-name = "hl7509"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1230000>; + fcs,suspend-voltage-selector = <1>; + fcs,disable-suspend; + }; diff --git a/Documentation/devicetree/bindings/regulator/gdsc-regulator.txt b/Documentation/devicetree/bindings/regulator/gdsc-regulator.txt new file mode 100644 index 000000000000..20e5c5be37ce --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/gdsc-regulator.txt @@ -0,0 +1,67 @@ +Qualcomm Global Distributed Switch Controller (GDSC) Regulator Driver + +The GDSC driver, implemented under the regulator framework, is responsible for +safely collapsing and restoring power to peripheral cores on chipsets like +msm8974 for power savings. + +Required properties: + - compatible: Must be "qcom,gdsc" + - regulator-name: A string used as a descriptive name for regulator outputs + - reg: The address of the GDSCR register + +Optional properties: + - parent-supply: phandle to the parent supply/regulator node + - clock-names: List of string names for core clocks + - qcom,retain-mem: Presence denotes a hardware requirement to leave the + forced core memory retention signals in the core's clock + branch control registers asserted. + - qcom,retain-periph: Presence denotes a hardware requirement to leave the + forced periph memory retention signal in the core's clock + branch control registers asserted. + - qcom,skip-logic-collapse: Presence denotes a requirement to leave power to + the core's logic enabled. + - qcom,support-hw-trigger: Presence denotes a hardware feature to switch + on/off this regulator based on internal HW signals + to save more power. + - qcom,enable-root-clk: Presence denotes that the clocks in the "clocks" + property are required to be enabled before gdsc is + turned on and disabled before turning off gdsc. This + will be used in subsystems where reset is synchronous + and root clk is active without sw being aware of its + state. The clock-name which denotes the root clock + should be named as "core_root_clk". + - qcom,force-enable-root-clk: If set, denotes that the root clock should be + force enabled before turning on the GDSC and then be + immediately force disabled. Likewise for GDSC disable. + This is used in cases where the core root clock needs + to be force-enabled prior to turning on the core. The + clock-name which denotes the root clock should be + "core_root_clk". + - qcom,clk-dis-wait-val: Input value for CLK_DIS_WAIT controls state transition + delay after halting clock in the collapsible core. + - reg-names: Names of the bases for the above "reg" registers. + Ex. "base", "domain_addr". + - qcom,no-status-check-on-disable: Do not poll the status bit when GDSC + is disabled. + - qcom,disallow-clear: Presence denotes the periph & core memory will not be + cleared, unless the required subsystem does not invoke + the api which will allow clearing the bits. + - qcom,gds-timeout: Maximum time (in usecs) that might be taken by a GDSC + to enable. + - qcom,reset-aon-logic: If present, the GPU DEMET cells need to be reset while + enabling the GX GDSC. + - resets: reset specifier pair consisting of phandle for the reset controller + and reset lines used by this controller. These can be + supplied only if we support qcom,skip-logic-collapse. + - reset-names: reset signal name strings sorted in the same order as the resets + property. These can be supplied only if we support + qcom,skip-logic-collapse. + +Example: + gdsc_oxili_gx: qcom,gdsc@fd8c4024 { + compatible = "qcom,gdsc"; + regulator-name = "gdsc_oxili_gx"; + parent-supply = <&pm8841_s4>; + reg = <0xfd8c4024 0x4>; + clock-names = "core_clk"; + }; diff --git a/Documentation/devicetree/bindings/regulator/kryo-regulator.txt b/Documentation/devicetree/bindings/regulator/kryo-regulator.txt new file mode 100644 index 000000000000..ad630eeb3a29 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/kryo-regulator.txt @@ -0,0 +1,151 @@ +Qualcomm Technologies, Inc. Kryo Regulator + +The Kryo regulator device is designed for QTI's application processor cores +that can draw power from a common power rail via a block head switch (BHS) +or from a configurable LDO when certain power constraints are met. By using +Kryo regulators, the CPU subsystem is capable of selecting LDO or BHS modes +for each cluster. + +================= +First Level Nodes +================= + +- compatible + Usage: required + Value type: <string> + Definition: must be "qcom,kryo-regulator" + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Specifies addresses and sizes for the memory mapped regions of the + power gate and LDO registers per cluster and per shared power rail + domain. The third address must correspond to the register space + containing the CPU subsystem HW revision register. + +- reg-names + Usage: required + Value type: <stringlist> + Definition: Identifies the reg property entries. Must contain the following + strings: "pm-apc", "pm-apcc", and "apcs-csr". + +- qcom,ldo-default-voltage + Usage: required + Value type: <u32> + Definition: The default value for LDO voltage in microvolts. Must be + between 520000 uV and 865000 uV. + +- qcom,retention-voltage + Usage: required + Value type: <u32> + Definition: The value for retention voltage in microvolts. Must be + between 520000 and 865000 uV. + +- qcom,ldo-headroom-voltage + Usage: required + Value type: <u32> + Definition: Voltage in microvolts required between the VDD_APCC voltage supply + and the LDO output in order for the LDO to be operational. + +- qcom,vref-functional-step-voltage + Usage: required + Value type: <u32> + Definition: The voltage change in microvolts for each step in the + functional LDO set point. + +- qcom,vref-functional-min-voltage + Usage: required + Value type: <u32> + Definition: The minimum configurable functional LDO voltage in microvolts. + +- qcom,vref-retention-step-voltage + Usage: required + Value type: <u32> + Definition: The voltage change in microvolts for each step in the + retention LDO set point. + +- qcom,vref-retention-min-voltage + Usage: required + Value type: <u32> + Definition: The minimum configurable retention LDO voltage in microvolts. + +- qcom,ldo-config-init + Usage: required + Value type: <u32> + Definition: Initialization value used to configure the Kryo LDO hardware. + +- qcom,apm-config-init + Usage: required + Value type: <u32> + Definition: Initialization value used to configure the Kryo APM hardware. + +- qcom,cluster-num + Usage: required + Value type: <u32> + Definition: Specifies the number of the cluster this regulator controls. + +================== +Second Level Nodes +================== +The second level node represents a regulator which enables control of LDO retention +mode per Kryo regulator device. This second level node is required. + +The following regulator framework properties must be specified for both first and +second level nodes: regulator-name, regulator-min-microvolt, and regulator-max-microvolt. + +Additional core regulator framework properties may also be used. For a full list of +supported bindings refer to Documentation/devicetree/bindings/regulator/regulator.txt. + +======= +Example +======= + + kryo0_vreg: regulator@99a2000 { + compatible = "qcom,kryo-regulator"; + regulator-name = "kryo0"; + reg = <0x99a2000 0x1000>, <0x99e0000 0x1000>, + <0x9820000 0x1000>; + reg-names = "pm-apc", "pm-apcc", "apcs-csr"; + regulator-min-microvolt = <520000>; + regulator-max-microvolt = <865000>; + qcom,ldo-default-voltage = <750000>; + qcom,retention-voltage = <520000>; + qcom,ldo-headroom-voltage = <150000>; + qcom,vref-functional-step-voltage = <4100>; + qcom,vref-functional-min-voltage = <299000>; + qcom,vref-retention-step-voltage = <4554>; + qcom,vref-retention-min-voltage = <332000>; + qcom,ldo-config-init = <0xf1f0e471>; + qcom,apm-config-init = <0x0>; + qcom,cluster-num = <0>; + kryo0_retention_vreg: regulator { + regulator-name = "kryo0-retention"; + regulator-min-microvolt = <332000>; + regulator-max-microvolt = <865000>; + }; + }; + + kryo1_vreg: regulator@99d2000 { + compatible = "qcom,kryo-regulator"; + regulator-name = "kryo1"; + reg = <0x99d2000 0x1000>, <0x99e0000 0x1000>, + <0x9820000 0x1000>; + reg-names = "pm-apc", "pm-apcc", "apcs-csr"; + regulator-min-microvolt = <520000>; + regulator-max-microvolt = <865000>; + qcom,ldo-default-voltage = <750000>; + qcom,retention-voltage = <520000>; + qcom,ldo-headroom-voltage = <150000>; + qcom,vref-functional-step-voltage = <4063>; + qcom,vref-functional-min-voltage = <296000>; + qcom,vref-retention-step-voltage = <4554>; + qcom,vref-retention-min-voltage = <332000>; + qcom,ldo-config-init = <0xf1f0e471>; + qcom,apm-config-init = <0x0>; + qcom,cluster-num = <1>; + kryo1_retention_vreg: regulator { + regulator-name = "kryo1-retention"; + regulator-min-microvolt = <332000>; + regulator-max-microvolt = <865000>; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/mem-acc-regulator.txt b/Documentation/devicetree/bindings/regulator/mem-acc-regulator.txt new file mode 100644 index 000000000000..55154579840a --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/mem-acc-regulator.txt @@ -0,0 +1,266 @@ +Qualcomm Technologies, Inc. Memory Accelerator + +Memory accelerator configures the power-mode (corner) for the +accelerator. + +Required properties: +- compatible: Must be "qcom,mem-acc-regulator" +- regulator-name: A string used to describe the regulator +- regulator-min-microvolt: Minimum corner value as min constraint, which + should be 1 for SVS corner +- regulator-max-microvolt: Maximum corner value as max constraint, which + should be 4 for SUPER_TURBO or 3 for TURBO + +Optional properties: +- reg: Register addresses for acc-sel-l1, acc-sel-l2 control, acc-en, + MEM ACC eFuse address, acc-l1-custom , acc-l2-custom, + mem-acc-type1, mem-acc-type2, mem-acc-type3, mem-acc-type4, + mem-acc-type5 and mem-acc-type6. +- reg-names: Register names. Must be "acc-sel-l1", + "acc-sel-l2", "acc-en", "efuse_addr", + "acc-l1-custom", "acc-l2-custom", "mem-acc-type1", + "mem-acc-type2", "mem-acc-type3", "mem-acc-type4", + "mem-acc-type5", "mem-acc-type6". + A given mem-acc-regulator driver must have "acc-sel-l1" or + "acc-sel-l2" or "mem-acc-type*" reg-names property and + related register address property. +- qcom,corner-acc-map Array which maps the APC (application processor) + corner value to the accelerator corner. The number of elements + in this property defines the number of accelerator corners. + Either qcom,corner-acc-map property or qcom,cornerX-reg-config + properties should be specified. +- qcom,acc-en-bit-pos Array which specifies bit positions in the + 'acc-en' register. Setting these bits forces the + the acclerator to use the corner value specified + in the 'acc-sel-l1' and 'acc-sel-l2' register. +- qcom,acc-sel-l1-bit-size Integer which specifies the number of bits in + the 'acc-sel-l1' register which define each L1 + select parameter. If this property is not + specified, then a default value of 2 is assumed. +- qcom,acc-sel-l1-bit-pos Array which specifies bit positions in the + 'acc-sel-l1' register. Each element in this array + is the LSB of an N-bit value where 'N' is + defined by the qcom,acc-sel-l1-bit-size + property. This N-bit value specifies the corner + value used by the accelerator for the L1 cache. +- qcom,acc-sel-l2-bit-size Integer which specifies the number of bits in + the 'acc-sel-l2' register which define each L2 + select parameter. If this property is not + specified, then a default value of 2 is assumed. +- qcom,acc-sel-l2-bit-pos Array which specifies bit positions in the + 'acc-sel-l2' register. Each element in this array + is the LSB of an N-bit value where 'N' is + defined by the qcom,acc-sel-l2-bit-size + property. This N-bit value specifies the corner + value used by the accelerator for the L2 cache. +- qcom,l1-acc-custom-data: Array which maps APC corner values to L1 ACC custom data values. + The corresponding custom data is written into the custom register + while switching between APC corners. The custom register address + is specified by "acc-11-custom" reg-property. The length of the array + should be equal to number of APC corners. +- qcom,l2-acc-custom-data: Array which maps APC corner values to L2 ACC custom data values. + The corresponding custom data is written into the custom register + while switching between APC corners. The custom register address + is specified by "acc-l2-custom" reg-property. The length of the array + should be equal to number of APC corners. +- qcom,override-acc-fuse-sel: Array of 4 elements which specify the way to read the override fuse. + The override fuse value is used by the qcom,override-fuse-version-map + to identify the correct set of override properties. + The 4 elements with index [0..4] are: + [0] => the fuse row number of the selector + [1] => LSB bit position of the bits + [2] => number of bits + [3] => fuse reading method, 0 for direct reading or 1 for SCM reading +- qcom,override-fuse-version-map: Array of integers which each match to a override fuse value. + Any element in a tuple may use the value 0xffffffff as a wildcard. + The index of the first value (in the array) which matches the override fuse + is used to select the right tuples from the other override properties. +- qcom,override-corner-acc-map: Array of tuples which overrides the existing acc-corner map + (specified by qcom,corner-acc-map) with corner values selected + from this property. "qcom,override-corner-acc-map" must contain the + same number of tuples as "qcom,override-fuse-version-map". These tuples + are then mapped one-to-one in the order specified. If the + "qcom,override-fuse-version-map" property is not specified, then + "qcom,override-corner-acc-map" must contain a single tuple which is then + applied unconditionally. +- qcom,override-l1-acc-custom-data: Array of tuples of which overrides the existing l1-acc-custom data + (specified by qcom,l1-acc-custom-data), with values specified in this property. + The corresponding custom data is written into the custom register while + switching between APC corners. The custom register address is specified by + "acc-11-custom" reg-property. This property can only be specified if the + "qcom,l1-acc-custom-data" is already defined. If the + "qcom,override-fuse-version-map" property is specified, then + qcom,override-l1-acc-custom-data must contain the same number of tuples + as "qcom,override-fuse-version-map". These tuples are then mapped one-to-one + in the order specified. If the qcom,override-fuse-version-map property is + not specified, then "qcom,override-l1-acc-custom-data" must contain a single + tuple which is then applied unconditionally. +- qcom,override-l2-acc-custom-data: Array of tuples of which overrides the existing l1-acc-custom data + (specified by qcom,l2-acc-custom-data), with values specified in this property. + The corresponding custom data is written into the custom register while + switching between APC corners. The custom register address is specified by + "acc-12-custom" reg-property. This property can only be specified if the + "qcom,l2-acc-custom-data" is already defined. If the + "qcom,override-fuse-version-map" property is specified, then + "qcom,override-l2-acc-custom-data" must contain the same number of tuples + as "qcom,override-fuse-version-map". These tuples are then mapped one-to-one + in the order specified. If the qcom,override-fuse-version-map property is + not specified, then "qcom,override-l2-acc-custom-data" must contain a single + tuple which is then applied unconditionally. +- qcom,mem-acc-type1: Array which specifies the value to be written to the mem acc type1 register for each fuse + corner, from the lowest fuse corner to the highest fuse corner. The length of the array + must be equal to the number of APC fuse corners. This property must be present if reg names + specifies mem-acc-type1. +- qcom,mem-acc-type2: Same as qcom,mem-acc-type1 except for mem acc type2 register. +- qcom,mem-acc-type3: Same as qcom,mem-acc-type1 except for mem acc type3 register. +- qcom,mem-acc-type4: Same as qcom,mem-acc-type1 except for mem acc type4 register. +- qcom,mem-acc-type5: Same as qcom,mem-acc-type1 except for mem acc type5 register. +- qcom,mem-acc-type6: Same as qcom,mem-acc-type1 except for mem acc type6 register. +- qcom,acc-reg-addr-list: Array of register addresses which need to be programmed during any corner switch. + This property can be used when multi register configuration is needed during a corner switch. +- qcom,acc-init-reg-config: Array of tuples specify the multi register configuration sequence need to be programmed + one time during device boot. + The format of each tuple as below: + <register-address-index, value> + Where register-address-index is used as an index in to qcom,acc-reg-addr-list property + to get the required register address and the value is programmed in to the corresponding + mapped register address. This property is required if qcom,acc-corner-addr-val-map + property specified. +- qcom,cornerX-reg-config: Array of tuples specify the multi register configuration sequence need to be programmed + when switching from acc corner X to any other corner. The possible values for X are {1, N}, + where N is the value defined in qcom,num-acc-corners. + The format of each tuple as below: + <register-address-index, value> + Where register-address-index is used as an index in to qcom,acc-reg-addr-list property + to get the required register address and the value is programmed in to the corresponding + mapped register address. Same index can be used multiple times when the register is + required to configure multiple times with different values in the sequence. + The number of register configuration sequences should be equal to N, where N is the + value specified in qcom,num-acc-corners property. Also, the number of tuples in each + register configuration sequence should be same and must be equal to the maximum required + register configurations in any sequence. The invalid register configuration can be + specified as <(-1) (-1)>. This property can only be specified when qcom,acc-corner-addr-val-map + property already defined. Either this property or qcom,corner-acc-map should be specified. +- qcom,num-acc-corners: The number of acc corners supported. This property is required if qcom,cornerX-reg-config + property specified. +- qcom,boot-acc-corner: The acc corner used during device boot. This property is required if qcom,cornerX-reg-config + property specified. +- qcom,override-cornerX-reg-config: A grouping of register configuration sequence lists. Each list is same as + the qcom,cornerX-reg-config property. The possible values for X are {1, N} where N is + the value defined in qcom,num-acc-corners. This property is used to specify the different + register configuration sequence lists and select one list among them based on the selected + index in qcom,override-fuse-version-map property. The selected list overrides the existing + register configuration sequence list specified in "qcom,cornerX-reg-config". If the + "qcom,override-fuse-version-map" property is specified, then + "qcom,override-cornerX-reg-config" must contain the same number of register + configuration sequence lists as the number of tuples in "qcom,override-fuse-version-map". + These register configuration sequence lists are then mapped one-to-one + in the order specified. If the qcom,override-fuse-version-map property is + not specified, then "qcom,override-cornerX-reg-config" must contain a single + register configuration sequence list which is then applied unconditionally. + This property can only be specified if qcom,cornerX-reg-config property is already defined. + +mem_acc_vreg_corner: regulator@fd4aa044 { + compatible = "qcom,mem-acc-regulator"; + reg = <0xfd4aa048 0x1>, <0xfd4aa044 0x1>, <0xfd4af000 0x1>, + <0x58000 0x1000>, <0x01942124 0x4>, <0xf900d084 1>, + <0xf900d088 1>, <0xf900d08c 1>, <0xf900d090 1>; + reg-names = "acc-en", "acc-sel-l1" , "acc-sel-l2", + "efuse_addr", "acc-l2-custom", "mem-acc-type1", + "mem-acc-type2", "mem-acc-type3", "mem-acc-type4"; + regulator-name = "mem_acc_corner"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <3>; + + qcom,acc-en-bit-pos = <0>; + qcom,acc-sel-l1-bit-pos = <0>; + qcom,acc-sel-l2-bit-pos = <0>; + qcom,acc-sel-l1-bit-size = <2>; + qcom,acc-sel-l2-bit-size = <2>; + qcom,corner-acc-map = <0 1 3>; + qcom,l2-acc-custom-data = <0x0 0x3000 0x3000>; + + qcom,override-acc-fuse-sel = <0 52 2 0>; + qcom,override-fuse-version-map = <0>, + <2>, + <(-1)>; + qcom,override-corner-acc-map = <0 0 1>, + <0 1 2>, + <0 1 1>; + qcom,overide-l2-acc-custom-data = <0x0 0x0 0x3000>, + <0x0 0x3000 0x3000>, + <0x0 0x0 0x0>; + qcom,mem-acc-type1 = <0x02 0x02 0x00>; + qcom,mem-acc-type2 = <0x02 0x02 0x00>; + qcom,mem-acc-type3 = <0x02 0x02 0x00>; + qcom,mem-acc-type4 = <0x02 0x02 0x00>; + + qcom,acc-reg-addr-list = <0x01942130 0x01942124 0x01942120>; + qcom,acc-init-reg-config = <1 0x55> <2 0x02>; + + qcom,num-acc-corners = <3>; + qcom,boot-acc-corner = <2>; + qcom,corner1-reg-config = + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 1 -> 1 */ + < 1 0x155>, < 2 0x0>, < 3 0x155>, /* 1 -> 2 */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>; /* 1 -> 3 */ + + qcom,corner2-reg-config = + < 1 0x155>, <(-1) (-1)>, <(-1) (-1)>, /* 2 -> 1 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 2 -> 2 */ + < 1 0x155>, < 2 0x0>, < 3 0x155>; /* 2 -> 3 */ + + qcom,corner3-reg-config = + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 3 -> 1 */ + < 1 0x155>, <(-1) (-1)>, <(-1) (-1)>, /* 3 -> 2 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>; /* 3 -> 3 */ + + qcom,override-corner1-reg-config = + /* 1st fuse version tuple matched */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 1 -> 1 */ + < 1 0x155>, < 2 0x0>, < 3 0x155>, /* 1 -> 2 */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 1 -> 3 */ + + /* 2nd fuse version tuple matched */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 1 -> 1 */ + < 1 0x155>, < 2 0x0>, < 3 0x155>, /* 1 -> 2 */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 1 -> 3 */ + + /* 3rd fuse version tuple matched */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 1 -> 1 */ + < 1 0x155>, < 3 0x22>, < 3 0x155>, /* 1 -> 2 */ + < 1 0x0>, < 2 0x155>, < 3 0x144>; /* 1 -> 3 */ + + qcom,override-corner2-reg-config = + /* 1st fuse version tuple matched */ + < 1 0x144>, < 1 0x11>, <(-1) (-1)>, /* 2 -> 1 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 2 -> 2 */ + < 1 0x155>, < 2 0x0>, < 3 0x155>, /* 2 -> 3 */ + + /* 2nd fuse version tuple matched */ + < 1 0x144>, < 2 0x133>, <(-1) (-1)>, /* 2 -> 1 */ + <(-1) (-1)>, < 1 0x33>, <(-1) (-1)>, /* 2 -> 2 */ + < 1 0x133>, < 2 0x0>, < 3 0x155>, /* 2 -> 3 */ + + /* 3rd fuse version tuple matched */ + < 1 0x144>, < 1 0x11>, <(-1) (-1)>, /* 2 -> 1 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 2 -> 2 */ + < 1 0x155>, < 2 0x22>, < 3 0x155>; /* 2 -> 3 */ + + + qcom,override-corner3-reg-config = + /* 1st fuse version tuple matched */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 3 -> 1 */ + < 1 0x155>, <(-1) (-1)>, <(-1) (-1)>, /* 3 -> 2 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 3 -> 3 */ + + /* 2nd fuse version tuple matched */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 3 -> 1 */ + < 1 0x155>, <(-1) (-1)>, <(-1) (-1)>, /* 3 -> 2 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>, /* 3 -> 3 */ + + /* 3rd fuse version tuple matched */ + < 1 0x0>, < 2 0x155>, <(-1) (-1)>, /* 3 -> 1 */ + < 1 0x155>, < 3 0x11>, <(-1) (-1)>, /* 3 -> 2 */ + <(-1) (-1)>, <(-1) (-1)>, <(-1) (-1)>; /* 3 -> 3 */ +}; diff --git a/Documentation/devicetree/bindings/regulator/msm_gfx_ldo.txt b/Documentation/devicetree/bindings/regulator/msm_gfx_ldo.txt new file mode 100644 index 000000000000..bd7627b132ea --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/msm_gfx_ldo.txt @@ -0,0 +1,149 @@ +Qualcomm Technologies, Inc. GFX LDO for Graphics + +The GPU core on MSM 8953 can be powered by an internal (on-die) +MSM LDO or BHS based on its operating corner. + +This document describes the bindings that apply for the GFX LDO regulator. + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,msm8953-gfx-ldo" for MSM8953, + "qcom,sdm660-gfx-ldo" for SDM660 and "qcom,sdm630-gfx-ldo" + for SDM630. + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of the GFX ldo + +- reg-names + Usage: required + Value type: <stringlist> + Definition: Address names. "ldo_addr", "efuse_addr". Must be + specified in the same order as the corresponding addresses + are specified in the reg property. + +- regulator-name + Usage: required + Value type: <string> + Definition: A string used to describe the regulator. + +- regulator-min-microvolt + Usage: required + Value type: <u32> + Definition: Minimum corner value which should be 1 to represent the + lowest supported corner. + +- regulator-max-microvolt + Usage: required + Value type: <u32> + Definition: Maximum corner value which should be equal to qcom,num-corners. + +- qcom,num-corners + Usage: required + Value type: <u32> + Definition: Number of voltage corners present. Many other + properties are sized based upon this value. + +- qcom,num-ldo-corners + Usage: required + Value type: <u32> + Definition: Number of voltage corners defined for the ldo. It is a + subset of qcom,num-corners (i.e. 1 to qcom,num-ldo-corners + are the corners for ldo operation) + +- qcom,init-corner + Usage: required + Value type: <u32> + Definition: The initial-corner at which the GFX rail is powered on. + +- qcom,ldo-enable-corner-map + Usage: required + Value type: <prop-encoded-array> + Definition: Integer values ( / 0) which indicate the GFX corners in which + ldo is to enabled. The length of this property + should be equal to qcom,num-corners. + +- qcom,ldo-voltage-ceiling + Usage: required + Value type: <prop-encoded-array> + Definition: Array of ceiling voltages in microvolts for voltage corners + ordered from lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,num-ldo-corners. + +- qcom,ldo-voltage-floor + Usage: required + Value type: <prop-encoded-array> + Definition: Array of floor voltages in microvolts for voltage corners + ordered from lowest voltage corner to highest voltage corner. + This property must be of length defined by qcom,num-ldo-corners. + +- vdd-cx-supply + Usage: optional + Value type: <phandle> + Definition: Parent regulator supply to the ldo. + +- qcom,vdd-cx-corner-map + Usage: required if vdd-cx-supply is specified. + Value type: <prop-encoded-array> + Definition: Array of integers which define the mapping of the VDD_CX corner + to the corresponding GFX voltage corner. The elements in + the array are ordered from lowest voltage corner to highest + voltage corner. The length of this property must be equal to + the value defined by qcom,num-corners. +- mem-acc-supply + Usage: optional + Value type: <phandle> + Definition: Regulator to vote for the memory accelerator configuration. + Not Present: memory accelerator configuration not supported. + +- qcom,mem-acc-corner-map: + Usage: optional + Value type: <prop-encoded-aray> + Definition: Array of integer which defines the mapping from mem-acc + corner value for each gfx corner. The elements in the array + are ordered from lowest voltage corner to highest voltage corner. + +- qcom,ldo-init-voltage-adjustment + Usage: optional + Value type: <prop-encoded-aray> + Definition: Array of voltages in microvolts which indicate the static + adjustment to be applied to the open-loop voltages for the + LDO supported corners. The length of this property must be + equal to qcom,num-ldo-corners. + +======= +Example +======= + + gfx_vreg_corner: ldo@0185f000 { + compatible = "qcom,msm8953-gfx-ldo"; + reg = <0x0185f000 0x30>, <0xa0000 0x1000>; + reg-names = "ldo_addr", "efuse_addr"; + + regulator-name = "msm_gfx_ldo"; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <7>; + + qcom,ldo-voltage-ceiling = <500000 700000 900000>; + qcom,ldo-voltage-floor = <400000 600000 800000>; + + qcom,num-corners = <7>; + qcom,num-ldo-corners = <3>; + qcom,ldo-enable-corner-map = <1 1 1 0 0 0 0>; + qcom,init-corner = <5>; + + vdd-cx-supply = <&pm8953_s2_level>; + qcom,vdd-cx-corner-map = <RPM_SMD_REGULATOR_LEVEL_LOW_SVS>, + <RPM_SMD_REGULATOR_LEVEL_LOW_SVS>, + <RPM_SMD_REGULATOR_LEVEL_LOW_SVS>, + <RPM_SMD_REGULATOR_LEVEL_SVS>, + <RPM_SMD_REGULATOR_LEVEL_NOM>, + <RPM_SMD_REGULATOR_LEVEL_NOM_PLUS>, + <RPM_SMD_REGULATOR_LEVEL_TURBO>; + + mem-acc-supply = <&gfx_mem_acc>; + qcom,mem-acc-corner-map = <1 1 2 2 2 2 2>; + qcom,ldo-init-voltage-adjustment = <10000 20000 30000>; + }; diff --git a/Documentation/devicetree/bindings/regulator/qpnp-labibb-regulator.txt b/Documentation/devicetree/bindings/regulator/qpnp-labibb-regulator.txt new file mode 100644 index 000000000000..c9cfc889faba --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qpnp-labibb-regulator.txt @@ -0,0 +1,408 @@ +QTI's LAB (LCD/AMOLED BOOST)/IBB (Inverting Buck-Boost) Regulator + +LAB can be used as a standalone positive boost power supply for general purpose +applications. IBB can be used as a standalone negative power supply for general +applications. Also, LAB and IBB can be used together to provide power supply for +display panels, LCD or AMOLED. + +Main node required properties: + +- compatible: Must be "qcom,qpnp-labibb-regulator" +- qcom,qpnp-labibb-mode: A string used to specify the working mode of LAB/IBB + regulators when bootloader does not turned on the + display panel. Could be "lcd" or "amoled". + "lcd" means using LAB and IBB regulators are + configured for LCD mode. + "amoled" means using LAB and IBB regulators are + configured for AMOLED mode. +- qcom,pmic-revid: Specifies the phandle of the PMIC revid module. + Used to identify the PMIC subtype. + +Main node optional properties: + +- qcom,qpnp-labibb-touch-to-wake-en: A boolean property which upon set will + enable support for touch-to-wake mode + by configuring the required settings + in LAB and IBB modules. Make sure the + hardware has needed support before + enabling this property. +- qcom,swire-control: A boolean property which indicates if the LAB/IBB is + controlled by the SWIRE interface. Enable only + if qcom,qpnp-labibb-mode = "amoled". +- qcom,labibb-ttw-force-lab-on: A boolean property which forces LAB to be + always on during TTW mode. +- qcom,skip-2nd-swire-cmd: A boolean property which indicates if + the second SWIRE command needs to be skipped. +- qcom,swire-2nd-cmd-delay: An integer value which specifes the + delay in millisecs between the first and second + SWIRE command. If not specified this value + defaults to 20ms. This delay is applied only + if 'qcom,skip-2nd-swire-cmd' is defined. +- qcom,swire-ibb-ps-enable-delay: An integer value which specifes the delay + in millisecs to enable IBB pulse-skipping + after the skip-2nd-swire-cmd workaround is applied. + If not specified this value default to 200ms. + This property is applicable only if + 'qcom,skip-2nd-swire-cmd' is specified. +- qcom,labibb-standalone: A boolean property which forces LAB and + IBB to operate in standalone mode. If + this is not specified, then LAB and IBB + are controlled together in dual mode. +- parent-supply: Parent supply that is needed for LAB + and IBB regulators. This will be mostly + needed when LAB and IBB are operating + in standalone mode to vote for MBG. + +Following properties are available only for PM660A: + +- qcom,pbs-control: A boolean property which indicates if + the LAB/IBB is controlled by the PBS + sequencer. If this mode is enabled the + PBS sequencer does the SWIRE remapping + and program the voltages based on the + SWIRE count. + +LAB subnode required properties: + +- reg: Specifies the SPMI address and size for this peripheral. +- reg-names: Register names. Must be "lab". +- regulator-name: A string used to describe the regulator. +- regulator-min-microvolt: Minimum voltage in microvolts supported by this regulator. +- regulator-max-microvolt: Maximum voltage in microvolts supported by this regulator. + +- qcom,qpnp-lab-min-voltage: The minimum voltage in microvolts LAB regulator can support. +- qcom,qpnp-lab-step-size: The step size in microvolts of LAB regulator. +- qcom,qpnp-lab-slew-rate: The time in us taken by the regulator to change + voltage value in one step. + +- qcom,qpnp-lab-init-voltage: The default initial voltage when the bootloader + does not turn on LAB regulator. +- qcom,qpnp-lab-init-amoled-voltage: The default output voltage when LAB regulator + is configured in amoled mode. +- qcom,qpnp-lab-init-lcd-voltage: The default output voltage when LAB regulator + is configured in lcd mode. +- qcom,qpnp-lab-ps-threshold: The threshold in mA of Pulse Skip Mode for + LAB regulator. Supported values are 20, 30, + 40 and 50. +- interrupts: Specify the interrupts as per the interrupt + encoding. + Currently "lab-vreg-ok" is required for + LCD mode in pmi8998. For AMOLED mode, + "lab-vreg-ok" is required only when SWIRE + control is enabled and skipping 2nd SWIRE + pulse is required in pmi8952/8996. +- interrupt-names: Interrupt names to match up 1-to-1 with + the interrupts specified in 'interrupts' + property. + +LAB subnode optional properties: + +- qcom,qpnp-lab-current-sense: If this property is specified, the LAB current + sense gain will be programmed for LAB regulator. + Otherwise, LAB current sense gain will be + default to "1x". A string is used to specify the + LAB current sense gain. Could be "0.5x" or "1x" + or "1.5x" or "2x". For e.g. "0.5x" means current + sense gain is 0.5. +- qcom,qpnp-lab-ps-enable: A boolean proerty which upon set will enable + pulse skip mode for LAB regulator. Otherwise, + it is disabled. +- qcom,qpnp-lab-full-pull-down: A boolean property which upon set will enable + the pull down strength of LAB regulator to + full. Otherwise, the pull down strength is + configured to half. +- qcom,qpnp-lab-pull-down-enable: A boolean property which upon set will enable + the pull down for LAB regulator. Otherwise, + it is disabled. +- qcom,qpnp-lab-max-precharge-enable: A boolean property which upon set will + enable fast precharge. Otherwise, it is + disabled. +- qcom,qpnp-lab-ring-suppression-enable: A boolean property which upon set will + enable ring suppression for LAB + regulator. Otherwise, it is disabled. +- qcom,qpnp-lab-limit-max-current-enable: A boolean property which upon set will + enforce maximum inductor current constraint + for LAB regulator. Otherwise, there is no + maximum current constraint. +- qcom,qpnp-lab-switching-clock-frequency: The PWM switching clock frequency in + kHz of Lab regulator, Supported values + are: 3200, 2740, 2400, 2130, 1920, + 1750, 1600, 1480, 1370, 1280, 1200, + 1130, 1070, 1010, 960, 910. +- qcom,qpnp-lab-limit-maximum-current: The maximum inductor current limit in + mA of LAB regulator. Supported values + are 200, 400, 600, 800, 1000, 1200, + 1400 and 1600. +- qcom,qpnp-lab-pfet-size: PFET size in percentage. Supported values + are 25, 50, 75 and 100. +- qcom,qpnp-lab-nfet-size: NFET size in percentage. Supported values + are 25, 50, 75 and 100. +- qcom,qpnp-lab-max-precharge-time: Precharge time in uS for LAB regulator. + Supported values are 200, 300, 400 and 500. + Suggested values for LCD and AMOLED mode + are 500 and 300uS respectively. +- qcom,qpnp-lab-use-default-voltage: A boolean property which upon set will + use the value specified in + qcom,qpnp-lab-init-voltage property. + This will be used only if the bootloader + doesn't configure the output voltage + already. If it it not specified, then + output voltage can be configured to + any value in the allowed limit. +- qcom,notify-lab-vreg-ok-sts: A boolean property which upon set will + poll and notify the lab_vreg_ok status. + +Following properties are available only for PM660A: + +- qcom,qpnp-lab-soft-start: The soft start time in us of LAB regulator. + Supported value are 200, 400, 600 and 800. +- qcom,qpnp-lab-ldo-pulldown-enable: This property is used to enable/disable + the LDO pull down. + 1 - enable pulldown + 0 - disable pulldown +- qcom,qpnp-lab-enable-sw-high-psrr: A boolean property to enable the + software high psrr + (Power Suppy Rejection Rate) mode. +- qcom,qpnp-lab-high-psrr-src-select: This property is used to select the LAB + HW high psrr source. + The supported values are: + 0 = Either vph_high or high_psrr enable + 1 = vph_high only + 2 = high_psrr enable only + 3 = Either vph_high or high_psrr enable + This property is not valid if the + qcom,qpnp-lab-enable-sw-high-psrr property + is specified. +- qcom,qpnp-lab-vref-high-psrr-select: This property is required if the + qcom,qpnp-lab-high-psrr-src-select is + specified. The supported values (in mV) + are 350, 400, 450 and 500. Once the + rejection rate crosses the selected + high-psrr voltage the LDO is enabled + based on the value specified under + qcom,qpnp-lab-high-psrr-src-select + property. + This property is not valid if the + qcom,qpnp-lab-enable-sw-high-psrr property + is specified. + +IBB subnode required properties: + +- reg: Specifies the SPMI address and size for this peripheral. +- reg-names: Register names. Must be "ibb". +- regulator-name: A string used to describe the regulator. +- regulator-min-microvolt: Minimum voltage in microvolts supported by this regulator. +- regulator-max-microvolt: Maximum voltage in microvolts supported by this regulator. + +- qcom,qpnp-ibb-min-voltage: The minimum voltage in microvolts IBB regulator can support. +- qcom,qpnp-ibb-step-size: The step size in microvolts of IBB regulator. +- qcom,qpnp-ibb-soft-start: The soft start time in us of IBB regulator. + +- qcom,qpnp-ibb-init-voltage: The default initial voltage when the bootloader does + not turn on IBB regulator. +- qcom,qpnp-ibb-init-amoled-voltage: The default output voltage when IBB regulator + is configured in amoled mode. +- qcom,qpnp-ibb-init-lcd-voltage: The default output voltage when IBB regulator + is configured in lcd mode. + +IBB subnode optional properties: + +- qcom,qpnp-ibb-discharge-resistor: The discharge resistor in Kilo Ohms which + controls the soft start time. Supported values + are 300, 64, 32 and 16. + +- qcom,qpnp-ibb-slew-rate: The time (in us) taken by the regulator to change + voltage value in one step. This property is not + applicable to PM660A. + The following properties can be used as an + alternate. + qcom,qpnp-ibb-slew-rate-config + qcom,qpnp-ibb-fast-slew-rate + qcom,qpnp-ibb-slow-slew-rate +- qcom,qpnp-ibb-ps-enable: A boolean property which upon set will enable + pulse skip mode for IBB regulator. Otherwise, + it is disabled. +- qcom,qpnp-ibb-num-swire-trans: The number of SWIRE transactions + after which the pulse skipping is + enabled. This property is required when + qpnp-ibb-smart-ps-enable property is + set. +- qcom,qpnp-ibb-neg-curr-limit: This property must be set when the + qpnp-ibb-smart-ps-enable is specified. + The supported values in mA are 1, 2, 3, + 4, 5, 6 and 7. The recommended value is +- qcom,qpnp-ibb-full-pull-down: A boolean property which upon set will + enable the pull down strength of IBB + regulator to full. Otherwise, the pull + down strength is configured to half. +- qcom,qpnp-ibb-pull-down-enable: A boolean property which upon set will enable + the pull down for IBB regulator. Otherwise, + it is disabled. +- qcom,qpnp-ibb-lab-pwrup-delay: Power up delay (in us) for IBB regulator when + it is enabled or turned on. Supported values + are 1000, 2000, 4000 and 8000. +- qcom,qpnp-ibb-lab-pwrdn-delay: Power down delay (in us) for IBB regulator + when it is disabled or turned off. Supported + values are 1000, 2000, 4000 and 8000. +- qcom,qpnp-ibb-switching-clock-frequency: The PWM switching clock frequency in + kHz of IBB regulator. Supported values + are: 3200, 2740, 2400, 2130, 1920, + 1750, 1600, 1480, 1370, 1280, 1200, + 1130, 1070, 1010, 960, 910. +- qcom,qpnp-ibb-limit-maximum-current: The maximum inductor current limit in + mA of IBB regulator. Supported values + are: 0, 50, 100, 150, 200, 250, 300, + 350, 400, 450, 500, 550, 600, 650, 700, + 750, 800, 850, 900, 950, 1000, 1050, + 1100, 1150, 1200, 1250, 1300, 1350, + 1400, 1450, 1500 and 1550. +- qcom,qpnp-ibb-debounce-cycle: The debounce cycle of IBB regulator. + Supported values are 8, 16, 32 and 64. +- qcom,qpnp-ibb-en-discharge: A boolean property which upon set will + enable discharge for IBB regulator. + Otherwise, it is kept disabled. +- qcom,qpnp-ibb-ring-suppression-enable: A boolean property which upon set will + enable ring suppression for IBB + regulator. Otherwise, it is disabled. +- qcom,qpnp-ibb-limit-max-current-enable: A boolean property which upon set will + enforce maximum inductor current constraint + for IBB regulator. Otherwise, there is no + maximum current constraint. +- qcom,qpnp-ibb-use-default-voltage: A boolean property which upon set will + use the value specified in + qcom,qpnp-ibb-init-voltage property. + This will be used only if the bootloader + doesn't configure the output voltage + already. If it it not specified, then + output voltage can be configured to + any value in the allowed limit. +- qcom,output-voltage-one-pulse: The expected voltage (in mV) of VDISN signal + on the first SWIRE pulse. This property + can be specified only if 'qcom,swire-control' + is defined. The minimum and maximum values + are 1400mV and 7700mV. + +Following properties are available only for PM660A: + +- qcom,qpnp-ibb-smart-ps-enable: A boolean property which upon set + enables smart pulse skip mode for IBB + regulator. Otherwise, it is disabled. + This property is only applicable to + PM660A. +- qcom,qpnp-ibb-enable-pfm-mode: A boolean property which enables the IBB to work + in pfm mode. +- qcom,qpnp-ibb-pfm-peak-curr: The PFM peak current limit settings in mA. + Supported values are 150, 200, 250, 300, + 350, 400, 450 and 500. This property is + required if the qcom,qpnp-ibb-enable-pfm-mode + is true. +- qcom,qpnp-ibb-pfm-hysteresis: The PFM hysteresis voltage threshold in mV. + Supported values are 0, 25 and 50. + This property is required if the + qcom,qpnp-ibb-enable-pfm-mode is specified. +- qcom,qpnp-ibb-overload-blank: A boolean property which upon set enables + the IBB overload blanking. +- qcom,qpnp-ibb-overload-debounce: The expected overload debounce time (in ms) + values are 1, 2, 4 and 8. + This property is required only when the + qcom,qpnp-ibb-overload-blank is set. +- qcom,qpnp-ibb-vreg-ok-debounce: The expected vreg-ok-debounce time (us) + values are 4, 8, 16 and 32. + This property is required only when the + qcom,qpnp-ibb-overload-blank is set. +- qcom,qpnp-ibb-slew-rate-config: A boolean property to configure the + ibb fast/slow slew rate. + Either qcom,qpnp-ibb-fast-slew-rate or + qcom,qpnp-ibb-slow-slew-rate has to be + specified. Otherwise the + qcom,qpnp-ibb-slow-slew-rate takes precedence + over the qcom,qpnp-ibb-fast-slew-rate. +- qcom,qpnp-ibb-fast-slew-rate: This property is required if the qcom, + qpnp-ibb-slew-rate-config property is + specified. Supported values (in us) are + 100, 200, 500, 1000, 2000, 10000, 12000 + and 15000. +- qcom,qpnp-ibb-slow-slew-rate: This property is required if the qcom, + qpnp-ibb-slew-rate-config property is + specified. Supported values (in us) are + 100, 200, 500, 1000, 2000, 10000, 12000 + and 15000. + +Example: + qcom,pmi8994@3 { + qpnp-labibb-regulator { + compatible = "qcom,qpnp-labibb-regulator"; + #address-cells = <1>; + #size-cells = <1>; + qcom,qpnp-labibb-mode = "lcd"; + qcom,pmic-revid = <&pmi8994_revid>; + qcom,skip-2nd-swire-cmd; + + lab_regulator: qcom,lab@de00 { + reg = <0xde00 0x100>; + reg-names = "lab"; + + interrupts = <0x3 0xde 0x0 + IRQ_TYPE_EDGE_RISING>; + interrupt-names = "lab-vreg-ok"; + + regulator-name = "lab_reg"; + regulator-min-microvolt = <4600000>; + regulator-max-microvolt = <6000000>; + + qcom,qpnp-lab-min-voltage = <4600000>; + qcom,qpnp-lab-step-size = <100000>; + qcom,qpnp-lab-slew-rate = <5000>; + qcom,qpnp-lab-use-default-voltage; + qcom,qpnp-lab-init-voltage = <5500000>; + qcom,qpnp-lab-init-amoled-voltage = <4600000>; + qcom,qpnp-lab-init-lcd-voltage = <5500000>; + + qcom,qpnp-lab-soft-start = <400>; + + qcom,qpnp-lab-full-pull-down; + qcom,qpnp-lab-pull-down-enable; + qcom,qpnp-lab-switching-clock-frequency = <1600>; + qcom,qpnp-lab-limit-maximum-current = <1600>; + qcom,qpnp-lab-limit-max-current-enable; + qcom,qpnp-lab-ps-threshold = <40>; + qcom,qpnp-lab-ps-enable; + qcom,qpnp-lab-nfet-size = <100>; + qcom,qpnp-lab-pfet-size = <100>; + qcom,qpnp-lab-max-precharge-time = <200>; + }; + + ibb_regulator: qcom,ibb@dc00 { + reg = <0xdc00 0x100>; + reg-names = "ibb_reg"; + regulator-name = "ibb_reg"; + + regulator-min-microvolt = <4600000>; + regulator-max-microvolt = <6000000>; + + qcom,qpnp-ibb-min-voltage = <1400000>; + qcom,qpnp-ibb-step-size = <100000>; + qcom,qpnp-ibb-slew-rate = <2000000>; + qcom,qpnp-ibb-use-default-voltage; + qcom,qpnp-ibb-init-voltage = <5500000>; + qcom,qpnp-ibb-init-amoled-voltage = <4000000>; + qcom,qpnp-ibb-init-lcd-voltage = <5500000>; + + qcom,qpnp-ibb-soft-start = <400>; + + qcom,qpnp-ibb-discharge-resistor = <300>; + qcom,qpnp-ibb-lab-pwrup-delay = <8000>; + qcom,qpnp-ibb-lab-pwrdn-delay = <8000>; + qcom,qpnp-ibb-en-discharge; + + qcom,qpnp-ibb-full-pull-down; + qcom,qpnp-ibb-pull-down-enable; + qcom,qpnp-ibb-switching-clock-frequency = <1480>; + qcom,qpnp-ibb-limit-maximum-current = <1550>; + qcom,qpnp-ibb-debounce-cycle = <16>; + qcom,qpnp-ibb-limit-max-current-enable; + qcom,qpnp-ibb-ps-enable; + }; + + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/qpnp-lcdb-regulator.txt b/Documentation/devicetree/bindings/regulator/qpnp-lcdb-regulator.txt new file mode 100644 index 000000000000..63da8ecbfa4c --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qpnp-lcdb-regulator.txt @@ -0,0 +1,256 @@ +QPNP LCDB (LCD Bias) Regulator + +QPNP LCDB module provides voltage bias to the LCD display panel. The biases +are positive (VDISP - supported by LDO) and negative (VDISN - supported by +NCP) voltage signals. The module also supports TTW (touch-to-wake) capability. + +This document describes the bindings for QPNP LCDB module. + +======================= +Required Node Structure +======================= + +LCDB module must be described in two level of device nodes. + +============================== +First Level Node - LCDB module +============================== + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,qpnp-lcdb-regulator" + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Base address of the LCDB SPMI peripheral. + +- qcom,force-module-reenable + Usage: required if using SW mode for module enable + Value type: <bool> + Definition: This enables the workaround to force enable + the vph_pwr_2p5_ok signal required for + turning on the LCDB module. + +Touch-to-wake (TTW) properties: + +TTW supports 2 modes of operation - HW and SW. In the HW mode the enable/disable +logic is controlled by an external signal (pin) where as in the SW mode it is +is controlled by a pre-configured timer (ton/toff) programmed in the TTW +register. + +Properties below are specific to TTW mode only. They are sepecified in the +main node. + +- qcom,ttw-enable + Usage: optional + Value type: <bool> + Definition: Touch to wake-up support enabled. + +- qcom,ttw-mode-sw + Usage: optional + Value type: <bool> + Definition: Touch to wake supported in SW mode. + If not defined, ttw is enabled by HW pin. + +- qcom,attw-toff-ms + Usage: required if 'qcom,ttw-mode-sw' is true. + Value type: <bool> + Definition: Off time (in mS) for the VDISP/VDISN signals. + Possible values are 4, 8, 16, 32. + +- qcom,attw-ton-ms + Usage: required if 'qcom,ttw-mode-sw' is true. + Value type: <bool> + Definition: ON time (in mS) for the VDISP/VDISN signals. + Possible values are 4, 8, 16, 32. + +======================================== +Second Level Nodes - LDO/NCP/BOOST block +======================================== + +LDO / NCP subnode common properties: + +Properties below are common to the LDO and NCP bias. + +- label + Usage: required + Value type: <string> + Definition: A string used to describe the bias type. + Possible values are ldo, ncp, bst. + +- regulator-name + Usage: required + Value type: <string> + Definition: A string used to describe the regulator. + +- regulator-min-microvolt + Usage: required + Value type: <u32> + Definition: Minimum voltage (in uV) supported by the bias. + +- regulator-max-microvolt + Usage: required + Value type: <u32> + Definition: Maximum voltage (in uV) supported by the bias. + + +LDO subnode properties: + +Properties below are specific to LDO bias only. + +- qcom,ldo-voltage-mv + Usage: optional + Value type: <u32> + Definition: Voltage (in mV) progammed for the LDO (VDISP). + Possile values are 4000mV to 6000mV. The range + 4000mV to 4900mV is in 100mV steps and 4900mV to + 6000mV is in 50mV steps. + +- qcom,ldo-pd + Usage: optional + Value type: <u32> + Definition: Pull-down configuration of LDO. Possible values are: + 1 - Enable pull-down + 0 - Disable pull-down + +- qcom,ldo-pd-strength + Usage: optional + Value type: <u32> + Definition: Pull-down strength. Possible values are: + 0 - Weak pull-down + 1 - Strong pull-down + +- qcom,ldo-ilim-ma + Usage: optional + Value type: <u32> + Definition: Current limit (in mA) of the LDO bias. + Possible values are 110, 160, 210, 260, 310, 360, 410, 460. + +- qcom,ldo-soft-start-us + Usage: optional + Value type: <u32> + Definition: Soft-start time (in uS) of the LDO bias. + Possible values are 0, 500, 1000, 2000. + + +NCP subnode properties: + +Properties below are specific to NCP bias only. + +- qcom,ncp-voltage-mv + Usage: optional + Value type: <u32> + Definition: Voltage (in mV) progammed for the NCP (VDISN). + Possile values are 4000mV to 6000mV. The range + 4000mV to 4900mV is in 100mV steps and 4900mV to + 6000mV is in 50mV steps. + +- qcom,ncp-pd + Usage: optional + Value type: <u32> + Definition: Pull-down configuration of NCP. Possible values are: + 1 - Enable pull-down + 0 - Disable pull-down + +- qcom,ncp-pd-strength + Usage: optional + Value type: <u32> + Definition: Pull-down strength. Possible values are: + 0 - Weak pull-down + 1 - Strong pull-down + +- qcom,ncp-ilim-ma + Usage: optional + Value type: <u32> + Definition: Current limit (in mA) of the NCP bias. + Possible values are 260, 460, 640, 810. + +- qcom,ncp-soft-start-us + Usage: optional + Value type: <u32> + Definition: Soft-start time (in uS) of the NCP bias. + Possible values are 0, 500, 1000, 2000. + + +BOOST subnode properties: + +Properties below are specific to BOOST subnode only. + +- qcom,bst-pd + Usage: optional + Value type: <bool> + Definition: Pull-down configuration of BOOST. Possible values are: + 1 - Enable pull-down + 0 - Disable pull-down + +- qcom,bst-pd-strength + Usage: optional + Value type: <u32> + Definition: Pull-down strength. Possible values are: + 0 - Weak pull-down + 1 - Strong pull-down + +- qcom,bst-ps + Usage: optional + Value type: <u32> + Definition: Pulse-skip configuration for boost. Possible values are: + 1 - Enable Pulse-skip + 0 - Disable Pulse-skip + +- qcom,bst-ps-threshold-ma + Usage: optional + Value type: <u32> + Definition: Current threshold (in mA) at which pulse-skip is entered. + Possible values are 50, 60, 70, 80. + +- qcom,bst-ilim-ma + Usage: optional + Value type: <u32> + Definition: Current limit (in mA) of the BOOST rail. + Possible values are 200 to 1600mA in 200mA steps. + +======= +Example +======= + +pm660l_lcdb: qpnp-lcdb@ec00 { + compatible = "qcom,qpnp-lcdb-regulator"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xec00 0x100>; + + qcom,ttw-enable; + + lcdb_ldo_vreg: ldo { + label = "ldo"; + regulator-name = "lcdb_ldo"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6000000>; + + qcom,ldo-voltage-mv = <5400>; + qcom,ldo-pd = <1>; + qcom,ldo-pd-strength = <1>; + }; + + lcdb_ncp_vreg: ncp { + label = "ncp"; + regulator-name = "lcdb_ncp"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6000000>; + + qcom,ncp-voltage-mv = <5400>; + qcom,ncp-pd = <1>; + qcom,ncp-pd-strength = <1>; + }; + + lcdb_bst: bst { + label = "bst"; + + qcom,bst-pd = <1>; + qcom,bst-pd-strength = <1>; + qcom,bst-ps = <1>; + qcom,bst-ps-threshold-ma = <50>; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/qpnp-oledb-regulator.txt b/Documentation/devicetree/bindings/regulator/qpnp-oledb-regulator.txt new file mode 100644 index 000000000000..38f599ba5321 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qpnp-oledb-regulator.txt @@ -0,0 +1,244 @@ +QPNP OLEDB (AMOLED AVDD Bias) Regulator + +QPNP OLEDB module provides AVDD voltage bias to the AMOLED display panel. +The supported voltage range is 5V to 8.1V. + +This document describes the bindings for QPNP OLEDB module. + +======================= +Required Node Structure +======================= + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,qpnp-oledb-regulator". + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Base address of the OLEDB SPMI peripheral. + +- label + Usage: required + Value type: <string> + Definition: A string used to describe the bias type(oledb). + +- regulator-name + Usage: required + Value type: <string> + Definition: A string used to describe the regulator. + +- regulator-min-microvolt + Usage: required + Value type: <u32> + Definition: Minimum voltage (in uV) supported by the bias (5000000uV). + +- regulator-max-microvolt + Usage: required + Value type: <u32> + Definition: Maximum voltage (in uV) supported by the bias (8100000uV). + +- qcom,swire-control + Usage: optional + Value type: <bool> + Definition: Enables the voltage programming through SWIRE signal. + +- qcom,ext-pin-control + Usage: optional + Value type: <bool> + Definition: Configures the OLED module to be enabled by a external pin. + +- qcom,dynamic-ext-pinctl-config + Usage: optional + Value type: <bool> + Definition: Used to dynamically enable/disable the OLEDB module + using external pin to avoid the glitches on the voltage + rail. This property is applicable only if qcom,ext-pin-ctl + property is specified and it is specific to PM660A. + +- qcom,force-pd-control + Usage: optional + Value type: <bool> + Definition: Used to enable the pull down control forcibly via SPMI by + disabling the pull down configuration done by hardware + automatically through SWIRE pulses. + +- qcom,pbs-client + Usage: optional + Value type: <phandle> + Definition: Used to send the PBS trigger to the specified PBS client. + This property is applicable only if qcom,force-pd-control + property is specified. + +- qcom,pbs-control + Usage: optional + Value type: <bool> + Definition: PMIC PBS logic directly configures the output voltage update + and pull down control. + +- qcom,oledb-init-voltage-mv + Usage: optional + Value type: <u32> + Definition: Sets the AVDD bias voltage (in mV) when the module is + already enabled. Applicable only if the qcom,swire-control + property is not specified. Supported values are from 5.0V + to 8.1V with a step of 100mV. + +- qcom,oledb-default-voltage-mv + Usage: optional + Value type: <u32> + Definition: Sets the default AVDD bias voltage (in mV) before module + enable. Supported values are from 5.0V to 8.1V with the + step of 100mV. + +- qcom,bias-gen-warmup-delay-ns + Usage: optional + Value type: <u32> + Definition: Bias generator warm-up time (ns). Supported values are + 6700, 13300, 267000, 534000. + +- qcom,peak-curr-limit-ma + Usage: optional + Value type: <u32> + Definition: Peak current limit (in mA). Supported values are 115, 265, + 415, 570, 720, 870, 1020, 1170. + +- qcom,pull-down-enable + Usage: optional + Value type: <u32> + Definition: Pull down configuration of OLEDB. + 1 - Enable pull-down + 0 - Disable pull-down + +- qcom,negative-curr-limit-enable + Usage: optional + Value type: <u32> + Definition: negative current limit enable/disable. + 1 = enable negative current limit + 0 = disable negative current limit + +- qcom,negative-curr-limit-ma + Usage: optional + Value type: <u32> + Definition: Negative current limit (in mA). Supported values are + 170, 300, 420, 550. + +- qcom,enable-short-circuit + Usage: optional + Value type: <u32> + Definition: Short circuit protection enable/disable. + 1 = enable short circuit protection + 0 = disable short circuit protection + +- qcom,short-circuit-dbnc-time + usage: optional + Value type: <u32> + Definitioan: Short circuit debounce time (in Fsw). Supported + values are 2, 4, 8, 16. + +Fast precharge properties: +------------------------- + +- qcom,fast-precharge-ppulse-enable + usage: optional + Value type: <u32> + Definitioan: Fast precharge pfet pulsing enable/disable. + 1 = enable fast precharge pfet pulsing + 0 = disable fast precharge pfet pulsing + +- qcom,precharge-debounce-time-ms + usage: optional + Value type: <u32> + Definitioan: Fast precharge debounce time (in ms). Supported + values are 1, 2, 4, 8. + +- qcom,precharge-pulse-period-us + usage: optional + Value type: <u32> + Definitioan: Fast precharge pulse period (in us). Supported + values are 3, 6, 9, 12. + +- qcom,precharge-pulse-on-time-us + usage: optional + Value type: <u32> + Definitioan: Fast precharge pulse on time (in ns). Supported + values are 1200, 1800, 2400, 3000. + +Pulse Skip Modulation (PSM) properties: +-------------------------------------- + +- qcom,psm-enable + Usage: optional + Value type: <u32> + Definition: Pulse Skip Modulation mode. + 1 - Enable PSM mode + 0 - Disable PSM mode + +- qcom,psm-hys-mv + Usage: optional + Value type: <u32> + Definition: PSM hysterysis voltage (in mV). + Supported values are 13mV and 26mV. + +- qcom,psm-vref-mv + Usage: optional + Value type: <u32> + Definition: Reference voltage(in mV) control for PSM comparator. + Supported values are 440, 510, 580, 650, 715, 780, 850, + and 920. + +Pulse Frequency Modulation (PFM) properties: +------------------------------------------- + +- qcom,pfm-enable + Usage: optional + Value type: <u32> + Definition: Pulse Frequency Modulation mode. + 1 - Enable PFM mode + 0 - Disable PFM mode + +- qcom,pfm-hys-mv + Usage: optional + Value type: <u32> + Definition: PFM hysterysis voltage (in mV). + Supported values are 13mV and 26mV. + +- qcom,pfm-curr-limit-ma + Usage: optional + Value type: <u32> + Definition: PFM current limit (in mA). + Supported values are 130, 200, 270, 340. + +- qcom,pfm-off-time-ns + Usage: optional + Value type: <u32> + Definition: NFET off time at PFM (in ns). + Supported values are 110, 240, 350, 480. + +======= +Example +======= + +pm660a_oledb: qpnp-oledb@e000 { + compatible = "qcom,qpnp-oledb-regulator"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xe000 0x100>; + + label = "oledb"; + regulator-name = "regulator-oledb"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <8100000>; + + qcom,swire-control; + qcom,ext-pin-control; + + qcom,oledb-default-voltage-mv = <5000>; + qcom,bias-gen-warmup-delay-ns = <6700>; + qcom,pull-down-enable = <1>; + qcom,peak-curr-limit-ma = <570>; + + qcom, enable-psm = <1>; + qcom,psm-hys-mv = <13>; +}; diff --git a/Documentation/devicetree/bindings/regulator/qpnp-regulator.txt b/Documentation/devicetree/bindings/regulator/qpnp-regulator.txt new file mode 100644 index 000000000000..601903bc60de --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/qpnp-regulator.txt @@ -0,0 +1,151 @@ +Qualcomm Technologies, Inc. QPNP Regulators + +qpnp-regulator is a regulator driver which supports regulators inside of PMICs +that utilize the MSM SPMI implementation. + +Required properties: +- compatible: Must be "qcom,qpnp-regulator" +- reg: Specifies the SPMI address and size for this regulator device + Note, this is the only property which can be used within a + subnode. +- regulator-name: A string used as a descriptive name for regulator outputs +- parent-supply: phandle to the parent supply/regulator node + +Required structure: +- A qcom,qpnp-regulator node must be a child of an spmi_device node. + +Optional properties: +- interrupts: List of interrupts used by the regulator. +- interrupt-names: List of strings defining the names of the + interrupts in the 'interrupts' property 1-to-1. + Supported values are "ocp" for voltage switch + type regulators. If an OCP interrupt is + specified, then the voltage switch will be + toggled off and back on when OCP triggers in + order to handle high in-rush current. +- qcom,system-load: Load in uA present on regulator that is not + captured by any consumer request +- qcom,enable-time: Time in us to delay after enabling the regulator +- qcom,auto-mode-enable: 1 = Enable automatic hardware selection of + regulator mode (HPM vs LPM); not available on + boost type regulators + 0 = Disable auto mode selection +- qcom,bypass-mode-enable: 1 = Enable bypass mode for an LDO type regulator + so that it acts like a switch and simply outputs + its input voltage + 0 = Do not enable bypass mode +- qcom,ocp-enable: 1 = Allow over current protection (OCP) to be + enabled for voltage switch type regulators so + that they latch off automatically when over + current is detected. OCP is enabled when in + HPM or auto mode. + 0 = Disable OCP +- qcom,ocp-max-retries: Maximum number of times to try toggling a voltage + switch off and back on as a result of + consecutive over current events. +- qcom,ocp-retry-delay: Time to delay in milliseconds between each + voltage switch toggle after an over current + event takes place. +- qcom,pull-down-enable: 1 = Enable output pull down resistor when the + regulator is disabled + 0 = Disable pull down resistor +- qcom,soft-start-enable: 1 = Enable soft start for LDO and voltage switch + type regulators so that output voltage slowly + ramps up when the regulator is enabled + 0 = Disable soft start +- qcom,boost-current-limit: This property sets the current limit of boost + type regulators; supported values are: + 0 = 300 mA + 1 = 600 mA + 2 = 900 mA + 3 = 1200 mA + 4 = 1500 mA + 5 = 1800 mA + 6 = 2100 mA + 7 = 2400 mA +- qcom,pin-ctrl-enable: Bit mask specifying which hardware pins should be + used to enable the regulator, if any; supported + bits are: + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal +- qcom,pin-ctrl-hpm: Bit mask specifying which hardware pins should be + used to force the regulator into high power + mode, if any; supported bits are: + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal + BIT(4) = follow PMIC awake state +- qcom,vs-soft-start-strength: This property sets the soft start strength for + voltage switch type regulators; supported values + are: + 0 = 0.05 uA + 1 = 0.25 uA + 2 = 0.55 uA + 3 = 0.75 uA +- qcom,hpm-enable: 1 = Enable high power mode (HPM), also referred + to as NPM. HPM consumes more ground current + than LPM, but it can source significantly higher + load current. HPM is not available on boost + type regulators. For voltage switch type + regulators, HPM implies that over current + protection and soft start are active all the + time. This configuration can be overwritten + by changing the regulator's mode dynamically. + 0 = Do not enable HPM +- qcom,force-type: Override the type and subtype register values. Useful for some + regulators that have invalid types advertised by the hardware. + The format is two unsigned integers of the form <type subtype>. + +Note, if a given optional qcom,* binding is not present, then the qpnp-regulator +driver will leave that feature in the default hardware state. + +All properties specified within the core regulator framework can also be used. +These bindings can be found in regulator.txt. + +Example: + qcom,spmi@fc4c0000 { + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <3>; + + qcom,pm8941@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <1>; + + regulator@1400 { + regulator-name = "8941_s1"; + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qpnp-regulator"; + reg = <0x1400 0x300>; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1400000>; + + qcom,ctl@1400 { + reg = <0x1400 0x100>; + }; + qcom,ps@1500 { + reg = <0x1500 0x100>; + }; + qcom,freq@1600 { + reg = <0x1600 0x100>; + }; + }; + + regulator@4000 { + regulator-name = "8941_l1"; + reg = <0x4000 0x100>; + compatible = "qcom,qpnp-regulator"; + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1300000>; + qcom,pull-down-enable = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/rpm-smd-regulator.txt b/Documentation/devicetree/bindings/regulator/rpm-smd-regulator.txt new file mode 100644 index 000000000000..1eb27f4c1c56 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/rpm-smd-regulator.txt @@ -0,0 +1,324 @@ +Qualcomm RPM Regulators + +rpm-regulator-smd is a regulator driver which supports regulators inside of +PMICs which are controlled by the RPM processor. Communication with the RPM +processor takes place over SMD. + +Required structure: +- RPM regulators must be described in two levels of devices nodes. The first + level describes the interface with the RPM. The second level describes + properties of one regulator framework interface (of potentially many) to + the regulator. + +[First Level Nodes] + +Required properties: +- compatible: Must be "qcom,rpm-smd-regulator-resource" +- qcom,resource-name: Resource name string for this regulator to be used in RPM + transactions. Length is 4 characters max. +- qcom,resource-id: Resource instance ID for this regulator to be used in RPM + transactions. +- qcom,regulator-type: Type of this regulator. Supported values are: + 0 = LDO + 1 = SMPS + 2 = VS + 3 = NCP + 4 = Buck or Boost (BoB) + +Optional properties: +- qcom,allow-atomic: Flag specifying if atomic access is allowed for this + regulator. Supported values are: + 0 or not present = mutex locks used + 1 = spinlocks used +- qcom,enable-time: Time in us to delay after enabling the regulator +- qcom,apps-only: Flag which indicates that the regulator only has + consumers on the application processor. If this flag + is specified, then voltage and current updates are + only sent to the RPM if the regulator is enabled. +- qcom,always-wait-for-ack: Flag which indicates that the application + processor must wait for an ACK or a NACK from the RPM + for every request sent for this regulator including + those which are for a strictly lower power state. + +[Second Level Nodes] + +Required properties: +- compatible: Must be "qcom,rpm-smd-regulator" +- regulator-name: A string used as a descriptive name for regulator outputs +- qcom,set: Specifies which sets that requests made with this + regulator interface should be sent to. Regulator + requests sent in the active set take effect immediately. + Requests sent in the sleep set take effect when the Apps + processor transitions into RPM assisted power collapse. + Supported values are: + 1 = Active set only + 2 = Sleep set only + 3 = Both active and sleep sets + + + +Optional properties: +- parent-supply: phandle to the parent supply/regulator node +- qcom,system-load: Load in uA present on regulator that is not + captured by any consumer request +- qcom,use-voltage-corner: Flag that signifies if regulator_set_voltage + calls should modify the corner parameter instead + of the voltage parameter. When used, voltages + specified inside of the regulator framework + represent corners that have been incremented by + 1. This value shift is necessary to work around + limitations in the regulator framework which + treat 0 uV as an error. +- qcom,use-voltage-floor-corner: Flag that signifies if regulator_set_voltage + calls should modify the floor corner parameter + instead of the voltage parameter. When used, + voltages specified inside of the regulator + framework represent corners that have been + incremented by 1. The properties + qcom,use-voltage-corner and + qcom,use-voltage-floor-corner are mutually + exclusive. Only one may be specified for a + given regulator. +- qcom,use-voltage-level: Flag that signifies if regulator_set_voltage + calls should modify the level parameter instead + of the voltage parameter. +- qcom,use-voltage-floor-level: Flag that signifies if regulator_set_voltage + calls should modify the floor level parameter + instead of the voltage parameter. + The properties qcom,use-voltage-level and + qcom,use-voltage-floor-level are mutually + exclusive. Only one may be specified for a + given regulator. +- qcom,use-pin-ctrl-voltage1: Flag which indicates that updates to voltage + should be sent to the pin control voltage 1 + parameter. Only one pin may be specified per + regulator. This property only applies to BoB + type regulators. +- qcom,use-pin-ctrl-voltage2: Flag which indicates that updates to voltage + should be sent to the pin control voltage 2 + parameter. Only one pin may be specified per + regulator. This property only applies to BoB + type regulators. +- qcom,use-pin-ctrl-voltage3: Flag which indicates that updates to voltage + should be sent to the pin control voltage 3 + parameter. Only one pin may be specified per + regulator. This property only applies to BoB + type regulators. +- qcom,always-send-voltage: Flag which indicates that updates to the + voltage, voltage corner or voltage level set + point should always be sent immediately to the + RPM. If this flag is not specified, then + voltage set point updates are only sent if the + given regulator has also been enabled by a + Linux consumer. +- qcom,always-send-current: Flag which indicates that updates to the load + current should always be sent immediately to the + RPM. If this flag is not specified, then load + current updates are only sent if the given + regulator has also been enabled by a Linux + consumer. +- qcom,send-defaults: Boolean flag which indicates that the initial + parameter values should be sent to the RPM + before consumers make their own requests. If + this flag is not specified, then initial + parameters values will only be sent after some + consumer makes a request. +- qcom,enable-with-pin-ctrl: Double in which the first element corresponds to + the pin control enable parameter value to send + when all consumers have requested the regulator + to be disabled. The second element corresponds + to the pin control enable parameter value to + send when any consumer has requested the + regulator to be enabled. Each element supports + the same set of values as the + qcom,init-pin-ctrl-enable property listed below. + +The following properties specify initial values for parameters to be sent to the +RPM in regulator requests. +- qcom,init-enable: 0 = regulator disabled + 1 = regulator enabled +- qcom,init-voltage: Voltage in uV +- qcom,init-current: Current in mA +- qcom,init-ldo-mode: Operating mode to be used with LDO regulators + Supported values are: + 0 = mode determined by current requests + 1 = force HPM (NPM) +- qcom,init-smps-mode: Operating mode to be used with SMPS regulators + Supported values are: + 0 = auto; hardware determines mode + 1 = mode determined by current requests + 2 = force HPM (PWM) +- qcom,init-bob-mode: Operating mode to be used with BoB regulators + Supported values are: + 0 = pass; use priority order + 1 = force PFM + 2 = auto; hardware determines mode + 3 = force PWM +- qcom,init-pin-ctrl-enable: Bit mask specifying which hardware pins should be + used to enable the regulator, if any; supported + bits are: + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal +- qcom,init-pin-ctrl-mode: Bit mask specifying which hardware pins should be + used to force the regulator into high power + mode, if any. Supported bits are: + 0 = ignore all hardware enable signals + BIT(0) = follow HW0_EN signal + BIT(1) = follow HW1_EN signal + BIT(2) = follow HW2_EN signal + BIT(3) = follow HW3_EN signal + BIT(4) = follow PMIC awake state +- qcom,init-pin-ctrl-voltage1: Minimum voltage in micro-volts to use while pin + control 1 is enabled. This property only + applies to BoB type regulators. +- qcom,init-pin-ctrl-voltage2: Minimum voltage in micro-volts to use while pin + control 2 is enabled. This property only + applies to BoB type regulators. +- qcom,init-pin-ctrl-voltage3: Minimum voltage in micro-volts to use while pin + control 3 is enabled. This property only + applies to BoB type regulators. +- qcom,init-frequency: Switching frequency divisor for SMPS regulators. + Supported values are n = 0 to 31 where + freq = 19.2 MHz / (n + 1). +- qcom,init-head-room: Voltage head room in mV required for the + regulator. This head room value should be used + in situations where the device connected to the + output of the regulator has low noise tolerance. + Note that the RPM independently enforces a + safety head room value for subregulated LDOs + which is sufficient to account for LDO drop-out + voltage. +- qcom,init-quiet-mode: Specify that quiet mode is needed for an SMPS + regulator in order to have lower output noise. + Supported values are: + 0 = No quiet mode + 1 = Quiet mode + 2 = Super quiet mode +- qcom,init-freq-reason: Consumer requiring specified frequency for an + SMPS regulator. Supported values are: + 0 = None + 1 = Bluetooth + 2 = GPS + 4 = WLAN + 8 = WAN +- qcom,init-voltage-corner: Performance corner to use in order to determine + voltage set point. This value corresponds to + the actual value that will be sent and is not + incremented by 1 like the values used inside of + the regulator framework. The meaning of corner + values is set by the RPM. It is possible that + different regulators on a given platform or + similar regulators on different platforms will + utilize different corner values. These are + corner values supported on MSM8974 for PMIC + PM8841 SMPS 2 (VDD_Dig); nominal voltages for + these corners are also shown: + 0 = None (don't care) + 1 = Retention (0.5000 V) + 2 = SVS Krait (0.7250 V) + 3 = SVS SOC (0.8125 V) + 4 = Normal (0.9000 V) + 5 = Turbo (0.9875 V) + 6 = Super Turbo (1.0500 V) +- qcom,init-disallow-bypass: Specify that bypass mode should not be used for a + given LDO regulator. When in bypass mode, an + LDO performs no regulation and acts as a simple + switch. The RPM can utilize this mode for an + LDO that is subregulated from an SMPS when it is + possible to reduce the SMPS voltage to the + desired LDO output level. Bypass mode may be + disallowed if lower LDO output noise is + required. Supported values are: + 0 = Allow RPM to utilize LDO bypass mode + if possible + 1 = Disallow LDO bypass mode +- qcom,init-voltage-floor-corner: Minimum performance corner to use if any + processor in the system is awake. This property + supports the same values as + qcom,init-voltage-corner. +- qcom,init-voltage-level: Performance level to use in order to determine + voltage set point. The meaning of level + values is set by the RPM. It is possible that + different regulators on a given platform or + similar regulators on different platforms will + utilize different level values. These are + level values supported on MSM8952 for PMIC + PM8952 SMPS 2 (VDD_Dig); nominal voltages for + these level are also shown: + 16 = Retention (0.5000 V) + 128 = SVS (1.0500 V) + 192 = SVS+ (1.1550 V) + 256 = Normal (1.2250 V) + 320 = Normal+ (1.2875 V) + 384 = Turbo (1.3500 V) +- qcom,init-voltage-floor-level: Minimum performance level to use if any + processor in the system is awake. This property + supports the same values as + qcom,init-voltage-level. + +All properties specified within the core regulator framework can also be used in +second level nodes. These bindings can be found in: +Documentation/devicetree/bindings/regulator/regulator.txt. + +Examples: + +rpm-regulator-smpb1 { + qcom,resource-name = "smpb"; + qcom,resource-id = <1>; + qcom,regulator-type = <1>; + compatible = "qcom,rpm-smd-regulator-resource"; + status = "disabled"; + + pm8841_s1: regulator-s1 { + regulator-name = "8841_s1"; + qcom,set = <3>; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1150000>; + qcom,init-voltage = <1150000>; + compatible = "qcom,rpm-smd-regulator"; + }; + pm8841_s1_ao: regulator-s1-ao { + regulator-name = "8841_s1_ao"; + qcom,set = <1>; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1150000>; + compatible = "qcom,rpm-smd-regulator"; + }; + pm8841_s1_corner: regulator-s1-corner { + regulator-name = "8841_s1_corner"; + qcom,set = <3>; + regulator-min-microvolt = <1>; + regulator-max-microvolt = <6>; + qcom,init-voltage-corner = <3>; + qcom,use-voltage-corner; + compatible = "qcom,rpm-smd-regulator"; + }; +}; + +rpm-regulator-ldoa2 { + qcom,resource-name = "ldoa"; + qcom,resource-id = <2>; + qcom,regulator-type = <0>; + compatible = "qcom,rpm-smd-regulator-resource"; + + regulator-l2 { + compatible = "qcom,rpm-smd-regulator"; + regulator-name = "8941_l2"; + qcom,set = <3>; + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1225000>; + qcom,init-voltage = <1225000>; + }; + regulator-l2-pin-ctrl { + compatible = "qcom,rpm-smd-regulator"; + regulator-name = "8941_l2_pin_ctrl"; + qcom,set = <3>; + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1225000>; + qcom,init-voltage = <1225000>; + qcom,enable-with-pin-ctrl = <0 1>; + }; +}; diff --git a/Documentation/devicetree/bindings/regulator/stub-regulator.txt b/Documentation/devicetree/bindings/regulator/stub-regulator.txt new file mode 100644 index 000000000000..1057e175c998 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/stub-regulator.txt @@ -0,0 +1,48 @@ +Stub Voltage Regulators + +stub-regulators are place-holder regulator devices which do not impact any +hardware state. They provide a means for consumer devices to utilize all +regulator features for testing purposes. + +Required properties: +- compatible: Must be "qcom,stub-regulator". +- regulator-name: A string used as a descriptive name for regulator outputs. + +Optional properties: +- parent-supply: phandle to the parent supply/regulator node if one exists. +- qcom,hpm-min-load: Load current in uA which corresponds to the minimum load + which requires the regulator to be in high power mode. +- qcom,system-load: Load in uA present on regulator that is not captured by any + consumer request. + +All properties specified within the core regulator framework can also be used. +These bindings can be found in regulator.txt. + +Example: + +/ { + pm8026_s3: regulator-s3 { + compatible = "qcom,stub-regulator"; + regulator-name = "8026_s3"; + qcom,hpm-min-load = <100000>; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; + }; + + pm8026_l1: regulator-l1 { + compatible = "qcom,stub-regulator"; + regulator-name = "8026_l1"; + parent-supply = <&pm8026_s3>; + qcom,hpm-min-load = <10000>; + regulator-min-microvolt = <1225000>; + regulator-max-microvolt = <1225000>; + }; + + pm8026_l20: regulator-l20 { + compatible = "qcom,stub-regulator"; + regulator-name = "8026_l20"; + qcom,hpm-min-load = <5000>; + regulator-min-microvolt = <3075000>; + regulator-max-microvolt = <3075000>; + }; +}; diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index 3da0ebdba8d9..57181534c8e8 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -51,12 +51,24 @@ compatible (optional) - standard definition used as a shared pool of DMA buffers for a set of devices. It can be used by an operating system to instanciate the necessary pool management subsystem if necessary. + - removed-dma-pool: This indicates a region of memory which is meant to + be carved out and not exposed to kernel. - vendor specific string in the form <vendor>,[<device>-]<usage> no-map (optional) - empty property - Indicates the operating system must not create a virtual mapping of the region as part of its standard mapping of system memory, nor permit speculative access to it under any circumstances other than under the control of the device driver using the region. +no-map-fixup (optional) - empty property + - Indicates the operating system must reserve the memory region and keep + virtual mapping. Upon first allocation the actual allocated region is + removed for any virtual mapping and behaves as "no-map" while the + remaining memory is returned back to the system for normal use. One would + like to use this property where he is not sure about how much region size + must be reserved, so he gives it a max size which then is shrink once + (first) allocation is done. This property is for some specific use cases, + if unsure please don't use it. This property cannot be used together with + "no-map" attribute. reusable (optional) - empty property - The operating system can use the memory in this region with the limitation that the device driver(s) owning the region need to be diff --git a/Documentation/devicetree/bindings/rtc/qpnp-rtc.txt b/Documentation/devicetree/bindings/rtc/qpnp-rtc.txt new file mode 100644 index 000000000000..e0934b2aa82f --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/qpnp-rtc.txt @@ -0,0 +1,60 @@ +* msm-qpnp-rtc + +msm-qpnp-rtc is a RTC driver that supports 32 bit RTC housed inside PMIC. +Driver utilizes MSM SPMI interface to communicate with the RTC module. +RTC device is divided into two sub-peripherals one which controls basic RTC +and other for controlling alarm. + +[PMIC RTC Device Declarations] + +-Root Node- + +Required properties : + - compatible: Must be "qcom,qpnp-rtc" + - #address-cells: The number of cells dedicated to represent an address + This must be set to '1'. + - #size-cells: The number of cells dedicated to represent address + space range of a peripheral. This must be set to '1'. + +Optional properties: + - qcom,qpnp-rtc-write: This property enables/disables rtc write + operation. If not mentioned rtc driver keeps + rtc writes disabled. + 0 = Disable rtc writes. + 1 = Enable rtc writes. + - qcom,qpnp-rtc-alarm-pwrup: This property enables/disables feature of + powering up phone (from power down state) + through alarm interrupt. + If not mentioned rtc driver will disable + feature of powring-up phone through alarm. + 0 = Disable powering up of phone through + alarm interrupt. + 1 = Enable powering up of phone through + alarm interrupt. + +-Child Nodes- + +Required properties : + - reg : Specify the spmi offset and size for device. + - interrupts: Specifies alarm interrupt, only for rtc_alarm + sub-peripheral. + +Example: + qcom,pm8941_rtc { + compatible = "qcom,qpnp-rtc"; + #address-cells = <1>; + #size-cells = <1>; + qcom,qpnp-rtc-write = <0>; + qcom,qpnp-rtc-alarm-pwrup = <0>; + + qcom,pm8941_rtc_rw@6000 { + reg = <0x6000 0x100>; + }; + + qcom,pm8941_rtc_alarm@6100 { + reg = <0x6100 0x100>; + interrupts = <0x0 0x61 0x1>; + }; + }; + + diff --git a/Documentation/devicetree/bindings/scheduler/sched-energy-costs.txt b/Documentation/devicetree/bindings/scheduler/sched-energy-costs.txt new file mode 100644 index 000000000000..11216f09e596 --- /dev/null +++ b/Documentation/devicetree/bindings/scheduler/sched-energy-costs.txt @@ -0,0 +1,360 @@ +=========================================================== +Energy cost bindings for Energy Aware Scheduling +=========================================================== + +=========================================================== +1 - Introduction +=========================================================== + +This note specifies bindings required for energy-aware scheduling +(EAS)[1]. Historically, the scheduler's primary objective has been +performance. EAS aims to provide an alternative objective - energy +efficiency. EAS relies on a simple platform energy cost model to +guide scheduling decisions. The model only considers the CPU +subsystem. + +This note is aligned with the definition of the layout of physical +CPUs in the system as described in the ARM topology binding +description [2]. The concept is applicable to any system so long as +the cost model data is provided for those processing elements in +that system's topology that EAS is required to service. + +Processing elements refer to hardware threads, CPUs and clusters of +related CPUs in increasing order of hierarchy. + +EAS requires two key cost metrics - busy costs and idle costs. Busy +costs comprise of a list of compute capacities for the processing +element in question and the corresponding power consumption at that +capacity. Idle costs comprise of a list of power consumption values +for each idle state [C-state] that the processing element supports. +For a detailed description of these metrics, their derivation and +their use see [3]. + +These cost metrics are required for processing elements in all +scheduling domain levels that EAS is required to service. + +=========================================================== +2 - energy-costs node +=========================================================== + +Energy costs for the processing elements in scheduling domains that +EAS is required to service are defined in the energy-costs node +which acts as a container for the actual per processing element cost +nodes. A single energy-costs node is required for a given system. + +- energy-costs node + + Usage: Required + + Description: The energy-costs node is a container node and + it's sub-nodes describe costs for each processing element at + all scheduling domain levels that EAS is required to + service. + + Node name must be "energy-costs". + + The energy-costs node's parent node must be the cpus node. + + The energy-costs node's child nodes can be: + + - one or more cost nodes. + + Any other configuration is considered invalid. + +The energy-costs node can only contain a single type of child node +whose bindings are described in paragraph 4. + +=========================================================== +3 - energy-costs node child nodes naming convention +=========================================================== + +energy-costs child nodes must follow a naming convention where the +node name must be "thread-costN", "core-costN", "cluster-costN" +depending on whether the costs in the node are for a thread, core or +cluster. N (where N = {0, 1, ...}) is the node number and has no +bearing to the OS' logical thread, core or cluster index. + +=========================================================== +4 - cost node bindings +=========================================================== + +Bindings for cost nodes are defined as follows: + +- cluster-cost node + + Description: must be declared within an energy-costs node. A + system can contain multiple clusters and each cluster + serviced by EAS must have a corresponding cluster-costs + node. + + The cluster-cost node name must be "cluster-costN" as + described in 3 above. + + A cluster-cost node must be a leaf node with no children. + + Properties for cluster-cost nodes are described in paragraph + 5 below. + + Any other configuration is considered invalid. + +- core-cost node + + Description: must be declared within an energy-costs node. A + system can contain multiple cores and each core serviced by + EAS must have a corresponding core-cost node. + + The core-cost node name must be "core-costN" as described in + 3 above. + + A core-cost node must be a leaf node with no children. + + Properties for core-cost nodes are described in paragraph + 5 below. + + Any other configuration is considered invalid. + +- thread-cost node + + Description: must be declared within an energy-costs node. A + system can contain cores with multiple hardware threads and + each thread serviced by EAS must have a corresponding + thread-cost node. + + The core-cost node name must be "core-costN" as described in + 3 above. + + A core-cost node must be a leaf node with no children. + + Properties for thread-cost nodes are described in paragraph + 5 below. + + Any other configuration is considered invalid. + +=========================================================== +5 - Cost node properties +========================================================== + +All cost node types must have only the following properties: + +- busy-cost-data + + Usage: required + Value type: An array of 2-item tuples. Each item is of type + u32. + Definition: The first item in the tuple is the capacity + value as described in [3]. The second item in the tuple is + the energy cost value as described in [3]. + +- idle-cost-data + + Usage: required + Value type: An array of 1-item tuples. The item is of type + u32. + Definition: The item in the tuple is the energy cost value + as described in [3]. + +=========================================================== +4 - Extensions to the cpu node +=========================================================== + +The cpu node is extended with a property that establishes the +connection between the processing element represented by the cpu +node and the cost-nodes associated with this processing element. + +The connection is expressed in line with the topological hierarchy +that this processing element belongs to starting with the level in +the hierarchy that this processing element itself belongs to through +to the highest level that EAS is required to service. The +connection cannot be sparse and must be contiguous from the +processing element's level through to the highest desired level. The +highest desired level must be the same for all processing elements. + +Example: Given that a cpu node may represent a thread that is a part +of a core, this property may contain multiple elements which +associate the thread with cost nodes describing the costs for the +thread itself, the core the thread belongs to, the cluster the core +belongs to and so on. The elements must be ordered from the lowest +level nodes to the highest desired level that EAS must service. The +highest desired level must be the same for all cpu nodes. The +elements must not be sparse: there must be elements for the current +thread, the next level of hierarchy (core) and so on without any +'holes'. + +Example: Given that a cpu node may represent a core that is a part +of a cluster of related cpus this property may contain multiple +elements which associate the core with cost nodes describing the +costs for the core itself, the cluster the core belongs to and so +on. The elements must be ordered from the lowest level nodes to the +highest desired level that EAS must service. The highest desired +level must be the same for all cpu nodes. The elements must not be +sparse: there must be elements for the current thread, the next +level of hierarchy (core) and so on without any 'holes'. + +If the system comprises of hierarchical clusters of clusters, this +property will contain multiple associations with the relevant number +of cluster elements in hierarchical order. + +Property added to the cpu node: + +- sched-energy-costs + + Usage: required + Value type: List of phandles + Definition: a list of phandles to specific cost nodes in the + energy-costs parent node that correspond to the processing + element represented by this cpu node in hierarchical order + of topology. + + The order of phandles in the list is significant. The first + phandle is to the current processing element's own cost + node. Subsequent phandles are to higher hierarchical level + cost nodes up until the maximum level that EAS is to + service. + + All cpu nodes must have the same highest level cost node. + + The phandle list must not be sparsely populated with handles + to non-contiguous hierarchical levels. See commentary above + for clarity. + + Any other configuration is invalid. + +=========================================================== +5 - Example dts +=========================================================== + +Example 1 (ARM 64-bit, 6-cpu system, two clusters of cpus, one +cluster of 2 Cortex-A57 cpus, one cluster of 4 Cortex-A53 cpus): + +cpus { + #address-cells = <2>; + #size-cells = <0>; + . + . + . + A57_0: cpu@0 { + compatible = "arm,cortex-a57","arm,armv8"; + reg = <0x0 0x0>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A57_L2>; + clocks = <&scpi_dvfs 0>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_0 &CLUSTER_COST_0>; + }; + + A57_1: cpu@1 { + compatible = "arm,cortex-a57","arm,armv8"; + reg = <0x0 0x1>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A57_L2>; + clocks = <&scpi_dvfs 0>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_0 &CLUSTER_COST_0>; + }; + + A53_0: cpu@100 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x0 0x100>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + clocks = <&scpi_dvfs 1>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>; + }; + + A53_1: cpu@101 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x0 0x101>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + clocks = <&scpi_dvfs 1>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>; + }; + + A53_2: cpu@102 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x0 0x102>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + clocks = <&scpi_dvfs 1>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>; + }; + + A53_3: cpu@103 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x0 0x103>; + device_type = "cpu"; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + clocks = <&scpi_dvfs 1>; + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>; + sched-energy-costs = <&CPU_COST_1 &CLUSTER_COST_1>; + }; + + energy-costs { + CPU_COST_0: core-cost0 { + busy-cost-data = < + 417 168 + 579 251 + 744 359 + 883 479 + 1024 616 + >; + idle-cost-data = < + 15 + 0 + >; + }; + CPU_COST_1: core-cost1 { + busy-cost-data = < + 235 33 + 302 46 + 368 61 + 406 76 + 447 93 + >; + idle-cost-data = < + 6 + 0 + >; + }; + CLUSTER_COST_0: cluster-cost0 { + busy-cost-data = < + 417 24 + 579 32 + 744 43 + 883 49 + 1024 64 + >; + idle-cost-data = < + 65 + 24 + >; + }; + CLUSTER_COST_1: cluster-cost1 { + busy-cost-data = < + 235 26 + 303 30 + 368 39 + 406 47 + 447 57 + >; + idle-cost-data = < + 56 + 17 + >; + }; + }; +}; + +=============================================================================== +[1] https://lkml.org/lkml/2015/5/12/728 +[2] Documentation/devicetree/bindings/topology.txt +[3] Documentation/scheduler/sched-energy.txt diff --git a/Documentation/devicetree/bindings/scheduler/sched_hmp.txt b/Documentation/devicetree/bindings/scheduler/sched_hmp.txt new file mode 100644 index 000000000000..ba1d4db9e407 --- /dev/null +++ b/Documentation/devicetree/bindings/scheduler/sched_hmp.txt @@ -0,0 +1,35 @@ +* HMP scheduler + +This file describes the bindings for an optional HMP scheduler +node (/sched-hmp). + +Required properties: + +Optional properties: + +- boost-policy: The HMP scheduler has two types of task placement boost +policies. + +(1) boost-on-big policy make use of all big CPUs up to their full capacity +before using the little CPUs. This improves performance on true b.L systems +where the big CPUs have higher efficiency compared to the little CPUs. + +(2) boost-on-all policy place the tasks on the CPU having the highest +spare capacity. This policy is optimal for SMP like systems. + +The scheduler sets the boost policy to boost-on-big on systems which has +CPUs of different efficiencies. However it is possible that CPUs of the +same micro architecture to have slight difference in efficiency due to +other factors like cache size. Selecting the boost-on-big policy based +on relative difference in efficiency is not optimal on such systems. +The boost-policy device tree property is introduced to specify the +required boost type and it overrides the default selection of boost +type in the scheduler. + +The possible values for this property are "boost-on-big" and "boost-on-all". + +Example: + +sched-hmp { + boost-policy = "boost-on-all" +} diff --git a/Documentation/devicetree/bindings/slimbus/slim-msm-ctrl.txt b/Documentation/devicetree/bindings/slimbus/slim-msm-ctrl.txt new file mode 100644 index 000000000000..90d8a359ccc0 --- /dev/null +++ b/Documentation/devicetree/bindings/slimbus/slim-msm-ctrl.txt @@ -0,0 +1,81 @@ + Qualcomm Technologies,Inc SLIMBUS controller + Qualcomm Technologies,Inc implements 2 type of slimbus controllers: +1. "qcom,slim-msm": This controller is used if applications processor + driver is controlling slimbus master component. This driver is + responsible for communicating with slave HW directly using + messaging interface, and doing data channel management. Driver + also communicates with satellite component (driver implemented + by other execution environment, such as ADSP) to get its + requirements for data channel and bandwidth requirements. +2. "qcom,slim-ngd": This controller is used if applications processor + driver is controlling slimbus satellite component (also known as + Non-ported Generic Device, or NGD). This is light-weight slimbus + controller responsible for communicating with slave HW directly + over bus messaging interface, and communicating with master component + (driver residing on other execution environment, such as ADSP) + for bandwidth and data channel management. + +Required properties: + + - reg : Offset and length of the register region(s) for the device + - reg-names : Register region name(s) referenced in reg above + Required register resource entries are: + "slimbus_physical": Physical adderss of controller register blocks + "slimbus_bam_physical": Physical address of Bus Access Module (BAM) + for this controller + - compatible : should be "qcom,slim-msm" if this is master component driver + - compatible : should be "qcom,slim-ngd" if this is satellite component driver + - cell-index : SLIMBUS number used for this controller + - interrupts : Interrupt numbers used by this controller + - interrupt-names : Required interrupt resource entries are: + "slimbus_irq" : Interrupt for SLIMBUS core + "slimbus_bam_irq" : Interrupt for controller core's BAM + +Optional property: + - reg entry for slew rate : If slew rate control register is provided, this + entry should be used. + - reg-name for slew rate: "slimbus_slew_reg" + - qcom,min-clk-gear : Minimum clock gear at which this controller can be run + (range: 1-10) + Default value will be 1 if this entry is not specified + - qcom,max-clk-gear: Maximum clock gear at which this controller can be run + (range: 1-10) + Default value will be 10 if this entry is not specified + - qcom,rxreg-access: This boolean indicates that slimbus RX should use direct + register access to receive data. This flag is only needed if + BAM pipe is not available to receive data from slimbus + - qcom,apps-ch-pipes: This value represents BAM pipe-mask used by application + processor for data channels. If this property is not defined, + default mask of 0x3F000000 is used indicating apps can use 6 + pipes from 24-29. + - qcom,ea-pc: This value represents product code (PC) field of enumeration + address (EA) for the QTI slimbus controller hardware. + This value is needed if data-channels originating from apps + are to be used, so that application processor can query + logical address of the ported generic device to be used. + Other than PC, fields of EA are same across platforms. + - qcom,slim-mdm: This value provides the identifier of slimbus component on + external mdm. This property enables the slimbus driver to + register and receive subsytem restart notification from mdm + and follow appropriate steps to ensure communication on the bus + can be resumed after mdm-restart. + - qcom,subsys-name: This value provides the subsystem name where slimbus master + is present. This property enables the slimbus driver to + register and receive subsytem restart notification from subsystem + and follow appropriate steps to ensure communication on the bus + can be resumed after subsytem restart. By default slimbus driver + register with ADSP subsystem. +Example: + slim@fe12f000 { + cell-index = <1>; + compatible = "qcom,slim-msm"; + reg = <0xfe12f000 0x35000>, + <0xfe104000 0x20000>; + reg-names = "slimbus_physical", "slimbus_bam_physical"; + interrupts = <0 163 0 0 164 0>; + interrupt-names = "slimbus_irq", "slimbus_bam_irq"; + qcom,min-clk-gear = <10>; + qcom,rxreg-access; + qcom,apps-ch-pipes = <0x60000000>; + qcom,ea-pc = <0x30>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/avtimer.txt b/Documentation/devicetree/bindings/soc/qcom/avtimer.txt new file mode 100644 index 000000000000..157f79b2b07a --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/avtimer.txt @@ -0,0 +1,26 @@ +* avtimer + +Avtimer provides an interface for clients to enable avtimer block +on qdsp6. 64 bit AVtimer exposed by qdsp6 is used for audio and video +stream synchronization during capture and playback usecases. + +Required properties: +- reg : physical address and length of avtimer register +- reg-names : AVtimer register name + Required register resource entries are: + "avtimer_lsb_addr" : AVtimer lsb physical address + "avtimer_msb_addr" : AVtimer msb physical address +- compatible : Must be "qcom,avtimer" + +Optional properties: +- clk-div : The clk is at 27MHz and hence ticks are to be + divided by 27 to achive the msec value. + +Example: + qcom,avtimer@90f7000 { + compatible = "qcom,avtimer"; + reg = <0x90f700c 0x4>, + <0x90f7010 0x4>; + reg-names = "avtimer_lsb_addr", "avtimer_msb_addr"; + qcom,clk-div = <27>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/dcc.txt b/Documentation/devicetree/bindings/soc/qcom/dcc.txt new file mode 100644 index 000000000000..53ac911d182e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/dcc.txt @@ -0,0 +1,42 @@ +* Data Capture and Compare (DCC) + +DCC (Data Capture and Compare) is a DMA engine, which is used to save +configuration data or system memory contents during catastrophic failure or +SW trigger. +It can also perform CRC over the same configuration or memory space. + +Required properties: + +- compatible : name of the component used for driver matching, should be + "qcom,dcc" + +- reg : physical base address and length of the register set(s), SRAM and XPU + of the component. + +- reg-names : names corresponding to each reg property value. + +Optional properties: + +- qcom,save-reg: boolean, To save dcc registers state in memory after dcc + enable and disable + +- qcom,data-sink: string, To specify default data sink for dcc, should be one + of the following: + "atb" : To send captured data over ATB to a trace sink + "sram" : To save captured data in dcc internal SRAM. + +Example: + + dcc: dcc@4b3000 { + compatible = "qcom,dcc"; + reg = <0x4b3000 0x1000>, + <0x4b4000 0x2000>, + <0x4b0000 0x1>; + reg-names = "dcc-base", "dcc-ram-base", "dcc-xpu-base"; + + clocks = <&clock_gcc clk_gcc_dcc_ahb_clk>; + clock-names = "dcc_clk"; + + qcom,save-reg; + }; + diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,cx_ipeak.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,cx_ipeak.txt new file mode 100644 index 000000000000..d5fb03cc9318 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,cx_ipeak.txt @@ -0,0 +1,22 @@ +* Cx iPeak driver to handle requests from various multimedia clients. + +Cx ipeak HW module is used to limit the current drawn by various subsystem +blocks on Cx power rail. Each client needs to set their +bit in tcsr register if it is going to cross its own threshold. If all +clients are going to cross their thresholds then Cx ipeak hw module will raise +an interrupt to cDSP block to throttle cDSP's fmax. + +Required properties: + +- compatible : name of the component used for driver matching, should be + "qcom,cx-ipeak-sdm660" + +- reg : physical base address and length of the register set(s), SRAM and XPU + of the component. + +Example: + + cx_ipeak_lm: cx_ipeak@1fe5040 { + compatible = "qcom,cx-ipeak-sdm660"; + reg = <0x01fe5040 0x28>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qpnp-haptic.txt b/Documentation/devicetree/bindings/soc/qcom/qpnp-haptic.txt new file mode 100644 index 000000000000..6574cfe30ce5 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qpnp-haptic.txt @@ -0,0 +1,140 @@ +QPNP Haptic + +QPNP (Qualcomm Technologies Plug N Play) Haptic is a peripheral on +Qualcomm Technologies PMICs. The PMIC is connected to Host processor +via SPMI bus. + +This device can be operated in four modes - direct, buffer, +pwm(pulse width modulation) and audio. + +Required Properties: + - compatible: must be "qcom,qpnp-haptic" + - reg: address of device + - qcom,pmic-revid : phandle to fetch PMIC revid + - qcom,actuator-type: must be one of "erm" or "lra" + - qcom,play-mode : must be one of "buffer", "direct", "pwm" or "audio" + +Optional Properties: + - qcom,timeout-ms: timeout in ms. + - qcom,vmax-mv : maximum output voltage in milli volts + - qcom,ilim-ma : maximum output current limit threshold in milli amps + - qcom,int-pwm-freq-khz : frequency for internal pwm + - qcom,en-brake : specify to enable internal reverse braking + - qcom,brake-pattern : 4 byte active brake pattern. Each pattern represents + 2-bit amplitude control 0x00: 0, 0x01: vmax/4, 0x02: vmax/2, + 0x03: vmax. Default values are 0x00. + - qcom,sc-deb-cycles : short circuit debounce in internal pwm switching clock cycles + - qcom,use-play-irq : boolean, use this if the device uses irq for play + - qcom,use-sc-irq : boolean, use this if the device uses irq for play + - interrupts: Specifies the interrupt associated with Haptics. The available + interrupts are play and short circuit. The values for play and + short circuit are <0x3 0xc0 0x0> and <0x3 0xc0 0x1>. + - interrupt-names: Specify the interrupt names associated with interrupts. Must be + one of "play-irq" or "sc-irq" + - vcc_pon-supply: power-on driver regulator + +Optional properties for buffer play mode: + - qcom,wave-samples : 8 byte buffer representing the wave. The bits in each sample + are represented as follows- bit 0: reserved, bits 1 to 5: amplitude + of the waveform, bit 6: over drive and bit 7: direction. + - qcom,wave-shape : must be "sine" or "square" + - qcom,wave-rep-cnt : repetition count for wave form + - qcom,wave-samp-rep-cnt : repetition count for each sample of wave + - qcom,wave-play-rate-us : duration at which each sample to be played in micro seconds + +Required properties for pwm play mode: + - qcom,pwm-channel: pwm channel the led will operate on + - qcom,period-us: pwm period in us + - qcom,duty-us: pwm duty cycle in us + - qcom,ext-pwm-dtest-line: dtest line to used with pwm + +Optional properties for pwm play mode: + - qcom,ext-pwm-freq-khz : frequency for external pwm in kilo HZ + +Optional properties when qcom,actuator-type is "lra" + - qcom,correct-lra-drive-freq : boolean, use this to ensure LRA is driven at correct resonant + frequency, which may change due to operating conditions. + - qcom,misc-trim-error-rc19p2-clk-reg-present : boolean, use this if TRIM_ERROR_RC19P2_CLK + register is present in MISC module. This register holds + the frequency error in 19.2Mhz RC clock. + - qcom,lra-auto-res-mode : auto resonance technique, four different modes + "none" : no auto resonance + "zxd" : zero crossing based discontinuous method + "qwd" : quarter wave drive method + "max-qwd" : Maximum QWD + "zxd-eop" : ZXD + End of pattern (This is the Default) + - qcom,lra-high-z : High Z configuration for auto resonance. Possible string values are + "none", "opt1", "opt2" and "opt3" (default). For PM660, + "opt0" is valid value for 1 LRA period. + - qcom,lra-qwd-drive-duration : Drive duration of LRA in QWD mode for PM660. + Possible values are: 0: 1/4 LRA PERIOD and 1: 3/8 LRA PERIOD + - qcom,lra-calibrate-at-eop : To calibrate at End of Pattern for PM660. + Possible values are: 0 to disable and 1 to enable Calibration + at End of Pattern + - qcom,lra-res-cal-period : Auto resonance calibration period. The values range from + 4 to 32(default) + - qcom,perform-lra-auto-resonance-search : boolean, define this property if: + a) the underlying PMI chip does not have a register in the MISC block to + read the error percentage in RC clock + b) the actuator type is LRA + Defining this causes the auto resonance search algorithm to be be performed + for such devices. + c) This property is not defined by default. + +- qcom,drive-period-code-max-limit-percent-variation: RATE_CFG1 and RATE_CFG2 registers will + be updated with the values from AUTO_RES_LO and AUTO_RES_HI registers + only if the variation from the resonant frequency is within the value + mentioned by this property on the higher side. + The default value is 25, which means if the drive period code resulting + from AUTO_RES register's is more than 25 percent of the existing drive + period code, then driver does not update RATE_CFG registers. +- qcom,drive-period-code-min-limit-percent-variation: RATE_CFG1 and RATE_CFG2 registers will + be updated with the values from AUTO_RES_LO and AUTO_RES_HI registers + only if the variation from the resonant frequency is within the value + mentioned by this property on the lower side. + The default value is 25, which means if the drive period code resulting + from AUTO_RES register's is less than 25 percent of the existing drive + period code, then driver does not update RATE_CFG registers. + +Optional properties when qcom,lra-auto-res-mode is "qwd" + - qcom,time-required-to-generate-back-emf-us: Time period required to generate sufficient + back-emf (in case of QWD mode only) in us. For auto resonance + detection to work properly,sufficient back-emf has to be + generated. In general, back-emf takes some time to build up. + When the auto resonance mode is chosen as QWD, high-z will + be applied for every LRA cycle and hence there won't be + enough back-emf at the start-up. So we need to drive the + motor for a few LRA cycles. Hence, auto resonance detection + is enabled after this delay period after the PLAY bit is + asserted. The default value is 20000us. + +Example: + qcom,haptic@c000 { + status = "disabled"; + compatible = "qcom,qpnp-haptic"; + reg = <0xc000 0x100>; + interrupts = <0x3 0xc0 0x0>, + <0x3 0xc0 0x1>; + interrupt-names = "sc-irq", "play-irq"; + qcom,pmic-revid = <&pm660_revid>; + vcc_pon-supply = <&pon_perph_reg>; + qcom,play-mode = "direct"; + qcom,wave-play-rate-us = <5263>; + qcom,actuator-type = "lra"; + qcom,wave-shape = "square"; + qcom,vmax-mv = <2000>; + qcom,ilim-ma = <800>; + qcom,sc-deb-cycles = <8>; + qcom,int-pwm-freq-khz = <505>; + qcom,en-brake; + qcom,brake-pattern = [03 03 00 00]; + qcom,use-play-irq; + qcom,use-sc-irq; + qcom,wave-samples = [3e 3e 3e 3e 3e 3e 3e 3e]; + qcom,wave-rep-cnt = <1>; + qcom,wave-samp-rep-cnt = <1>; + qcom,lra-high-z = "opt1"; + qcom,lra-auto-res-mode = "qwd"; + qcom,lra-res-cal-period = <4>; + qcom,time-required-to-generate-back-emf-us = <20000>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qpnp-pbs.txt b/Documentation/devicetree/bindings/soc/qcom/qpnp-pbs.txt new file mode 100644 index 000000000000..d7aefbf9c19c --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qpnp-pbs.txt @@ -0,0 +1,30 @@ +QPNP PBS + +QPNP (Qualcomm Technologies, Inc. Plug N Play) PBS is programmable boot sequence +and this driver is for helping the client drivers triggering such sequence +to be configured in PMIC. + +This document describes the bindings for QPNP PBS driver. + +======================= +Required Node Structure +======================= + +- compatible + Usage: required + Value type: <string> + Definition: should be "qcom,qpnp-pbs". + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Base address of the PBS registers. + + +======= +Example +======= + pm660l_pbs: qcom,pbs@7300 { + compatible = "qcom,qpnp-pbs"; + reg = <0x7300 0x100>; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom-audio-dev.txt b/Documentation/devicetree/bindings/sound/qcom-audio-dev.txt new file mode 100644 index 000000000000..6f0d99d560cd --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom-audio-dev.txt @@ -0,0 +1,2509 @@ +Qualcomm audio devices for ALSA sound SoC + +* msm-pcm + +Required properties: + + - compatible : "qcom,msm-pcm-dsp" + + - qcom,msm-pcm-dsp-id : device node id + +* msm-pcm-low-latency + +Required properties: + + - compatible : "qcom,msm-pcm-dsp" + + - qcom,msm-pcm-dsp-id : device node id + + Optional properties + + - qcom,msm-pcm-low-latency : Flag indicating whether + the device node is of type low latency. + + - qcom,latency-level : Flag indicating whether the device node + is of type regular low latency or ultra + low latency. + regular : regular low latency stream + ultra : ultra low latency stream + ull-pp : ultra low latency stream with post-processing capability + +* msm-pcm-dsp-noirq + +Required properties: + + - compatible : "qcom,msm-pcm-dsp-noirq"; + + Optional properties + + - qcom,msm-pcm-low-latency : Flag indicating whether + the device node is of type low latency + + - qcom,latency-level : Flag indicating whether the device node + is of type low latency or ultra low latency + ultra : ultra low latency stream + ull-pp : ultra low latency stream with post-processing capability +* msm-pcm-routing + +Required properties: + + - compatible : "qcom,msm-pcm-routing" + +* msm-pcm-lpa + +Required properties: + + - compatible : "qcom,msm-pcm-lpa" + +* msm-compr-dsp + +Required properties: + + - compatible : "qcom,msm-compr-dsp" + +* msm-compress-dsp + +Required properties: + + - compatible : "qcom,msm-compress-dsp" + +Optional properties + - qcom,adsp-version: + This property can be used to specify the ADSP version/name. + Based on ADSP version, we decide if we have to use older + ADSP APIs or newer. Right now we are adding "MDSP 1.2" for + 8909 purpose.If the ADSP version is anything other than this + we use new ADSP APIs. + +* msm-voip-dsp + +Required properties: + + - compatible : "qcom,msm-voip-dsp" + +* msm-pcm-voice + +Required properties: + + - compatible : "qcom,msm-pcm-voice" + - qcom,destroy-cvd : Flag indicating whether to destroy cvd at + the end of call for low memory targets + - qcom,vote-bms : Flag indicating whether to vote for BMS during + the call start and stop + +* msm-voice-host-pcm + +Required properties: + + - compatible : "qcom,msm-voice-host-pcm" + +* msm-stub-codec + +Required properties: + + - compatible : "qcom,msm-stub-codec" + +* msm-hdmi-dba-codec-rx + +Required properties: + + - compatible : "qcom,msm-hdmi-dba-codec-rx" + - qcom,dba-bridge-chip: String info to indicate which bridge-chip + is used for HDMI using DBA. + +* msm-dai-fe + +Required properties: + + - compatible : "qcom,msm-dai-fe" + +* msm-pcm-afe + +Required properties: + + - compatible : "qcom,msm-pcm-afe" + +* msm-pcm-dtmf + +Required properties: + + - compatible : "qcom,msm-pcm-dtmf" + - qcom,msm-pcm-dtmf : Enable DTMF driver in Audio. DTMF driver is + used for generation and detection of DTMF tones, when user is in + active voice call. APR commands are sent from DTMF driver to ADSP. + +* msm-dai-stub + +[First Level Nodes] + +Required properties: + + - compatible : "msm-dai-stub" + +[Second Level Nodes] + +Required properties: + + - compatible : "qcom,msm-dai-stub-dev" + - qcom,msm-dai-stub-dev-id : Stub dai port ID value is from 0 to 3. + This enables stub CPU dai in Audio. The stub dai is used when + there is no real backend in Audio. + +* msm-dai-q6-spdif + +Optional properties: + + - compatible : "msm-dai-q6-spdif" + +* msm-dai-q6-hdmi + +Required properties: + - compatible : "msm-dai-q6-hdmi" + - qcom,msm-dai-q6-dev-id : The hdmi multi channel port ID. + It is passed onto the dsp from the apps to form an audio + path to the HDMI device. Currently the only supported value + is 8, which indicates the rx path used for audio playback + on HDMI device. + +* msm-lsm-client + +Required properties: + + - compatible : "qcom,msm-lsm-client" + +* msm-pcm-loopback + +Required properties: + + - compatible : "qcom,msm-pcm-loopback" + +Optional properties: + + - qcom,msm-pcm-loopback-low-latency : Flag indicating whether + the device node is of type low latency. + +* msm-dai-q6 + +[First Level Nodes] + +Required properties: + + - compatible : "msm-dai-q6" + +Optional properties: + + - qcom,ext-spk-amp-supply : External speaker amplifier power supply. + - qcom,ext-spk-amp-gpio : External speaker amplifier enable signal. + +[Second Level Nodes] + +Required properties: + + - compatible : "qcom,msm-dai-q6-dev" + - qcom,msm-dai-q6-dev-id : The slimbus multi channel port ID + Value is from 16384 to 16397 + BT SCO port ID value from 12288 to 12289 + RT Proxy port ID values from 224 to 225 and 240 to + 241 + FM Rx and TX port ID values from 12292 to 12293 + incall record Rx and TX port ID values from 32771 to 32772 + inCall Music Delivery port ID is 32773 + incall Music 2 Delivery port ID is 32770 + +* msm-auxpcm + +Required properties: + + - compatible : "qcom,msm-auxpcm-dev" + + - qcom,msm-cpudai-auxpcm-mode: mode information. The first value is + for 8khz mode, the second is for + 16khz + 0 - for PCM + + - qcom,msm-cpudai-auxpcm-sync: sync information. The first value is + for 8khz mode, the second is for + 16khz + + - qcom,msm-cpudai-auxpcm-frame: No.of bytes per frame. The first + value is for 8khz mode, the second + is for 16khz + 5 - 256BPF + 4 - 128BPF + + - qcom,msm-cpudai-auxpcm-quant: Type of quantization. The first + value is for 8khz mode, the second + is for 16khz + 2 - Linear quantization + + - qcom,msm-cpudai-auxpcm-num-slots: Number of slots per mode in the + msm-cpudai-auxpcm-slot-mapping + array. + The first value is for 8khz mode, the + second is for 16khz. Max number of + slots supported by DSP is 4, anything + above 4 will be truncated to 4 when + sent to DSP. + + - qcom,msm-cpudai-auxpcm-slot-mapping: Array of slot numbers for multi + slot scenario. The first array + is for 8khz mode, the second is + for 16khz. The size of the array + is determined by the value in + qcom,msm-cpudai-auxpcm-num-slots + + - qcom,msm-cpudai-auxpcm-data: Data field - 0. The first value is + for 8khz mode, the second is for + 16khz + + - qcom,msm-cpudai-auxpcm-pcm-clk-rate: Clock rate for pcm - 2048000. The + first value is for 8khz mode, the + second is for 16KHz mode. When clock + rate is set to zero, then external + clock is assumed. + + - qcom,msm-auxpcm-interface: name of AUXPCM interface "primary" + indicates primary AUXPCM interface + "secondary" indicates secondary + AUXPCM interface +Optional properties: + +- pinctrl-names: Pinctrl state names for each pin + group configuration. +- pinctrl-x: Defines pinctrl state for each pin + group +- qcom,msm-cpudai-afe-clk-ver: Indicates version of AFE clock + interface to be used for enabling + PCM clock. If not defined, selects + default AFE clock interface. + +* msm-pcm-hostless + +Required properties: + + - compatible : "qcom,msm-pcm-hostless" + +* msm-ocmem-audio + +Required properties: + + - compatible : "qcom,msm-ocmem-audio" + + - qcom,msm_bus,name: Client name + + - qcom,msm_bus,num_cases: Total number of use cases + + - qcom,msm_bus,active_only: Context flag for requests in active + or dual (active & sleep) contex + + - qcom,msm_bus,num_paths: Total number of master-slave pairs + + - qcom,msm_bus,vectors: Arrays of unsigned integers + representing: + master-id, slave-id, arbitrated + bandwidth, + instantaneous bandwidth +* wcd9xxx_intc + +Required properties: + + - compatible : "qcom,wcd9xxx-irq" + + - interrupt-controller : Mark this device node as an + interrupt controller + + - #interrupt-cells : Should be 1 + + - interrupt-parent : Parent interrupt controller + + - qcom,gpio-connect Gpio that connects to parent + interrupt controller + +* audio-ext-clk + +Required properties: + + - compatible : "qcom,audio-ref-clk" + + - qcom,audio-ref-clk-gpio : PMIC or APQ gpio that will be + requested to enable reference + or external clock. + +Optional properties: + + - qcom,node_has_rpm_clock: Boolean property used to indicate + whether ref. clock can be enabled + with a gpio toggle or Kernel clock + API call. + + - clock-names: Name of the PMIC clock that needs + to be enabled for audio ref clock. + This clock is set as parent. + + - clocks: phandle reference to the parent + clock. + +* audio_slimslave + +Required properties: + + - compatible : "qcom,audio-slimslave" + + - elemental-addr: slimbus slave enumeration address. + +* msm-cpe-lsm + +Required properties: + + - compatible : "qcom,msm-cpe-lsm" + - qcom,msm-cpe-lsm-id : lsm afe port ID. CPE lsm driver uses + this property to find out the input afe port ID. Currently + only supported values are 1 and 3. + +* wcd_us_euro_gpio + +Required properties: + + - compatible : "qcom,msm-cdc-pinctrl" + +Optional properties: + - qcom,lpi-gpios : This boolean property is added if GPIOs are under + LPI TLMM. + +* msm-dai-slim + +Required properties: + + - compatible : "qcom,msm-dai-slim" + + - elemental-addr: slimbus slave enumeration address. + +* wcd_gpio_ctrl + +Required properties: + + - compatible : "qcom,msm-cdc-pinctrl" + + - qcom,cdc-rst-n-gpio : TLMM GPIO number + + - pinctrl-names: Pinctrl state names for each pin + group configuration. + - pinctrl-x: Defines pinctrl state for each pin + group. +* msm_cdc_pinctrl + +Required properties: + + - compatible : "qcom,msm-cdc-pinctrl" + + - pinctrl-names: Pinctrl state names for each pin + group configuration. + - pinctrl-x: Defines pinctrl state for each pin + group. + +* wcd_dsp_glink + +Required properties: + + - compatible : "qcom,wcd-dsp-glink" + +Example: + + qcom,msm-pcm { + compatible = "qcom,msm-pcm-dsp"; + qcom,msm-pcm-dsp-id = <0>; + }; + + qcom,msm-pcm-low-latency { + compatible = "qcom,msm-pcm-dsp"; + qcom,msm-pcm-dsp-id = <1>; + qcom,msm-pcm-low-latency; + }; + + qcom,msm-pcm-loopback-low-latency { + compatible = "qcom,msm-pcm-loopback"; + qcom,msm-pcm-loopback-low-latency; + }; + + qcom,msm-pcm-routing { + compatible = "qcom,msm-pcm-routing"; + }; + + qcom,msm-pcm-lpa { + compatible = "qcom,msm-pcm-lpa"; + }; + + qcom,msm-compr-dsp { + compatible = "qcom,msm-compr-dsp"; + }; + + qcom,msm-compress-dsp { + compatible = "qcom,msm-compress-dsp"; + }; + + qcom,msm-voip-dsp { + compatible = "qcom,msm-voip-dsp"; + }; + + qcom,msm-pcm-voice { + compatible = "qcom,msm-pcm-voice"; + qcom,destroy-cvd; + }; + + qcom,msm-pcm-voice { + compatible = "qcom,msm-pcm-voice"; + qcom,vote-bms; + }; + + qcom,msm-voice-host-pcm { + compatible = "qcom,msm-voice-host-pcm"; + }; + + qcom,msm-stub-codec { + compatible = "qcom,msm-stub-codec"; + }; + + qcom,msm-dai-fe { + compatible = "qcom,msm-dai-fe"; + }; + + qcom,msm-pcm-dtmf { + compatible = "qcom,msm-pcm-dtmf"; + }; + + qcom,msm-dai-stub { + compatible = "qcom,msm-dai-stub"; + }; + + qcom,msm-dai-q6-spdif { + compatible = "qcom,msm-dai-q6-spdif"; + }; + + qcom,msm-dai-q6-hdmi { + compatible = "qcom,msm-dai-q6-hdmi"; + qcom,msm-dai-q6-dev-id = <8>; + }; + + dai_dp: qcom,msm-dai-q6-dp { + compatible = "qcom,msm-dai-q6-hdmi"; + qcom,msm-dai-q6-dev-id = <24608>; + }; + + qcom,msm-dai-q6 { + compatible = "qcom,msm-dai-q6"; + qcom,msm-dai-q6-sb-0-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16384>; + }; + + qcom,msm-dai-q6-sb-0-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16385>; + }; + + qcom,msm-dai-q6-sb-1-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16386>; + }; + + qcom,msm-dai-q6-sb-1-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16387>; + }; + + qcom,msm-dai-q6-sb-3-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16390>; + }; + + qcom,msm-dai-q6-sb-3-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16391>; + }; + + qcom,msm-dai-q6-sb-4-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16392>; + }; + + qcom,msm-dai-q6-sb-4-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16393>; + }; + + qcom,msm-dai-q6-sb-5-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16395>; + }; + + qcom,msm-dai-q6-sb-6-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16396>; + }; + + qcom,msm-dai-q6-sb-6-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <16397>; + }; + + qcom,msm-dai-q6-bt-sco-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <12288>; + }; + + qcom,msm-dai-q6-bt-sco-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <12289>; + }; + + qcom,msm-dai-q6-int-fm-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <12292>; + }; + + qcom,msm-dai-q6-int-fm-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <12293>; + }; + + qcom,msm-dai-q6-be-afe-pcm-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <224>; + }; + + qcom,msm-dai-q6-be-afe-pcm-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <225>; + }; + + qcom,msm-dai-q6-afe-proxy-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <241>; + }; + + qcom,msm-dai-q6-afe-proxy-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <240>; + }; + + qcom,msm-dai-q6-incall-record-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <32771>; + }; + + qcom,msm-dai-q6-incall-record-tx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <32772>; + }; + + qcom,msm-dai-q6-incall-music-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <32773>; + }; + + qcom,msm-dai-q6-incall-music-2-rx { + compatible = "qcom,msm-dai-q6-dev"; + qcom,msm-dai-q6-dev-id = <32770>; + }; + }; + + qcom,msm-pri-auxpcm { + qcom,msm-cpudai-auxpcm-mode = <1>, <1>; + qcom,msm-cpudai-auxpcm-sync = <1>, <1>; + qcom,msm-cpudai-auxpcm-frame = <5>, <4>; + qcom,msm-cpudai-auxpcm-quant = <2>, <2>; + qcom,msm-cpudai-auxpcm-num-slots = <4>, <4>; + qcom,msm-cpudai-auxpcm-slot-mapping = <1 0 0 0>, <1 3 0 0>; + qcom,msm-cpudai-auxpcm-data = <0>, <0>; + qcom,msm-cpudai-auxpcm-pcm-clk-rate = <2048000>, <2048000>; + qcom,msm-auxpcm-interface = "primary"; + compatible = "qcom,msm-auxpcm-dev"; + pinctrl-names = "default", "idle"; + pinctrl-0 = <&pri_aux_pcm_active &pri_aux_pcm_din_active>; + pinctrl-1 = <&pri_aux_pcm_sleep &pri_aux_pcm_din_sleep>; + }; + + qcom,msm-pcm-hostless { + compatible = "qcom,msm-pcm-hostless"; + }; + + qcom,msm-ocmem-audio { + compatible = "qcom,msm-ocmem-audio"; + qcom,msm_bus,name = "audio-ocmem"; + qcom,msm_bus,num_cases = <2>; + qcom,msm_bus,active_only = <0>; + qcom,msm_bus,num_paths = <1>; + qcom,msm_bus,vectors = + <11 604 0 0>, + <11 604 32505856 325058560>; + }; + + wcd9xxx_intc: wcd9xxx-irq { + compatible = "qcom,wcd9xxx-irq"; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&msmgpio>; + interrupts = <72 0>; + interrupt-names = "cdc-int"; + }; + + clock_audio: audio_ext_clk { + compatible = "qcom,audio-ref-clk"; + qcom,audio-ref-clk-gpios = <&pm8994_gpios 15 0>; + clock-names = "osr_clk"; + clocks = <&clock_rpm clk_div_clk1>; + qcom,node_has_rpm_clock; + #clock-cells = <1>; + pinctrl-names = "sleep", "active"; + pinctrl-0 = <&spkr_i2s_clk_sleep>; + pinctrl-1 = <&spkr_i2s_clk_active>; + }; + + audio_slimslave { + compatible = "qcom,audio-slimslave"; + elemental-addr = [ff ff ff ff 17 02]; + }; + + msm_dai_slim { + compatible = "qcom,msm_dai_slim"; + elemental-addr = [ff ff ff fe 17 02]; + }; + + wcd_gpio_ctrl { + compatible = "qcom,msm-cdc-pinctrl"; + qcom,cdc-rst-n-gpio = <&tlmm 64 0>; + pinctrl-names = "aud_active", "aud_sleep"; + pinctrl-0 = <&cdc_reset_active>; + pinctrl-1 = <&cdc_reset_sleep>; + }; + + msm_cdc_pinctrl { + compatible = "qcom,msm-cdc-pinctrl"; + pinctrl-names = "aud_active", "aud_sleep"; + pinctrl-0 = <&cdc_reset_active>; + pinctrl-1 = <&cdc_reset_sleep>; + }; + + wcd_dsp_glink { + compatible = "qcom,wcd-dsp-glink"; + }; + + +* MSM8916 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8x16-audio-codec" +- qcom,model : The user-visible name of this sound card. +- qcom,msm-snd-card-id : This id is used to recognize the sound card number +- qcom,msm-codec-type : This property is used to recognize the codec type + internal or external. +- qcom,msm-hs-micbias-type : This property is used to recognize the headset + micbias type, internal or external. +- qcom,msm-ext-pa : This property is used to inform machine driver about + the connection of external PA over available MI2S interfaces, + following values can be given to this property. + primary -> Primary MI2S interface + secondary -> Secondary MI2S interface + tertiary -> Tertiary MI2S interface + quaternary -> Quaternary MI2S interface +- qcom,msm-mclk-freq : This property is used to inform machine driver about +mclk frequency needs to be configured for internal and external PA. +- qcom,msm-mbhc-hphl-swh: This property is used to distinguish headset HPHL +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,msm-mbhc-gnd-swh: This property is used to distinguish headset GND +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,audio-routing : A list of the connections between audio components. +- pinctrl-names : Pincntrl entries to configure the PDM gpio lines and + cross connection switch gpio accordingly +- pinctrl-0 : This explains the active state of the PDM gpio lines +- pinctrl-1 : This explains the suspend state of the PDM gpio lines +- pinctrl-2 : This explains the active state of the cross connection + gpio lines +- pinctrl-3 : This explains the suspend state of the cross connection + gpio lines +- qcom,tapan-mclk-clk-freq : Tapan mclk Freq in Hz. +- qcom,prim-auxpcm-gpio-clk : GPIO on which Primary AUXPCM clk signal is coming. +- qcom,prim-auxpcm-gpio-sync : GPIO on which Primary AUXPCM SYNC signal is coming. +- qcom,prim-auxpcm-gpio-din : GPIO on which Primary AUXPCM DIN signal is coming. +- qcom,prim-auxpcm-gpio-dout : GPIO on which Primary AUXPCM DOUT signal is coming. +- qcom,prim-auxpcm-gpio-set : set of GPIO lines used for Primary AUXPCM port +- qcom,tapan-codec-9302: Indicates that this device node is for WCD9302 audio + codec. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". + +Optional Properties: +- qcom,us-euro-gpios : GPIO on which gnd/mic swap signal is coming. + +Example: + + msm_dig_codec: qcom,msm-int-codec { + compatible = "qcom,msm_int_core_codec"; + qcom,dig-cdc-base-addr = <0xc0f0000>; + }; + + sound { + compatible = "qcom,msm8x16-audio-codec"; + qcom,model = "msm8x16-snd-card"; + qcom,msm-snd-card-id = <0>; + qcom,msm-codec-type = "internal"; + qcom,msm-ext-pa = <0>; + qcom,msm-mclk-freq = <12288000>; + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,msm-hs-micbias-type = "internal"; + qcom,cdc-us-euro-gpios = <&msmgpio 120 0>; + qcom,audio-routing = + "RX_BIAS", "MCLK", + "INT_LDO_H", "MCLK", + "MIC BIAS External", "Handset Mic", + "MIC BIAS Internal2", "Headset Mic", + "MIC BIAS External", "Secondary Mic", + "AMIC1", "MIC BIAS External", + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS External"; + pinctrl-names = "cdc_pdm_lines_act", + "cdc_pdm_lines_sus", + "cross_conn_det_act", + "cross_conn_det_sus"; + pinctrl-0 = <&cdc_pdm_lines_act>; + pinctrl-1 = <&cdc_pdm_lines_sus>; + pinctrl-2 = <&cross_conn_det_act>; + pinctrl-3 = <&cross_conn_det_sus>; + qcom,tapan-mclk-clk-freq = <9600000>; + qcom,prim-auxpcm-gpio-clk = <&msm_gpio 63 0>; + qcom,prim-auxpcm-gpio-sync = <&msm_gpio 64 0>; + qcom,prim-auxpcm-gpio-din = <&msm_gpio 65 0>; + qcom,prim-auxpcm-gpio-dout = <&msm_gpio 66 0>; + qcom,prim-auxpcm-gpio-set = "prim-gpio-prim"; + qcom,tapan-codec-9302; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&lpa>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", "msm-pcm-afe", + "msm-lsm-client", "msm-pcm-routing", "msm-pcm-lpa"; + asoc-cpu = <&dai_pri_auxpcm>, <&dai_hdmi>, <&dai_dp>, + <&dai_mi2s0>, <&dai_mi2s1>, <&dai_mi2s2>, <&dai_mi2s3>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_3_rx>, <&sb_3_tx>, <&sb_4_rx>, <&sb_4_tx>, + <&bt_sco_rx>, <&bt_sco_tx>, <&int_fm_rx>, <&int_fm_tx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-hdmi.8", + "msm-dai-q6-dp.24608", + "msm-dai-q6-mi2s.0", "msm-dai-q6-mi2s.1", + "msm-dai-q6-mi2s.2", "msm-dai-q6-mi2s.3", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.12288", "msm-dai-q6-dev.12289", + "msm-dai-q6-dev.12292", "msm-dai-q6-dev.12293", + "msm-dai-q6-dev.224", "msm-dai-q6-dev.225", + "msm-dai-q6-dev.241", "msm-dai-q6-dev.240", + "msm-dai-q6-dev.32771", "msm-dai-q6-dev.32772", + "msm-dai-q6-dev.32773", "msm-dai-q6-dev.32770"; + asoc-codec = <&stub>, <&pm8916_tombak_dig>; + asoc-codec-names = "msm-stub-codec.1", "tombak_codec"; + }; + +* MSM8974 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8974-audio-taiko" +- qcom,model : The user-visible name of this sound card. +- qcom,audio-routing : A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. +- qcom,cdc-mclk-gpios : GPIO on which mclk signal is coming. +- qcom,taiko-mclk-clk-freq : Taiko mclk Freq in Hz. currently only 9600000Hz + is supported. +- qcom,prim-auxpcm-gpio-clk : GPIO on which Primary AUXPCM clk signal is coming. +- qcom,prim-auxpcm-gpio-sync : GPIO on which Primary AUXPCM SYNC signal is coming. +- qcom,prim-auxpcm-gpio-din : GPIO on which Primary AUXPCM DIN signal is coming. +- qcom,prim-auxpcm-gpio-dout : GPIO on which Primary AUXPCM DOUT signal is coming. +- qcom,prim-auxpcm-gpio-set : set of GPIO lines used for Primary AUXPCM port + Possible Values: + prim-gpio-prim : Primary AUXPCM shares GPIOs with Primary MI2S + prim-gpio-tert : Primary AUXPCM shares GPIOs with Tertiary MI2S +- qcom,sec-auxpcm-gpio-clk : GPIO on which Secondary AUXPCM clk signal is coming. +- qcom,sec-auxpcm-gpio-sync : GPIO on which Secondary AUXPCM SYNC signal is coming. +- qcom,sec-auxpcm-gpio-din : GPIO on which Secondary AUXPCM DIN signal is coming. +- qcom,sec-auxpcm-gpio-dout : GPIO on which Secondary AUXPCM DOUT signal is coming. +- qcom,us-euro-gpios : GPIO on which gnd/mic swap signal is coming. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- reg : Offset and length of the register region(s) for MI2S/PCM MUX. + Not applicable for all targets. +- reg-names : Register region name(s) referenced in reg above. + Not applicable for all targets. + Required register resource entries are: + "lpaif_pri_mode_muxsel": Physical address of MUX to select between + Primary PCM and Primary MI2S + "lpaif_sec_mode_muxsel": Physical address of MUX to select between + Secondary PCM and Secondary MI2S + "lpaif_tert_mode_muxsel": Physical address of MUX to select between + Primary PCM and Tertiary MI2S + "lpaif_quat_mode_muxsel": Physical address of MUX to select between + Secondary PCM and Quarternary MI2S +- qcom,hdmi-audio-rx: specifies if HDMI audio support is enabled or not. +- qcom,ext-ult-spk-amp-gpio : GPIO for enabling of speaker path amplifier. + +- qcom,ext-ult-lo-amp-gpio: GPIO to enable external ultrasound lineout + amplifier. + +- qcom,headset-jack-type-NO: Adjust GPIO level based on the headset jack type. +- qcom,tapan-codec-9302: Indicates that this device node is for WCD9302 audio + codec. +- qcom,mbhc-bias-internal: Flag to indicate if internal micbias should be used + for headset detection. +- qcom,dock-plug-det-irq: Interrupt line to detect Docking/Undocking of Liquid + device +- qcom,ext-spk-rear-panel-irq: Interrupt line to detect rear panel speakers + jack for Dragon Board. +- qcom,ext-spk-front-panel-irq: Interrupt line to detect front panel speakers + jack for Dragon Board. +- qcom,ext-mic-front-panel-irq: Interrupt line to detect front panel microphone + jack for Dragon Board. +- qcom,mbhc-audio-jack-type : String to indicate the jack type on the hardware. + Possible Values: + 4-pole-jack : Jack on the hardware is 4-pole. + 5-pole-jack : Jack on the hardware is 5-pole. + 6-pole-jack : Jack on the hardware is 6-pole. + +* APQ8074 ASoC Machine driver + +Required properties: +- compatible : "qcom,apq8074-audio-taiko" + +Example: + +sound { + compatible = "qcom,msm8974-audio-taiko"; + qcom,model = "msm8974-taiko-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "HEADPHONE", "LDO_H", + "Ext Spk Bottom Pos", "LINEOUT1", + "Ext Spk Bottom Neg", "LINEOUT3", + "Ext Spk Top Pos", "LINEOUT2", + "Ext Spk Top Neg", "LINEOUT4", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS3 Internal1", + "MIC BIAS3 Internal1", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS1 Internal2", + "MIC BIAS1 Internal2", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + qcom,cdc-mclk-gpios = <&pm8941_gpios 15 0>; + qcom,taiko-mclk-clk-freq = <9600000>; + qcom,us-euro-gpios = <&pm8941_gpios 20 0>; + + qcom,hdmi-audio-rx; + qcom,ext-ult-lo-amp-gpio = <&pm8941_gpios 6 0>; + + qcom,ext-mclk-gpio = <&msmgpio 47 0>; + qcom,dock-plug-det-irq = <&pm8841_mpps 2 0>; + qcom,prim-auxpcm-gpio-clk = <&msmgpio 65 0>; + qcom,prim-auxpcm-gpio-sync = <&msmgpio 66 0>; + qcom,prim-auxpcm-gpio-din = <&msmgpio 67 0>; + qcom,prim-auxpcm-gpio-dout = <&msmgpio 68 0>; + qcom,prim-auxpcm-gpio-set = "prim-gpio-prim"; + qcom,sec-auxpcm-gpio-clk = <&msmgpio 79 0>; + qcom,sec-auxpcm-gpio-sync = <&msmgpio 80 0>; + qcom,sec-auxpcm-gpio-din = <&msmgpio 81 0>; + qcom,sec-auxpcm-gpio-dout = <&msmgpio 82 0>; + qcom,mbhc-audio-jack-type = "4-pole-jack"; +}; + +* msm-dai-mi2s + +[First Level Nodes] + +Required properties: + + - compatible : "msm-dai-mi2s" + + [Second Level Nodes] + +Required properties: + + - compatible : "qcom,msm-dai-q6-mi2s" + - qcom,msm-dai-q6-mi2s-dev-id: MSM or MDM can use Slimbus or I2S interface to + transfer data to (WCD9XXX) codec. + If slimbus interface is used then "msm-dai-q6" + needs to be filled with correct data for + slimbus interface. + The sections "msm-dai-mi2s" is used by MDM or + MSM to use I2S interface with codec. + This section is used by CPU driver in ASOC MSM + to configure MI2S interface. MSM internally + has multiple MI2S namely Primary, Secondary, + Tertiary and Quaternary MI2S. + They are represented with id 0, 1, 2, 3 + respectively. + The field "qcom,msm-dai-q6-mi2s-dev-id" + represents which of the MI2S block is used. + These MI2S are connected to I2S interface. + + - qcom,msm-mi2s-rx-lines: Each MI2S interface in MSM has one or more SD + lines. These lines are used for data transfer + between codec and MSM. + This element in indicates which output RX lines + are used in the MI2S interface. + + - qcom,msm-mi2s-tx-lines: Each MI2S interface in MSM has one or more SD + lines. These lines are used for data transfer + between codec and MSM. + This element in indicates which input TX lines + are used in the MI2S interface. + +Optional properties: + +- pinctrl-names: Pinctrl state names for each pin group + configuration. +- pinctrl-x: Defines pinctrl state for each pin group + +Example: + +qcom,msm-dai-mi2s { + compatible = "qcom,msm-dai-mi2s"; + qcom,msm-dai-q6-mi2s-prim { + compatible = "qcom,msm-dai-q6-mi2s"; + qcom,msm-dai-q6-mi2s-dev-id = <0>; + qcom,msm-mi2s-rx-lines = <2>; + qcom,msm-mi2s-tx-lines = <1>; + pinctrl-names = "default", "idle"; + pinctrl-0 = <&tert_mi2s_active &tert_mi2s_sd0_active>; + pinctrl-1 = <&tert_mi2s_sleep &tert_mi2s_sd0_sleep>; + }; +}; + +* msm-adsp-loader + +Required properties: + - compatible : "qcom,adsp-loader" + - qcom,adsp-state: + It is possible that some MSM use PIL to load the ADSP image. While + other MSM may use SBL to load the ADSP image at boot. Audio APR needs + state of ADSP to register and enable APR to be used for sending commands + to ADSP. so adsp-state represents the state of ADSP to ADSP loader. + Value of 0 indicates ADSP loader needs to use PIL and value of 2 means + ADSP image is already loaded by SBL. + +Optional properties: + - qcom,proc-img-to-load; + This property can be used to override default ADSP + loading by PIL. Based on string input, different proc is + loaded. Right now we are adding option "modem" + for 8916 purpose. Default image will be "adsp" which + will load LPASS Q6 for other targets as expected. + "adsp" option need not be explicitly mentioned in + DTSI file, as it is default option. + +Example: + +qcom,msm-adsp-loader { + compatible = "qcom,adsp-loader"; + qcom,adsp-state = <2>; + qcom,proc-img-to-load = "modem"; +}; + +* msm-audio-ion + +Required properties: + - compatible : "qcom,msm-audio-ion" + +Optional properties: + - qcom,smmu-version: + version ID to provide info regarding smmu version + used in chipset. If ARM SMMU HW - use id value as 1, + If QSMMU HW - use id value as 2. + + - qcom,smmu-enabled: + It is possible that some MSM have SMMU in ADSP. While other MSM use + no SMMU. Audio lib introduce wrapper for ION APIs. The wrapper needs + presence of SMMU in ADSP to handle ION APIs differently. + Presence of this property means ADSP has SMMU in it. + - iommus: + A phandle parsed by smmu driver. Number of entries will vary across + targets. + +Example: + +qcom,msm-audio-ion { + compatible = "qcom,msm-audio-ion; + qcom,smmu-enabled; +}; + +* MSM8994 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8994-audio-tomtom" +- qcom,model : The user-visible name of this sound card. +- clock-names : clock name defined for external clock. +- clocks : external clock defined for codec clock. +- pinctrl-names : pinctrl state names for each pin group configuration. +- pinctrl-x : defines pinctrl state for each pin group +- qcom,ext-ult-spk-amp-gpio : GPIO to enable ultrasound emitter amp. +- qcom,mbhc-audio-jack-type : Indicates headset jack type. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". + +Example: + + sound { + compatible = "qcom,msm8994-asoc-snd"; + qcom,model = "msm8994-tomtom-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AIF4 MAD", "MCLK", + "ultrasound amp", "LINEOUT1", + "ultrasound amp", "LINEOUT3", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + clock-names = "osr_clk"; + clocks = <&clock_rpm clk_div_clk1>; + pinctrl-names= "mi2s-sleep", + "mi2s-active", + "auxpcm-sleep", + "auxpcm-active"; + pinctrl-0 = <&pri_mi2s_sleep>; + pinctrl-1 = <&pri_mi2s_active>; + pinctrl-2 = <&sec_aux_pcm_sleep>; + pinctrl-3 = <&sec_aux_pcm_active>; + qcom,ext-ult-spk-amp-gpio = <&pmi8994_gpios 1 0>; + qcom,mbhc-audio-jack-type = "6-pole-jack"; + asoc-platform = <&pcm0>,<&pcm1>,<&pcm2>,<&voip>,<&voice>, + <&loopback>,<&compress>,<&hostless>, + <&afe>,<&lsm>,<&routing>,<&cpe>,<&compr>; + asoc-platform-names = "msm-pcm-dsp.0","msm-pcm-dsp.1","msm-pcm-dsp.2", + "msm-voip-dsp","msm-pcm-voice","msm-pcm-loopback", + "msm-compress-dsp","msm-pcm-hostless","msm-pcm-afe", + "msm-lsm-client","msm-pcm-routing", "msm-cpe-lsm", + "msm-compr-dsp"; + asoc-cpu = <&dai_pri_auxpcm>,<&dai_sec_auxpcm>,<&dai_hdmi>,<&dai_mi2s>, + <&sb_0_rx>,<&sb_0_tx>,<&sb_1_rx>,<&sb_1_tx>, + <&sb_2_rx>,<&sb_2_tx>,<&sb_3_rx>,<&sb_3_tx>, + <&sb_4_rx>,<&sb_4_tx>,<&sb_5_tx>,<&bt_sco_rx>, + <&bt_sco_tx>,<&int_fm_rx>,<&int_fm_tx>,<&afe_pcm_rx>, + <&afe_pcm_tx>,<&afe_proxy_rx>,<&afe_proxy_tx>, + <&incall_record_rx>,<&incall_record_tx>,<&incall_music_rx>, + <&incall_music2_rx>,<&dai_dp>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1","msm-dai-q6-auxpcm.2", + "msm-dai-q6-hdmi.8","msm-dai-q6-mi2s.0", + "msm-dai-q6-dev.16384","msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386","msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16388","msm-dai-q6-dev.16389", + "msm-dai-q6-dev.16390","msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392","msm-dai-q6-dev.16393", + "msm-dai-q6-dev.16395","msm-dai-q6-dev.12288", + "msm-dai-q6-dev.12289","msm-dai-q6-dev.12292", + "msm-dai-q6-dev.12293","msm-dai-q6-dev.224", + "msm-dai-q6-dev.225","msm-dai-q6-dev.241", + "msm-dai-q6-dev.240","msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772","msm-dai-q6-dev.32773", + "msm-dai-q6-dev.32770","msm-dai-q6-dp.24608"; + asoc-codec = <&stub>; + asoc-codec-names = "msm-stub-codec.1"; + }; + +* msm-dai-tdm + +[First Level Nodes] + +Required properties: + + - compatible : "qcom,msm-dai-tdm" + - qcom,msm-cpudai-tdm-group-id: ID of the group device. TDM interface + supports up to 8 groups: + Primary RX: 37120 + Primary TX: 37121 + Secondary RX: 37136 + Secondary TX: 37137 + Tertiary RX: 37152 + Tertiary TX: 37153 + Quaternary RX: 37168 + Quaternary TX: 37169 + + - qcom,msm-cpudai-tdm-group-num-ports: Number of ports in + msm-cpudai-tdm-group-port-id array. + Max number of ports supported by DSP is 8. + + - qcom,msm-cpudai-tdm-group-port-id: Array of TDM port IDs of the group. + The size of the array is determined by + the value in msm-cpudai-tdm-group-num-ports. + Each group supports up to 8 ports: + Primary RX: 36864, 36866, 36868, 36870, + 36872, 36874, 36876, 36878 + Primary TX: 36865, 36867, 36869, 36871, + 36873, 36875, 36877, 36879 + Secondary RX: 36880, 36882, 36884, 36886, + 36888, 36890, 36892, 36894 + Secondary TX: 36881, 36883, 36885, 36887, + 36889, 36891, 36893, 36895 + Tertiary RX: 36896, 36898, 36900, 36902, + 36904, 36906, 36908, 36910 + Tertiary TX: 36897, 36899, 36901, 36903, + 36905, 36907, 36909, 36911 + Quaternary RX: 36912, 36914, 36916, 36918, + 36920, 36922, 36924, 36926 + Quaternary TX: 36913, 36915, 36917, 36919, + 36921, 36923, 36925, 36927 + + - qcom,msm-cpudai-tdm-clk-rate: Clock rate for tdm - 12288000. + When clock rate is set to zero, + then external clock is assumed. + + [Second Level Nodes] + +Required properties: + + - compatible : "qcom,msm-dai-q6-tdm" + - qcom,msm-dai-q6-mi2s-dev-id: TDM port ID. + + - qcom,msm-cpudai-tdm-sync-mode: Synchronization setting. + 0 - Short sync bit mode + 1 - Long sync mode + 2 - Short sync slot mode + + - qcom,msm-cpudai-tdm-sync-src: Synchronization source. + 0 - External source + 1 - Internal source + + - qcom,msm-cpudai-tdm-data-out: Data out signal to drive with other masters. + 0 - Disable + 1 - Enable + + - qcom,msm-cpudai-tdm-invert-sync: Invert the sync. + 0 - Normal + 1 - Invert + + - qcom,msm-cpudai-tdm-data-delay: Number of bit clock to delay data + with respect to sync edge. + 0 - 0 bit clock cycle + 1 - 1 bit clock cycle + 2 - 2 bit clock cycle + + - qcom,msm-cpudai-tdm-data-align: Indicate how data is packed + within the slot. For example, 32 slot width in case of + sample bit width is 24. + 0 - MSB + 1 - LSB + +Optional properties: + + - qcom,msm-cpudai-tdm-header-start-offset: TDM Custom header start offset + in bytes from this sub-frame. The bytes is counted from 0. + 0 is mapped to the 1st byte in or out of + the digital serial data line this sub-frame belong to. + Supported value: 0, 4, 8. + + - qcom,msm-cpudai-tdm-header-width: Header width per frame followed. + 2 bytes for MOST/TDM case. + Supported value: 2. + + - qcom,msm-cpudai-tdm-header-num-frame-repeat: Number of header followed. + Supported value: 8. + + - pinctrl-names: Pinctrl state names for each pin group + configuration. + + - pinctrl-x: Defines pinctrl state for each pin group. + +Example: + + qcom,msm-dai-tdm-quat-rx { + compatible = "qcom,msm-dai-tdm"; + qcom,msm-cpudai-tdm-group-id = <37168>; + qcom,msm-cpudai-tdm-group-num-ports = <1>; + qcom,msm-cpudai-tdm-group-port-id = <36912>; + qcom,msm-cpudai-tdm-clk-rate = <12288000>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&quat_tdm_active &quat_tdm_dout_active>; + pinctrl-1 = <&quat_tdm_sleep &quat_tdm_dout_sleep>; + dai_quat_tdm_rx_0: qcom,msm-dai-q6-tdm-quat-rx-0 { + compatible = "qcom,msm-dai-q6-tdm"; + qcom,msm-cpudai-tdm-dev-id = <36912>; + qcom,msm-cpudai-tdm-sync-mode = <0>; + qcom,msm-cpudai-tdm-sync-src = <1>; + qcom,msm-cpudai-tdm-data-out = <0>; + qcom,msm-cpudai-tdm-invert-sync = <0>; + qcom,msm-cpudai-tdm-data-delay = <0>; + qcom,msm-cpudai-tdm-data-align = <0>; + qcom,msm-cpudai-tdm-header-start-offset = <0>; + qcom,msm-cpudai-tdm-header-width = <2>; + qcom,msm-cpudai-tdm-header-num-frame-repeat = <8>; + }; + }; + +* MSM8996 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8996-asoc-snd-tomtom" for tomtom codec and + node is "sound" and "qcom,msm8996-asoc-snd-tasha" + for tasha codec and node is "sound-9335" +- qcom,model : The user-visible name of this sound card. +- qcom,tomtom-mclk-clk-freq : MCLK frequency value for tomtom codec + and node is "sound" +- qcom,tasha-mclk-clk-freq : MCLK frequency value for tasha codec + and node is "sound-9335" +- qcom,audio-routing : A list of the connections between audio components. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- qcom,ext-ult-spk-amp-gpio : GPIO to enable ultrasound emitter amp. +- qcom,mbhc-audio-jack-type : String to indicate the jack type on the hardware. + Possible Values: + 4-pole-jack : Jack on the hardware is 4-pole. + 5-pole-jack : Jack on the hardware is 5-pole. + 6-pole-jack : Jack on the hardware is 6-pole. +- clock-names : clock name defined for external clock. +- clocks : external clock defined for codec clock. +- qcom,hph-en1-gpio : GPIO to enable HiFi amplifiers. +- qcom,hph-en0-gpio : GPIO to enable HiFi audio route to headset. +- qcom,wsa-max-devs : Maximum number of WSA881x devices present in the target +- qcom,wsa-devs : List of phandles for all possible WSA881x devices supported for the target +- qcom,wsa-aux-dev-prefix : Name prefix with Left/Right configuration for WSA881x device + +Example: + + sound { + compatible = "qcom,msm8996-asoc-snd"; + qcom,model = "msm8996-tomtom-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AIF4 MAD", "MCLK", + "ultrasound amp", "LINEOUT1", + "ultrasound amp", "LINEOUT3", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + clock-names = "osr_clk"; + clocks = <&clock_rpm clk_div_clk1>; + qcom,mbhc-audio-jack-type = "6-pole-jack"; + asoc-platform = <&pcm0>, <&pcm1>, <&pcm2>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&cpe>, <&compr>, <&cpe3>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", "msm-pcm-dsp.2", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", "msm-pcm-afe", + "msm-lsm-client", "msm-pcm-routing", "msm-cpe-lsm", + "msm-compr-dsp", "msm-cpe-lsm.3"; + asoc-cpu = <&dai_pri_auxpcm>, <&dai_sec_auxpcm>, <&dai_hdmi>, <&dai_mi2s>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_2_rx>, <&sb_2_tx>, <&sb_3_rx>, <&sb_3_tx>, + <&sb_4_rx>, <&sb_4_tx>, <&sb_5_tx>, <&afe_pcm_rx>, + <&afe_pcm_tx>, <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, + <&incall_music_rx>, <&incall_music2_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-auxpcm.2", + "msm-dai-q6-hdmi.8", "msm-dai-q6-mi2s.2", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16388", "msm-dai-q6-dev.16389", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.16395", "msm-dai-q6-dev.224", + "msm-dai-q6-dev.225", "msm-dai-q6-dev.241", + "msm-dai-q6-dev.240", "msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772", "msm-dai-q6-dev.32773", + "msm-dai-q6-dev.32770"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,wsa-max-devs = <2>; + qcom,wsa-devs = <&wsa881x_211>, <&wsa881x_212>, + <&wsa881x_213>, <&wsa881x_214>; + qcom,wsa-aux-dev-prefix = "SpkrRight", "SpkrLeft", + "SpkrRight", "SpkrLeft"; + }; + +* MSM8952 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8952-audio-codec" +- qcom,model : The user-visible name of this sound card. +- reg : Offset and length of the register region(s) for MI2S/PCM MUX +- reg-names : Register region name(s) referenced in reg above + Required register resource entries are: + "csr_gp_io_mux_mic_ctl": Physical address of MUX that controls + controls LPA IF tertiary, quad, PCM0, Digital Codec + and Secondary TLMM mux setting for mic path operation. + "csr_gp_io_mux_spkr_ctl": Physical address of MUX that controls + IF primary, secondary, Digital Codec and Primary TLMM + setting for speaker path operation. + "csr_gp_io_lpaif_pri_pcm_pri_mode_muxsel": Physical address of MUX + that controls the mux between LPA IF Quad and PCM0 + path to secondary TLMM +- qcom,msm-hs-micbias-type : This property is used to recognize the headset + micbias type, internal or external. +- qcom,msm-ext-pa : This property is used to inform machine driver about + the connection of external PA over available MI2S interfaces, + following values can be given to this property. + primary -> Primary MI2S interface + secondary -> Secondary MI2S interface + tertiary -> Tertiary MI2S interface + quaternary -> Quaternary MI2S interface +- qcom,msm-mbhc-hphl-swh: This property is used to distinguish headset HPHL +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,msm-mbhc-gnd-swh: This property is used to distinguish headset GND +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,audio-routing : A list of the connections between audio components. +- qcom,msm-gpios : Lists down all the gpio sets that are supported. +- qcom,pinctrl-names : Lists all the possible combinations of the gpio sets +mentioned in qcom,msm-gpios. +- pinctrl-names : The combinations of gpio sets from above that are supported in +the flavor. +- pinctrl-# : Pinctrl states as mentioned in pinctrl-names. + +Optional properties: +- qcom,prim-auxpcm-gpio-clk : GPIO on which Primary AUXPCM clk signal is coming. +- qcom,prim-auxpcm-gpio-sync : GPIO on which Primary AUXPCM SYNC signal is coming. +- qcom,prim-auxpcm-gpio-din : GPIO on which Primary AUXPCM DIN signal is coming. +- qcom,prim-auxpcm-gpio-dout : GPIO on which Primary AUXPCM DOUT signal is coming. +- qcom,prim-auxpcm-gpio-set : set of GPIO lines used for Primary AUXPCM port +- qcom,cdc-us-euro-gpios : GPIO on which gnd/mic swap signal is coming. +- qcom,msm-micbias1-ext-cap : Boolean. Enable micbias1 external +capacitor mode. +- qcom,msm-micbias2-ext-cap : Boolean. Enable micbias2 external +capacitor mode. +- qcom,msm-spk-ext-pa : GPIO which enables external speaker pa. + +To Configure External Audio Switch +- qcom,msm-ext-audio-switch : GPIO which controls external switch that switches + audio path between headset and speakers. +- ext-switch-vdd-supply : Power supply that control external audio switch +- qcom,ext-switch-vdd-voltage : Minimum and maximum voltage in uV to set for + power supply. +- qcom,ext-switch-vdd-op-mode : Maxmum # of uA current the switch will draw + from the power supply. +Example: + qcom,msm-ext-audio-switch = <&msm_gpio 2 0>; - gpio # and active_state + ext-switch-vdd-supply = <&pm8950_l13>; - Power Rail + qcom,ext-switch-vdd-voltage = <3075000 3075000>; - Min, Max uV voltage + qcom,ext-switch-vdd-op-mode = <5000>; - Operational current uA + Additional needs to add two additional qcom,audio-routings + "HEADPHONE", "VDD_EXT_AUDIO_SWITCH" + "SPK_OUT", "VDD_EXT_AUDIO_SWITCH" + +- qcom,msm-mclk-freq : This property is used to inform machine driver about +mclk frequency needs to be configured for internal and external PA. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +- asoc-wsa-codec-names: This property contains list of wsa codec names. The names + should comply with the wsa nodes configurations. +- asoc-wsa-codec-prefixes: This property contains list of wsa codec prefixes. +- msm-vdd-wsa-switch-supply: WSA codec supply's regulator device tree node. +- qcom,msm-vdd-wsa-switch-voltage: WSA codec supply's voltage level in mV. +- qcom,msm-vdd-wsa-switch-current: WSA codec max current level in mA. + +Example: + sound { + compatible = "qcom,msm8952-audio-codec"; + qcom,model = "msm8952-snd-card"; + reg = <0xc051000 0x4>, + <0xc051004 0x4>, + <0xc055000 0x4>; + reg-names = "csr_gp_io_mux_mic_ctl", + "csr_gp_io_mux_spkr_ctl", + "csr_gp_io_lpaif_pri_pcm_pri_mode_muxsel"; + qcom,msm-ext-pa = "primary"; + qcom,msm-mclk-freq = <9600000>; + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,msm-hs-micbias-type = "internal"; + qcom,msm-micbias1-ext-cap; + qcom,audio-routing = + "RX_BIAS", "MCLK", + "SPK_RX_BIAS", "MCLK", + "INT_LDO_H", "MCLK", + "MIC BIAS External", "Handset Mic", + "MIC BIAS Internal2", "Headset Mic", + "MIC BIAS External", "Secondary Mic", + "AMIC1", "MIC BIAS External", + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS External"; + qcom,msm-gpios = + "pri_i2s", + "us_eu_gpio"; + qcom,pinctrl-names = + "all_off", + "pri_i2s_act", + "us_eu_gpio_act", + "pri_i2s_us_eu_gpio_act"; + pinctrl-names = + "all_off", + "pri_i2s_act", + "us_eu_gpio_act", + "pri_i2s_us_eu_gpio_act"; + pinctrl-0 = <&cdc_pdm_lines_sus &cdc_pdm_lines_2_sus &cross_conn_det_sus>; + pinctrl-1 = <&cdc_pdm_lines_act &cdc_pdm_lines_2_act &cross_conn_det_sus>; + pinctrl-2 = <&cdc_pdm_lines_sus &cdc_pdm_lines_2_sus &cross_conn_det_act>; + pinctrl-3 = <&cdc_pdm_lines_act &cdc_pdm_lines_2_act &cross_conn_det_act>; + qcom,cdc-us-euro-gpios = <&msm_gpio 63 0>; + qcom,prim-auxpcm-gpio-clk = <&msm_gpio 63 0>; + qcom,prim-auxpcm-gpio-sync = <&msm_gpio 64 0>; + qcom,prim-auxpcm-gpio-din = <&msm_gpio 65 0>; + qcom,prim-auxpcm-gpio-dout = <&msm_gpio 66 0>; + qcom,prim-auxpcm-gpio-set = "prim-gpio-prim"; + qcom,tapan-codec-9302; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&lpa>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", "msm-pcm-afe", + "msm-lsm-client", "msm-pcm-routing", "msm-pcm-lpa"; + asoc-cpu = <&dai_pri_auxpcm>, <&dai_hdmi>, + <&dai_mi2s0>, <&dai_mi2s1>, <&dai_mi2s2>, <&dai_mi2s3>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_3_rx>, <&sb_3_tx>, <&sb_4_rx>, <&sb_4_tx>, + <&bt_sco_rx>, <&bt_sco_tx>, <&int_fm_rx>, <&int_fm_tx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-hdmi.8", + "msm-dai-q6-mi2s.0", "msm-dai-q6-mi2s.1", + "msm-dai-q6-mi2s.2", "msm-dai-q6-mi2s.3", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.12288", "msm-dai-q6-dev.12289", + "msm-dai-q6-dev.12292", "msm-dai-q6-dev.12293", + "msm-dai-q6-dev.224", "msm-dai-q6-dev.225", + "msm-dai-q6-dev.241", "msm-dai-q6-dev.240", + "msm-dai-q6-dev.32771", "msm-dai-q6-dev.32772", + "msm-dai-q6-dev.32773", "msm-dai-q6-dev.32770"; + asoc-codec = <&stub>, <&pm8916_tombak_dig>; + asoc-codec-names = "msm-stub-codec.1", "tombak_codec"; + asoc-wsa-codec-names = "wsa881x-i2c-codec.8-000f"; + asoc-wsa-codec-prefixes = "SpkrMono"; + }; + +* SDM660 ASoC Machine driver + +Required properties: +- compatible : "qcom,sdm660-asoc-snd" +- qcom,model : The user-visible name of this sound card. +- qcom,msm-hs-micbias-type : This property is used to recognize the headset + micbias type, internal or external. +- qcom,msm-mbhc-hphl-swh: This property is used to distinguish headset HPHL +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,msm-mbhc-gnd-swh: This property is used to distinguish headset GND +switch type on target typically the switch type will be normally open or +normally close, value for this property 0 for normally close and 1 for +normally open. +- qcom,audio-routing : A list of the connections between audio components. +- qcom,msm-gpios : Lists down all the gpio sets that are supported. +- qcom,pinctrl-names : Lists all the possible combinations of the gpio sets +mentioned in qcom,msm-gpios. +- pinctrl-names : The combinations of gpio sets from above that are supported in +the flavor. +- pinctrl-# : Pinctrl states as mentioned in pinctrl-names. + +Optional properties: +- qcom,cdc-us-euro-gpios : GPIO on which gnd/mic swap signal is coming. +- qcom,msm-micbias1-ext-cap : Boolean. Enable micbias1 external +capacitor mode. +- qcom,msm-micbias2-ext-cap : Boolean. Enable micbias2 external +capacitor mode. +- qcom,wsa-disable : Boolean. Disables WSA speaker dailinks from sound node. +- qcom,msm-spk-ext-pa : GPIO which enables external speaker pa. +- qcom,msm-mclk-freq : This property is used to inform machine driver about +mclk frequency needs to be configured for internal and external PA. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +- qcom,wsa-max-devs : Maximum number of WSA881x devices present in the target +- qcom,wsa-devs : List of phandles for all possible WSA881x devices supported for the target +- qcom,wsa-aux-dev-prefix : Name prefix with Left/Right configuration for WSA881x device +- qcom,cdc-pdm-gpios : phandle for pdm gpios. +- qcom,cdc-comp-gpios : phandle for compander gpios. +- qcom,cdc-dmic-gpios : phandle for Digital mic clk and data gpios. +- qcom,cdc-sdw-gpios : phandle for soundwire clk and data gpios. +- qcom,msm-mbhc-moist-cfg: This property is used to set moisture detection + threshold values for different codecs. First parameter is V(voltage) + second one is i(current), third one is r (resistance). Depending on the + codec set corresponding element in array and set others to 0. + +Example: + sound { + compatible = "qcom,sdm660-asoc-snd"; + qcom,model = "sdm660-snd-card"; + qcom,msm-mclk-freq = <9600000>; + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,wsa-disable; + qcom,msm-mbhc-moist-cfg = <1>, <3>, <0>; + qcom,msm-hs-micbias-type = "internal"; + qcom,msm-micbias1-ext-cap; + qcom,audio-routing = + "RX_BIAS", "MCLK", + "SPK_RX_BIAS", "MCLK", + "INT_LDO_H", "MCLK", + "MIC BIAS External", "Handset Mic", + "MIC BIAS Internal2", "Headset Mic", + "MIC BIAS External", "Secondary Mic", + "AMIC1", "MIC BIAS External", + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS External"; + qcom,cdc-us-euro-gpios = <&msm_gpio 63 0>; + qcom,cdc-pdm-gpios = <&cdc_pdm_gpios>; + qcom,cdc-comp-gpios = <&cdc_comp_gpios>; + qcom,cdc-dmic-gpios = <&cdc_dmic_gpios>; + qcom,cdc-sdw-gpios = <&cdc_sdw_gpios>; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&lpa>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", "msm-pcm-afe", + "msm-lsm-client", "msm-pcm-routing", "msm-pcm-lpa"; + asoc-cpu = <&dai_pri_auxpcm>, <&dai_hdmi>, + <&dai_mi2s0>, <&dai_mi2s1>, <&dai_mi2s2>, <&dai_mi2s3>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_3_rx>, <&sb_3_tx>, <&sb_4_rx>, <&sb_4_tx>, + <&bt_sco_rx>, <&bt_sco_tx>, <&int_fm_rx>, <&int_fm_tx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-hdmi.8", + "msm-dai-q6-mi2s.0", "msm-dai-q6-mi2s.1", + "msm-dai-q6-mi2s.2", "msm-dai-q6-mi2s.3", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.12288", "msm-dai-q6-dev.12289", + "msm-dai-q6-dev.12292", "msm-dai-q6-dev.12293", + "msm-dai-q6-dev.224", "msm-dai-q6-dev.225", + "msm-dai-q6-dev.241", "msm-dai-q6-dev.240", + "msm-dai-q6-dev.32771", "msm-dai-q6-dev.32772", + "msm-dai-q6-dev.32773", "msm-dai-q6-dev.32770"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,wsa-max-devs = <2>; + qcom,wsa-devs = <&wsa881x_211>, <&wsa881x_212>, + <&wsa881x_213>, <&wsa881x_214>; + qcom,wsa-aux-dev-prefix = "SpkrRight", "SpkrLeft", + "SpkrRight", "SpkrLeft"; + }; + +* MSM8952 Slimbus ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8952-audio-slimbus-codec" +- qcom,model : The user-visible name of this sound card. +- qcom,pinctrl-names : Lists all the possible combinations of the gpio sets +mentioned in qcom,msm-gpios. Say we have 2^N combinations for N GPIOs, +this would list all the 2^N combinations. +- pinctrl-names : The combinations of gpio sets from above that are supported in +the flavor. This can be sometimes same as qcom, pinctrl-names i.e with 2^N +combinations or will have less incase if some combination is not supported. +- pinctrl-# : Pinctrl states as mentioned in pinctrl-names. +- reg : Offset and length of the register region(s) for MI2S/PCM MUX +- reg-names : Register region name(s) referenced in reg above + Required register resource entries are: + "csr_gp_io_mux_mic_ctl": Physical address of MUX that controls + controls LPA IF tertiary, quad, PCM0, Digital Codec + and Secondary TLMM mux setting for mic path operation. + "csr_gp_io_mux_spkr_ctl": Physical address of MUX that controls + IF primary, secondary, Digital Codec and Primary TLMM + setting for speaker path operation. +- qcom,cdc-mclk-gpios : GPIO on which mclk signal is coming. +- clock-names : clock name defined for external clock. +- qcom,audio-routing : A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. + +Optional Properties: +- qcom,cdc-us-euro-gpios : GPIO on which gnd/mic swap signal is coming. +- qcom,cdc-vdd-spkr-gpios : GPIO which controls PA for VDD speaker +- qcom,headset-jack-type-NC: Set if the headset jack type is NC (Normally Closed) +- qcom,tomtom-mclk-clk-freq : Tapan mclk Freq in Hz. currently only 9600000Hz + is supported. +- qcom,msm-ext-pa : This property is used to inform machine driver about + the connection of external PA over available MI2S interfaces, + following values can be given to this property. + primary -> Primary MI2S interface + secondary -> Secondary MI2S interface + tertiary -> Tertiary MI2S interface + quaternary -> Quaternary MI2S interface +- qcom,mi2s-audio-intf: This property is used to inform machine driver + if mi2s backend dailink has to be added as part of the sound card dai-links. +- qcom,auxpcm-audio-intf: This property is used to inform machine driver + if auxpcm backend dailink has to be added as part of the sound card dai-links. +- qcom,msm-mi2s-master: This property is used to inform machine driver + if MSM is the clock master of mi2s. 1 means master and 0 means slave. The + first entry is primary mi2s; the second entry is secondary mi2s, and so on. +- qcom,msm-mi2s-ext-mclk: This property is used to inform machine driver + if MCLK from MSM is used for any external audio connections. 1 means used + as external mclk source and 0 indicate not used. The first entry is + primary mclk; the second entry is secondary mclk, and so on. +- reg: This property provides the AUX PCM/MI2S mux select register addresses + and size. +- reg_names: This property provides the name of the AUX PCM/MI2S mux select + registers so the machine driver can retrieve the addresses. The order of the + names has to match the order of the registers in "reg" property. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +- asoc-wsa-codec-names: This property contains list of wsa codec names. The names + should comply with the wsa nodes configurations. +- asoc-wsa-codec-prefixes: This property contains list of wsa codec prefixes. + +Example: + sound { + compatible = "qcom,msm8952-audio-slim-codec"; + qcom,model = "msm8952-tomtom-snd-card"; + reg = <0xc051000 0x4>, + <0xc051004 0x4>, + <0xc055000 0x4>; + reg-names = "csr_gp_io_mux_mic_ctl", + "csr_gp_io_mux_spkr_ctl", + "csr_gp_io_lpaif_pri_pcm_pri_mode_muxsel"; + qcom,msm-ext-pa = "primary"; + qcom,mi2s-audio-intf; + qcom,auxpcm-audio-intf; + qcom,msm-mi2s-master = <1>, <0>, <1>, <1>; + qcom,msm-mi2s-ext-mclk = <1>, <1>, <0>, <1>; + reg = <0x1711a000 0x4>, + <0x1711b000 0x4>, + <0x1711c000 0x4>, + <0x1711d000 0x4>; + reg-names = "lpaif_pri_mode_muxsel", + "lpaif_sec_mode_muxsel", + "lpaif_tert_mode_muxsel", + "lpaif_quat_mode_muxsel"; + qcom,msm-mclk-freq = <9600000>; + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,msm-hs-micbias-type = "internal"; + qcom,msm-micbias1-ext-cap; + qcom,audio-routing = + "RX_BIAS", "MCLK", + "SPK_RX_BIAS", "MCLK", + "INT_LDO_H", "MCLK", + "MIC BIAS External", "Handset Mic", + "MIC BIAS Internal2", "Headset Mic", + "MIC BIAS External", "Secondary Mic", + "AMIC1", "MIC BIAS External", + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS External"; + qcom,msm-gpios = + "slim", + "us_eu_gpio"; + qcom,pinctrl-names = + "all_off", + "slim_act", + "us_eu_gpio_act", + "slim_us_eu_gpio_act"; + pinctrl-names = + "all_off", + "slim_act", + "us_eu_gpio_act", + "slim_us_eu_gpio_act"; + pinctrl-0 = <&cdc_slim_lines_sus &cross_conn_det_sus>; + pinctrl-1 = <&cdc_slim_lines_act &cross_conn_det_sus>; + pinctrl-2 = <&cdc_slim_lines_sus &cross_conn_det_act>; + pinctrl-3 = <&cdc_slim_lines_act &cross_conn_det_act>; + qcom,cdc-us-euro-gpios = <&msm_gpio 63 0>; + qcom,headset-jack-type-NC; + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "SPK_OUT", "MCLK", + "AMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC5", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4"; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&lpa>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", "msm-pcm-afe", + "msm-lsm-client", "msm-pcm-routing", "msm-pcm-lpa"; + asoc-cpu = <&dai_hdmi>, <&dai_mi2s0>, <&dai_mi2s1>, + <&dai_mi2s2>, <&dai_mi2s3>, <&sb_0_rx>, <&sb_0_tx>, + <&sb_1_rx>, <&sb_1_tx>, <&sb_3_rx>, <&sb_3_tx>, + <&sb_4_rx>, <&sb_4_tx>, <&sb_5_tx>, <&bt_sco_rx>, + <&bt_sco_tx>, <&int_fm_rx>, <&int_fm_tx>, <&afe_pcm_rx>, + <&afe_pcm_tx>, <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>; + asoc-cpu-names = "msm-dai-q6-hdmi.8", "msm-dai-q6-mi2s.0", + "msm-dai-q6-mi2s.1", "msm-dai-q6-mi2s.2", + "msm-dai-q6-mi2s.3", "msm-dai-q6-dev.16384", + "msm-dai-q6-dev.16385", "msm-dai-q6-dev.16386", + "msm-dai-q6-dev.16387", "msm-dai-q6-dev.16390", + "msm-dai-q6-dev.16391", "msm-dai-q6-dev.16392", + "msm-dai-q6-dev.16393", "msm-dai-q6-dev.16395", + "msm-dai-q6-dev.12288", "msm-dai-q6-dev.12289", + "msm-dai-q6-dev.12292", "msm-dai-q6-dev.12293", + "msm-dai-q6-dev.224", "msm-dai-q6-dev.225", + "msm-dai-q6-dev.241", "msm-dai-q6-dev.240", + "msm-dai-q6-dev.32771", "msm-dai-q6-dev.32772", + "msm-dai-q6-dev.32773", "msm-dai-q6-dev.32770"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + asoc-wsa-codec-names = "wsa881x.20170212"; + asoc-wsa-codec-prefixes = "SpkrLeft"; + }; + +* MDM9607 ASoC Machine driver + +Required properties: +- compatible : "qcom,mdm9607-audio-tomtom" +- qcom,model : The user-visible name of this sound card. +- qcom,audio-routing : A list of the connections between audio components. +Each entry is a pair of strings, the first being the connection's sink, +the second being the connection's source. +- qcom,tomtom-mclk-clk-freq : Master clock value given to codec. Some WCD9XXX +codec can run at different mclk values. Mclk value can be 9.6MHz or 12.288MHz. +- pinctrl-names : pinctrl state names for each pin group configuration. +- pinctrl-x : defines pinctrl state for each pin group +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". + +Example: + +sound { + compatible = "qcom,mdm9607-audio-tomtom"; + qcom,model = "mdm9607-tomtom-i2s-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3"; + + qcom,tomtom-mclk-clk-freq = <12288000>; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&hostless>, <&afe>, <&routing>, + <&pcm_dtmf>, <&host_pcm>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-pcm-hostless", "msm-pcm-afe", + "msm-pcm-routing", "msm-pcm-dtmf", "msm-voice-host-pcm"; + asoc-cpu = <&dai_pri_auxpcm>, <&mi2s_prim>, <&dtmf_tx>, + <&rx_capture_tx>, <&rx_playback_rx>, + <&tx_capture_tx>, <&tx_playback_rx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, + <&afe_proxy_tx>, <&incall_record_rx>, + <&incall_record_tx>, <&incall_music_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-mi2s.0", + "msm-dai-stub-dev.4", "msm-dai-stub-dev.5", + "msm-dai-stub-dev.6", "msm-dai-stub-dev.7", + "msm-dai-stub-dev.8", "msm-dai-q6-dev.224", + "msm-dai-q6-dev.225", "msm-dai-q6-dev.241", + "msm-dai-q6-dev.240", "msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772", "msm-dai-q6-dev.32773"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + }; + +* MDMCALIFORNIUM ASoC Machine driver + +- compatible : "qcom,mdm-audio-tasha" for tasha codec and + node is "sound" +- qcom,model : The user-visible name of this sound card. +- qcom,tasha-mclk-clk-freq : MCLK frequency value for tasha codec + and node is "sound-9335" +- qcom,audio-routing : A list of the connections between audio components. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- clock-names : clock name defined for external clock. +- clocks : external clock defined for codec clock. +- qcom,hph-en1-gpio : GPIO to enable HiFi amplifiers. +- qcom,hph-en0-gpio : GPIO to enable HiFi audio route to headset. + +Example: + + sound { + compatible = "qcom,mdm-audio-tasha"; + qcom,model = "mdm-tasha-i2s-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AIF4 MAD", "MCLK", + "ultrasound amp", "LINEOUT1", + "ultrasound amp", "LINEOUT3", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + qcom,tasha-mclk-clk-freq = <12288000>; + asoc-platform = <&pcm0>, <&pcm1>, <&voip>, <&voice>, + <&loopback>, <&hostless>, <&afe>, <&routing>, + <&pcm_dtmf>, <&host_pcm>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-voip-dsp", "msm-pcm-voice", "msm-pcm-loopback", + "msm-pcm-hostless", "msm-pcm-afe", + "msm-pcm-routing", "msm-pcm-dtmf", "msm-voice-host-pcm"; + asoc-cpu = <&dai_pri_auxpcm>, <&mi2s_prim>, <&dtmf_tx>, + <&rx_capture_tx>, <&rx_playback_rx>, + <&tx_capture_tx>, <&tx_playback_rx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, + <&afe_proxy_tx>, <&incall_record_rx>, + <&incall_record_tx>, <&incall_music_rx>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-mi2s.0", + "msm-dai-stub-dev.4", "msm-dai-stub-dev.5", + "msm-dai-stub-dev.6", "msm-dai-stub-dev.7", + "msm-dai-stub-dev.8", "msm-dai-q6-dev.224", + "msm-dai-q6-dev.225", "msm-dai-q6-dev.241", + "msm-dai-q6-dev.240", "msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772", "msm-dai-q6-dev.32773"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,aux-codec = <&stub_codec>; + }; + +* APQ8096 Automotive ASoC Machine driver + +Required properties: +- compatible : "qcom,apq8096-asoc-snd-auto" for auto codec and + node is "sound-auto", + "qcom,apq8096-asoc-snd-adp-agave" for adp agave codec and + node is "sound-adp-agave", + "qcom,apq8096-asoc-snd-adp-mmxf" for adp mmxf codec and + node is "sound-adp-mmxf". +- qcom,model : The user-visible name of this sound card. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". + +Example: + + sound-auto { + compatible = "qcom,apq8096-asoc-snd-auto"; + qcom,model = "apq8096-auto-snd-card"; + + asoc-platform = <&pcm0>, <&pcm1>, <&pcm2>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&compr>, + <&loopback1>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-pcm-dsp.2", "msm-voip-dsp", + "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", + "msm-pcm-afe", "msm-lsm-client", + "msm-pcm-routing", "msm-compr-dsp", + "msm-pcm-loopback.1"; + asoc-cpu = <&dai_pri_auxpcm>, <&dai_sec_auxpcm>, <&dai_hdmi>, + <&dai_mi2s>, <&dai_mi2s_quat>, + <&afe_pcm_rx>, <&afe_pcm_tx>, + <&afe_proxy_rx>, <&afe_proxy_tx>, + <&incall_record_rx>, <&incall_record_tx>, + <&incall_music_rx>, <&incall_music2_rx>, + <&dai_tert_tdm_rx_0>, <&dai_tert_tdm_rx_1>, + <&dai_tert_tdm_rx_2>, <&dai_tert_tdm_rx_3>, + <&dai_tert_tdm_tx_0>, <&dai_tert_tdm_tx_1>, + <&dai_tert_tdm_tx_2>, <&dai_tert_tdm_tx_3>, + <&dai_quat_tdm_rx_0>, <&dai_quat_tdm_rx_1>, + <&dai_quat_tdm_rx_2>, <&dai_quat_tdm_rx_3>, + <&dai_quat_tdm_tx_0>, <&dai_quat_tdm_tx_1>, + <&dai_quat_tdm_tx_2>, <&dai_quat_tdm_tx_3>; + asoc-cpu-names = "msm-dai-q6-auxpcm.1", "msm-dai-q6-auxpcm.2", + "msm-dai-q6-hdmi.8", + "msm-dai-q6-mi2s.2", "msm-dai-q6-mi2s.3", + "msm-dai-q6-dev.224", "msm-dai-q6-dev.225", + "msm-dai-q6-dev.241", "msm-dai-q6-dev.240", + "msm-dai-q6-dev.32771", "msm-dai-q6-dev.32772", + "msm-dai-q6-dev.32773", "msm-dai-q6-dev.32770", + "msm-dai-q6-tdm.36896", "msm-dai-q6-tdm.36898", + "msm-dai-q6-tdm.36900", "msm-dai-q6-tdm.36902", + "msm-dai-q6-tdm.36897", "msm-dai-q6-tdm.36899", + "msm-dai-q6-tdm.36901", "msm-dai-q6-tdm.36903", + "msm-dai-q6-tdm.36912", "msm-dai-q6-tdm.36914", + "msm-dai-q6-tdm.36916", "msm-dai-q6-tdm.36918", + "msm-dai-q6-tdm.36913", "msm-dai-q6-tdm.36915", + "msm-dai-q6-tdm.36917", "msm-dai-q6-tdm.36919"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + }; + +* SDM660 ASoC Slimbus Machine driver + +Required properties: +- compatible : "qcom,sdm660-asoc-snd-tasha" for tasha codec, + "qcom,sdm660-asoc-snd-tavil" for tavil codec. +- qcom,model : The user-visible name of this sound card. +- qcom,msm-mclk-freq : MCLK frequency value for external codec +- qcom,msm-gpios : Lists down all the gpio sets that are supported. +- qcom,pinctrl-names : Lists all the possible combinations of the gpio sets +mentioned in qcom,msm-gpios. Say we have 2^N combinations for N GPIOs, +this would list all the 2^N combinations. +- pinctrl-names : The combinations of gpio sets from above that are supported in +the flavor. This can be sometimes same as qcom, pinctrl-names i.e with 2^N +combinations or will have less incase if some combination is not supported. +- pinctrl-# : Pinctrl states as mentioned in pinctrl-names. +- qcom,audio-routing : A list of the connections between audio components. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- qcom,cdc-us-euro-gpios : GPIO on which gnd/mic swap signal is coming. +- clock-names : clock name defined for external clock. +- clocks : external clock defined for codec clock. +- qcom,wsa-max-devs : Maximum number of WSA881x devices present in the target +- qcom,wsa-devs : List of phandles for all possible WSA881x devices supported for the target +- qcom,wsa-aux-dev-prefix : Name prefix with Left/Right configuration for WSA881x device + +Example: + + sound-9335 { + compatible = "qcom,sdm660-asoc-snd-tasha"; + qcom,model = "sdm660-tasha-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AIF4 MAD", "MCLK", + "ultrasound amp", "LINEOUT1", + "ultrasound amp", "LINEOUT3", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,msm-mclk-freq = <9600000>; + qcom,msm-gpios = + "slim", + "us_eu_gpio"; + qcom,pinctrl-names = + "all_off", + "slim_act", + "us_eu_gpio_act", + "slim_us_eu_gpio_act"; + pinctrl-names = + "all_off", + "slim_act", + "us_eu_gpio_act", + "slim_us_eu_gpio_act"; + pinctrl-0 = <&cdc_slim_lines_sus &cross_conn_det_sus>; + pinctrl-1 = <&cdc_slim_lines_act &cross_conn_det_sus>; + pinctrl-2 = <&cdc_slim_lines_sus &cross_conn_det_act>; + pinctrl-3 = <&cdc_slim_lines_act &cross_conn_det_act>; + qcom,cdc-us-euro-gpios = <&msm_gpio 63 0>; + asoc-platform = <&pcm0>, <&pcm1>, <&pcm2>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&cpe>, <&compr>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-pcm-dsp.2", "msm-voip-dsp", + "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", + "msm-pcm-afe", "msm-lsm-client", + "msm-pcm-routing", "msm-cpe-lsm", + "msm-compr-dsp"; + asoc-cpu = <&dai_hdmi>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_2_rx>, <&sb_2_tx>, <&sb_3_rx>, <&sb_3_tx>, + <&sb_4_rx>, <&sb_4_tx>, <&sb_5_tx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, + <&afe_proxy_tx>, <&incall_record_rx>, + <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>, <&sb_5_rx>; + asoc-cpu-names = "msm-dai-q6-hdmi.8", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16388", "msm-dai-q6-dev.16389", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.16395", "msm-dai-q6-dev.224", + "msm-dai-q6-dev.225", "msm-dai-q6-dev.241", + "msm-dai-q6-dev.240", "msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772", "msm-dai-q6-dev.32773", + "msm-dai-q6-dev.32770", "msm-dai-q6-dev.16394"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,wsa-max-devs = <2>; + qcom,wsa-devs = <&wsa881x_211>, <&wsa881x_212>, + <&wsa881x_213>, <&wsa881x_214>; + qcom,wsa-aux-dev-prefix = "SpkrRight", "SpkrLeft", + "SpkrRight", "SpkrLeft"; + }; + +* MSM8998 ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8998-asoc-snd-tasha" for tasha codec, + "qcom,msm8998-asoc-snd-tavil" for tavil codec. +- qcom,model : The user-visible name of this sound card. +- qcom,tasha-mclk-clk-freq : MCLK frequency value for tasha codec +- qcom,tavil-mclk-clk-freq : MCLK frequency value for tavil codec +- qcom,audio-routing : A list of the connections between audio components. +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- qcom,mbhc-audio-jack-type : String to indicate the jack type on the hardware. + Possible Values: + 4-pole-jack : Jack on the hardware is 4-pole. + 5-pole-jack : Jack on the hardware is 5-pole. + 6-pole-jack : Jack on the hardware is 6-pole. +- clock-names : clock name defined for external clock. +- clocks : external clock defined for codec clock. +- qcom,hph-en1-gpio : GPIO to enable HiFi amplifiers. +- qcom,hph-en0-gpio : GPIO to enable HiFi audio route to headset. +- qcom,wsa-max-devs : Maximum number of WSA881x devices present in the target +- qcom,wsa-devs : List of phandles for all possible WSA881x devices supported for the target +- qcom,wsa-aux-dev-prefix : Name prefix with Left/Right configuration for WSA881x device +- qcom,wcn-btfm : Property to specify if WCN BT/FM chip is used for the target +- qcom,msm-mbhc-usbc-audio-supported : Property to specify if analog audio feature is + enabled or not. +- qcom,usbc-analog-en1_gpio : EN1 GPIO to enable USB type-C analog audio +- qcom,usbc-analog-en2_n_gpio : EN2 GPIO to enable USB type-C analog audio +- qcom,usbc-analog-force_detect_gpio : Force detect GPIO to enable USB type-C analog audio + +Example: + + sound-9335 { + compatible = "qcom,msm8998-asoc-snd"; + qcom,model = "msm8998-tasha-snd-card"; + + qcom,audio-routing = + "RX_BIAS", "MCLK", + "LDO_H", "MCLK", + "AIF4 MAD", "MCLK", + "ultrasound amp", "LINEOUT1", + "ultrasound amp", "LINEOUT3", + "AMIC1", "MIC BIAS1 Internal1", + "MIC BIAS1 Internal1", "Handset Mic", + "AMIC2", "MIC BIAS2 External", + "MIC BIAS2 External", "Headset Mic", + "AMIC3", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCRight Headset Mic", + "AMIC4", "MIC BIAS2 External", + "MIC BIAS2 External", "ANCLeft Headset Mic", + "DMIC1", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic1", + "DMIC2", "MIC BIAS1 External", + "MIC BIAS1 External", "Digital Mic2", + "DMIC3", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic3", + "DMIC4", "MIC BIAS3 External", + "MIC BIAS3 External", "Digital Mic4", + "DMIC5", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic5", + "DMIC6", "MIC BIAS4 External", + "MIC BIAS4 External", "Digital Mic6"; + + qcom,msm-mbhc-hphl-swh = <0>; + qcom,msm-mbhc-gnd-swh = <0>; + qcom,tasha-mclk-clk-freq = <9600000>; + asoc-platform = <&pcm0>, <&pcm1>, <&pcm2>, <&voip>, <&voice>, + <&loopback>, <&compress>, <&hostless>, + <&afe>, <&lsm>, <&routing>, <&cpe>, <&compr>; + asoc-platform-names = "msm-pcm-dsp.0", "msm-pcm-dsp.1", + "msm-pcm-dsp.2", "msm-voip-dsp", + "msm-pcm-voice", "msm-pcm-loopback", + "msm-compress-dsp", "msm-pcm-hostless", + "msm-pcm-afe", "msm-lsm-client", + "msm-pcm-routing", "msm-cpe-lsm", + "msm-compr-dsp"; + asoc-cpu = <&dai_hdmi>, + <&sb_0_rx>, <&sb_0_tx>, <&sb_1_rx>, <&sb_1_tx>, + <&sb_2_rx>, <&sb_2_tx>, <&sb_3_rx>, <&sb_3_tx>, + <&sb_4_rx>, <&sb_4_tx>, <&sb_5_tx>, + <&afe_pcm_rx>, <&afe_pcm_tx>, <&afe_proxy_rx>, + <&afe_proxy_tx>, <&incall_record_rx>, + <&incall_record_tx>, <&incall_music_rx>, + <&incall_music_2_rx>, <&sb_5_rx>; + asoc-cpu-names = "msm-dai-q6-hdmi.8", + "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385", + "msm-dai-q6-dev.16386", "msm-dai-q6-dev.16387", + "msm-dai-q6-dev.16388", "msm-dai-q6-dev.16389", + "msm-dai-q6-dev.16390", "msm-dai-q6-dev.16391", + "msm-dai-q6-dev.16392", "msm-dai-q6-dev.16393", + "msm-dai-q6-dev.16395", "msm-dai-q6-dev.224", + "msm-dai-q6-dev.225", "msm-dai-q6-dev.241", + "msm-dai-q6-dev.240", "msm-dai-q6-dev.32771", + "msm-dai-q6-dev.32772", "msm-dai-q6-dev.32773", + "msm-dai-q6-dev.32770", "msm-dai-q6-dev.16394"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,wsa-max-devs = <2>; + qcom,wsa-devs = <&wsa881x_211>, <&wsa881x_212>, + <&wsa881x_213>, <&wsa881x_214>; + qcom,wsa-aux-dev-prefix = "SpkrRight", "SpkrLeft", + "SpkrRight", "SpkrLeft"; + qcom,msm-mbhc-usbc-audio-supported = <1>; + qcom,usbc-analog-en1_gpio = <&wcd_usbc_analog_en1_gpio>; + qcom,usbc-analog-en2_n_gpio = <&wcd_usbc_analog_en2n_gpio>; + qcom,usbc-analog-force_detect_gpio = <&wcd_usbc_analog_f_gpio>; + }; + +* MSMSTUB ASoC Machine driver + +Required properties: +- compatible : "qcom,msm8998-asoc-snd-stub" +- qcom,model : The user-visible name of this sound card. +- qcom,tasha-mclk-clk-freq : MCLK frequency value for tasha codec +- asoc-platform: This is phandle list containing the references to platform device + nodes that are used as part of the sound card dai-links. +- asoc-platform-names: This property contains list of platform names. The order of + the platform names should match to that of the phandle order + given in "asoc-platform". +- asoc-cpu: This is phandle list containing the references to cpu dai device nodes + that are used as part of the sound card dai-links. +- asoc-cpu-names: This property contains list of cpu dai names. The order of the + cpu dai names should match to that of the phandle order given + in "asoc-cpu". The cpu names are in the form of "%s.%d" form, + where the id (%d) field represents the back-end AFE port id that + this CPU dai is associated with. +- asoc-codec: This is phandle list containing the references to codec dai device + nodes that are used as part of the sound card dai-links. +- asoc-codec-names: This property contains list of codec dai names. The order of the + codec dai names should match to that of the phandle order given + in "asoc-codec". +Optional properties: +- qcom,wsa-max-devs : Maximum number of WSA881x devices present in the target + +Example: + + sound_msm:sound-9335 { + compatible = "qcom,msm8998-asoc-snd"; + qcom,model = "msm8998-stub-snd-card"; + + qcom,tasha-mclk-clk-freq = <9600000>; + asoc-platform = <&pcm0>; + asoc-platform-names = "msm-pcm-dsp.0"; + asoc-cpu = <&sb_0_rx>, <&sb_0_tx>; + asoc-cpu-names = "msm-dai-q6-dev.16384", "msm-dai-q6-dev.16385"; + asoc-codec = <&stub_codec>; + asoc-codec-names = "msm-stub-codec.1"; + qcom,wsa-max-devs = <0>; + }; + +* WCD DSP manager driver + +Required properties: +- compatible : "qcom,wcd-dsp-mgr" +- qcom,wdsp-components : This is phandle list containing the references to the + components of the manager driver. Manager driver will + register to component framework with these phandles. +- qcom,img-filename : String property to provide the dsp image file name that is + to be read from file system and downloaded to dsp memory +Optional properties: +- qcom,wdsp-cmpnt-dev-name : Property that manager driver will parse, but defined + in the child's DT entry that is given to manager driver + with phandle. This property will be used by the manager + driver in case the manager driver cannot match child's + of_node pointer to registered phandle. + +Example: + + qcom,wcd-dsp-mgr { + compatible = "qcom,wcd-dsp-mgr"; + qcom,wdsp-components = <&wcd934x_cdc 0>, + <&wcd_spi_0 1>, + <&glink_spi 2>; + qcom,img-filename = "cpe_9340"; + }; + +Example of child node that would have qcom,wdsp-cmpnt-dev-name property + + wcd934x_cdc: tavil_codec { + qcom,wdsp-cmpnt-dev-name = "tavil_codec"; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom-usb-audio-qmi-dev.txt b/Documentation/devicetree/bindings/sound/qcom-usb-audio-qmi-dev.txt new file mode 100644 index 000000000000..9d3fb78f96a7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom-usb-audio-qmi-dev.txt @@ -0,0 +1,26 @@ +QTI USB Audio QMI Device + +USB Audio QMI device is used to attach to remote processor IOMMU and +map USB Audio driver specific memory to iova to share with remote +processor. + +Required Properties: + +- compatible : "qcom,usb-audio-qmi-dev" + +- iommus : A list of phandle and IOMMU specifier pairs that describe the + IOMMU master interfaces of the device. + +- qcom,usb-audio-stream-id : Stream id is prepended to iova before passing + iova to remote processor. This allows remote processor to access iova. + +- qcom,usb-audio-intr-num : Interrupter number for external sub system + destination. + +Example: + usb_audio_qmi_dev { + compatible = "qcom,usb-audio-qmi-dev"; + iommus = <&lpass_q6_smmu 12>; + qcom,usb-audio-stream-id = <12>; + qcom,usb-audio-intr-num = <1>; + }; diff --git a/Documentation/devicetree/bindings/sound/wcd-spi.txt b/Documentation/devicetree/bindings/sound/wcd-spi.txt new file mode 100644 index 000000000000..2cd833d1851e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wcd-spi.txt @@ -0,0 +1,37 @@ +WCD audio codec SPI driver support + +* wcd_spi + +The wcd_spi device can be added as child device node to the audio codec device +node if the audio codec has SPI slave hardware. The codec driver upon probe will +create spi_device and perform spi_add_device. Note that the SPI framework does +not parse this DT node and hence the DT properties defined by SPI framework +cannot be used in wcd_spi device node. + +Required properties: + +- compatible : "qcom,wcd-spi-v2" + +- qcom,master-bus-num : Bus number of the SPI master controller driver. This + will be used to get a reference to the SPI master. + +- qcom,chip-select : Specifies the chip select number used for spi device + registration. + +- qcom,max-frequency : Specifies the max frequency of the SPI interface. + +- qcom,mem-base-addr : Defines the memory base address from the SPI + memory map. This will be used as an offset to read + and write memory. + +Example: + +tavil_codec { + wcd_spi_0: wcd_spi { + compatible = "qcom,wcd-spi-v2"; + qcom,master-bus-num = <10>; + qcom,chip-select = <0>; + qcom,max-frequency = <24000000>; + qcom,mem-base-addr = <0x100000>; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/wcd_codec.txt b/Documentation/devicetree/bindings/sound/wcd_codec.txt new file mode 100644 index 000000000000..5b5d43a6323c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wcd_codec.txt @@ -0,0 +1,671 @@ +* Qualcomm Technologies WCD Audio Codec + +This node models the Qualcomm Technologies Audio HW WCD Codecs + +Required properties: + + - compatible : "qcom,tasha-slim-pgd" or "qcom,tasha-i2c-pgd" for Tasha Codec + or "qcom,tavil-slim-pgd" for Tavil Codec + - elemental-addr: codec slimbus slave PGD enumeration address.(48 bits) + + - qcom,cdc-reset-gpio: gpio used for codec SOC reset. + If this property is not defined, it is expected + to atleast have "qcom,wcd-rst-n-gpio" to be defined. + - qcom,wcd-rst-gpio-node: Phandle reference to the DT node having codec reset gpio + configuration. If this property is not defined, it is + expected to atleast define "qcom,cdc-reset-gpio" property. + + - cdc-vdd-buck-supply: phandle of buck supply's regulator device tree node. + - qcom,cdc-vdd-buck-voltage: buck supply's voltage level min and max in mV. + - qcom,cdc-vdd-buck-current: buck supply's max current in mA. + + - cdc-vdd-tx-h-supply: phandle of tx-h supply's regulator device tree node. + - qcom,cdc-vdd-tx-h-voltage: tx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-tx-h-current: tx-h supply's max current in mA. + + - cdc-vdd-rx-h-supply: phandle of rx-h supply's regulator device tree node. + - qcom,cdc-vdd-rx-h-voltage: rx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-rx-h-current: rx-h supply's max current in mA. + + - cdc-vddpx-1-supply: phandle of px-1 supply's regulator device tree node. + - qcom,cdc-vddpx-1-voltage: px-1 supply's voltage level min and max in mV. + - qcom,cdc-vddpx-1-current: px-1 supply's max current in mA. + + - cdc-vdd-a-1p2v-supply: phandle of 1.2v supply's regulator device tree node. + - qcom,cdc-vdd-a-1p2v-voltage: 1.2v supply's voltage level min and max in mV. + - qcom,cdc-vdd-a-1p2v-current: 1.2v supply's max current in mA. + + - cdc-vddcx-1-supply: phandle of cx-1 supply's regulator device tree node. + - qcom,cdc-vddcx-1-voltage: cx-1 supply's voltage level min and max in mV. + - qcom,cdc-vddcx-1-current: cx-1 supply's max current in mA. + + - cdc-vddcx-2-supply: phandle of cx-2 supply's regulator device tree node. + - qcom,cdc-vddcx-2-voltage: cx-2 supply's voltage level min and max in mV. + - qcom,cdc-vddcx-2-current: cx-2 supply's max current in mA. + + - cdc-vdd-buckhelper-supply: phandle of helper regulator supply's + device tree node. This supply is a helper regulator for + cdc-vdd-buck-supply regulator. + - cdc-vdd-buckhelper-voltage: helper supply's voltage level min and max in mV. + - qcom,cdc-vdd-buckhelper-current: helper supply's max current in mA. + + - qcom,cdc-static-supplies: List of supplies to be enabled prior to codec + hardware probe. Supplies in this list will be + stay enabled. + + - qcom,cdc-micbias-ldoh-v - LDOH output in volts (should be 1.95 V and 3.00 V). + + - qcom,cdc-micbias-cfilt1-mv - cfilt1 output voltage in milli volts. + - qcom,cdc-micbias-cfilt2-mv - cfilt2 output voltage in milli volts. + - qcom,cdc-micbias-cfilt3-mv - cfilt3 output voltage in milli volts. + cfilt voltage can be set to max of qcom,cdc-micbias-ldoh-v - 0.15V. + + - qcom,cdc-micbias1-cfilt-sel = cfilt to use for micbias1 + (should be from 1 to 3). + - qcom,cdc-micbias2-cfilt-sel = cfilt to use for micbias2 + (should be from 1 to 3). + - qcom,cdc-micbias3-cfilt-sel = cfilt to use for micbias3 + (should be from 1 to 3). + - qcom,cdc-micbias4-cfilt-sel = cfilt to use for micbias4 + (should be from 1 to 3). + This value represents the connected CFLIT to MIC Bias. + + - qcom,cdc-micbias1-ext-cap: Boolean. Enable micbias 1 external capacitor mode. + - qcom,cdc-micbias2-ext-cap: Boolean. Enable micbias 2 external capacitor mode. + - qcom,cdc-micbias3-ext-cap: Boolean. Enable micbias 3 external capacitor mode. + - qcom,cdc-micbias4-ext-cap: Boolean. Enable micbias 4 external capacitor mode. + - qcom,cdc-mclk-clk-rate - Specifies the master clock rate in Hz required for + codec. + - qcom,cdc-slim-ifd-dev - namme of the codec slim interface device. + - qcom,cdc-slim-ifd-elemental-addr - codec slimbus slave interface device + enumeration address. + +Optional properties: + - cdc-dmic-sample-rate: Specifies the sample rate of digital mic in HZ. The + values for 9.6MHZ mclk can be 2400000 Hz, 3200000 Hz + and 4800000 Hz. The values for 12.288MHz mclk can be + 3072200 Hz, 4096000 Hz and 6144000 Hz. + + - qcom,cdc-mad-dmic-rate: Specifies the sample rate of digital mic in HZ to be + used by MAD (Microphone Activity Detection) hardware + block on the codec. The valid set of values are same + as that of cdc-dmic-sample-rate, but this rate will + only be used by MAD and all other audio use cases + involving DMIC will use the rate defined by + cdc-dmic-sample-rate. + + - qcom,cdc-ecpp-dmic-rate: Specifies the sample rate of digital mic in HZ to be + used by ECPP (Echo Cancellation Ping Pong) block + on the codec. The valid set of values are same + as that of cdc-dmic-sample-rate, but this rate will + only be used by ECPP and all other audio use cases + involving DMIC will use the rate defined by + cdc-dmic-sample-rate. + + - qcom,cdc-dmic-clk-drv-strength: Specifies the drive strength for digital microphone + clock in the codec. Accepted values are 2,4,8 and 16. + The clock drive strentgh is in uA. Codec driver will + choose default value for particular codec if this + value is not specified in device tree. + + - qcom,cdc-on-demand-supplies: List of supplies which can be enabled + dynamically. + Supplies in this list are off by default. + +- qcom,cdc-cp-supplies: List of supplies required for codec chargepump enable + Supplies in this list can be enabled/disabled dynamically and + are off by default. + + - qcom,cdc-micbias2-headset-only: Boolean. Allow micbias 2 only to headset mic. + + - qcom,cdc-variant: Indicates codec variant, WCD9XXX indicates all codecs till Taiko + WCD9330 indicates wcd9330 audio codec + + - qcom,cdc-micbias1-mv: micbias1 output voltage in milli volts. + This is used when cfilt is not user configurable + and micbias1 is directly controlled with a register + write. + + - qcom,cdc-micbias2-mv: micbias2 output voltage in milli volts. + This is used when cfilt is not user configurable + and micbias2 is directly controlled with a register + write. + + - qcom,cdc-micbias3-mv: micbias3 output voltage in milli volts. + This is used when cfilt is not user configurable + and micbias3 is directly controlled with a register + write. + + - qcom,cdc-micbias4-mv: micbias4 output voltage in milli volts. + This is used when cfilt is not user configurable + and micbias4 is directly controlled with a register + write. + + - clock-names : clock name defined for external clock. + - clocks : external clock defined for codec clock. + +Example: + +taiko_codec { + compatible = "qcom,taiko-slim-pgd"; + elemental-addr = [00 01 A0 00 17 02]; + + qcom,cdc-reset-gpio = <&msmgpio 63 0>; + + cdc-vdd-buck-supply = <&pm8941_s2>; + qcom,cdc-vdd-buck-voltage = <2150000 2150000>; + qcom,cdc-vdd-buck-current = <500000>; + + cdc-vdd-tx-h-supply = <&pm8941_s3>; + qcom,cdc-vdd-tx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-tx-h-current = <200000>; + + cdc-vdd-rx-h-supply = <&pm8941_s3>; + qcom,cdc-vdd-rx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-rx-h-current = <200000>; + + cdc-vddpx-1-supply = <&pm8941_s3>; + qcom,cdc-vddpx-1-voltage = <1800000 1800000>; + qcom,cdc-vddpx-1-current = <5000>; + + cdc-vdd-a-1p2v-supply = <&pm8941_l1>; + qcom,cdc-vdd-a-1p2v-voltage = <1225000 1225000>; + qcom,cdc-vdd-a-1p2v-current = <5000>; + + cdc-vddcx-1-supply = <&pm8941_l1>; + qcom,cdc-vddcx-1-voltage = <1225000 1225000>; + qcom,cdc-vddcx-1-current = <5000>; + + cdc-vddcx-2-supply = <&pm8941_l1>; + qcom,cdc-vddcx-2-voltage = <1225000 1225000>; + qcom,cdc-vddcx-2-current = <5000>; + + qcom,cdc-static-supplies = "cdc-vdd-buck", + "cdc-vdd-tx-h", + "cdc-vdd-rx-h", + "cdc-vddpx-1", + "cdc-vdd-a-1p2v", + "cdc-vddcx-1", + "cdc-vddcx-2"; + + com,cdc-on-demand-supplies = "cdc-vdd-spkdrv"; + + qcom,cdc-micbias-ldoh-v = <0x3>; + qcom,cdc-micbias-cfilt1-mv = <1800>; + qcom,cdc-micbias-cfilt2-mv = <2700>; + qcom,cdc-micbias-cfilt3-mv = <1800>; + qcom,cdc-micbias1-cfilt-sel = <0x0>; + qcom,cdc-micbias2-cfilt-sel = <0x1>; + qcom,cdc-micbias3-cfilt-sel = <0x2>; + qcom,cdc-micbias4-cfilt-sel = <0x2>; + qcom,cdc-micbias1-ext-cap; + qcom,cdc-micbias2-ext-cap; + qcom,cdc-micbias3-ext-cap; + qcom,cdc-micbias4-ext-cap; + qcom,cdc-mclk-clk-rate = <9600000>; + qcom,cdc-slim-ifd = "taiko-slim-ifd"; + qcom,cdc-slim-ifd-elemental-addr = [00 00 A0 00 17 02]; + qcom,cdc-dmic-sample-rate = <4800000>; + qcom,cdc-micbias2-headset-only; +}; + +Wcd9xxx audio CODEC in I2C mode + + - compatible = "qcom,wcd9xxx-i2c-device"; + - reg: represents the slave address provided to the I2C driver. + - qcom,cdc-reset-gpio: gpio used for codec SOC reset. + + - cdc-vdd-buck-supply: phandle of buck supply's regulator device tree node. + - qcom,cdc-vdd-buck-voltage: buck supply's voltage level min and max in mV. + - qcom,cdc-vdd-buck-current: buck supply's max current in mA. + + - cdc-vdd-tx-h-supply: phandle of tx-h supply's regulator device tree node. + - qcom,cdc-vdd-tx-h-voltage: tx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-tx-h-current: tx-h supply's max current in mA. + + - cdc-vdd-rx-h-supply: phandle of rx-h supply's regulator device tree node. + - qcom,cdc-vdd-rx-h-voltage: rx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-rx-h-current: rx-h supply's max current in mA. + + - cdc-vddpx-1-supply: phandle of px-1 supply's regulator device tree node. + - qcom,cdc-vddpx-1-voltage: px-1 supply's voltage level min and max in mV. + - qcom,cdc-vddpx-1-current: px-1 supply's max current in mA. + + - cdc-vdd-a-1p2v-supply: phandle of 1.2v supply's regulator device tree node. + - qcom,cdc-vdd-a-1p2v-voltage: 1.2v supply's voltage level min and max in mV. + - qcom,cdc-vdd-a-1p2v-current: 1.2v supply's max current in mA. + + - cdc-vddcx-1-supply: phandle of cx-1 supply's regulator device tree node. + - qcom,cdc-vddcx-1-voltage: cx-1 supply's voltage level min and max in mV. + - qcom,cdc-vddcx-1-current: cx-1 supply's max current in mA. + + - cdc-vddcx-2-supply: phandle of cx-2 supply's regulator device tree node. + - qcom,cdc-vddcx-2-voltage: cx-2 supply's voltage level min and max in mV. + - qcom,cdc-vddcx-2-current: cx-2 supply's max current in mA. + + - qcom,cdc-static-supplies: List of supplies to be enabled prior to codec + hardware probe. Supplies in this list will be + stay enabled. + + - qcom,cdc-micbias-ldoh-v - LDOH output in volts (should be 1.95 V and 3.00 V). + + - qcom,cdc-micbias-cfilt1-mv - cfilt1 output voltage in milli volts. + - qcom,cdc-micbias-cfilt2-mv - cfilt2 output voltage in milli volts. + - qcom,cdc-micbias-cfilt3-mv - cfilt3 output voltage in milli volts. + cfilt voltage can be set to max of qcom,cdc-micbias-ldoh-v - 0.15V. + + - qcom,cdc-micbias1-cfilt-sel = cfilt to use for micbias1 + (should be from 1 to 3). + - qcom,cdc-micbias2-cfilt-sel = cfilt to use for micbias2 + (should be from 1 to 3). + - qcom,cdc-micbias3-cfilt-sel = cfilt to use for micbias3 + (should be from 1 to 3). + - qcom,cdc-micbias4-cfilt-sel = cfilt to use for micbias4 + (should be from 1 to 3). + This value represents the connected CFLIT to MIC Bias. + + - qcom,cdc-micbias1-ext-cap: Boolean. Enable micbias 1 external capacitor mode. + - qcom,cdc-micbias2-ext-cap: Boolean. Enable micbias 2 external capacitor mode. + - qcom,cdc-micbias3-ext-cap: Boolean. Enable micbias 3 external capacitor mode. + - qcom,cdc-micbias4-ext-cap: Boolean. Enable micbias 4 external capacitor mode. + - qcom,cdc-mclk-clk-rate - Specifies the master clock rate in Hz required for + codec. + +Optional properties: + + - cdc-vdd-spkdrv-supply: phandle of spkdrv supply's regulator device tree node. + - qcom,cdc-vdd-spkdrv-voltage: spkdrv supply voltage level min and max in mV. + - qcom,cdc-vdd-spkdrv-current: spkdrv supply max current in mA. + + - cdc-vdd-spkdrv-supply: phandle of spkdrv supply's regulator device tree node. + - qcom,cdc-vdd-spkdrv-voltage: spkdrv supply voltage level min and max in mV. + - qcom,cdc-vdd-spkdrv-current: spkdrv supply max current in mA. + + - cdc-vdd-spkdrv-2-supply: phandle of spkdrv2 supply's regulator device tree node. + - qcom,cdc-vdd-spkdrv-2-voltage: spkdrv2 supply voltage level min and max in mV. + - qcom,cdc-vdd-spkdrv-2-current: spkdrv2 supply max current in mA. + + - qcom,cdc-on-demand-supplies: List of supplies which can be enabled + dynamically. + Supplies in this list are off by default. + +Example: +i2c@f9925000 { + cell-index = <3>; + compatible = "qcom,i2c-qup"; + reg = <0xf9925000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + reg-names = "qup_phys_addr"; + interrupts = <0 97 0>; + interrupt-names = "qup_err_intr"; + qcom,i2c-bus-freq = <100000>; + qcom,i2c-src-freq = <24000000>; + + wcd9xxx_codec@0d{ + compatible = "qcom,wcd9xxx-i2c"; + reg = <0x0d>; + qcom,cdc-reset-gpio = <&msmgpio 22 0>; + interrupt-parent = <&wcd9xxx_intc>; + interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 + 20 21 22 23 24 25 26 27 28>; + + cdc-vdd-buck-supply = <&pm8019_l11>; + qcom,cdc-vdd-buck-voltage = <1800000 1800000>; + qcom,cdc-vdd-buck-current = <25000>; + + cdc-vdd-tx-h-supply = <&pm8019_l11>; + qcom,cdc-vdd-tx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-tx-h-current = <25000>; + + cdc-vdd-rx-h-supply = <&pm8019_l11>; + qcom,cdc-vdd-rx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-rx-h-current = <25000>; + + cdc-vddpx-1-supply = <&pm8019_l11>; + qcom,cdc-vddpx-1-voltage = <1800000 1800000>; + qcom,cdc-vddpx-1-current = <10000>; + + cdc-vdd-a-1p2v-supply = <&pm8019_l9>; + qcom,cdc-vdd-a-1p2v-voltage = <1200000 1200000>; + qcom,cdc-vdd-a-1p2v-current = <10000>; + + cdc-vddcx-1-supply = <&pm8019_l9>; + qcom,cdc-vddcx-1-voltage = <1200000 1200000>; + qcom,cdc-vddcx-1-current = <10000>; + + cdc-vddcx-2-supply = <&pm8019_l9>; + qcom,cdc-vddcx-2-voltage = <1200000 1200000>; + qcom,cdc-vddcx-2-current = <10000>; + + qcom,cdc-static-supplies = "cdc-vdd-buck", + "cdc-vdd-tx-h", + "cdc-vdd-rx-h", + "cdc-vddpx-1", + "cdc-vdd-a-1p2v", + "cdc-vddcx-1", + "cdc-vddcx-2"; + + cdc-vdd-spkdrv-supply = <&pmi8994_boost>; + qcom,cdc-vdd-spkdrv-voltage = <5000000 5000000>; + qcom,cdc-vdd-spkdrv-current = <600000>; + + cdc-vdd-spkdrv-2-supply = <&pmi8994_boost>; + qcom,cdc-vdd-spkdrv-2-voltage = <5000000 5000000>; + qcom,cdc-vdd-spkdrv-2-current = <600000>; + + qcom,cdc-on-demand-supplies = "cdc-vdd-spkdrv", + "cdc-vdd-spkdrv-2"; + + qcom,cdc-micbias-ldoh-v = <0x3>; + qcom,cdc-micbias-cfilt1-mv = <1800>; + qcom,cdc-micbias-cfilt2-mv = <2700>; + qcom,cdc-micbias-cfilt3-mv = <1800>; + qcom,cdc-micbias1-cfilt-sel = <0x0>; + qcom,cdc-micbias2-cfilt-sel = <0x1>; + qcom,cdc-micbias3-cfilt-sel = <0x2>; + qcom,cdc-micbias4-cfilt-sel = <0x2>; + qcom,cdc-mclk-clk-rate = <12288000>; + }; + + wcd9xxx_codec@77{ + compatible = "qcom,wcd9xxx-i2c"; + reg = <0x77>; + }; + + wcd9xxx_codec@66{ + compatible = "qcom,wcd9xxx-i2c"; + reg = <0x66>; + }; + wcd9xxx_codec@55{ + compatible = "qcom,wcd9xxx-i2c"; + reg = <0x55>; + }; +}; + +Tombak audio CODEC in SPMI mode + + - compatible = "qcom,msm-codec-core", + - compatible = "qcom,pmic-codec-digital" + - compatible = "qcom,pmic-codec-analog" + - reg: represents the slave base address provided to the peripheral. + - interrupt-parent : The parent interrupt controller. + - interrupts: List of interrupts in given SPMI peripheral. + - interrupt-names: Names specificed to above list of interrupts in same + order. + +Optional properties: + + - cdc-vdda-cp-supply: phandle of cp supply's regulator device tree node. + - qcom,cdc-vdda-cp-voltage: cp supply's voltage level min and max in mV. + - qcom,cdc-vdda-cp-current: cp supply's max current in mA. + + - cdc-vdda-rx-h-supply: phandle of vdda-rx-h supply's regulator device tree node. + - qcom,cdc-vdda-rx-h-voltage: vdda-rx-h supply's voltage level min and max in mV. + - qcom,cdc-vdda-rx-h-current: vdda-rx-h supply's max current in mA. + + - cdc-vdda-tx-h-supply: phandle of vdda-tx-h supply's regulator device tree node. + - qcom,cdc-vdda-tx-h-voltage: vdda-tx-h supply's voltage level min and max in mV. + - qcom,cdc-vdda-tx-h-current: vdda-tx-h supply's max current in mA. + + - cdc-vdd-px-supply: phandle of vdd-px supply's regulator device tree node. + - qcom,cdc-vdd-px-voltage: vdd-px supply's voltage level min and max in mV. + - qcom,cdc-vdd-px-current: vdd-px supply's max current in mA. + + - cdc-vdd-pa-supply: phandle of vdd-pa supply's regulator device tree node. + - qcom,cdc-vdd-pa-voltage: vdd-pa supply's voltage level min and max in mV. + - qcom,cdc-vdd-pa-current: vdd-pa supply's max current in mA. + + - cdc-vdd-mic-bias-supply: phandle of mic-bias supply's regulator device tree + node. + - qcom,cdc-vdd-mic-bias-voltage: mic-bias supply's voltage level min and max + in mV. + - qcom,cdc-vdd-mic-bias-current: mic-bias supply's max current in mA. + + - qcom,cdc-mclk-clk-rate: Specifies the master clock rate in Hz required for + codec. + + - qcom,cdc-static-supplies: List of supplies to be enabled prior to codec + hardware probe. Supplies in this list will be + stay enabled. + + - qcom,cdc-on-demand-supplies: List of supplies which can be enabled + dynamically. + Supplies in this list are off by default. + - qcom,cdc-micbias-cfilt-mv : MICBIAS voltage value + - qcom,cdc-boost-voltage: Specifies the analog boost output voltage value. + Value from 4000 to 5550 in mV in steps of 50 mV can be given. + - qcom,dig-cdc-base-addr: Specifies the digital codec base address for MSM digital + core register writes. + +Example: + +msm_digital_codec: msm-dig-codec@c0f0000 { + compatible = "qcom,msm-digital-codec"; + reg = <0xc0f0000 0x0>; +}; + +pmic_analog_codec: analog-codec@f000 { + compatible = "qcom,pmic-analog-codec"; + reg = <0xf000 0x200>; + interrupt-parent = <&spmi_bus>; + interrupts = <0x1 0xf0 0x0>, + <0x1 0xf0 0x1>, + <0x1 0xf0 0x2>, + <0x1 0xf0 0x3>, + <0x1 0xf0 0x4>, + <0x1 0xf0 0x5>, + <0x1 0xf0 0x6>, + <0x1 0xf0 0x7>; + interrupt-names = "spk_cnp_int", + "spk_clip_int", + "spk_ocp_int", + "ins_rem_det1", + "but_rel_det", + "but_press_det", + "ins_rem_det", + "mbhc_int"; + + cdc-vdda-cp-supply = <&pm8916_s4>; + qcom,cdc-vdda-cp-voltage = <1800000 2200000>; + qcom,cdc-vdda-cp-current = <770000>; + + cdc-vdda-rx-h-supply = <&pm8916_l5>; + qcom,cdc-vdda-rx-h-voltage = <1800000 1800000>; + qcom,cdc-vdda-rx-h-current = <20000>; + + cdc-vdda-tx-h-supply = <&pm8916_l5>; + qcom,cdc-vdda-tx-h-voltage = <1800000 1800000>; + qcom,cdc-vdda-tx-h-current = <20000>; + + cdc-vdd-px-supply = <&pm8916_s4>; + qcom,cdc-vdd-px-voltage = <1800000 2200000>; + qcom,cdc-vdd-px-current = <770000>; + + cdc-vdd-pa-supply = <&pm8916_l5>; + qcom,cdc-vdd-pa-voltage = <1800000 1800000>; + qcom,cdc-vdd-pa-current = <5000>; + + cdc-vdd-mic-bias-supply = <&pm8916_l13>; + qcom,cdc-vdd-mic-bias-voltage = <3075000 3075000>; + qcom,cdc-vdd-mic-bias-current = <25000>; + + qcom,cdc-mclk-clk-rate = <9600000>; + + qcom,cdc-static-supplies = "cdc-vdda-h", + "cdc-vdd-px", + "cdc-vdd-pa", + "cdc-vdda-cp"; + + qcom,cdc-on-demand-supplies = "cdc-vdd-mic-bias"; +}; + +MSM based Soundwire audio codec + +Required properties: + - compatible = "qcom,msm-sdw-codec"; + - reg: Specifies the soundwire codec base address for MSM digital + soundwire core registers. + - interrupts: Specifies the soundwire master interrupt number to Apps processor. + - interrupt-names: Specify the interrupt name from soundwire master. + - swr_master: This node is added as a child of MSM soundwire codec + and uses already existing driver soundwire master. + And there is/are subchild node(s) under soundwire master + which is also existing driver WSA881x that represents + soundwire slave devices. + +Example: + +msm_sdw_codec: qcom,msm-sdw-codec@152c1000 { + compatible = "qcom,msm-sdw-codec"; + reg = <0x152c1000 0x0>; + interrupts = <0 161 0>; + interrupt-names = "swr_master_irq"; + + swr_master { + compatible = "qcom,swr-wcd"; + #address-cells = <2>; + #size-cells = <0>; + + wsa881x_1: wsa881x@20170212 { + compatible = "qcom,wsa881x"; + reg = <0x00 0x20170212>; + qcom,spkr-sd-n-gpio = <&tlmm 80 0>; + }; + }; +}; + +Tasha audio CODEC in I2C mode + + - compatible = "qcom,tasha-i2c-pgd"; + - reg: represents the slave address provided to the I2C driver. + - qcom,cdc-reset-gpio: gpio used for codec SOC reset. + + - cdc-vdd-buck-supply: phandle of buck supply's regulator device tree node. + - qcom,cdc-vdd-buck-voltage: buck supply's voltage level min and max in mV. + - qcom,cdc-vdd-buck-current: buck supply's max current in mA. + + - cdc-buck-sido-supply: phandle of sido supply's regulator device tree node. + - qcom,cdc-buck-sido-voltage = sido supply's voltage level min and max in mV. + - qcom,cdc-buck-sido-current = sido supply's max current in mA. + + - cdc-vdd-tx-h-supply: phandle of tx-h supply's regulator device tree node. + - qcom,cdc-vdd-tx-h-voltage: tx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-tx-h-current: tx-h supply's max current in mA. + + - cdc-vdd-rx-h-supply: phandle of rx-h supply's regulator device tree node. + - qcom,cdc-vdd-rx-h-voltage: rx-h supply's voltage level min and max in mV. + - qcom,cdc-vdd-rx-h-current: rx-h supply's max current in mA. + + - cdc-vddpx-1-supply: phandle of px-1 supply's regulator device tree node. + - qcom,cdc-vddpx-1-voltage: px-1 supply's voltage level min and max in mV. + - qcom,cdc-vddpx-1-current: px-1 supply's max current in mA. + + - qcom,cdc-static-supplies: List of supplies to be enabled prior to codec + hardware probe. Supplies in this list will be + stay enabled. + + - qcom,cdc-micbias1-mv - micbias1 output voltage in milli volts. + - qcom,cdc-micbias2-mv - micbias2 output voltage in milli volts. + - qcom,cdc-micbias3-mv - micbias3 output voltage in milli volts. + - qcom,cdc-micbias4-mv - micbias4 output voltage in milli volts. + + - qcom,cdc-mclk-clk-rate - Specifies the master clock rate in Hz required for + codec. + + - qcom,cdc-dmic-sample-rate - Specifies dmic sample rate. + - qcom,cdc-variant - Specifies codec variant. + +Example: +i2c_3: i2c@78B7000 { /* BLSP1 QUP3 */ + compatible = "qcom,i2c-msm-v2"; + #address-cells = <1>; + #size-cells = <0>; + reg-names = "qup_phys_addr"; + reg = <0x78B7000 0x600>; + interrupt-names = "qup_irq"; + interrupts = <0 97 0>; + dmas = <&dma_blsp1 12 64 0x20000020 0x20>, + <&dma_blsp1 13 32 0x20000020 0x20>; + dma-names = "tx", "rx"; + qcom,master-id = <86>; + qcom,clk-freq-out = <400000>; + qcom,clk-freq-in = <19200000>; + clock-names = "iface_clk", "core_clk"; + clocks = <&clock_gcc clk_gcc_blsp1_ahb_clk>, + <&clock_gcc clk_gcc_blsp1_qup3_i2c_apps_clk>; + pinctrl-names = "i2c_active", "i2c_sleep"; + pinctrl-0 = <&i2c_3_active>; + pinctrl-1 = <&i2c_3_sleep>; + status = "disabled"; + + wcd9xxx_codec@d{ + compatible = "qcom,tasha-i2c-pgd"; + reg = <0x0d>; + + interrupt-parent = <&wcd9xxx_intc>; + interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 + 17 18 19 20 21 22 23 24 25 26 27 28 29 + 30>; + + qcom,cdc-reset-gpio = <&tlmm_pinmux 90 0>; + + cdc-vdd-buck-supply = <&codec_buck_vreg>; + qcom,cdc-vdd-buck-voltage = <1800000 1800000>; + qcom,cdc-vdd-buck-current = <650000>; + + cdc-buck-sido-supply = <&codec_buck_vreg>; + qcom,cdc-buck-sido-voltage = <1800000 1800000>; + qcom,cdc-buck-sido-current = <200000>; + + cdc-vdd-tx-h-supply = <&pmdcalifornium_l6>; + qcom,cdc-vdd-tx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-tx-h-current = <25000>; + + cdc-vdd-rx-h-supply = <&pmdcalifornium_l6>; + qcom,cdc-vdd-rx-h-voltage = <1800000 1800000>; + qcom,cdc-vdd-rx-h-current = <25000>; + + cdc-vddpx-1-supply = <&pmdcalifornium_l6>; + qcom,cdc-vddpx-1-voltage = <1800000 1800000>; + qcom,cdc-vddpx-1-current = <10000>; + + qcom,cdc-static-supplies = "cdc-vdd-buck", + "cdc-buck-sido", + "cdc-vdd-tx-h", + "cdc-vdd-rx-h", + "cdc-vddpx-1"; + + qcom,cdc-micbias1-mv = <1800>; + qcom,cdc-micbias2-mv = <1800>; + qcom,cdc-micbias3-mv = <1800>; + qcom,cdc-micbias4-mv = <1800>; + qcom,cdc-mclk-clk-rate = <12288000>; + qcom,cdc-dmic-sample-rate = <4800000>; + + swr_master { + compatible = "qcom,swr-wcd"; + #address-cells = <2>; + #size-cells = <0>; + + wsa881x_1: wsa881x@20170212 { + compatible = "qcom,wsa881x"; + reg = <0x00 0x20170212>; + qcom,spkr-sd-n-gpio = <&tlmm_pinmux 80 0>; + + cdc-vdd-d-supply = <&pmdcalifornium_l6>; + qcom,cdc-vdd-d-voltage = <1800000 + 1800000>; + qcom,cdc-vdd-d-current = <2000>; + + cdc-vdd-a-supply = <&pmdcalifornium_l6>; + qcom,cdc-vdd-a-voltage = <1800000 + 1800000>; + qcom,cdc-vdd-a-current = <2000>; + + qcom,cdc-static-supplies = "cdc-vdd-d", + "cdc-vdd-a"; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/wsa881x-analog.txt b/Documentation/devicetree/bindings/sound/wsa881x-analog.txt new file mode 100755 index 000000000000..ca7bc045f01e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wsa881x-analog.txt @@ -0,0 +1,88 @@ +wsa881x Audio CODEC + +wsa881x Audio CODEC can support either I2C interface or Soundwire interface. +In Analog mode, this codec will operate as I2C slave device and +interacts with I2C controller for status, control and interrupt management. +The wsa881x device nodes will be represented as child nodes to I2C +master device node in the devicetree. Currently, the below devicetree +bindings are for I2C mode only and does not include soundwire mode. + +Required properties: + + - compatible : "qcom,wsa881x-i2c-codec" + - reg : Unique device ID of I2C slave device. + +Optional properties: +- qcom,msm-gpios : Lists down all the gpio sets that are supported. +- qcom,pinctrl-names : Lists all the possible combinations of the gpio sets +mentioned in qcom,msm-gpios. Say we have 2^N combinations for N GPIOs, this +list all 2^N combinations. +- pinctrl-names : The combinations of gpio sets from above that are supported in +the flavor. This can be sometimes same as qcom, pinctrl-names i.e with 2^N +combinations or will have less incase if some combination is not supported. +- pinctrl-# : Pinctrl states as mentioned in pinctrl-names. + +* wsa_intc + +Required properties: + + - compatible : "qcom,wsa-irq" + - interrupt-controller : Mark this device node as an + interrupt controller + - #interrupt-cells : Should be 1 + - interrupt-parent : Parent interrupt controller + - interrupts : Interrupt number on the parent + interrupt controller + - interrupt-names : Name of interrupt on the parent + interrupt controller +Example: + +wsa881x-i2c-codec@0e { + compatible = "qcom,wsa881x-i2c-codec"; + reg = <0x0e>; + qcom,msm-gpios = "wsa_clk", + "wsa_reset"; + qcom,pinctrl-names = "all_off", + "wsa_clk", + "wsa_active", + "wsa_clk_active"; + pinctrl-names = "all_off", + "wsa_clk", + "wsa_active", + "wsa_clk_active"; + pinctrl-0 = <&wsa_clk_off &wsa_suspend>; + pinctrl-1 = <&wsa_clk_on &wsa_suspend>; + pinctrl-2 = <&wsa_clk_off &wsa_active>; + pinctrl-3 = <&wsa_clk_on &wsa_active>; +}; + +wsa881x-i2c-codec@44 { + compatible = "qcom,wsa881x-i2c-codec"; + reg = <0x44>; +}; + +wsa881x-i2c-codec@0f { + compatible = "qcom,wsa881x-i2c-codec"; + reg = <0x0f>; + qcom,msm-gpios = "wsa_clk", + "wsa_reset"; + qcom,pinctrl-names = "all_off", + "wsa_clk", + "wsa_active", + "wsa_clk_active"; + pinctrl-names = "all_off", + "wsa_active", + "wsa_clk_active"; + pinctrl-0 = <&wsa_clk_off &wsa_suspend>; + pinctrl-1 = <&wsa_clk_off &wsa_active>; + pinctrl-2 = <&wsa_clk_on &wsa_active>; +}; + +wsa_intc: wsa-irq { + compatible = "qcom,wsa-irq"; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&msm_gpio>; + interrupts = <97 0>; + interrupt-names = "wsa-int"; +}; diff --git a/Documentation/devicetree/bindings/soundwire/swr-wcd-ctrl.txt b/Documentation/devicetree/bindings/soundwire/swr-wcd-ctrl.txt new file mode 100755 index 000000000000..7873f5e94859 --- /dev/null +++ b/Documentation/devicetree/bindings/soundwire/swr-wcd-ctrl.txt @@ -0,0 +1,31 @@ +Qualcomm WCD Codec SoundWire controller + +Required properties: + + - compatible : should be "qcom,swr-wcd" + - reg : Unique device ID(48 bits) of Soundwire slave device node. + In the below example, wsa881x is soundwire slave device for + which the swr-devid is <0x0 0x032000> where 0x03 represents + device Unique_ID, 0x20 represents Part_Id1 and 0x00 + represents part_Id2. +- #address-cells = <2>; +- #size-cells = <0>; + +Optional property: + + Example: + swr_master { + compatible = "qcom,swr-wcd"; + #address-cells = <2>; + #size-cells = <0>; + + wsa881x@32000 { + compatible = "qcom,wsa881x"; + reg = <0x00 0x032000>; + }; + + wsa881x@42000 { + compatible = "qcom,wsa881x"; + reg = <0x00 0x042000>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi_qsd.txt b/Documentation/devicetree/bindings/spi/spi_qsd.txt new file mode 100644 index 000000000000..1edf0820398a --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_qsd.txt @@ -0,0 +1,106 @@ +Qualcomm Serial Peripheral Interface (SPI) + +Required properties: +- compatible : Should be "qcom,spi-qup-v2". +- reg : Offset and length of the register regions for the device +- reg-names : Register region names referenced in reg above. + Required register resource entries are: + "spi_physical" : Physical address of controller register blocks. +- interrupts : Interrupt numbers used by this controller +- interrupt-names : Interrupt resource names referenced in interrupts above. + Required interrupt resource entries are: + "spi_irq" : QUP-core interrupt. +- spi-max-frequency : Specifies maximum SPI clock frequency, Units - Hz. + +Required alias: +- The desired bus-number is specified via an alias with the following format + 'spi{n}' where n is the bus number. + +Optional properties: +- qcom,gpio-mosi : GPIO pin number of the MOSI bus line. +- qcom,gpio-miso : GPIO pin number of the MISO bus line. +- qcom,gpio-clk : GPIO pin number of the CLK bus line. +- qcom,gpio-cs0 : GPIO pin number of the chipselect0 bus line. +- qcom,gpio-cs1 : GPIO pin number of the chipselect1 bus line. +- qcom,gpio-cs2 : GPIO pin number of the chipselect2 bus line. +- qcom,gpio-cs3 : GPIO pin number of the chipselect3 bus line. +- qcom,infinite-mode: When missing or set to zero, QUP uses infinite-mode. When + value is non-zero, the value is the number of words in maximum transfer + length. + - qcom,active-only : Vote for core clock when the application processor goes + to active state and remove that vote when it goes to idle state. This flag may + improve service time of first spi request at the expense of power consumption. + When this entry is not present, voting is done by the runtime-pm callbacks. + - qcom,master-id : Master endpoint number used for voting on clocks using the + bus-scaling driver. + - qcom,rt-priority : whether spi message queue is set to run as a realtime task. + With this spi transaction message pump with high (realtime) priority to reduce + the transfer latency on the bus by minimising the delay between a transfer request + - qcom,shared : whether this qup is shared with other ee's + +Optional properties which are required for support of BAM-mode: +- qcom,ver-reg-exists : Boolean. When present, allows driver to verify if HW + version support latest features (e.g. BAM) and then enable them. Should be + removed for legacy HW. +- qcom,use-bam : Boolean. When present, enables BAM-mode. +- qcom,use-pinctrl : Boolean. When present, enables pinctrl frame work to configure GPIO's + instead of existing gpio mux hence gpio entries are no more required if present. +- pinctrl-names : Property must contain "spi_default" and "spi_sleep" if + pinctrl is to be used. + instead of existing gpio mux hence gpio entries are no more required if present. +- qcom,bam-consumer-pipe-index : BAM consumer-pipe index. +- qcom,bam-producer-pipe-index : BAM producer-pipe index. +- reg-names : register region names referenced in reg. + Required register resource for BAM are: + "spi_bam_physical" : Physical address of BAM for this controller. +- interrupt-names : interrupt resource names referenced in interrupts. + Required interrupt resource from BAM are: + "spi_bam_irq" : BAM interrupt used by the controller. + +Optional SPI slave nodes must be children of the SPI master node and contain +the following properties. +- reg: (required) chip-select address of the device. +- compatible : (required) Name of SPI device following generic names. +- spi-max-frequency : (required) Maximum SPI clocking speed of device in Hz +- interrupts : (recommended) Should contain the SPI slave interrupt number + encoded depending on the type of the interrupt controller. +- interrupt-parent : (recommended) The phandle for the interrupt controller + that services interrupts for this device. +- spi-cpol : (optional) Empty property indicating device requires inverse + clock polarity (CPOL) mode +- spi-cpha : (optional) Empty property indicating device requires shifted + clock phase (CPHA) mode +- spi-cs-high : (optional) Empty property indicating device requires + chip select active high + +Example: + aliases { + spi0 = &spi_0; + }; + + spi_0: spi@f9923000 { + compatible = "qcom,spi-qup-v2"; + + reg-names = "spi_physical", "spi_bam_physical"; + reg = <0xf9923000 0x1000>, + <0xf9904000 0x10000>; + interrupt-names = "spi_irq", "spi_bam_irq"; + interrupts = <0 95 0>, <0 238 0>; + + spi-max-frequency = <19200000>; + #address-cells = <1>; + #size-cells = <0>; + qcom,gpio-mosi = <&msmgpio 0 0>; + qcom,gpio-miso = <&msmgpio 1 0>; + qcom,gpio-clk = <&msmgpio 3 0>; + qcom,gpio-cs2 = <&msmgpio 9 0>; + + qcom,infinite-mode = <0>; + qcom,use-bam; + qcom,use-pinctrl; + qcom,bam-consumer-pipe-index = <12>; + qcom,bam-producer-pipe-index = <13>; + qcom,ver-reg-exists; + qcom,master-id = <86>; + qcom,rt-priority; + }; diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt index e16b9b5afc70..bef919334574 100644 --- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt +++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt @@ -42,7 +42,7 @@ Required properties: cell 4: interrupt flags indicating level-sense information, as defined in dt-bindings/interrupt-controller/irq.h -Example: +Example V1 PMIC-Arbiter: spmi { compatible = "qcom,spmi-pmic-arb"; @@ -63,3 +63,26 @@ Example: interrupt-controller; #interrupt-cells = <4>; }; + +Example V2 PMIC-Arbiter: + + spmi_bus: qcom,spmi@200f000 { + compatible = "qcom,spmi-pmic-arb"; + reg-names = "core", "chnls", "obsrvr", "intr", "cnfg"; + reg = <0x200f000 0xc00>, + <0x2400000 0x400000>, + <0x2c00000 0x400000>, + <0x3800000 0x200000>, + <0x200a000 0x2100>; + + interrupt-names = "periph_irq"; + interrupts = <0 190 0>; + + qcom,ee = <0>; + + #address-cells = <2>; + #size-cells = <0>; + + interrupt-controller; + #interrupt-cells = <4>; + }; diff --git a/Documentation/devicetree/bindings/thermal/qpnp-adc-tm.txt b/Documentation/devicetree/bindings/thermal/qpnp-adc-tm.txt new file mode 100644 index 000000000000..07e4374956f1 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qpnp-adc-tm.txt @@ -0,0 +1,241 @@ +Qualcomm's QPNP PMIC thermal monitor ADC driver (VADC_TM) + +QPNP PMIC thermal monitoring (TM) provides interface to thermal clients +to set temperature thresholds and receive notification when the thresholds +are crossed. A 15 bit ADC is used for measurements. The driver is part +of the sysfs thermal framework that provides support to read the trip +points, set threshold for the trip points and enable the trip points. +Seperate kernel api's are provided to usb_id and batt_therm +to set thresholds and receive threshold notifications. + +VADC_TM node + +Required properties: +- compatible : should be "qcom,qpnp-adc-tm" for thermal ADC driver. + : should be "qcom,qpnp-adc-tm-hc" for thermal ADC driver using + refreshed BTM peripheral. +- reg : offset and length of the PMIC Aribter register map. +- address-cells : Must be one. +- size-cells : Must be zero. +- interrupts : The thermal ADC bank peripheral interrupts for eoc, high and low interrupts. +- interrupt-names : Should be "eoc-int-en-set", "high-thr-en-set" and "low-thr-en-set" + for qcom,qpnp-adc-tm type. + : Should be "eoc-int-en-set" for qcom,qpnp-adc-tm-hc type. +- qcom,adc-bit-resolution : Bit resolution of the ADC. +- qcom,adc-vdd-reference : Voltage reference used by the ADC. + +The following properties are required in the main node for qcom,qpnp-adc-tm-hc peripheral. +- qcom,decimation : Should be present for qcom,qpnp-adc-tm-hc peripheral as its common setting + across all the channels. Sampling rate to use for all the channel measurements. + Select from the following unsigned int. + 0 : 512 + 1 : 1K + 2 : 2K + 3 : 4K +- qcom,fast-avg-setup : Should be present for qcom,qpnp-adc-tm-hc peripheral as its common setting + across all the channels. Average number of samples to be used for measurement. + Fast averaging provides the option to obtain a single measurement from the ADC + that is an average of multiple samples. The value selected is 2^(value) + Select from the following unsigned int. + 0 : 1 + 1 : 2 + 2 : 4 + 3 : 8 + 4 : 16 + 5 : 32 + 6 : 64 + 7 : 128 + 8 : 256 + +Optional properties: +- qcom,thermal-node : If present a thermal node is created and the channel is registered as + part of the thermal sysfs which allows clients to use the thermal framework + to set temperature thresholds and receive notification when the temperature + crosses a set threshold, read temperature and enable/set trip types supported + by the thermal framework. +- qcom,meas-interval-timer-idx: If present select from the following timer index to choose + a preset configurable measurement interval timer value. The driver defaults + to timer 2 with a measurement interval of 1 second if the property is not present. + 0 : Select Timer 1 for a measurement polling interval of 3.9 milliseconds. + 1 : Select Timer 2 for a measurement polling interval of 1 second. + 2 : Select Timer 3 for a measurement polling interval of 4 seconds. +- qcom,adc-tm-recalib-check: Add this property to check if recalibration required due to inaccuracy. +- hkadc_ldo-supply : Add this property if VADC needs to perform a Software Vote for the HKADC. +- hkadc_ok-supply : Add this property if the VADC needs to perform a Software vote for the HKADC VREG_OK. + +Client required property: +- qcom,<consumer name>-adc_tm : The phandle to the corresponding adc_tm device. + The consumer name passed to the driver when calling + qpnp_get_adc_tm() is used to associate the client + with the corresponding device. + +Channel nodes +NOTE: Atleast one Channel node is required. + +Required properties: +- label : Channel name used for sysfs entry. +- reg : AMUX channel number. +- qcom,decimation : Sampling rate to use for the individual channel measurement. + Select from the following unsigned int. + 0 : 512 + 1 : 1K + 2 : 2K + 3 : 4K + Note: This property is not required in the channel node in qcom,qpnp-adc-tm-hc + peripheral. +- qcom,pre-div-channel-scaling : Pre-div used for the channel before the signal is being measured. + Select from the following unsigned int for the corresponding + numerator/denominator pre-div ratio. + 0 : pre-div ratio of {1, 1} + 1 : pre-div ratio of {1, 3} + 2 : pre-div ratio of {1, 4} + 3 : pre-div ratio of {1, 6} + 4 : pre-div ratio of {1, 20} + 5 : pre-div ratio of {1, 8} + 6 : pre-div ratio of {10, 81} + 7 : pre-div ratio of {1, 10} +- qcom,calibration-type : Reference voltage to use for channel calibration. + Channel calibration is dependendent on the channel. + Certain channels like XO_THERM, BATT_THERM use ratiometric + calibration. Most other channels fall under absolute calibration. + Select from the following strings. + "absolute" : Uses the 625mv and 1.25V reference channels. + "ratiometric" : Uses the reference Voltage/GND for calibration. +- qcom,scale-function : Reverse scaling fuction used to convert raw ADC code to units specific to + a given channel. + Select from the following unsigned int. + 0 : Scaling to convert voltage in uV to raw adc code. + 1 : Scaling to convert decidegC to raw adc code. + 2 : Scaling for converting USB_ID reverse scaling. + 3 : Scaling to convert milldegC to raw ADC code. + 4 : Scaling to convert smb_batt_therm values to raw ADC code. + 5 : Scaling to perform reverse calibration for absolute voltage from uV + to raw ADC code. + 6 : Scaling to convert qrd skuh battery decidegC to raw ADC code. +- qcom,hw-settle-time : Settling period for the channel before ADC read. + Select from the following unsigned int. + 0 : 0us + 1 : 100us + 2 : 200us + 3 : 300us + 4 : 400us + 5 : 500us + 6 : 600us + 7 : 700us + 8 : 800us + 9 : 900us + 0xa : 1ms + 0xb : 2ms + 0xc : 4ms + 0xd : 6ms + 0xe : 8ms + 0xf : 10ms +- qcom,fast-avg-setup : Average number of samples to be used for measurement. Fast averaging + provides the option to obtain a single measurement from the ADC that + is an average of multiple samples. The value selected is 2^(value) + Select from + 0 : 1 + 1 : 2 + 2 : 4 + 3 : 8 + 4 : 16 + 5 : 32 + 6 : 64 + 7 : 128 + 8 : 256 + Note: This property is not required in the channel node in + qcom,qpnp-adc-tm-hc peripheral. +- qcom,btm-channel-number : Depending on the PMIC version, a max of upto 8 BTM channels. + The BTM channel numbers are statically allocated to the + corresponding channel node. +- qcom,adc_tm-vadc : phandle to the corresponding VADC device to read the ADC channels. + +Client device example: +/* Add to the clients node that needs the ADC_TM channel A/D */ +client_node { + qcom,client-adc_tm = <&pm8941_adc_tm>; +}; + +Example for "qcom,qpnp-adc-tm" device: + /* Main Node */ + qcom,vadc@3400 { + compatible = "qcom,qpnp-adc-tm"; + reg = <0x3400 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0x0 0x34 0x0>, + <0x0 0x34 0x3>, + <0x0 0x34 0x4>; + interrupt-names = "eoc-int-en-set", + "high-thr-en-set", + "low-thr-en-set"; + qcom,adc-bit-resolution = <15>; + qcom,adc-vdd-reference = <1800>; + qcom,adc_tm-vadc = <&pm8941_vadc>; + + /* Channel Node to be registered as part of thermal sysfs */ + chan@b5 { + label = "pa_therm1"; + reg = <0xb5>; + qcom,decimation = <0>; + qcom,pre-div-channel-scaling = <0>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <2>; + qcom,hw-settle-time = <0>; + qcom,fast-avg-setup = <0>; + qcom,btm-channel-number = <0x70>; + qcom,thermal-node; + }; + + /* Channel Node */ + chan@6 { + label = "vbat_sns"; + reg = <6>; + qcom,decimation = <0>; + qcom,pre-div-channel-scaling = <1>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <3>; + qcom,hw-settle-time = <0>; + qcom,fast-avg-setup = <0>; + qcom,btm-channel-number = <0x78>; + }; + }; + +Example for "qcom,qpnp-adc-tm-hc" device: + /* Main Node */ + pm8998_adc_tm: vadc@3400 { + compatible = "qcom,qpnp-adc-tm-hc"; + reg = <0x3400 0x100>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "eoc-int-en-set"; + qcom,adc-bit-resolution = <15>; + qcom,adc-vdd-reference = <1875>; + qcom,adc_tm-vadc = <&pm8998_vadc>; + qcom,decimation = <0>; + qcom,fast-avg-setup = <0>; + + /* Channel Node to be registered as part of thermal sysfs */ + chan@b5 { + label = "pa_therm1"; + reg = <0xb5>; + qcom,pre-div-channel-scaling = <0>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <2>; + qcom,hw-settle-time = <0>; + qcom,btm-channel-number = <0x70>; + qcom,thermal-node; + }; + + /* Channel Node */ + chan@6 { + label = "vbat_sns"; + reg = <6>; + qcom,pre-div-channel-scaling = <1>; + qcom,calibration-type = "absolute"; + qcom,scale-function = <3>; + qcom,hw-settle-time = <0>; + qcom,btm-channel-number = <0x78>; + }; + }; diff --git a/Documentation/devicetree/bindings/thermal/qpnp-temp-alarm.txt b/Documentation/devicetree/bindings/thermal/qpnp-temp-alarm.txt new file mode 100644 index 000000000000..bb20644afde6 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qpnp-temp-alarm.txt @@ -0,0 +1,77 @@ +Qualcomm Technologies, Inc. QPNP Temperature Alarm + +QPNP temperature alarm peripherals are found inside of Qualcomm Technologies, +Inc. PMIC chips that utilize the MSM SPMI implementation. These peripherals +provide an interrupt signal and status register to identify high PMIC die +temperature. + +Required properties: +- compatible: Must be "qcom,qpnp-temp-alarm". +- reg: Specifies the SPMI address and size for this temperature + alarm device. +- interrupts: PMIC temperature alarm interrupt +- label: A string used as a descriptive name for this thermal device. + This name should be 19 characters or less. + +Required structure: +- A qcom,qpnp-temp-alarm node must be a child of an SPMI node that has specified + the spmi-slave-container property + +Optional properties: +- qcom,channel-num: VADC channel number associated PMIC DIE_TEMP thermistor. + If no channel is specified, then the die temperature + must be estimated based on the over temperature stage. +- qcom,threshold-set: Integer value which specifies which set of threshold + temperatures to use for the over temperature stages. + Possible values (x = {stage 1 threshold temperature, + stage 2 threshold temperature, + stage 3 threshold temperature}): + 0 = {105 C, 125 C, 145 C} + 1 = {110 C, 130 C, 150 C} + 2 = {115 C, 135 C, 155 C} + 3 = {120 C, 140 C, 160 C} +- qcom,clock-rate: Integer value which specifies the temperature monitoring + clock rate. This property is only supported on GEN2 + temperature alarm peripherals. + Supported values: + 0 = 100 Hz + 1 = 50 Hz + 2 = 25 Hz + 3 = 12.5 Hz +- qcom,allow-override: Boolean which controls the ability of software to + override shutdowns. If present, then software is + allowed to override automatic PMIC hardware stage 2 and + stage 3 over temperature shutdowns. Otherwise, software + is not allowed to override automatic shutdown. +- qcom,default-temp: Specifies the default temperature in millicelcius to use + if no ADC channel is present to read the real time + temperature. +- qcom,temp_alarm-vadc: Corresponding VADC device's phandle. + +Note, if a given optional qcom,* binding is not present, then the default +hardware state for that feature will be maintained. + +Example: +&spmi_bus { + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <3>; + + qcom,pm8941@0 { + spmi-slave-container; + reg = <0x0>; + #address-cells = <1>; + #size-cells = <1>; + + qcom,temp-alarm@2400 { + compatible = "qcom,qpnp-temp-alarm"; + reg = <0x2400 0x100>; + interrupts = <0x0 0x24 0x0>; + label = "pm8941_tz"; + qcom,channel-num = <8>; + qcom,threshold-set = <0>; + qcom,temp_alarm-vadc = <&pm8941_vadc>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/thermal/tsens.txt b/Documentation/devicetree/bindings/thermal/tsens.txt new file mode 100644 index 000000000000..53b2463a79dd --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/tsens.txt @@ -0,0 +1,107 @@ +Qualcomm's TSENS driver + +The TSENS driver supports reading temperature from sensors across +the MSM. The driver defaults to support a 10 bit ADC. + +The driver uses the Thermal sysfs framework to provide thermal +clients the ability to enable/disable the sensors, read trip zones, +read cool/warm temperature thresholds, set temperature thresholds +for cool/warm notification and receive notification on temperature +threshold events. + +TSENS node + +Required properties: +- compatible : should be "qcom,msm-tsens" for 8974, 9625, 8084, Samarium TSENS driver. + should be "qcom,msm8x10-tsens" for 8x10 TSENS driver. + should be "qcom,msm8x26-tsens" for 8x26 TSENS driver. + should be "qcom,fsm9900-tsens" for 9900 TSENS driver. + should be "qcom,mdm9630-tsens" for 9630 TSENS driver. + should be "qcom,msm8994-tsens" for 8994 TSENS driver. + should be "qcom,msm8996-tsens" for 8996 TSENS driver. + should be "qcom,msm8992-tsens" for 8992 TSENS driver. + should be "qcom,msm8916-tsens" for 8916 TSENS driver. + should be "qcom,msm8939-tsens" for 8939 TSENS driver. + should be "qcom,msm8909-tsens" for 8909 TSENS driver. + should be "qcom,msm8952-tsens" for 8952 TSENS driver. + should be "qcom,msmzirc-tsens" for zirc TSENS driver. + should be "qcom,mdm9607-tsens" for 9607 TSENS driver. + should be "qcom,msmtitanium-tsens" for titanium TSENS driver. + should be "qcom,msm8937-tsens" for 8937 TSENS driver. + should be "qcom,msmgold-tsens" for gold TSENS driver. + should be "qcom,msm8998-tsens" for 8998 TSENS driver. + should be "qcom,msmhamster-tsens" for hamster TSENS driver. + should be "qcom,sdm660-tsens" for 660 TSENS driver. + should be "qcom,sdm630-tsens" for 630 TSENS driver. + The compatible property is used to identify the respective fusemap to use + for the corresponding SoC. +- reg : offset and length of the TSENS registers with associated property in reg-names + as "tsens_physical" and QFPROM registers with associated property in reg-names + as "tsens_eeprom_physical". The efuse registers are used for storing + the calibration data for the individual sensors. If the gain and offset are + programmed by the TSENS control registers then adding the QFPROM register property + is optional. +- reg-names : resource names used for the physical address of the TSENS + registers, the QFPROM efuse primary calibration address region, + Should be "tsens_physical" for physical address of the TSENS, + "tsens_eeprom_physical" for physical address where primary + calibration data is stored. This includes the backup + calibration address region if TSENS calibration data is stored + in the region. The reg-name "tsens_eeprom_physical" property is + optional if the gain and offset are programmed by the TSENS + control registers and the status registers directly reports the TSENS + temperature readings. +- interrupts : TSENS interrupt to notify Upper/Lower temperature threshold. +- interrupt-names: Should be "tsens-upper-lower" for temperature threshold. + Add "tsens-critical" for Critical temperature threshold notification + in addition to "tsens-upper-lower" for 8996 TSENS since + 8996 supports Upper/Lower and Critical temperature threshold. +- qcom,sensors : Total number of available Temperature sensors for TSENS. +- qcom,slope : One point calibration characterized slope data for each + sensor used to compute the offset. Slope is represented + as ADC code/DegC and the value is multipled by a factor + of 1000. If gain and offset are programmed by the TSENS control + registers then this property is optional. + +Optional properties: +- qcom,calibration-less-mode : If present the pre-characterized data for offsets + are used else it defaults to use calibration data from QFPROM. +- qcom,tsens-local-init : If the flag is present the TSENS control registers are + initialized. If the boot configures the control register there is + no need to re-initialize them. The control registers are also + under a secure domain which can prevent them from being initialized + locally. +- qcom,sensor-id : If the flag is present map the TSENS sensors based on the + remote sensors that are enabled in HW. Ensure the mapping is not + more than the number of supported sensors. +- qcom,client-id : If the flag is present use it to identify the SW ID mapping + used to associate it with the controller and the physical sensor + mapping within the controller. The physical sensor mapping within + each controller is done using the qcom,sensor-id property. If the + property is not present the SW ID mapping with default from 0 to + total number of supported sensors with each controller instance. +- qcom,valid-status-check: If property is present, check the VALID bit is set + before reporting the temperature data. +- qcom,temp1-offset: If flag is present, Use these offset values + to be added for 30 deg calib points. +- qcom,temp2-offset: If flag is present, Use these offset values + to be added for 120 deg calib points. +- qcom,cycle-monitor: If flag is present, Use the value for cycle + completion monitoring. +- qcom,wd-bark: If flag is present, Use the value for watchdog bark. + +Example: + +tsens@fc4a8000 { + compatible = "qcom,msm-tsens"; + reg = <0xfc4a8000 0x2000>, + <0xfc4b8000 0x1000>; + reg-names = "tsens_physical", + "tsens_eeprom_physical"; + interrupts = <0 184 0>; + interrupt-names = "tsens-upper-lower"; + qcom,calibration-less-mode; + qcom,sensors = <11>; + qcom,slope = <3200 3200 3200 3200 3200 3200 3200 3200 3200 + 3200>; +}; diff --git a/Documentation/devicetree/bindings/tty/serial/msm_serial_hs.txt b/Documentation/devicetree/bindings/tty/serial/msm_serial_hs.txt new file mode 100644 index 000000000000..031be45f81b8 --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/msm_serial_hs.txt @@ -0,0 +1,121 @@ +* Qualcomm MSM HSUART + +Required properties: +- compatible : + - "qcom,msm-hsuart-v14" to be used for UARTDM Core v1.4 +- reg : offset and length of the register set for both the device, + uart core and bam core +- reg-names : + - "core_mem" to be used as name of the uart core + - "bam_mem" to be used as name of the bam core +- interrupts : interrupts for both the device,uart core and bam core +- interrupt-names : + - "core_irq" to be used as uart irq + - "bam irq" to be used as bam irq +- #interrupt-cells: Specifies the number of cells needed to encode an interrupt + source. The type shall be a <u32> and the value shall be 1 +- #address-cells: Specifies the number of cells needed to encode an address. + The type shall be <u32> and the value shall be 0 +- interrupt-parent = It is needed for interrupt mapping +- bam-tx-ep-pipe-index : BAM TX Endpoint Pipe Index for HSUART +- bam-rx-ep-pipe-index : BAM RX Endpoint Pipe Index for HSUART + +BLSP has a static pipe allocation and assumes a pair-pipe for each uart core. +Pipes [2*i : 2*i+1] are allocated for UART cores where i = [0 : 5]. +Hence, Minimum and Maximum permitted value of endpoint pipe index to be used +with uart core is 0 and 11 respectively. + +There is one HSUART block used in MSM devices, +"qcom,msm-hsuart-v14". The msm-serial-hs driver is +able to handle this, and matches against the "qcom,msm-hsuart-v14" +as the compatibility. + +The registers for the "qcom,msm-hsuart-v14" device need to specify both +register blocks - uart core and bam core. + +Example: + + uart7: uart@f995d000 { + compatible = "qcom,msm-hsuart-v14"; + reg = <0xf995d000 0x1000>, + <0xf9944000 0x5000>; + reg-names = "core_mem", "bam_mem"; + interrupt-names = "core_irq", "bam_irq"; + #address-cells = <0>; + interrupt-parent = <&uart7>; + interrupts = <0 1>; + #interrupt-cells = <1>; + interrupt-map = <0 &intc 0 113 0 + 1 &intc 0 239 0> + qcom,bam-tx-ep-pipe-index = <0>; + qcom,bam-rx-ep-pipe-index = <1>; + }; + +Optional properties: +- qcom,<gpio-name>-gpio : handle to the GPIO node, see "gpios property" in +Documentation/devicetree/bindings/gpio/gpio.txt. +"gpio-name" can be "tx", "rx", "cts" and "rfr" based on number of UART GPIOs +need to configured. +Gpio's are optional if it is required to be not configured by UART driver or +case where there is nothing connected and we want to use internal loopback mode +for uart. +- qcom, wakeup_irq : UART RX GPIO IRQ line to be configured as wakeup source. +- qcom,inject-rx-on-wakeup : inject_rx_on_wakeup enables feature where on +receiving interrupt with UART RX GPIO IRQ line (i.e. above wakeup_irq property), +HSUART driver injects provided character with property rx_to_inject. +- qcom, rx-char-to-inject : The character to be inserted on wakeup. +- qcom, no-suspend-delay : This decides system to go to suspend immediately +or not + +- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for +below optional properties: + - qcom,msm_bus,name + - qcom,msm_bus,num_cases + - qcom,msm_bus,active_only + - qcom,msm_bus,num_paths + - qcom,msm_bus,vectors + +Aliases : +An alias may be optionally used to bind the UART device to a TTY device +(ttyHS<alias_num>) with a given alias number. Aliases are of the form +uart<n> where <n> is an integer representing the alias number to use. +On systems with multiple UART devices present, an alias may optionally be +defined for such devices. The alias value should be from 0 to 255. + +Example: + + aliases { + uart4 = &uart7; // This device will be enumerated as ttyHS4 + }; + + uart7: uart@f995d000 { + compatible = "qcom,msm-hsuart-v14" + reg = <0x19c40000 0x1000">, + <0xf9944000 0x5000>; + reg-names = "core_mem", "bam_mem"; + interrupt-names = "core_irq", "bam_irq", "wakeup_irq"; + #address-cells = <0>; + interrupt-parent = <&uart7>; + interrupts = <0 1 2>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xffffffff>; + interrupt-map = <0 &intc 0 113 0 + 1 &intc 0 239 0 + 2 &msmgpio 42 0>; + qcom,tx-gpio = <&msmgpio 41 0x00>; + qcom,rx-gpio = <&msmgpio 42 0x00>; + qcom,cts-gpio = <&msmgpio 43 0x00>; + qcom,rfr-gpio = <&msmgpio 44 0x00>; + qcom,inject-rx-on-wakeup = <1>; + qcom,rx-char-to-inject = <0xFD>; + + qcom,bam-tx-ep-pipe-index = <0>; + qcom,bam-rx-ep-pipe-index = <1>; + + qcom,msm-bus,name = "uart7"; + qcom,msm-bus,num-cases = <2>; + qcom,msm-bus,num-paths = <1>; + qcom,msm-bus,vectors-KBps = + <84 512 0 0>, + <84 512 500 800>; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt index 070baf4d7d97..f836fc7ab439 100644 --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt @@ -8,7 +8,10 @@ contain a phandle reference to UFS PHY node. Required properties: - compatible : compatible list, contains "qcom,ufs-phy-qmp-20nm" - or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in use. + or "qcom,ufs-phy-qmp-14nm" or "qcom,ufs-phy-qmp-v3" + or "qcom,ufs-phy-qrbtc-v2" or + "qcom,ufs-phy-qmp-v3-660" + according to the relevant phy in use. - reg : should contain PHY register address space (mandatory), - reg-names : indicates various resources passed to driver (via reg proptery) by name. Required "reg-names" is "phy_mem". @@ -27,6 +30,8 @@ Optional properties: - vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply - vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply - vddp-ref-clk-always-on : specifies if this supply needs to be kept always on +- qcom,disable-lpm : disable various LPM mechanisms in UFS for platform compatibility + (limit link to PWM Gear-1, 1-lane slow mode; disable hibernate, and avoid suspend/resume) Example: diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 03c0e989e020..8b99dbce871b 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -11,6 +11,11 @@ Required properties: "qcom,ufshc" - interrupts : <interrupt mapping for UFS host controller IRQ> - reg : <registers mapping> + first entry should contain UFS host controller register address space (mandatory), + second entry is the device ref. clock control register map (optional). +- reset : reset specifier pair consists of phandle for the reset provider + and reset lines used by this controller. +- reset-names : reset signal name strings sorted in the same order as the resets property. Optional properties: - phys : phandle to UFS PHY node @@ -38,6 +43,22 @@ Optional properties: defined or a value in the array is "0" then it is assumed that the frequency is set by the parent clock or a fixed rate clock source. +- rpm-level : UFS Runtime power management level. Following PM levels are suppported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active state but Link in Hibern8 state + 2 - UFS device in Sleep state but Link in active state + 3 - UFS device in Sleep state and Link in hibern8 state (default PM level) + 4 - UFS device in Power-down state and Link in Hibern8 state + 5 - UFS device in Power-down state and Link in OFF state (Lowest power consumption) +- spm-level : UFS System power management level. Allowed PM levels are same as rpm-level. +- ufs-qcom-crypto : phandle to UFS-QCOM ICE (Inline Cryptographic Engine) node +- lanes-per-direction: number of lanes available per direction - either 1 or 2. + Note that it is assume same number of lanes is used both directions at once. + If not specified, default is 2 lanes per direction. +- pinctrl-names, pinctrl-0, pinctrl-1,.. pinctrl-n: Refer to "Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt" + for these optional properties + + Note: If above properties are not defined it can be assumed that the supply regulators or clocks are always on. @@ -45,9 +66,10 @@ regulators or clocks are always on. Example: ufshc@0xfc598000 { compatible = "jedec,ufs-1.1"; - reg = <0xfc598000 0x800>; + reg = <0xfc598000 0x800>, <0xfd512074 0x4>; interrupts = <0 28 0>; + ufs-qcom-crypto = <&ufs_ice>; vdd-hba-supply = <&xxx_reg0>; vdd-hba-fixed-regulator; vcc-supply = <&xxx_reg1>; @@ -61,6 +83,112 @@ Example: clocks = <&core 0>, <&ref 0>, <&iface 0>; clock-names = "core_clk", "ref_clk", "iface_clk"; freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; + resets = <clock_gcc GCC_UFS_BCR>; + reset-names = "core_reset"; phys = <&ufsphy1>; phy-names = "ufsphy"; + rpm-level = <3>; + spm-level = <5>; + }; + +==== MSM UFS platform driver properties ===== +* For UFS host controller in MSM platform following clocks are required - + Controller clock source - + "core_clk_src", max-clock-frequency-hz = 200MHz + + Controller System clock branch: + "core_clk" - Controller core clock + + AHB/AXI interface clocks: + "iface_clk" - AHB interface clock + "bus_clk" - AXI bus master clock + + PHY to controller symbol synchronization clocks: + "rx_lane0_sync_clk" - RX Lane 0 + "rx_lane1_sync_clk" - RX Lane 1 + "tx_lane0_sync_clk" - TX Lane 0 + "tx_lane1_sync_clk" - TX Lane 1 + + Optional reference clock input to UFS device + "ref_clk", max-clock-frequency-hz = 19.2MHz + +* Following bus parameters are required - +- qcom,msm-bus,name +- qcom,msm-bus,num-cases +- qcom,msm-bus,num-paths +- qcom,msm-bus,vectors-KBps +For the above four properties please refer to +Documentation/devicetree/bindings/arm/msm/msm_bus.txt +Note: The instantaneous bandwidth (IB) value in the vectors-KBps field should + be zero as UFS data transfer path doesn't have latency requirements and + voting for aggregated bandwidth (AB) should take care of providing + optimum throughput requested. + +- qcom,bus-vector-names: specifies string IDs for the corresponding +bus vectors in the same order as qcom,msm-bus,vectors-KBps property. + +* The following parameters are optional, but required in order for PM QoS to be +enabled and functional in the driver: +- qcom,pm-qos-cpu-groups: arrays of unsigned integers representing the cpu groups. + The number of values in the array defines the number of cpu-groups. + Each value is a bit-mask defining the cpus that take part in that cpu group. + i.e. if bit N is set, then cpuN is a part of the cpu group. So basically, + a cpu group corelated to a cpu cluster. + A PM QoS request object is maintained for each cpu-group. +- qcom,pm-qos-cpu-group-latency-us: array of values used for PM QoS voting, one for each cpu-group defined. + the number of values must match the number of values defined in + qcom,pm-qos-cpu-mask property. +- qcom,pm-qos-default-cpu: PM QoS voting is based on the cpu associated with each IO request by the block layer. + This defined the default cpu used for PM QoS voting in case a specific cpu value is not available. + +- qcom,vddp-ref-clk-supply : reference clock to ufs device. Controlled by the host driver. +- qcom,vddp-ref-clk-max-microamp : specifies max. load that can be drawn for + ref-clk supply. +Example: + ufshc@0xfc598000 { + ... + + qcom,msm-bus,name = "ufs1"; + qcom,msm-bus,num-cases = <22>; + qcom,msm-bus,num-paths = <2>; + qcom,msm-bus,vectors-KBps = + <95 512 0 0>, <1 650 0 0>, /* No vote */ + + <95 512 922 0>, <1 650 1000 0>, /* PWM G1 */ + <95 512 1844 0>, <1 650 1000 0>, /* PWM G2 */ + <95 512 3688 0>, <1 650 1000 0>, /* PWM G3 */ + <95 512 7376 0>, <1 650 1000 0>, /* PWM G4 */ + <95 512 1844 0>, <1 650 1000 0>, /* PWM G1 L2 */ + <95 512 3688 0>, <1 650 1000 0>, /* PWM G2 L2 */ + <95 512 7376 0>, <1 650 1000 0>, /* PWM G3 L2 */ + <95 512 14752 0>, <1 650 1000 0>, /* PWM G4 L2 */ + + <95 512 127796 0>, <1 650 1000 0>, /* HS G1 RA */ + <95 512 255591 0>, <1 650 1000 0>, /* HS G2 RA */ + <95 512 511181 0>, <1 650 1000 0>, /* HS G3 RA */ + <95 512 255591 0>, <1 650 1000 0>, /* HS G1 RA L2 */ + <95 512 511181 0>, <1 650 1000 0>, /* HS G2 RA L2 */ + <95 512 1022362 0>, <1 650 1000 0>, /* HS G3 RA L2 */ + + <95 512 149422 0>, <1 650 1000 0>, /* HS G1 RB */ + <95 512 298189 0>, <1 650 1000 0>, /* HS G2 RB */ + <95 512 596378 0>, <1 650 1000 0>, /* HS G3 RB */ + <95 512 298189 0>, <1 650 1000 0>, /* HS G1 RB L2 */ + <95 512 596378 0>, <1 650 1000 0>, /* HS G2 RB L2 */ + <95 512 1192756 0>, <1 650 1000 0>, /* HS G3 RB L2 */ + + <95 512 4096000 0>, <1 650 1000 0>; /* Max. bandwidth */ + + qcom,bus-vector-names = "MIN", + "PWM_G1_L1", "PWM_G2_L1", "PWM_G3_L1", "PWM_G4_L1", + "PWM_G1_L2", "PWM_G2_L2", "PWM_G3_L2", "PWM_G4_L2", + "HS_RA_G1_L1", "HS_RA_G2_L1", "HS_RA_G3_L1", + "HS_RA_G1_L2", "HS_RA_G2_L2", "HS_RA_G3_L2", + "HS_RB_G1_L1", "HS_RB_G2_L1", "HS_RB_G3_L1", + "HS_RB_G1_L2", "HS_RB_G2_L2", "HS_RB_G3_L2", + "MAX"; + + qcom,pm-qos-cpu-groups = <0x03 0x0C>; /* group0: cpu0, cpu1, group1: cpu2, cpu3 */ + qcom,pm-qos-cpu-group-latency-us = <200 300>; /* group0: 200us, group1: 300us */ + qcom,pm-qos-default-cpu = <0>; }; diff --git a/Documentation/devicetree/bindings/uio/msm_sharedmem.txt b/Documentation/devicetree/bindings/uio/msm_sharedmem.txt new file mode 100644 index 000000000000..749c6e856819 --- /dev/null +++ b/Documentation/devicetree/bindings/uio/msm_sharedmem.txt @@ -0,0 +1,18 @@ +msm_sharedmem provides the shared memory addresses for various clients in user-space + +Required properties: +- compatible: Must be "qcom,sharedmem-uio" +- reg : The address and size of the shared memory. The address/sizes may vary. + A reg address of Zero indicates that the shared memory is dynamically + allocated using dma_alloc_coherent. A non zero reg address is used + directly. +- reg-names : Indicates various client-names. +- qcom,client-id : The client id for the QMI clients. + +Example: + qcom,msm_sharedmem@0dc80000 { + compatible = "qcom,sharedmem-uio"; + reg = <0x0dc80000 0x00180000>, + reg-names = "rmtfs"; + qcom,client-id = <0x00000001>; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index fb2ad0acedbd..ddca4c39e2de 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,6 +6,10 @@ DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties Required properties: - compatible: must be "snps,dwc3" - reg : Address and length of the register set for the device + Required regs are: + - "core_base" : USB DWC3 controller register set. + - "ahb2phy_base" : AHB2PHY register base. It is used to update read/write + wait cycle for accessing PHY. - interrupts: Interrupts used by the dwc3 controller. Optional properties: @@ -46,13 +50,30 @@ Optional properties: - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. + - snps,nominal-elastic-buffer: When set, the nominal elastic buffer setting + is used. By default, the half-full setting is used. + - snps,usb3-u1u2-disable: If present, disable u1u2 low power modes for DWC3 core + controller in SS mode. + - snps,disable-clk-gating: If present, disable controller's internal clock gating. Default it is enabled. + - snps,bus-suspend-enable: If present then controller supports low power mode + during bus suspend. + - snps,num-normal-evt-buffs: If present, specifies number of normal event buffers. Default is 1. + - snps,num-gsi-evt-buffs: If present, specifies number of GSI based hardware accelerated event buffers. + 1 event buffer is needed per h/w accelerated endpoint. + - xhci-imod-value: Interrupt moderation interval for host mode (in increments of 250nsec). This is usually a subnode to DWC3 glue to which it is connected. dwc3@4a030000 { compatible = "snps,dwc3"; - reg = <0x4a030000 0xcfff>; + reg = <0x07600000 0xfc000>, + <0x7416000 0x400>; + reg-names = "core_base", + "ahb2phy_base"; interrupts = <0 92 4> usb-phy = <&usb2_phy>, <&usb3,phy>; tx-fifo-resize; + snps,usb3-u1u2-disable; + snps,num-gsi-evt-buffs = <0x2>; + xhci-imod-value = <4000>; }; diff --git a/Documentation/devicetree/bindings/usb/msm-dbm.txt b/Documentation/devicetree/bindings/usb/msm-dbm.txt new file mode 100644 index 000000000000..6ded52615f21 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-dbm.txt @@ -0,0 +1,15 @@ +MSM DBM (Device Bus Manager) + +Required properties : +- compatible : must be one of "qcom,usb-dbm-1p4", or "qcom,usb-dbm-1p5" +- reg : offset and length of the register set in the memory map. + +Optional properties : +- qcom,reset-ep-after-lpm-resume: If present, dbm requires ep reset after + going to lpm + +Example MSM DBM (Device Bus Manager) device node : + dbm_1p4: dbm@f92f8000 { + compatible = "qcom,usb-dbm-1p4"; + reg = <0xf92f8000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/usb/msm-phy.txt b/Documentation/devicetree/bindings/usb/msm-phy.txt new file mode 100644 index 000000000000..032f07535415 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-phy.txt @@ -0,0 +1,234 @@ +MSM USB PHY transceivers + +HSUSB PHY + +Required properties: + - compatible: Should be "qcom,usb-hsphy" + - reg: Address and length of the register set for the device + Required regs are: + "core" : the QSCRATCH base register set + - <supply-name>-supply: phandle to the regulator device tree node + Required "supply-name" examples are: + "vdd" : vdd supply for HSPHY digital circuit operation + "vdda18" : 1.8v supply for HSPHY + "vdda33" : 3.3v supply for HSPHY + - qcom,vdd-voltage-level: This property must be a list of three integer + values (no, min, max) where each value represents either a voltage in + microvolts or a value corresponding to voltage corner + +Optional properties: + - reg: Additional registers + "tcsr" : top-level CSR register to be written during power-on reset + initialize the internal MUX that controls whether this PHY is + used with the USB3 or the USB2 controller. + + - qcom,hsphy-init: Init value used to override HSPHY parameters into + QSCRATCH register. This 32-bit value represents parameters as follows: + bits 0-5 PARAMETER_OVERRIDE_A + bits 6-12 PARAMETER_OVERRIDE_B + bits 13-19 PARAMETER_OVERRIDE_C + bits 20-25 PARAMETER_OVERRIDE_D + - qcom,ext-vbus-id: If present, indicates that the PHY does not handle VBUS and ID changes. + - qcom,vbus-valid-override: If present, indicates VBUS pin is not connected to + the USB PHY and the controller must rely on external VBUS notification in + order to manually enable the D+ pull-up resistor. + - qcom,primary-phy: If present, indicates this is a secondary PHY and is + dependent on the primary PHY referenced by this phandle. + - qcom,set-pllbtune: If present, PLL tune is required in PHY initialization. + - qcom,num_ports: Indicates the number of ports that supported by the HS PHY. + If omitted, defaults to 1 + - qcom,sleep-clk-reset: If present, the HSUSB PHY sleep clock supports the clk_reset + operation, and should be called during initialization. + - qcom,vdda-force-on: If present, HW requires a workaround that forces 1.8V and 3.1V + regulator supplies to be left on even when PHY enters into + low power mode. + +Example: + hsphy@f9200000 { + compatible = "qcom,usb-hsphy"; + reg = <0xf9200000 0xfc000>; + qcom,hsphy-init = <0x00D191A4>; + vdd-supply = <&pm8841_s2_corner>; + vdda18-supply = <&pm8941_l6>; + vdda33-supply = <&pm8941_l24>; + qcom,num_of_ports = <3>; + qcom,vdd-voltage-level = <1 5 7>; + }; + +SSUSB PHY + +Required properties: + - compatible: Should be "qcom,usb-ssphy" or "qcom,usb-ssphy-qmp-v2" + - reg: Address and length of the register set for the device + - <supply-name>-supply: phandle to the regulator device tree node + Required "supply-name" examples are: + "vdd" : vdd supply for SSPHY digital circuit operation + "vdda18" : 1.8v high-voltage analog supply for SSPHY + - qcom,vdd-voltage-level: This property must be a list of three integer + values (no, min, max) where each value represents either a voltage in + microvolts or a value corresponding to voltage corner + +Optional properties: + - qcom,vbus-valid-override: If present, indicates VBUS pin is not connected to + the USB PHY and the controller must rely on external VBUS notification in + order to manually relay the notification to the SSPHY. + - qcom,deemphasis-value: This property if present represents ss phy + deemphasis value to be used for overriding into SSPHY register. + - qcom,primary-phy: If present, indicates this is a secondary PHY and is + dependent on the primary PHY referenced by this phandle. + +Example: + ssphy@f9200000 { + compatible = "qcom,usb-ssphy"; + reg = <0xf9200000 0xfc000>; + vdd-supply = <&pm8841_s2_corner>; + vdda18-supply = <&pm8941_l6>; + qcom,vdd-voltage-level = <1 5 7>; + qcom,deemphasis-value = <26>; + }; + +SSUSB-QMP PHY + +Required properties: + - compatible: Should be "qcom,usb-ssphy-qmp", "qcom,usb-ssphy-qmp-v1" or + "qcom,usb-ssphy-qmp-v2" + - reg: Address and length of the register set for the device + Required regs are: + "qmp_phy_base" : QMP PHY Base register set. + - "vls_clamp_reg" : top-level CSR register to be written to enable phy vls + clamp which allows phy to detect autonomous mode. + - <supply-name>-supply: phandle to the regulator device tree node + Required "supply-name" examples are: + "vdd" : vdd supply for SSPHY digital circuit operation + "core" : high-voltage analog supply for SSPHY + - clocks: a list of phandles to the PHY clocks. Use as per + Documentation/devicetree/bindings/clock/clock-bindings.txt + - clock-names: Names of the clocks in 1-1 correspondence with the "clocks" + property. Required clocks are "aux_clk" and "pipe_clk". + - qcom,vdd-voltage-level: This property must be a list of three integer + values (no, min, max) where each value represents either a voltage in + microvolts or a value corresponding to voltage corner + - qcom,qmp-phy-init-seq: QMP PHY initialization sequence with reg offset, its + value, delay after register write. It is not must property to have for emulation. + - qcom,qmp-phy-reg-offset: Provides important phy register offsets in an order + defined in the phy driver. Provide below mentioned register offsets in order: + USB3_PHY_PCS_STATUS, + USB3_PHY_AUTONOMOUS_MODE_CTRL, + USB3_PHY_LFPS_RXTERM_IRQ_CLEAR, + USB3_PHY_POWER_DOWN_CONTROL, + USB3_PHY_SW_RESET, + USB3_PHY_START +- resets: reset specifier pair consists of phandle for the reset controller + and reset lines used by this controller. +- reset-names: reset signal name strings sorted in the same order as the resets + property. + +Optional properties: + - reg: Additional register set of address and length to control QMP PHY are: + "tcsr_usb3_dp_phymode" : top-level CSR register to be written to select + super speed usb qmp phy. + - clocks: a list of phandles to the PHY clocks. Use as per + Documentation/devicetree/bindings/clock/clock-bindings.txt + - clock-names: Names of the clocks in 1-1 correspondence with the "clocks" + property. "cfg_ahb_clk" is an optional clock. + - qcom,vbus-valid-override: If present, indicates VBUS pin is not connected to + the USB PHY and the controller must rely on external VBUS notification in + order to manually relay the notification to the SSPHY. + - qcom,emulation: Indicates that we are running on emulation platform. + - qcom,core-voltage-level: This property must be a list of three integer + values (no, min, max) where each value represents either a voltage in + microvolts or a value corresponding to voltage corner. + +Example: + ssphy0: ssphy@f9b38000 { + compatible = "qcom,usb-ssphy-qmp"; + reg = <0xf9b38000 0x16c>, + <0x01947244 0x4>; + reg-names = "qmp_phy_base", + "vls_clamp_reg"; + vdd-supply = <&pmd9635_l4>; + vdda18-supply = <&pmd9635_l8>; + qcom,vdd-voltage-level = <0 900000 1050000>; + qcom,vbus-valid-override; + + clocks = <&clock_gcc clk_gcc_usb3_phy_aux_clk>, + <&clock_gcc clk_gcc_usb3_phy_pipe_clk>, + <&clock_gcc clk_gcc_usb_phy_cfg_ahb2phy_clk>, + <&clock_gcc clk_ln_bb_clk1>, + <&clock_gcc clk_gcc_usb3_clkref_clk>; + + clock-names = "aux_clk", "pipe_clk", "cfg_ahb_clk", + "ref_clk_src", "ref_clk"; + + resets = <&clock_gcc GCC_USB3_PHY_BCR>, + <&clock_gcc GCC_USB3PHY_PHY_BCR>; + reset-names = "phy_reset", + "phy_phy_reset"; + + }; + +QUSB2 High-Speed PHY + +Required properties: + - compatible: Should be "qcom,qusb2phy" or "qcom,qusb2phy-v2" + - reg: Address and length of the QUSB2 PHY register set + - reg-names: Should be "qusb_phy_base". + - <supply-name>-supply: phandle to the regulator device tree node + Required supplies are: + "vdd" : vdd supply for digital circuit operation + "vdda18" : 1.8v high-voltage analog supply + "vdda33" : 3.3v high-voltage analog supply + "vdda12" : 1.2v high-voltage analog supply + - qcom,vdd-voltage-level: This property must be a list of three integer + values (no, min, max) where each value represents either a voltage in + microvolts or a value corresponding to voltage corner + - phy_type: Should be one of "ulpi" or "utmi". ChipIdea core uses "ulpi" mode. + - resets: reset specifier pair consists of phandle for the reset controller + and reset lines used by this controller. + - reset-names: reset signal name strings sorted in the same order as the resets + property. + +Optional properties: + - reg-names: Additional registers corresponding with the following: + "efuse_addr": EFUSE address to read and update analog tune parameter. + "emu_phy_base" : phy base address used for programming emulation target phy. + "ref_clk_addr" : ref_clk bcr address used for on/off ref_clk before reset. + "tcsr_clamp_dig_n" : To enable/disable digital clamp to the phy. When + de-asserted, it will prevent random leakage from qusb2 phy resulting from + out of sequence turn on/off of 1p8, 3p3 and DVDD regulators. + - clocks: a list of phandles to the PHY clocks. Use as per + Documentation/devicetree/bindings/clock/clock-bindings.txt + - clock-names: Names of the clocks in 1-1 correspondence with the "clocks" + property. "cfg_ahb_clk", "ref_clk_src" and "ref_clk" are optional clocks. + - qcom,qusb-phy-init-seq: QUSB PHY initialization sequence with value,reg pair. + - qcom,qusb-phy-host-init-seq: QUSB PHY initialization sequence for host mode + with value,reg pair. + - qcom,emu-init-seq : emulation initialization sequence with value,reg pair. + - qcom,phy-pll-reset-seq : emulation PLL reset sequence with value,reg pair. + - qcom,emu-dcm-reset-seq : emulation DCM reset sequence with value,reg pair. + - qcom,efuse-bit-pos: start bit position within EFUSE register + - qcom,efuse-num-bits: Number of bits to read from EFUSE register + - qcom,emulation: Indicates that we are running on emulation platform. + - qcom,hold-reset: Indicates that hold QUSB PHY into reset state. + - qcom,phy-clk-scheme: Should be one of "cml" or "cmos" if ref_clk_addr is provided. + - qcom,major-rev: provide major revision number to differentiate power up sequence. default is 2.0 + +Example: + qusb_phy: qusb@f9b39000 { + compatible = "qcom,qusb2phy"; + reg = <0x00079000 0x7000>; + reg-names = "qusb_phy_base"; + vdd-supply = <&pm8994_s2_corner>; + vdda18-supply = <&pm8994_l6>; + vdda33-supply = <&pm8994_l24>; + qcom,vdd-voltage-level = <1 5 7>; + qcom,efuse-bit-pos = <21>; + qcom,efuse-num-bits = <3>; + + clocks = <&clock_rpm clk_ln_bb_clk>, + <&clock_gcc clk_gcc_rx2_usb1_clkref_clk>, + <&clock_gcc clk_gcc_usb_phy_cfg_ahb2phy_clk>; + clock-names = "ref_clk_src", "ref_clk", "cfg_ahb_clk"; + resets = <&clock_gcc GCC_QUSB2PHY_PRIM_BCR>; + reset-names = "phy_reset"; + }; diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt new file mode 100644 index 000000000000..47fad8aa4a1a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt @@ -0,0 +1,122 @@ +MSM SuperSpeed USB3.0 SoC controller + +Required properties : +- compatible : should be "qcom,dwc-usb3-msm" + - reg: Address and length of the register set for the device + Required regs are: + "core_base" : usb controller register set +- interrupts: IRQ lines used by this controller +- interrupt-names : Interrupt resource entries are : + "hs_phy_irq" : Interrupt from HS PHY for asynchronous events in LPM. + "pwr_event_irq" : Interrupt to controller for asynchronous events in LPM. + Used for SS-USB power events. + - clocks: a list of phandles to the controller clocks. Use as per + Documentation/devicetree/bindings/clock/clock-bindings.txt + - clock-names: Names of the clocks in 1-1 correspondence with the "clocks" + property. Required clocks are "xo", "iface_clk", "core_clk", "sleep_clk" + and "utmi_clk". +- resets: reset specifier pair consists of phandle for the reset provider + and reset lines used by this controller. +- reset-names: reset signal name strings sorted in the same order as the resets + property. +- qcom,core-clk-rate: clock frequency to be set for USB master clock. + +Optional properties : +- reg: Additional registers + "tcsr_base" : top-level CSR register to be written during power-on reset + initialize the internal MUX that controls whether to use USB3 controller + with primary port. + "ahb2phy_base" : top-level register to configure read/write wait cycle with + both QMP and QUSB PHY registers. +- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for + below optional properties: + - qcom,msm_bus,name + - qcom,msm_bus,num_cases + - qcom,msm_bus,num_paths + - qcom,msm_bus,vectors +- interrupt-names : Optional interrupt resource entries are: + "pmic_id_irq" : Interrupt from PMIC for external ID pin notification. + "ss_phy_irq" : Interrupt from super speed phy for wake up notification. + - clocks: a list of phandles to the controller clocks. Use as per + Documentation/devicetree/bindings/clock/clock-bindings.txt + - clock-names: Names of the clocks in 1-1 correspondence with the "clocks" + property. Optional clocks are "bus_aggr_clk", "noc_aggr_clk" and "cfg_ahb_clk". +- qcom,charging-disabled: If present then battery charging using USB + is disabled. +- vbus_dwc3-supply: phandle to the 5V VBUS supply regulator used for host mode. +- USB3_GDSC-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. +- qcom,dwc-usb3-msm-tx-fifo-size: If present, represents RAM size available for + TX fifo allocation in bytes +- qcom,usb-dbm : phandle for the DBM device +- qcom,lpm-to-suspend-delay-ms: Indicates timeout (in milliseconds) to release wakeup source + after USB is kept into LPM. +- qcom,ext-hub-reset-gpio: This corresponds to gpio which is used for HUB reset. +- qcom,disable-dev-mode-pm: If present, it disables PM runtime functionality for device mode. +- qcom,disable-host-mode-pm: If present, it disables XHCI PM runtime functionality when USB + host mode is used. +- qcom,core-clk-rate-hs: If present, indicates min core clock frequency required to support + hs speed. +- extcon: phandles to external connector devices. First phandle should point to + external connector, which provide "USB" cable events, the second + should point to external connector device, which provide "USB-HOST" + cable events. A single phandle may be specified if a single connector + device provides both "USB" and "USB-HOST" events. +- qcom,pm-qos-latency: This represents max tolerable CPU latency in microsecs, + which is used as a vote by driver to get max performance in perf mode. + +Sub nodes: +- Sub node for "DWC3- USB3 controller". + This sub node is required property for device node. The properties of this subnode + are specified in dwc3.txt. + +Example MSM USB3.0 controller device node : + usb@f9200000 { + compatible = "qcom,dwc-usb3-msm"; + reg = <0xf9200000 0xfc000>, + <0xfd4ab000 0x4>, + <0xf9b3e000 0x3ff>; + reg-names = "core_base", + "tcsr_base", + "ahb2phy_base", + interrupts = <0 133 0>; + interrupt-names = "hs_phy_irq"; + vbus_dwc3-supply = <&pm8941_mvs1>; + USB3_GDSC-supply = <&gdsc_usb30>; + qcom,dwc-usb3-msm-dbm-eps = <4> + qcom,dwc_usb3-adc_tm = <&pm8941_adc_tm>; + qcom,dwc-usb3-msm-tx-fifo-size = <29696>; + qcom,usb-dbm = <&dbm_1p4>; + qcom,lpm-to-suspend-delay-ms = <2>; + qcom,pm-qos-latency = <2>; + + qcom,msm_bus,name = "usb3"; + qcom,msm_bus,num_cases = <2>; + qcom,msm_bus,num_paths = <1>; + qcom,msm_bus,vectors = + <61 512 0 0>, + <61 512 240000000 960000000>; + + clocks = <&clock_gcc clk_gcc_usb30_master_clk>, + <&clock_gcc clk_gcc_cfg_noc_usb3_axi_clk>, + <&clock_gcc clk_gcc_aggre1_usb3_axi_clk>, + <&clock_rpmcc RPM_AGGR2_NOC_CLK>, + <&clock_gcc clk_gcc_usb30_mock_utmi_clk>, + <&clock_gcc clk_gcc_usb30_sleep_clk>, + <&clock_gcc clk_gcc_usb_phy_cfg_ahb2phy_clk>, + <&clock_gcc clk_cxo_dwc3_clk>; + + clock-names = "core_clk", "iface_clk", "bus_aggr_clk", "noc_aggr_clk", + "utmi_clk", "sleep_clk", "cfg_ahb_clk", "xo"; + + resets = <&clock_gcc GCC_USB_30_BCR>; + reset-names = "core_reset"; + + dwc3@f9200000 { + compatible = "synopsys,dwc3"; + reg = <0xf9200000 0xfc000>; + interrupts = <0 131 0>, <0 179 0>; + interrupt-names = "irq", "otg_irq"; + tx-fifo-resize; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/qpnp-pdphy.txt b/Documentation/devicetree/bindings/usb/qpnp-pdphy.txt new file mode 100644 index 000000000000..cf0628a26c5a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/qpnp-pdphy.txt @@ -0,0 +1,74 @@ +Qualcomm QPNP PD PHY - USB Power Delivery Physical layer + +Required properties: +- compatible: Must be "qcom,qpnp-pdphy" +- reg: The base address for this peripheral +- vdd-pdphy-supply: phandle to the VDD supply regulator node +- interrupts: Specifies the interrupt associated with the peripheral. +- interrupt-names: Specifies the interrupt names for the peripheral. Every + available interrupt needs to have an associated name + with it to indentify its purpose. + + The following interrupts are required: + + 0: sig-tx + Triggers when a signal (HardReset or CableReset) + has been sent. + 1: sig-rx + Triggers when a signal has been received. + 2: msg-tx + Triggers when a message has been sent and the + related GoodCRC has been received. + 3: msg-rx + Triggers when a message has been received and + the related GoodCRC was sent successfully. + 4: msg-tx-failed + Triggers when a message failed all its + transmission attempts, either due to a non-idle + bus or missing GoodCRC reply. + 5: msg-tx-discarded + Triggers when a message is received while a + transmission request was in place. The request + itself is discarded. + 6: msg-rx-discarded + Triggers when a message was received but had to + be discarded due to the RX buffer still in use + by SW. + +Optional properties: +- vbus-supply: Regulator that enables VBUS source output +- vconn-supply: Regulator that enables VCONN source output. This will + be supplied on the USB CC line that is not used for + communication when Ra resistance is detected. +- qcom,vconn-uses-external-source: Indicates whether VCONN supply is sourced + from an external regulator. If omitted, then it is + assumed it is connected to VBUS. +- qcom,default-sink-caps: List of 32-bit values representing the nominal sink + capabilities in voltage (millivolts) and current + (milliamps) pairs. + +Example: + qcom,qpnp-pdphy@1700 { + compatible = "qcom,qpnp-pdphy"; + reg = <0x1700 0x100>; + vdd-pdphy-supply = <&pm8998_l24>; + interrupts = <0x2 0x17 0x0 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x1 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x2 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x3 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x4 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x5 IRQ_TYPE_EDGE_RISING>, + <0x2 0x17 0x6 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "sig-tx", + "sig-rx", + "msg-tx", + "msg-rx", + "msg-tx-failed", + "msg-tx-discarded", + "msg-rx-discarded"; + + qcom,default-sink-caps = <5000 3000>, /* 5V @ 3A */ + <9000 3000>, /* 9V @ 3A */ + <12000 2250>; /* 12V @ 2.25A */ + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 55df1d444e9f..91412a10bf65 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -87,6 +87,7 @@ firefly Firefly focaltech FocalTech Systems Co.,Ltd fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. +goodix Goodix. Ltd. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. geniatech Geniatech, Inc. giantplus Giantplus Technology Co., Ltd. @@ -97,6 +98,7 @@ google Google, Inc. grinn Grinn gumstix Gumstix, Inc. gw Gateworks Corporation +halo Halo Microelectronics Co., Ltd. hannstar HannStar Display Corporation haoyu Haoyu Microelectronic Co. Ltd. hardkernel Hardkernel Co., Ltd @@ -119,6 +121,7 @@ intercontrol Inter Control Group invensense InvenSense Inc. isee ISEE 2007 S.L. isil Intersil +ite ITE Tech. Inc. jedec JEDEC Solid State Technology Association karo Ka-Ro electronics GmbH keymile Keymile GmbH @@ -144,6 +147,7 @@ mosaixtech Mosaix Technologies, Inc. moxa Moxa mpl MPL AG msi Micro-Star International Co. Ltd. +mstar MStar Semiconductor, Inc. mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) mundoreader Mundo Reader S.L. murata Murata Manufacturing Co., Ltd. @@ -171,6 +175,7 @@ parade Parade Technologies Inc. pericom Pericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd +pixart PixArt Imaging Inc plathome Plat'Home Co., Ltd. plda PLDA pixcir PIXCIR MICROELECTRONICS Co., Ltd @@ -220,6 +225,7 @@ sprd Spreadtrum Communications Inc. st STMicroelectronics ste ST-Ericsson stericsson ST-Ericsson +synaptics Synaptics, Inc. synology Synology, Inc. tbs TBS Technologies tcl Toby Churchill Ltd. diff --git a/Documentation/devicetree/bindings/wcnss/wcnss-wlan.txt b/Documentation/devicetree/bindings/wcnss/wcnss-wlan.txt new file mode 100644 index 000000000000..061c1d16ad24 --- /dev/null +++ b/Documentation/devicetree/bindings/wcnss/wcnss-wlan.txt @@ -0,0 +1,100 @@ +* Qualcomm WCNSS Platform Driver + +WCNSS driver is the platform driver. It is used for performing the cold +boot-up of the wireless device. It is responsible for adjusting +the necessary I/O rails and enabling appropriate gpios for wireless +connectivity subsystem. + +Required properties: +- compatible: "wcnss_wlan" +- reg: physical address and length of the register set for the device. +- reg-names: "wcnss_mmio", "wcnss_fiq", "pronto_phy_base", "riva_phy_base", + "riva_ccu_base", "pronto_a2xb_base", "pronto_ccpu_base", + "pronto_saw2_base", "wlan_tx_phy_aborts","wlan_brdg_err_source", + "wlan_tx_status", "alarms_txctl", "alarms_tactl", + "pronto_mcu_base". +- interupts: Pronto to Apps interrupts for tx done and rx pending. +- qcom,pronto-vddmx-supply: regulator to supply pronto pll. +- qcom,pronto-vddcx-supply: voltage corner regulator to supply WLAN/BT/FM + digital module. +- qcom,pronto-vddpx-supply: regulator to supply WLAN DAC. +- qcom,iris-vddxo-supply : regulator to supply RF XO. +- qcom,iris-vddrfa-supply : regulator to supply RFA digital. +- qcom,iris-vddpa-supply : regulator to supply RF PA. +- qcom,iris-vdddig-supply : regulator to supply RF digital(BT/FM). +- gpios: gpio numbers to configure 5-wire interface of WLAN connectivity +- qcom,has-48mhz-xo: boolean flag to determine the usage of 24MHz XO from RF +- qcom,has-pronto-hw: boolean flag to determine the revId of the WLAN subsystem +- qcom,wcnss-adc_tm: ADC handle for vbatt notification APIs. +- qcom,wcnss-vadc: VADC handle for battery voltage notification APIs. +- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt +- pinctrl-names : Names corresponding to the numbered pinctrl states +- clocks: from common clock binding: handle to xo and rf_clk clocks. +- clock-names: Names of all the clocks that are accessed by the subsystem +- qcom,vdd-voltage-level: This property represents (nominal, min, max) voltage +for iris and pronto regulators in milli-volts. +- qcom,vdd-current: This property represents current value for +iris and pronto regulators in micro-amps. + +Optional properties: +- qcom,has-autodetect-xo: boolean flag to determine whether Iris XO auto detect +should be performed during boot up. +- qcom,wlan-rx-buff-count: WLAN RX buffer count is a configurable value, +using a smaller count for this buffer will reduce the memory usage. +- qcom,is-pronto-v3: boolean flag to determine the pronto hardware version +in use. subsequently correct workqueue will be used by DXE engine to push frames +in TX data path. +- qcom,is-pronto-vadc: boolean flag to determine Battery voltage feature +support for pronto hardware. +- qcom,wcnss-pm : <Core rail LDO#, PA rail LDO#, XO settling time, + RPM power collapse enabled, standalone power collapse enabled> + Power manager related parameter for LDO configuration. + 11 - WCN CORE rail LDO number + 21 - WCN PA rail LDO number + 1200 - WCN XO settling time (usec) + 1 - WCN RPM power collapse enabled + 1 - WCN standalone power collapse enabled + 6 - GPIO strength value +- qcom,has-vsys-adc-channel: boolean flag to determine which ADC HW channel need +to use for VBATT feature. +- qcom,has-a2xb-split-reg: boolean flag to determine A2xb split timeout limit +register is available or not. + +Example: + + qcom,wcnss-wlan@fb000000 { + compatible = "qcom,wcnss_wlan"; + reg = <0xfb000000 0x280000>, + <0xf9011008 0x04>; + reg-names = "wcnss_mmio", "wcnss_fiq"; + interrupts = <0 145 0 0 146 0>; + interrupt-names = "wcnss_wlantx_irq", "wcnss_wlanrx_irq"; + + qcom,pronto-vddmx-supply = <&pm8841_s1>; + qcom,pronto-vddcx-supply = <&pm8841_s2_corner>; + qcom,pronto-vddpx-supply = <&pm8941_s3>; + qcom,iris-vddxo-supply = <&pm8941_l6>; + qcom,iris-vddrfa-supply = <&pm8941_l11>; + qcom,iris-vddpa-supply = <&pm8941_l19>; + qcom,iris-vdddig-supply = <&pm8941_l3>; + + gpios = <&msmgpio 36 0>, <&msmgpio 37 0>, <&msmgpio 38 0>, + <&msmgpio 39 0>, <&msmgpio 40 0>; + qcom,has-48mhz-xo; + qcom,is-pronto-vt; + qcom,wlan-rx-buff-count = <512>; + qcom,has-pronto-hw; + qcom,wcnss-adc_tm = <&pm8226_adc_tm>; + + pinctrl-names = "wcnss_default", "wcnss_sleep"; + pinctrl-0 = <&wcnss_default>; + pinctrl-1 = <&wcnss_sleep>; + pinctrl-2 = <&wcnss_gpio_default>; + + clocks = <&clock_rpm clk_xo_wlan_clk>, + <&clock_rpm clk_rf_clk2>, + <&clock_debug clk_gcc_debug_mux>, + <&clock_gcc clk_wcnss_m_clk>; + clock-names = "xo", "rf_clk", "measure", "wcnss_debug"; + qcom,wcnss-pm = <11 21 1200 1 1 6>; + }; diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index e63316239938..4199ffecc0ff 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | .. | | arc: | TODO | | arm: | ok | - | arm64: | .. | + | arm64: | ok | | avr32: | TODO | | blackfin: | TODO | | c6x: | TODO | diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index af6816bccb43..df1d1f3c9af2 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | TODO | | arc: | TODO | | arm: | TODO | - | arm64: | TODO | + | arm64: | ok | | avr32: | TODO | | blackfin: | TODO | | c6x: | TODO | diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 06d443450f21..539ac9c78ccf 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -197,7 +197,9 @@ prototypes: int (*releasepage) (struct page *, int); void (*freepage)(struct page *); int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset); + bool (*isolate_page) (struct page *, isolate_mode_t); int (*migratepage)(struct address_space *, struct page *, struct page *); + void (*putback_page) (struct page *); int (*launder_page)(struct page *); int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long); int (*error_remove_page)(struct address_space *, struct page *); @@ -221,7 +223,9 @@ invalidatepage: yes releasepage: yes freepage: yes direct_IO: +isolate_page: yes migratepage: yes (both) +putback_page: yes launder_page: yes is_partially_uptodate: yes error_remove_page: yes diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 6716413c17ba..aaafd8178eab 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -43,6 +43,7 @@ Table of Contents 3.7 /proc/<pid>/task/<tid>/children - Information about task children 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file 3.9 /proc/<pid>/map_files - Information about memory mapped files + 3.10 /proc/<pid>/timerslack_ns - Task timerslack value 4 Configuring procfs 4.1 Mount options @@ -137,6 +138,7 @@ Table 1-1: Process specific entries in /proc maps Memory maps to executables and library files (2.4) mem Memory held by this process root Link to the root directory of this process + reclaim Reclaim pages in this process stat Process status statm Process memory status information status Process status in human readable form @@ -380,6 +382,8 @@ is not associated with a file: [stack] = the stack of the main process [vdso] = the "virtual dynamic shared object", the kernel system call handler + [anon:<name>] = an anonymous mapping that has been + named by userspace or if empty, the mapping is anonymous. @@ -432,6 +436,7 @@ KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB VmFlags: rd ex mr mw me dw +Name: name from userspace the first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping @@ -494,6 +499,9 @@ Note that there is no guarantee that every flag and associated mnemonic will be present in all further kernel releases. Things get changed, the flags may be vanished or the reverse -- new added. +The "Name" field will only be present on a mapping that has been named by +userspace, and will show the name passed in by userspace. + This file is only present if the CONFIG_MMU kernel configuration option is enabled. @@ -518,6 +526,25 @@ current value: Any other value written to /proc/PID/clear_refs will have no effect. +The file /proc/PID/reclaim is used to reclaim pages in this process. +To reclaim file-backed pages, + > echo file > /proc/PID/reclaim + +To reclaim anonymous pages, + > echo anon > /proc/PID/reclaim + +To reclaim all pages, + > echo all > /proc/PID/reclaim + +Also, you can specify address range of process so part of address space +will be reclaimed. The format is following as + > echo addr size-byte > /proc/PID/reclaim + +NOTE: addr should be page-aligned. + +Below is example which try to reclaim 2M from 0x100000. + > echo 0x100000 2M > /proc/PID/reclaim + The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags using /proc/kpageflags and number of times a page is mapped using /proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt. @@ -1847,6 +1874,23 @@ time one can open(2) mappings from the listings of two processes and comparing their inode numbers to figure out which anonymous memory areas are actually shared. +3.10 /proc/<pid>/timerslack_ns - Task timerslack value +--------------------------------------------------------- +This file provides the value of the task's timerslack value in nanoseconds. +This value specifies a amount of time that normal timers may be deferred +in order to coalesce timers and avoid unnecessary wakeups. + +This allows a task's interactivity vs power consumption trade off to be +adjusted. + +Writing 0 to the file will set the tasks timerslack to the default value. + +Valid values are from 0 - ULLONG_MAX + +An application setting the value must have PTRACE_MODE_ATTACH_FSCREDS level +permissions on the task specified to change its timerslack_ns value. + + ------------------------------------------------------------------------------ Configuring procfs ------------------------------------------------------------------------------ diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 8c6f07ad373a..66ddf1e8fe28 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -593,9 +593,14 @@ struct address_space_operations { int (*releasepage) (struct page *, int); void (*freepage)(struct page *); ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset); + /* isolate a page for migration */ + bool (*isolate_page) (struct page *, isolate_mode_t); /* migrate the contents of a page to the specified target */ int (*migratepage) (struct page *, struct page *); + /* put migration-failed page back to right list */ + void (*putback_page) (struct page *); int (*launder_page) (struct page *); + int (*is_partially_uptodate) (struct page *, unsigned long, unsigned long); void (*is_dirty_writeback) (struct page *, bool *, bool *); @@ -748,6 +753,10 @@ struct address_space_operations { and transfer data directly between the storage and the application's address space. + isolate_page: Called by the VM when isolating a movable non-lru page. + If page is successfully isolated, VM marks the page as PG_isolated + via __SetPageIsolated. + migrate_page: This is used to compact the physical memory usage. If the VM wants to relocate a page (maybe off a memory card that is signalling imminent failure) it will pass a new page @@ -755,6 +764,8 @@ struct address_space_operations { transfer any private data across and update any references that it has to the page. + putback_page: Called by the VM when isolated page's migration fails. + launder_page: Called before freeing a page - it writes back the dirty page. To prevent redirtying the page, it is kept locked during the whole operation. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ca64ca566099..296980b95be9 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -56,6 +56,7 @@ parameter is applicable: BLACKFIN Blackfin architecture is enabled. CLK Common clock infrastructure is enabled. CMA Contiguous Memory Area support is enabled. + DM Device mapper support is enabled. DRM Direct Rendering Management support is enabled. DYNAMIC_DEBUG Build in debug messages and enable them at runtime EDD BIOS Enhanced Disk Drive Services (EDD) is enabled @@ -548,6 +549,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. embedded devices based on command line input. See Documentation/block/cmdline-partition.txt + boot_cpus= [SMP] + Rather than attempting to online all possible CPUs at + boot time, only online the specified set of CPUs. + boot_delay= Milliseconds to delay each printk during boot. Values larger than 10 seconds (10000) are changed to no delay (0). @@ -915,6 +920,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dis_ucode_ldr [X86] Disable the microcode loader. + dm= [DM] Allows early creation of a device-mapper device. + See Documentation/device-mapper/boot.txt. + + dmasound= [HW,OSS] Sound subsystem buff + dma_debug=off If the kernel is compiled with DMA_API_DEBUG support, this option disables the debugging code at boot. @@ -3420,6 +3430,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ro [KNL] Mount root device read-only on boot + rodata= [KNL] + on Mark read-only kernel memory as read-only (default). + off Leave read-only kernel memory writable for debugging. + root= [KNL] Root filesystem See name_to_dev_t comment in init/do_mounts.c. @@ -4127,6 +4141,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. or other driver-specific files in the Documentation/watchdog/ directory. + workqueue.watchdog_thresh= + If CONFIG_WQ_WATCHDOG is configured, workqueue can + warn stall conditions and dump internal state to + help debugging. 0 disables workqueue stall + detection; otherwise, it's the stall threshold + duration in seconds. The default value is 30 and + it can be updated at runtime by writing to the + corresponding sysfs file. + workqueue.disable_numa By default, all work items queued to unbound workqueues are affine to the NUMA nodes they're diff --git a/Documentation/misc-devices/qcom_invoke_driver.txt b/Documentation/misc-devices/qcom_invoke_driver.txt new file mode 100644 index 000000000000..5ba6b27558ea --- /dev/null +++ b/Documentation/misc-devices/qcom_invoke_driver.txt @@ -0,0 +1,56 @@ +Introduction: +============= +Invoke driver is a misc driver which helps communication between non secure +and secure world. Invoke driver communicates with secure side using SCM +driver. To use invoke driver, open must be called on invoke device i.e. +/dev/invoke. Invoke driver exposes only one IOCTL invoke which passes +userspace request to TZ. + +SW Architecture +=============== +Following is SW stack for Invoke driver. + ++++++++++++++++++++++++++++++++++++++++++ ++ Applications + ++++++++++++++++++++++++++++++++++++++++++ ++ System Layer + ++++++++++++++++++++++++++++++++++++++++++ ++ Kernel + ++ +++++++++++++++++++ + ++ + Invoke driver + + ++ +++++++++++++++++++ + ++ + SCM Driver + + ++++++++++++++++++++++++++++++++++++++++++ + || + || + \/ ++++++++++++++++++++++++++++++++++++++++++ ++ Trust Zone + ++ +++++++++++ +++++++++++ + ++ + TZ App1 + + TZ App2 + + ++++++++++++++++++++++++++++++++++++++++++ + + +Interfaces +========== +Invoke driver exposes INVOKE_IOCTL_INVOKE_REQ IOCTL for userspace to +communicate with driver. More details of IOCTL are avilable in +corresponding header file. + + +Driver Parameters +================= +This driver is built and statically linked into the kernel; therefore, +there are no module parameters supported by this driver. + +There are no kernel command line parameters supported by this driver. + +Power Management +================ +TBD + +Dependencies +============ +Invoke driver depends on SCM driver to communicate with TZ. + + diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index caa555706f89..e9d2debb29d3 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -8,12 +8,29 @@ The following attributes are read/write. force_ro Enforce read-only access even if write protect switch is off. + num_wr_reqs_to_start_packing This attribute is used to determine + the trigger for activating the write packing, in case the write + packing control feature is enabled. + + When the MMC manages to reach a point where num_wr_reqs_to_start_packing + write requests could be packed, it enables the write packing feature. + This allows us to start the write packing only when it is beneficial + and has minimum affect on the read latency. + + The number of potential packed requests that will trigger the packing + can be configured via sysfs by writing the required value to: + /sys/block/<block_dev_name>/num_wr_reqs_to_start_packing. + + The default value of num_wr_reqs_to_start_packing was determined by + running parallel lmdd write and lmdd read operations and calculating + the max number of packed writes requests. + SD and MMC Device Attributes ============================ All attributes are read-only. - cid Card Identifaction Register + cid Card Identification Register csd Card Specific Data Register scr SD Card Configuration Register (SD only) date Manufacturing Date (from CID Register) @@ -72,3 +89,51 @@ Note on raw_rpmb_size_mult: "raw_rpmb_size_mult" is a mutliple of 128kB block. RPMB size in byte is calculated by using the following equation: RPMB partition size = 128kB x raw_rpmb_size_mult + +SD/MMC/SDIO Clock Gating Attribute +================================== + +Read and write access is provided to following attribute. +This attribute appears only if CONFIG_MMC_CLKGATE is enabled. + + clkgate_delay Tune the clock gating delay with desired value in milliseconds. + +echo <desired delay> > /sys/class/mmc_host/mmcX/clkgate_delay + +SD/MMC/SDIO Clock Scaling Attributes +==================================== + +Read and write accesses are provided to following attributes. + + polling_interval Measured in milliseconds, this attribute + defines how often we need to check the card + usage and make decisions on frequency scaling. + + up_threshold This attribute defines what should be the + average card usage between the polling + interval for the mmc core to make a decision + on whether it should increase the frequency. + For example when it is set to '35' it means + that between the checking intervals the card + needs to be on average more than 35% in use to + scale up the frequency. The value should be + between 0 - 100 so that it can be compared + against load percentage. + + down_threshold Similar to up_threshold, but on lowering the + frequency. For example, when it is set to '2' + it means that between the checking intervals + the card needs to be on average less than 2% + in use to scale down the clocks to minimum + frequency. The value should be between 0 - 100 + so that it can be compared against load + percentage. + + enable Enable clock scaling for hosts (and cards) + that support ultrahigh speed modes + (SDR104, DDR50, HS200). + +echo <desired value> > /sys/class/mmc_host/mmcX/clk_scaling/polling_interval +echo <desired value> > /sys/class/mmc_host/mmcX/clk_scaling/up_threshold +echo <desired value> > /sys/class/mmc_host/mmcX/clk_scaling/down_threshold +echo <desired value> > /sys/class/mmc_host/mmcX/clk_scaling/enable diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 2ea4c45cf1c8..2d8fe6499090 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -584,6 +584,16 @@ tcp_fastopen - INTEGER See include/net/tcp.h and the code for more details. +tcp_fwmark_accept - BOOLEAN + If set, incoming connections to listening sockets that do not have a + socket mark will set the mark of the accepting socket to the fwmark of + the incoming SYN packet. This will cause all packets on that connection + (starting from the first SYNACK) to be sent with that fwmark. The + listening socket's mark is unchanged. Listening sockets that already + have a fwmark set via setsockopt(SOL_SOCKET, SO_MARK, ...) are + unaffected. + Default: 0 + tcp_syn_retries - INTEGER Number of times initial SYNs for an active TCP connection attempt will be retransmitted. Should not be higher than 255. Default value @@ -819,6 +829,11 @@ ip_local_reserved_ports - list of comma separated ranges Default: Empty +reserved_port_bind - BOOLEAN + If set, allows explicit bind requests to applications requesting + any port within the range of ip_local_reserved_ports. + Default: 1 + ip_nonlocal_bind - BOOLEAN If set, allows processes to bind() to non-local IP addresses, which can be quite useful - but may break some applications. @@ -1425,6 +1440,11 @@ accept_ra_mtu - BOOLEAN Functional default: enabled if accept_ra is enabled. disabled if accept_ra is disabled. +accept_ra_prefix_route - BOOLEAN + Set the prefix route for the autoconfigured interface address + + Functional default: enabled + accept_redirects - BOOLEAN Accept Redirects. diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 129f7c0e1483..73bfa1624004 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -43,6 +43,17 @@ registered notifiers are called only if the target value is now different. Clients of pm_qos need to save the returned handle for future use in other pm_qos API functions. +The handle is a pm_qos_request object. By default the request object sets the +request type to PM_QOS_REQ_ALL_CORES, in which case, the PM QoS request +applies to all cores. However, the driver can also specify a request type to +be either of + PM_QOS_REQ_ALL_CORES, + PM_QOS_REQ_AFFINE_CORES, + PM_QOS_REQ_AFFINE_IRQ, + +Specify the cpumask when type is set to PM_QOS_REQ_AFFINE_CORES and specify +the IRQ number with PM_QOS_REQ_AFFINE_IRQ. + void pm_qos_update_request(handle, new_target_value): Will update the list element pointed to by the handle with the new target value and recompute the new aggregated target, calling the notification tree if the @@ -56,6 +67,13 @@ the request. int pm_qos_request(param_class): Returns the aggregated value for a given PM QoS class. +int pm_qos_request_for_cpu(param_class, cpu): +Returns the aggregated value for a given PM QoS class for the specified cpu. + +int pm_qos_request_for_cpumask(param_class, cpumask): +Returns the aggregated value for a given PM QoS class for the specified +cpumask. + int pm_qos_request_active(handle): Returns if the request is still active, i.e. it has not been removed from a PM QoS class constraints list. diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt index 5d8675615e59..9264bcab4099 100644 --- a/Documentation/ramoops.txt +++ b/Documentation/ramoops.txt @@ -45,7 +45,7 @@ corrupt, but usually it is restorable. 2. Setting the parameters -Setting the ramoops parameters can be done in 2 different manners: +Setting the ramoops parameters can be done in 3 different manners: 1. Use the module parameters (which have the names of the variables described as before). For quick debugging, you can also reserve parts of memory during boot @@ -54,7 +54,9 @@ Setting the ramoops parameters can be done in 2 different manners: kernel to use only the first 128 MB of memory, and place ECC-protected ramoops region at 128 MB boundary: "mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1" - 2. Use a platform device and set the platform data. The parameters can then + 2. Use Device Tree bindings, as described in + Documentation/device-tree/bindings/misc/ramoops.txt. + 3. Use a platform device and set the platform data. The parameters can then be set through that platform data. An example of doing that is: #include <linux/pstore_ram.h> diff --git a/Documentation/scheduler/sched-energy.txt b/Documentation/scheduler/sched-energy.txt new file mode 100644 index 000000000000..dab2f9088b33 --- /dev/null +++ b/Documentation/scheduler/sched-energy.txt @@ -0,0 +1,362 @@ +Energy cost model for energy-aware scheduling (EXPERIMENTAL) + +Introduction +============= + +The basic energy model uses platform energy data stored in sched_group_energy +data structures attached to the sched_groups in the sched_domain hierarchy. The +energy cost model offers two functions that can be used to guide scheduling +decisions: + +1. static unsigned int sched_group_energy(struct energy_env *eenv) +2. static int energy_diff(struct energy_env *eenv) + +sched_group_energy() estimates the energy consumed by all cpus in a specific +sched_group including any shared resources owned exclusively by this group of +cpus. Resources shared with other cpus are excluded (e.g. later level caches). + +energy_diff() estimates the total energy impact of a utilization change. That +is, adding, removing, or migrating utilization (tasks). + +Both functions use a struct energy_env to specify the scenario to be evaluated: + + struct energy_env { + struct sched_group *sg_top; + struct sched_group *sg_cap; + int cap_idx; + int util_delta; + int src_cpu; + int dst_cpu; + int energy; + }; + +sg_top: sched_group to be evaluated. Not used by energy_diff(). + +sg_cap: sched_group covering the cpus in the same frequency domain. Set by +sched_group_energy(). + +cap_idx: Capacity state to be used for energy calculations. Set by +find_new_capacity(). + +util_delta: Amount of utilization to be added, removed, or migrated. + +src_cpu: Source cpu from where 'util_delta' utilization is removed. Should be +-1 if no source (e.g. task wake-up). + +dst_cpu: Destination cpu where 'util_delta' utilization is added. Should be -1 +if utilization is removed (e.g. terminating tasks). + +energy: Result of sched_group_energy(). + +The metric used to represent utilization is the actual per-entity running time +averaged over time using a geometric series. Very similar to the existing +per-entity load-tracking, but _not_ scaled by task priority and capped by the +capacity of the cpu. The latter property does mean that utilization may +underestimate the compute requirements for task on fully/over utilized cpus. +The greatest potential for energy savings without affecting performance too much +is scenarios where the system isn't fully utilized. If the system is deemed +fully utilized load-balancing should be done with task load (includes task +priority) instead in the interest of fairness and performance. + + +Background and Terminology +=========================== + +To make it clear from the start: + +energy = [joule] (resource like a battery on powered devices) +power = energy/time = [joule/second] = [watt] + +The goal of energy-aware scheduling is to minimize energy, while still getting +the job done. That is, we want to maximize: + + performance [inst/s] + -------------------- + power [W] + +which is equivalent to minimizing: + + energy [J] + ----------- + instruction + +while still getting 'good' performance. It is essentially an alternative +optimization objective to the current performance-only objective for the +scheduler. This alternative considers two objectives: energy-efficiency and +performance. Hence, there needs to be a user controllable knob to switch the +objective. Since it is early days, this is currently a sched_feature +(ENERGY_AWARE). + +The idea behind introducing an energy cost model is to allow the scheduler to +evaluate the implications of its decisions rather than applying energy-saving +techniques blindly that may only have positive effects on some platforms. At +the same time, the energy cost model must be as simple as possible to minimize +the scheduler latency impact. + +Platform topology +------------------ + +The system topology (cpus, caches, and NUMA information, not peripherals) is +represented in the scheduler by the sched_domain hierarchy which has +sched_groups attached at each level that covers one or more cpus (see +sched-domains.txt for more details). To add energy awareness to the scheduler +we need to consider power and frequency domains. + +Power domain: + +A power domain is a part of the system that can be powered on/off +independently. Power domains are typically organized in a hierarchy where you +may be able to power down just a cpu or a group of cpus along with any +associated resources (e.g. shared caches). Powering up a cpu means that all +power domains it is a part of in the hierarchy must be powered up. Hence, it is +more expensive to power up the first cpu that belongs to a higher level power +domain than powering up additional cpus in the same high level domain. Two +level power domain hierarchy example: + + Power source + +-------------------------------+----... +per group PD G G + | +----------+ | + +--------+-------| Shared | (other groups) +per-cpu PD G G | resource | + | | +----------+ + +-------+ +-------+ + | CPU 0 | | CPU 1 | + +-------+ +-------+ + +Frequency domain: + +Frequency domains (P-states) typically cover the same group of cpus as one of +the power domain levels. That is, there might be several smaller power domains +sharing the same frequency (P-state) or there might be a power domain spanning +multiple frequency domains. + +From a scheduling point of view there is no need to know the actual frequencies +[Hz]. All the scheduler cares about is the compute capacity available at the +current state (P-state) the cpu is in and any other available states. For that +reason, and to also factor in any cpu micro-architecture differences, compute +capacity scaling states are called 'capacity states' in this document. For SMP +systems this is equivalent to P-states. For mixed micro-architecture systems +(like ARM big.LITTLE) it is P-states scaled according to the micro-architecture +performance relative to the other cpus in the system. + +Energy modelling: +------------------ + +Due to the hierarchical nature of the power domains, the most obvious way to +model energy costs is therefore to associate power and energy costs with +domains (groups of cpus). Energy costs of shared resources are associated with +the group of cpus that share the resources, only the cost of powering the +cpu itself and any private resources (e.g. private L1 caches) is associated +with the per-cpu groups (lowest level). + +For example, for an SMP system with per-cpu power domains and a cluster level +(group of cpus) power domain we get the overall energy costs to be: + + energy = energy_cluster + n * energy_cpu + +where 'n' is the number of cpus powered up and energy_cluster is the cost paid +as soon as any cpu in the cluster is powered up. + +The power and frequency domains can naturally be mapped onto the existing +sched_domain hierarchy and sched_groups by adding the necessary data to the +existing data structures. + +The energy model considers energy consumption from two contributors (shown in +the illustration below): + +1. Busy energy: Energy consumed while a cpu and the higher level groups that it +belongs to are busy running tasks. Busy energy is associated with the state of +the cpu, not an event. The time the cpu spends in this state varies. Thus, the +most obvious platform parameter for this contribution is busy power +(energy/time). + +2. Idle energy: Energy consumed while a cpu and higher level groups that it +belongs to are idle (in a C-state). Like busy energy, idle energy is associated +with the state of the cpu. Thus, the platform parameter for this contribution +is idle power (energy/time). + +Energy consumed during transitions from an idle-state (C-state) to a busy state +(P-state) or going the other way is ignored by the model to simplify the energy +model calculations. + + + Power + ^ + | busy->idle idle->busy + | transition transition + | + | _ __ + | / \ / \__________________ + |______________/ \ / + | \ / + | Busy \ Idle / Busy + | low P-state \____________/ high P-state + | + +------------------------------------------------------------> time + +Busy |--------------| |-----------------| + +Wakeup |------| |------| + +Idle |------------| + + +The basic algorithm +==================== + +The basic idea is to determine the total energy impact when utilization is +added or removed by estimating the impact at each level in the sched_domain +hierarchy starting from the bottom (sched_group contains just a single cpu). +The energy cost comes from busy time (sched_group is awake because one or more +cpus are busy) and idle time (in an idle-state). Energy model numbers account +for energy costs associated with all cpus in the sched_group as a group. + + for_each_domain(cpu, sd) { + sg = sched_group_of(cpu) + energy_before = curr_util(sg) * busy_power(sg) + + (1-curr_util(sg)) * idle_power(sg) + energy_after = new_util(sg) * busy_power(sg) + + (1-new_util(sg)) * idle_power(sg) + energy_diff += energy_before - energy_after + + } + + return energy_diff + +{curr, new}_util: The cpu utilization at the lowest level and the overall +non-idle time for the entire group for higher levels. Utilization is in the +range 0.0 to 1.0 in the pseudo-code. + +busy_power: The power consumption of the sched_group. + +idle_power: The power consumption of the sched_group when idle. + +Note: It is a fundamental assumption that the utilization is (roughly) scale +invariant. Task utilization tracking factors in any frequency scaling and +performance scaling differences due to difference cpu microarchitectures such +that task utilization can be used across the entire system. + + +Platform energy data +===================== + +struct sched_group_energy can be attached to sched_groups in the sched_domain +hierarchy and has the following members: + +cap_states: + List of struct capacity_state representing the supported capacity states + (P-states). struct capacity_state has two members: cap and power, which + represents the compute capacity and the busy_power of the state. The + list must be ordered by capacity low->high. + +nr_cap_states: + Number of capacity states in cap_states list. + +idle_states: + List of struct idle_state containing idle_state power cost for each + idle-state supported by the system orderd by shallowest state first. + All states must be included at all level in the hierarchy, i.e. a + sched_group spanning just a single cpu must also include coupled + idle-states (cluster states). In addition to the cpuidle idle-states, + the list must also contain an entry for the idling using the arch + default idle (arch_idle_cpu()). Despite this state may not be a true + hardware idle-state it is considered the shallowest idle-state in the + energy model and must be the first entry. cpus may enter this state + (possibly 'active idling') if cpuidle decides not enter a cpuidle + idle-state. Default idle may not be used when cpuidle is enabled. + In this case, it should just be a copy of the first cpuidle idle-state. + +nr_idle_states: + Number of idle states in idle_states list. + +There are no unit requirements for the energy cost data. Data can be normalized +with any reference, however, the normalization must be consistent across all +energy cost data. That is, one bogo-joule/watt must be the same quantity for +data, but we don't care what it is. + +A recipe for platform characterization +======================================= + +Obtaining the actual model data for a particular platform requires some way of +measuring power/energy. There isn't a tool to help with this (yet). This +section provides a recipe for use as reference. It covers the steps used to +characterize the ARM TC2 development platform. This sort of measurements is +expected to be done anyway when tuning cpuidle and cpufreq for a given +platform. + +The energy model needs two types of data (struct sched_group_energy holds +these) for each sched_group where energy costs should be taken into account: + +1. Capacity state information + +A list containing the compute capacity and power consumption when fully +utilized attributed to the group as a whole for each available capacity state. +At the lowest level (group contains just a single cpu) this is the power of the +cpu alone without including power consumed by resources shared with other cpus. +It basically needs to fit the basic modelling approach described in "Background +and Terminology" section: + + energy_system = energy_shared + n * energy_cpu + +for a system containing 'n' busy cpus. Only 'energy_cpu' should be included at +the lowest level. 'energy_shared' is included at the next level which +represents the group of cpus among which the resources are shared. + +This model is, of course, a simplification of reality. Thus, power/energy +attributions might not always exactly represent how the hardware is designed. +Also, busy power is likely to depend on the workload. It is therefore +recommended to use a representative mix of workloads when characterizing the +capacity states. + +If the group has no capacity scaling support, the list will contain a single +state where power is the busy power attributed to the group. The capacity +should be set to a default value (1024). + +When frequency domains include multiple power domains, the group representing +the frequency domain and all child groups share capacity states. This must be +indicated by setting the SD_SHARE_CAP_STATES sched_domain flag. All groups at +all levels that share the capacity state must have the list of capacity states +with the power set to the contribution of the individual group. + +2. Idle power information + +Stored in the idle_states list. The power number is the group idle power +consumption in each idle state as well when the group is idle but has not +entered an idle-state ('active idle' as mentioned earlier). Due to the way the +energy model is defined, the idle power of the deepest group idle state can +alternatively be accounted for in the parent group busy power. In that case the +group idle state power values are offset such that the idle power of the +deepest state is zero. It is less intuitive, but it is easier to measure as +idle power consumed by the group and the busy/idle power of the parent group +cannot be distinguished without per group measurement points. + +Measuring capacity states and idle power: + +The capacity states' capacity and power can be estimated by running a benchmark +workload at each available capacity state. By restricting the benchmark to run +on subsets of cpus it is possible to extrapolate the power consumption of +shared resources. + +ARM TC2 has two clusters of two and three cpus respectively. Each cluster has a +shared L2 cache. TC2 has on-chip energy counters per cluster. Running a +benchmark workload on just one cpu in a cluster means that power is consumed in +the cluster (higher level group) and a single cpu (lowest level group). Adding +another benchmark task to another cpu increases the power consumption by the +amount consumed by the additional cpu. Hence, it is possible to extrapolate the +cluster busy power. + +For platforms that don't have energy counters or equivalent instrumentation +built-in, it may be possible to use an external DAQ to acquire similar data. + +If the benchmark includes some performance score (for example sysbench cpu +benchmark), this can be used to record the compute capacity. + +Measuring idle power requires insight into the idle state implementation on the +particular platform. Specifically, if the platform has coupled idle-states (or +package states). To measure non-coupled per-cpu idle-states it is necessary to +keep one cpu busy to keep any shared resources alive to isolate the idle power +of the cpu from idle/busy power of the shared resources. The cpu can be tricked +into different per-cpu idle states by disabling the other states. Based on +various combinations of measurements with specific cpus busy and disabling +idle-states it is possible to extrapolate the idle-state power. diff --git a/Documentation/scheduler/sched-hmp.txt b/Documentation/scheduler/sched-hmp.txt new file mode 100644 index 000000000000..32906610b25f --- /dev/null +++ b/Documentation/scheduler/sched-hmp.txt @@ -0,0 +1,1673 @@ +CONTENTS + +1. Introduction + 1.1 Heterogeneous Systems + 1.2 CPU Frequency Guidance +2. Window-Based Load Tracking Scheme + 2.1 Synchronized Windows + 2.2 struct ravg + 2.3 Scaling Load Statistics + 2.4 sched_window_stats_policy + 2.5 Task Events + 2.6 update_task_ravg() + 2.7 update_history() + 2.8 Per-task 'initial task load' +3. CPU Capacity + 3.1 Load scale factor + 3.2 CPU Power +4. CPU Power +5. HMP Scheduler + 5.1 Classification of Tasks and CPUs + 5.2 select_best_cpu() + 5.2.1 sched_boost + 5.2.2 task_will_fit() + 5.2.3 Tunables affecting select_best_cpu() + 5.2.4 Wakeup Logic + 5.3 Scheduler Tick + 5.4 Load Balancer + 5.5 Real Time Tasks + 5.6 Task packing +6. Frequency Guidance + 6.1 Per-CPU Window-Based Stats + 6.2 Per-task Window-Based Stats + 6.3 Effect of various task events + 6.4 Tying it all together +7. Tunables +8. HMP Scheduler Trace Points + 8.1 sched_enq_deq_task + 8.2 sched_task_load + 8.3 sched_cpu_load_* + 8.4 sched_update_task_ravg + 8.5 sched_update_history + 8.6 sched_reset_all_windows_stats + 8.7 sched_migration_update_sum + 8.8 sched_get_busy + 8.9 sched_freq_alert + 8.10 sched_set_boost +9. Device Tree bindings + +=============== +1. INTRODUCTION +=============== + +Scheduler extensions described in this document serves two goals: + +1) handle heterogeneous multi-processor (HMP) systems +2) guide cpufreq governor on proactive changes to cpu frequency + +*** 1.1 Heterogeneous systems + +Heterogeneous systems have cpus that differ with regard to their performance and +power characteristics. Some cpus could offer peak performance better than +others, although at cost of consuming more power. We shall refer such cpus as +"high performance" or "performance efficient" cpus. Other cpus that offer lesser +peak performance are referred to as "power efficient". + +In this situation the scheduler is tasked with the responsibility of assigning +tasks to run on the right cpus where their performance requirements can be met +at the least expense of power. + +Achieving that goal is made complicated by the fact that the scheduler has +little clue about performance requirements of tasks and how they may change by +running on power or performance efficient cpus! One simplifying assumption here +could be that a task's desire for more performance is expressed by its cpu +utilization. A task demanding high cpu utilization on a power-efficient cpu +would likely improve in its performance by running on a performance-efficient +cpu. This idea forms the basis for HMP-related scheduler extensions. + +Key inputs required by the HMP scheduler for its task placement decisions are: + +a) task load - this reflects cpu utilization or demand of tasks +b) CPU capacity - this reflects peak performance offered by cpus +c) CPU power - this reflects power or energy cost of cpus + +Once all 3 pieces of information are available, the HMP scheduler can place +tasks on the lowest power cpus where their demand can be satisfied. + +*** 1.2 CPU Frequency guidance + +A somewhat separate but related goal of the scheduler extensions described here +is to provide guidance to the cpufreq governor on the need to change cpu +frequency. Most governors that control cpu frequency work on a reactive basis. +CPU utilization is sampled at regular intervals, based on which the need to +change frequency is determined. Higher utilization leads to a frequency increase +and vice-versa. There are several problems with this approach that scheduler +can help resolve. + +a) latency + + Reactive nature introduces latency for cpus to ramp up to desired speed + which can hurt application performance. This is inevitable as cpufreq + governors can only track cpu utilization as a whole and not tasks which + are driving that demand. Scheduler can however keep track of individual + task demand and can alert the governor on changing task activity. For + example, request raise in frequency when tasks activity is increasing on + a cpu because of wakeup or migration or request frequency to be lowered + when task activity is decreasing because of sleep/exit or migration. + +b) part-picture + + Most governors track utilization of each CPU independently. When a task + migrates from one cpu to another the task's execution time is split + across the two cpus. The governor can fail to see the full picture of + task demand in this case and thus the need for increasing frequency, + affecting the task's performance. Scheduler can keep track of task + migrations, fix up busy time upon migration and report per-cpu busy time + to the governor that reflects task demand accurately. + +The rest of this document explains key enhancements made to the scheduler to +accomplish both of the aforementioned goals. + +==================================== +2. WINDOW-BASED LOAD TRACKING SCHEME +==================================== + +As mentioned in the introduction section, knowledge of the CPU demand exerted by +a task is a prerequisite to knowing where to best place the task in an HMP +system. The per-entity load tracking (PELT) scheme, present in Linux kernel +since v3.7, has some perceived shortcomings when used to place tasks on HMP +systems or provide recommendations on CPU frequency. + +Per-entity load tracking does not make a distinction between the ramp up +vs ramp down time of task load. It also decays task load without exception when +a task sleeps. As an example, a cpu bound task at its peak load (LOAD_AVG_MAX or +47742) can see its load decay to 0 after a sleep of just 213ms! A cpu-bound task +running on a performance-efficient cpu could thus get re-classified as not +requiring such a cpu after a short sleep. In the case of mobile workloads, tasks +could go to sleep due to a lack of user input. When they wakeup it is very +likely their cpu utilization pattern repeats. Resetting their load across sleep +and incurring latency to reclassify them as requiring a high performance cpu can +hurt application performance. + +The window-based load tracking scheme described in this document avoids these +drawbacks. It keeps track of N windows of execution for every task. Windows +where a task had no activity are ignored and not recorded. N can be tuned at +compile time (RAVG_HIST_SIZE defined in include/linux/sched.h) or at runtime +(/proc/sys/kernel/sched_ravg_hist_size). The window size, W, is common for all +tasks and currently defaults to 10ms ('sched_ravg_window' defined in +kernel/sched/core.c). The window size can be tuned at boot time via the +sched_ravg_window=W argument to kernel. Alternately it can be tuned after boot +via tunables provided by the interactive governor. More on this later. + +Based on the N samples available per-task, a per-task "demand" attribute is +calculated which represents the cpu demand of that task. The demand attribute is +used to classify tasks as to whether or not they need a performance-efficient +CPU and also serves to provide inputs on frequency to the cpufreq governor. More +on this later. The 'sched_window_stats_policy' tunable (defined in +kernel/sched/core.c) controls how the demand field for a task is derived from +its N past samples. + +*** 2.1 Synchronized windows + +Windows of observation for task activity are synchronized across cpus. This +greatly aids in the scheduler's frequency guidance feature. Scheduler currently +relies on a synchronized clock (sched_clock()) for this feature to work. It may +be possible to extend this feature to work on systems having an unsynchronized +sched_clock(). + +struct rq { + + .. + + u64 window_start; + + .. +}; + +The 'window_start' attribute represents the time when current window began on a +cpu. It is updated when key task events such as wakeup or context-switch call +update_task_ravg() to record task activity. The window_start value is expected +to be the same for all cpus, although it could be behind on some cpus where it +has not yet been updated because update_task_ravg() has not been recently +called. For example, when a cpu is idle for a long time its window_start could +be stale. The window_start value for such cpus is rolled forward upon +occurrence of a task event resulting in a call to update_task_ravg(). + +*** 2.2 struct ravg + +The ravg struct contains information tracked per-task. + +struct ravg { + u64 mark_start; + u32 sum, demand; + u32 sum_history[RAVG_HIST_SIZE]; +}; + +struct task_struct { + + .. + + struct ravg ravg; + + .. +}; + +sum_history[] - stores cpu utilization samples from N previous windows + where task had activity + +sum - stores cpu utilization of the task in its most recently + tracked window. Once the corresponding window terminates, + 'sum' will be pushed into the sum_history[] array and is then + reset to 0. It is possible that the window corresponding to + sum is not the current window being tracked on a cpu. For + example, a task could go to sleep in window X and wakeup in + window Y (Y > X). In this case, sum would correspond to the + task's activity seen in window X. When update_task_ravg() is + called during the task's wakeup event it will be seen that + window X has elapsed. The sum value will be pushed to + 'sum_history[]' array before being reset to 0. + +demand - represents task's cpu demand and is derived from the + elements in sum_history[]. The section on + 'sched_window_stats_policy' provides more details on how + 'demand' is derived from elements in sum_history[] array + +mark_start - records timestamp of the beginning of the most recent task + event. See section on 'Task events' for possible events that + update 'mark_start' + +curr_window - this is described in the section on 'Frequency guidance' + +prev_window - this is described in the section on 'Frequency guidance' + + +*** 2.3 Scaling load statistics + +Time required for a task to complete its work (and hence its load) depends on, +among various other factors, cpu frequency and its efficiency. In a HMP system, +some cpus are more performance efficient than others. Performance efficiency of +a cpu can be described by its "instructions-per-cycle" (IPC) attribute. History +of task execution could involve task having run at different frequencies and on +cpus with different IPC attributes. To avoid ambiguity of how task load relates +to the frequency and IPC of cpus on which a task has run, task load is captured +in a scaled form, with scaling being done in reference to an "ideal" cpu that +has best possible IPC and frequency. Such an "ideal" cpu, having the best +possible frequency and IPC, may or may not exist in system. + +As an example, consider a HMP system, with two types of cpus, A53 and A57. A53 +has IPC count of 1024 and can run at maximum frequency of 1 GHz, while A57 has +IPC count of 2048 and can run at maximum frequency of 2 GHz. Ideal cpu in this +case is A57 running at 2 GHz. + +A unit of work that takes 100ms to finish on A53 running at 100MHz would get +done in 10ms on A53 running at 1GHz, in 5 ms running on A57 at 1 GHz and 2.5ms +on A57 running at 2 GHz. Thus a load of 100ms can be expressed as 2.5ms in +reference to ideal cpu of A57 running at 2 GHz. + +In order to understand how much load a task will consume on a given cpu, its +scaled load needs to be multiplied by a factor (load scale factor). In above +example, scaled load of 2.5ms needs to be multiplied by a factor of 4 in order +to estimate the load of task on A53 running at 1 GHz. + +/proc/sched_debug provides IPC attribute and load scale factor for every cpu. + +In summary, task load information stored in a task's sum_history[] array is +scaled for both frequency and efficiency. If a task runs for X ms, then the +value stored in its 'sum' field is derived as: + + X_s = X * (f_cur / max_possible_freq) * + (efficiency / max_possible_efficiency) + +where: + +X = cpu utilization that needs to be accounted +X_s = Scaled derivative of X +f_cur = current frequency of the cpu where the task was + running +max_possible_freq = maximum possible frequency (across all cpus) +efficiency = instructions per cycle (IPC) of cpu where task was + running +max_possible_efficiency = maximum IPC offered by any cpu in system + + +*** 2.4 sched_window_stats_policy + +sched_window_stats_policy controls how the 'demand' attribute for a task is +derived from elements in its 'sum_history[]' array. + +WINDOW_STATS_RECENT (0) + demand = recent + +WINDOW_STATS_MAX (1) + demand = max + +WINDOW_STATS_MAX_RECENT_AVG (2) + demand = maximum(average, recent) + +WINDOW_STATS_AVG (3) + demand = average + +where: + M = history size specified by + /proc/sys/kernel/sched_ravg_hist_size + average = average of first M samples found in the sum_history[] array + max = maximum value of first M samples found in the sum_history[] + array + recent = most recent sample (sum_history[0]) + demand = demand attribute found in 'struct ravg' + +This policy can be changed at runtime via +/proc/sys/kernel/sched_window_stats_policy. For example, the command +below would select WINDOW_STATS_USE_MAX policy + +echo 1 > /proc/sys/kernel/sched_window_stats_policy + +*** 2.5 Task events + +A number of events results in the window-based stats of a task being +updated. These are: + +PICK_NEXT_TASK - the task is about to start running on a cpu +PUT_PREV_TASK - the task stopped running on a cpu +TASK_WAKE - the task is waking from sleep +TASK_MIGRATE - the task is migrating from one cpu to another +TASK_UPDATE - this event is invoked on a currently running task to + update the task's window-stats and also the cpu's + window-stats such as 'window_start' +IRQ_UPDATE - event to record the busy time spent by an idle cpu + processing interrupts + +*** 2.6 update_task_ravg() + +update_task_ravg() is called to mark the beginning of an event for a task or a +cpu. It serves to accomplish these functions: + +a. Update a cpu's window_start value +b. Update a task's window-stats (sum, sum_history[], demand and mark_start) + +In addition update_task_ravg() updates the busy time information for the given +cpu, which is used for frequency guidance. This is described further in section +6. + +*** 2.7 update_history() + +update_history() is called on a task to record its activity in an elapsed +window. 'sum', which represents task's cpu demand in its elapsed window is +pushed onto sum_history[] array and its 'demand' attribute is updated based on +the sched_window_stats_policy in effect. + +*** 2.8 Initial task load attribute for a task (init_load_pct) + +In some cases, it may be desirable for children of a task to be assigned a +"high" load so that they can start running on best capacity cluster. By default, +newly created tasks are assigned a load defined by tunable sched_init_task_load +(Sec 7.8). Some specialized tasks may need a higher value than the global +default for their child tasks. This will let child tasks run on cpus with best +capacity. This is accomplished by setting the 'initial task load' attribute +(init_load_pct) for a task. Child tasks starting load (ravg.demand and +ravg.sum_history[]) is initialized from their parent's 'initial task load' +attribute. Note that child task's 'initial task load' attribute itself will be 0 +by default (i.e it is not inherited from parent). + +A task's 'initial task load' attribute can be set in two ways: + +**** /proc interface + +/proc/[pid]/sched_init_task_load can be written to for setting a task's 'initial +task load' attribute. A numeric value between 0 - 100 (in percent scale) is +accepted for task's 'initial task load' attribute. + +Reading /proc/[pid]/sched_init_task_load returns the 'initial task load' +attribute for the given task. + +**** kernel API + +Following kernel APIs are provided to set or retrieve a given task's 'initial +task load' attribute: + +int sched_set_init_task_load(struct task_struct *p, int init_load_pct); +int sched_get_init_task_load(struct task_struct *p); + + +=============== +3. CPU CAPACITY +=============== + +CPU capacity reflects peak performance offered by a cpu. It is defined both by +maximum frequency at which cpu can run and its efficiency attribute. Capacity of +a cpu is defined in reference to "least" performing cpu such that "least" +performing cpu has capacity of 1024. + + capacity = 1024 * (fmax_cur * / min_max_freq) * + (efficiency / min_possible_efficiency) + +where: + + fmax_cur = maximum frequency at which cpu is currently + allowed to run at + efficiency = IPC of cpu + min_max_freq = max frequency at which "least" performing cpu + can run + min_possible_efficiency = IPC of "least" performing cpu + +'fmax_cur' reflects the fact that a cpu may be constrained at runtime to run at +a maximum frequency less than what is supported. This may be a constraint placed +by user or drivers such as thermal that intends to reduce temperature of a cpu +by restricting its maximum frequency. + +'max_possible_capacity' reflects the maximum capacity of a cpu based on the +maximum frequency it supports. + +max_possible_capacity = 1024 * (fmax * / min_max_freq) * + (efficiency / min_possible_efficiency) + +where: + fmax = maximum frequency supported by a cpu + +/proc/sched_debug lists capacity and maximum_capacity information for a cpu. + +In the example HMP system quoted in Sec 2.3, "least" performing CPU is A53 and +thus min_max_freq = 1GHz and min_possible_efficiency = 1024. + +Capacity of A57 = 1024 * (2GHz / 1GHz) * (2048 / 1024) = 4096 +Capacity of A53 = 1024 * (1GHz / 1GHz) * (1024 / 1024) = 1024 + +Capacity of A57 when constrained to run at maximum frequency of 500MHz can be +calculated as: + +Capacity of A57 = 1024 * (500MHz / 1GHz) * (2048 / 1024) = 1024 + +*** 3.1 load_scale_factor + +'lsf' or load scale factor attribute of a cpu is used to estimate load of a task +on that cpu when running at its fmax_cur frequency. 'lsf' is defined in +reference to "best" performing cpu such that it's lsf is 1024. 'lsf' for a cpu +is defined as: + + lsf = 1024 * (max_possible_freq / fmax_cur) * + (max_possible_efficiency / ipc) + +where: + fmax_cur = maximum frequency at which cpu is currently + allowed to run at + ipc = IPC of cpu + max_possible_freq = max frequency at which "best" performing cpu + can run + max_possible_efficiency = IPC of "best" performing cpu + +In the example HMP system quoted in Sec 2.3, "best" performing CPU is A57 and +thus max_possible_freq = 2 GHz, max_possible_efficiency = 2048 + +lsf of A57 = 1024 * (2GHz / 2GHz) * (2048 / 2048) = 1024 +lsf of A53 = 1024 * (2GHz / 1 GHz) * (2048 / 1024) = 4096 + +lsf of A57 constrained to run at maximum frequency of 500MHz can be calculated +as: + +lsf of A57 = 1024 * (2GHz / 500Mhz) * (2048 / 2048) = 4096 + +To estimate load of a task on a given cpu running at its fmax_cur: + + load = scaled_load * lsf / 1024 + +A task with scaled load of 20% would thus be estimated to consume 80% bandwidth +of A53 running at 1GHz. The same task with scaled load of 20% would be estimated +to consume 160% bandwidth on A53 constrained to run at maximum frequency of +500MHz. + +load_scale_factor, thus, is very useful to estimate load of a task on a given +cpu and thus to decide whether it can fit in a cpu or not. + +*** 3.2 cpu_power + +A metric 'cpu_power' related to 'capacity' is also listed in /proc/sched_debug. +'cpu_power' is ideally same for all cpus (1024) when they are idle and running +at the same frequency. 'cpu_power' of a cpu can be scaled down from its ideal +value to reflect reduced frequency it is operating at and also to reflect the +amount of cpu bandwidth consumed by real-time tasks executing on it. +'cpu_power' metric is used by scheduler to decide task load distribution among +cpus. CPUs with low 'cpu_power' will be assigned less task load compared to cpus +with higher 'cpu_power' + +============ +4. CPU POWER +============ + +The HMP scheduler extensions currently depend on an architecture-specific driver +to provide runtime information on cpu power. In the absence of an +architecture-specific driver, the scheduler will resort to using the +max_possible_capacity metric of a cpu as a measure of its power. + +================ +5. HMP SCHEDULER +================ + +For normal (SCHED_OTHER/fair class) tasks there are three paths in the +scheduler which these HMP extensions affect. The task wakeup path, the +load balancer, and the scheduler tick are each modified. + +Real-time and stop-class tasks are served by different code +paths. These will be discussed separately. + +Prior to delving further into the algorithm and implementation however +some definitions are required. + +*** 5.1 Classification of Tasks and CPUs + +With the extensions described thus far, the following information is +available to the HMP scheduler: + +- per-task CPU demand information from either Per-Entity Load Tracking + (PELT) or the window-based algorithm described above + +- a power value for each frequency supported by each CPU via the API + described in section 4 + +- current CPU frequency, maximum CPU frequency (may be throttled by at + runtime due to thermal conditions), maximum possible CPU frequency supported + by hardware + +- data previously maintained within the scheduler such as the number + of currently runnable tasks on each CPU + +Combined with tunable parameters, this information can be used to classify +both tasks and CPUs to aid in the placement of tasks. + +- big task + + A big task is one that exerts a CPU demand too high for a particular + CPU to satisfy. The scheduler will attempt to find a CPU with more + capacity for such a task. + + The definition of "big" is specific to a task *and* a CPU. A task + may be considered big on one CPU in the system and not big on + another if the first CPU has less capacity than the second. + + What task demand is "too high" for a particular CPU? One obvious + answer would be a task demand which, as measured by PELT or + window-based load tracking, matches or exceeds the capacity of that + CPU. A task which runs on a CPU for a long time, for example, might + meet this criteria as it would report 100% demand of that CPU. It + may be desirable however to classify tasks which use less than 100% + of a particular CPU as big so that the task has some "headroom" to grow + without its CPU bandwidth getting capped and its performance requirements + not being met. This task demand is therefore a tunable parameter: + + /proc/sys/kernel/sched_upmigrate + + This value is a percentage. If a task consumes more than this much of a + particular CPU, that CPU will be considered too small for the task. The task + will thus be seen as a "big" task on the cpu and will reflect in nr_big_tasks + statistics maintained for that cpu. Note that certain tasks (whose nice + value exceeds SCHED_UPMIGRATE_MIN_NICE value or those that belong to a cgroup + whose upmigrate_discourage flag is set) will never be classified as big tasks + despite their high demand. + + As the load scale factor is calculated against current fmax, it gets boosted + when a lower capacity CPU is restricted to run at lower fmax. The task + demand is inflated in this scenario and the task upmigrates early to the + maximum capacity CPU. Hence this threshold is auto-adjusted by a factor + equal to max_possible_frequency/current_frequency of a lower capacity CPU. + This adjustment happens only when the lower capacity CPU frequency is + restricted. The same adjustment is applied to the downmigrate threshold + as well. + + When the frequency restriction is relaxed, the previous values are restored. + sched_up_down_migrate_auto_update macro defined in kernel/sched/core.c + controls this auto-adjustment behavior and it is enabled by default. + + If the adjusted upmigrate threshold exceeds the window size, it is clipped to + the window size. If the adjusted downmigrate threshold decreases the difference + between the upmigrate and downmigrate, it is clipped to a value such that the + difference between the modified and the original thresholds is same. + +- spill threshold + + Tasks will normally be placed on lowest power-cost cluster where they can fit. + This could result in power-efficient cluster becoming overcrowded when there + are "too" many low-demand tasks. Spill threshold provides a spill over + criteria, wherein low-demand task are allowed to be placed on idle or + busy cpus in high-performance cluster. + + Scheduler will avoid placing a task on a cpu if it can result in cpu exceeding + its spill threshold, which is defined by two tunables: + + /proc/sys/kernel/sched_spill_nr_run (default: 10) + /proc/sys/kernel/sched_spill_load (default : 100%) + + A cpu is considered to be above its spill level if it already has 10 tasks or + if the sum of task load (scaled in reference to given cpu) and + rq->cumulative_runnable_avg exceeds 'sched_spill_load'. + +- power band + + The scheduler may be faced with a tradeoff between power and performance when + placing a task. If the scheduler sees two CPUs which can accommodate a task: + + CPU 1, power cost of 20, load of 10 + CPU 2, power cost of 10, load of 15 + + It is not clear what the right choice of CPU is. The HMP scheduler + offers the sched_powerband_limit tunable to determine how this + situation should be handled. When the power delta between two CPUs + is less than sched_powerband_limit_pct, load will be prioritized as + the deciding factor as to which CPU is selected. If the power delta + between two CPUs exceeds that, the lower power CPU is considered to + be in a different "band" and it is selected, despite perhaps having + a higher current task load. + +*** 5.2 select_best_cpu() + +CPU placement decisions for a task at its wakeup or creation time are the +most important decisions made by the HMP scheduler. This section will describe +the call flow and algorithm used in detail. + +The primary entry point for a task wakeup operation is try_to_wake_up(), +located in kernel/sched/core.c. This function relies on select_task_rq() to +determine the target CPU for the waking task. For fair-class (SCHED_OTHER) +tasks, that request will be routed to select_task_rq_fair() in +kernel/sched/fair.c. As part of these scheduler extensions a hook has been +inserted into the top of that function. If HMP scheduling is enabled the normal +scheduling behavior will be replaced by a call to select_best_cpu(). This +function, select_best_cpu(), represents the heart of the HMP scheduling +algorithm described in this document. Note that select_best_cpu() is also +invoked for a task being created. + +The behavior of select_best_cpu() depends on several factors such as boost +setting, choice of several tunables and on task demand. + +**** 5.2.1 Boost + +The task placement policy changes signifincantly when scheduler boost is in +effect. When boost is in effect the scheduler ignores the power cost of +placing tasks on CPUs. Instead it figures out the load on each CPU and then +places task on the least loaded CPU. If the load of two or more CPUs is the +same (generally when CPUs are idle) the task prefers to go highest capacity +CPU in the system. + +A further enhancement during boost is the scheduler' early detection feature. +While boost is in effect the scheduler checks for the precence of tasks that +have been runnable for over some period of time within the tick. For such +tasks the scheduler informs the governor of imminent need for high frequency. +If there exists a task on the runqueue at the tick that has been runnable +for greater than SCHED_EARLY_DETECTION_DURATION amount of time, it notifies +the governor with a fabricated load of the full window at the highest +frequency. The fabricated load is maintained until the task is no longer +runnable or until the next tick. + +Boost can be set via either /proc/sys/kernel/sched_boost or by invoking +kernel API sched_set_boost(). + + int sched_set_boost(int enable); + +Once turned on, boost will remain in effect until it is explicitly turned off. +To allow for boost to be controlled by multiple external entities (application +or kernel module) at same time, boost setting is reference counted. This means +that two applications can turn on boost and the effect of boost is eliminated +only after both applications have turned off boost. boost_refcount variable +represents this reference count. + +**** 5.2.2 task_will_fit() + +The overall goal of select_best_cpu() is to place a task on the least power +cluster where it can "fit" i.e where its cpu usage shall be below the capacity +offered by cluster. Criteria for a task to be considered as fitting in a cluster +is: + + i) A low-priority task, whose nice value is greater than + SCHED_UPMIGRATE_MIN_NICE or whose cgroup has its + upmigrate_discourage flag set, is considered to be fitting in all clusters, + irrespective of their capacity and task's cpu demand. + + ii) All tasks are considered to fit in highest capacity cluster. + + iii) Task demand scaled in reference to the given cluster should be less than a + threshold. See section on load_scale_factor to know more about how task + demand is scaled in reference to a given cpu (cluster). The threshold used + is normally sched_upmigrate. Its possible for a task's demand to exceed + sched_upmigrate threshold in reference to a cluster when its upmigrated to + higher capacity cluster. To prevent it from coming back immediately to + lower capacity cluster, the task is not considered to "fit" on its earlier + cluster until its demand has dropped below sched_downmigrate in reference + to that earlier cluster. sched_downmigrate thus provides for some + hysteresis control. + + +**** 5.2.3 Factors affecting select_best_cpu() + +Behavior of select_best_cpu() is further controlled by several tunables and +synchronous nature of wakeup. + +a. /proc/sys/kernel/sched_cpu_high_irqload + A cpu whose irq load is greater than this threshold will not be + considered eligible for placement. This threshold value in expressed in + nanoseconds scale, with default threshold being 10000000 (10ms). See + notes on sched_cpu_high_irqload tunable to understand how irq load on a + cpu is measured. + +b. Synchronous nature of wakeup + Synchronous wakeup is a hint to scheduler that the task issuing wakeup + (i.e task currently running on cpu where wakeup is being processed by + scheduler) will "soon" relinquish CPU. A simple example is two tasks + communicating with each other using a pipe structure. When reader task + blocks waiting for data, its woken by writer task after it has written + data to pipe. Writer task usually blocks waiting for reader task to + consume data in pipe (which may not have any more room for writes). + + Synchronous wakeup is accounted for by adjusting load of a cpu to not + include load of currently running task. As a result, a cpu that has only + one runnable task and which is currently processing synchronous wakeup + will be considered idle. + +c. PF_WAKE_UP_IDLE + Any task with this flag set will be woken up to an idle cpu (if one is + available) independent of sched_prefer_idle flag setting, its demand and + synchronous nature of wakeup. Similarly idle cpu is preferred during + wakeup for any task that does not have this flag set but is being woken + by a task with PF_WAKE_UP_IDLE flag set. For simplicity, we will use the + term "PF_WAKE_UP_IDLE wakeup" to signify wakeups involving a task with + PF_WAKE_UP_IDLE flag set. + +d. /proc/sys/kernel/sched_select_prev_cpu_us + This threshold controls whether task placement goes through fast path or + not. If task's wakeup time since last sleep is short there are high + chances that it's better to place the task on its previous CPU. This + reduces task placement latency, cache miss and number of migrations. + Default value of sched_select_prev_cpu_us is 2000 (2ms). This can be + turned off by setting it to 0. + +e. /proc/sys/kernel/sched_short_burst_ns + This threshold controls whether a task is considered as "short-burst" + or not. "short-burst" tasks are eligible for packing to avoid overhead + associated with waking up an idle CPU. "non-idle" CPUs which are not + loaded with IRQs and can accommodate the waking task without exceeding + spill limits are considered. The ties are broken with load followed + by previous CPU. This tunable does not affect cluster selection. + It only affects CPU selection in a given cluster. This packing is + skipped for tasks that are eligible for "wake-up-idle" and "boost". + +**** 5.2.4 Wakeup Logic for Task "p" + +Wakeup task placement logic is as follows: + +1) Eliminate CPUs with high irq load based on sched_cpu_high_irqload tunable. + +2) Eliminate CPUs where either the task does not fit or CPUs where placement +will result in exceeding the spill threshold tunables. CPUs elimiated at this +stage will be considered as backup choices incase none of the CPUs get past +this stage. + +3) Find out and return the least power CPU that satisfies all conditions above. + +4) If two or more CPUs are projected to have the same power, break ties in the +following preference order: + a) The CPU is the task's previous CPU. + b) The CPU is in the same cluster as the task's previous CPU. + c) The CPU has the least load + +The placement logic described above does not apply when PF_WAKE_UP_IDLE is set +for either the waker task or the wakee task. Instead the scheduler chooses the +most power efficient idle CPU. + +5) If no CPU is found after step 2, resort to backup CPU selection logic +whereby the CPU with highest amount of spare capacity is selected. + +6) If none of the CPUs have any spare capacity, return the task's previous +CPU. + +*** 5.3 Scheduler Tick + +Every CPU is interrupted periodically to let kernel update various statistics +and possibly preempt the currently running task in favor of a waiting task. This +periodicity, determined by CONFIG_HZ value, is set at 10ms. There are various +optimizations by which a CPU however can skip taking these interrupts (ticks). +A cpu going idle for considerable time in one such case. + +HMP scheduler extensions brings in a change in processing of tick +(scheduler_tick()) that can result in task migration. In case the currently +running task on a cpu belongs to fair_sched class, a check is made if it needs +to be migrated. Possible reasons for migrating task could be: + +a) A big task is running on a power-efficient cpu and a high-performance cpu is +available (idle) to service it + +b) A task is starving on a CPU with high irq load. + +c) A task with upmigration discouraged is running on a performance cluster. +See notes on 'cpu.upmigrate_discourage'. + +In case the test for migration turns out positive (which is expected to be rare +event), a candidate cpu is identified for task migration. To avoid multiple task +migrations to the same candidate cpu(s), identification of candidate cpu is +serialized via global spinlock (migration_lock). + +*** 5.4 Load Balancer + +Load balance is a key functionality of scheduler that strives to distribute task +across available cpus in a "fair" manner. Most of the complexity associated with +this feature involves balancing fair_sched class tasks. Changes made to load +balance code serve these goals: + +1. Restrict flow of tasks from power-efficient cpus to high-performance cpu. + Provide a spill-over threshold, defined in terms of number of tasks + (sched_spill_nr_run) and cpu demand (sched_spill_load), beyond which tasks + can spill over from power-efficient cpu to high-performance cpus. + +2. Allow idle power-efficient cpus to pick up extra load from over-loaded + performance-efficient cpu + +3. Allow idle high-performance cpu to pick up big tasks from power-efficient cpu + +*** 5.5 Real Time Tasks + +Minimal changes introduced in treatment of real-time tasks by HMP scheduler +aims at preferring scheduling of real-time tasks on cpus with low load on +a power efficient cluster. + +Prior to HMP scheduler, the fast-path cpu selection for placing a real-time task +(at wakeup) is its previous cpu, provided the currently running task on its +previous cpu is not a real-time task or a real-time task with lower priority. +Failing this, cpu selection in slow-path involves building a list of candidate +cpus where the waking real-time task will be of highest priority and thus can be +run immediately. The first cpu from this candidate list is chosen for the waking +real-time task. Much of the premise for this simple approach is the assumption +that real-time tasks often execute for very short intervals and thus the focus +is to place them on a cpu where they can be run immediately. + +HMP scheduler brings in a change which avoids fast-path and always resorts to +slow-path. Further cpu with lowest load in a power efficient cluster from +candidate list of cpus is chosen as cpu for placing waking real-time task. + +- PF_WAKE_UP_IDLE + +Idle cpu is preferred for any waking task that has this flag set in its +'task_struct.flags' field. Further idle cpu is preferred for any task woken by +such tasks. PF_WAKE_UP_IDLE flag of a task is inherited by it's children. It can +be modified for a task in two ways: + + > kernel-space interface + set_wake_up_idle() needs to be called in the context of a task + to set or clear its PF_WAKE_UP_IDLE flag. + + > user-space interface + /proc/[pid]/sched_wake_up_idle file needs to be written to for + setting or clearing PF_WAKE_UP_IDLE flag for a given task + +===================== +6. FREQUENCY GUIDANCE +===================== + +As mentioned in the introduction section the scheduler is in a unique +position to assist with the determination of CPU frequency. Because +the scheduler now maintains an estimate of per-task CPU demand, task +activity can be tracked, aggregated and provided to the CPUfreq +governor as a replacement for simple CPU busy time. + +Two of the most popular CPUfreq governors, interactive and ondemand, +utilize a window-based approach for measuring CPU busy time. This +works well with the window-based load tracking scheme previously +described. The following APIs are provided to allow the CPUfreq +governor to query busy time from the scheduler instead of using the +basic CPU busy time value derived via get_cpu_idle_time_us() and +get_cpu_iowait_time_us() APIs. + + int sched_set_window(u64 window_start, unsigned int window_size) + + This API is invoked by governor at initialization time or whenever + window size is changed. 'window_size' argument (in jiffy units) + indicates the size of window to be used. The first window of size + 'window_size' is set to begin at jiffy 'window_start' + + -EINVAL is returned if per-entity load tracking is in use rather + than window-based load tracking, otherwise a success value of 0 + is returned. + + int sched_get_busy(int cpu) + + Returns the busy time for the given CPU in the most recent + complete window. The value returned is microseconds of busy + time at fmax of given CPU. + +The values returned by sched_get_busy() take a bit of explanation, +both in what they mean and also how they are derived. + +*** 6.1 Per-CPU Window-Based Stats + +The scheduler tracks two separate types of quantities on a per CPU basis. +The first type has to deal with the aggregate load on a CPU and the second +type deals with top-tasks on that same CPU. We will first proceed to explain +what is maintained as part of each type of statistics and then provide the +connection between these two types of statistics at the end. + +First lets describe the HMP scheduler extensions to track the aggregate load +seen on each CPU. This is done using the same windows that the task demand +is tracked with (which is in turn set by the governor when frequency guidance +is in use). There are four quantities maintained for each CPU by the HMP +scheduler for tracking CPU load: + + curr_runnable_sum: aggregate demand from all tasks which executed during + the current (not yet completed) window + + prev_runnable_sum: aggregate demand from all tasks which executed during + the most recent completed window + + nt_curr_runnable_sum: aggregate demand from all 'new' tasks which executed + during the current (not yet completed) window + + nt_prev_runnable_sum: aggregate demand from all 'new' tasks which executed + during the most recent completed window. + +When the scheduler is updating a task's window-based stats it also +updates these values. Like per-task window-based demand these +quantities are normalized against the max possible frequency and max +efficiency (instructions per cycle) in the system. If an update occurs +and a window rollover is observed, curr_runnable_sum is copied into +prev_runnable_sum before being reset to 0. The sched_get_busy() API +returns prev_runnable_sum, scaled to the efficiency and fmax of given +CPU. The same applies to nt_curr_runnable_sum and nt_prev_runnable_sum. + +A 'new' task is defined as a task whose number of active windows since fork is +less than SCHED_NEW_TASK_WINDOWS. An active window is defined as a window +where a task was observed to be runnable. + +Moving on the second type of statistics; top-tasks, the scheduler tracks a list +of top tasks per CPU. A top-task is defined as the task that runs the most in a +given window on that CPU. This includes task that ran on that CPU through out +the window or were migrated to that CPU prior to window expiration. It does not +include tasks that were migrated away from that CPU prior to window expiration. + +To track top tasks, we first realize that there is no strict need to maintain +the task struct itself as long as we know the load exerted by the top task. We +also realize that to maintain top tasks on every CPU we have to track the +execution of every single task that runs during the window. The load associated +with a task needs to be migrated when the task migrates from one CPU to another. +When the top task migrates away, we need to locate the second top task and so +on. + +Given the above realizations, we use hashmaps to track top task load both +for the current and the previous window. This hashmap is implemented as an array +of fixed size. The key of the hashmap is given by +task_execution_time_in_a_window / array_size. The size of the array (number of +buckets in the hashmap) dictate the load granularity of each bucket. The value +stored in each bucket is a refcount of all the tasks that executed long enough +to be in that bucket. This approach has a few benefits. Firstly, any top task +stats update now take O(1) time. While task migration is also O(1), it does +still involve going through up to the size of the array to find the second top +task. We optimize this search by using bitmaps. The next set bit in the bitmap +gives the position of the second top task in our hashamp. + +Secondly, and more importantly, not having to store the task struct itself +saves a lot of memory usage in that 1) there is no need to retrieve task structs +later causing cache misses and 2) we don't have to unnecessarily hold up task +memory for up to 2 full windows by calling get_task_struct() after a task exits. + +Given the motivation above, here are a list of quantities tracked as part of +per CPU task top-tasks management + + top_tasks[NUM_TRACKED_WINDOWS] - Hashmap of top-task load for the current and + previous window + + BITMAP_ARRAY(top_tasks_bitmap) - Two bitmaps for the current and previous + windows corresponding to the top-task + hashmap. + + load_subs[NUM_TRACKED_WINDOWS] - An array of load subtractions to be carried + out form curr/prev_runnable_sums for each CPU + prior to reporting load to the governor. The + purpose for this will be explained later in + the section pertaining to the TASK_MIGRATE + event. The type struct load_subtractions, + stores the value of the subtraction along + with the window start value for the window + for which the subtraction has to take place. + + + curr_table - Indication of which index of the array points to the current + window. + + curr_top - The top task on a CPU at any given moment in the current window + + prev_top - The top task on a CPU in the previous window + + +*** 6.2 Per-task window-based stats + +Corresponding to curr_runnable_sum and prev_runnable_sum, two counters are +maintained per-task + +curr_window_cpu - represents task's contribution to cpu busy time on + various CPUs in the current window + +prev_window_cpu - represents task's contribution to cpu busy time on + various CPUs in the previous window + +curr_window - represents the sum of all entries in curr_window_cpu + +prev_window - represents the sum of all entries in prev_window_cpu + +"cpu demand" of a task includes its execution time and can also include its +wait time. 'SCHED_FREQ_ACCOUNT_WAIT_TIME' controls whether task's wait +time is included in its CPU load counters or not. + +Curr_runnable_sum counter of a cpu is derived from curr_window_cpu[cpu] +counter of various tasks that ran on it in its most recent window. + +*** 6.3 Effect of various task events + +We now consider various events and how they affect above mentioned counters. + +PICK_NEXT_TASK + This represents beginning of execution for a task. Provided the task + refers to a non-idle task, a portion of task's wait time that + corresponds to the current window being tracked on a cpu is added to + task's curr_window_cpu and curr_window counter, provided + SCHED_FREQ_ACCOUNT_WAIT_TIME is set. The same quantum is also added to + cpu's curr_runnable_sum counter. The remaining portion, which + corresponds to task's wait time in previous window is added to task's + prev_window, prev_window_cpu and cpu's prev_runnable_sum counters. + + CPUs top_tasks hashmap is updated if needed with the new information. + Any previous entries in the hashmap are deleted and newer entries are + created. The top_tasks_bitmap reflects the updated state of the + hashmap. If the top task for the current and/or previous window has + changed, curr_top and prev_top are updated accordingly. + +PUT_PREV_TASK + This represents end of execution of a time-slice for a task, where the + task could refer to a cpu's idle task also. In case the task is non-idle + or (in case of task being idle with cpu having non-zero rq->nr_iowait + count and sched_io_is_busy =1), a portion of task's execution time, that + corresponds to current window being tracked on a cpu is added to task's + curr_window_cpu and curr_window counter and also to cpu's + curr_runnable_sum counter. Portion of task's execution that corresponds + to the previous window is added to task's prev_window, prev_window_cpu + and cpu's prev_runnable_sum counters. + + CPUs top_tasks hashmap is updated if needed with the new information. + Any previous entries in the hashmap are deleted and newer entries are + created. The top_tasks_bitmap reflects the updated state of the + hashmap. If the top task for the current and/or previous window has + changed, curr_top and prev_top are updated accordingly. + +TASK_UPDATE + This event is called on a cpu's currently running task and hence + behaves effectively as PUT_PREV_TASK. Task continues executing after + this event, until PUT_PREV_TASK event occurs on the task (during + context switch). + +TASK_WAKE + This event signifies a task waking from sleep. Since many windows + could have elapsed since the task went to sleep, its + curr_window_cpu/curr_window and prev_window_cpu/prev_window are + updated to reflect task's demand in the most recent and its previous + window that is being tracked on a cpu. Updated stats will trigger + the same book-keeping for top-tasks as other events. + +TASK_MIGRATE + This event signifies task migration across cpus. It is invoked on the + task prior to being moved. Thus at the time of this event, the task + can be considered to be in "waiting" state on src_cpu. In that way + this event reflects actions taken under PICK_NEXT_TASK (i.e its + wait time is added to task's curr/prev_window/_cpu counters as well + as src_cpu's curr/prev_runnable_sum counters, provided + SCHED_FREQ_ACCOUNT_WAIT_TIME is non-zero). + + After that update, we make a distinction between intra-cluster and + inter-cluster migrations for further book-keeping. + + For intra-cluster migrations, we simply remove the entry for the task + in the top_tasks hashmap from the source CPU and add the entry to the + destination CPU. The top_tasks_bitmap, curr_top and prev_top are + updated accordingly. We then find the second top-task top in our + top_tasks hashmap for both the current and previous window and set + curr_top and prev_top to their new values. + + For inter-cluster migrations we have a much more complicated scheme. + Firstly we add to the destination CPU's curr/prev_runnable_sum + the tasks curr/prev_window. Note we add the sum and not the + contribution any individual CPU. This is because when a tasks migrates + across clusters, we need the new cluster to ramp up to the appropriate + frequency given the task's total execution summed up across all CPUs + in the previous cluster. + + Secondly the src_cpu's curr/prev_runnable_sum are reduced by task's + curr/prev_window_cpu values. + + Thirdly, we need to walk all the CPUs in the cluster and subtract from + each CPU's curr/prev_runnable_sum the task's respective + curr/prev_window_cpu values. However, subtracting load from each of + the source CPUs is not trivial, as it would require all runqueue + locks to be held. To get around this we introduce a deferred load + subtraction mechanism whereby subtracting load from each of the source + CPUs is deferred until an opportune moment. This opportune moment is + when the governor comes asking the scheduler for load. At that time, all + necessary runqueue locks are already held. + + There are a few cases to consider when doing deferred subtraction. Since + we are not holding all runqueue locks other CPUs in the source cluster + can be in a different window than the source CPU where the task is + migrating from. + + Case 1: + Other CPU in the source cluster is in the same window. No special + consideration. + + Case 2: + Other CPU in the source cluster is ahead by 1 window. In this + case, we will be doing redundant updates to subtraction load for the + prev window. There is no way to avoid this redundant update though, + without holding the rq lock. + + Case 3: + Other CPU in the source cluster is trailing by 1 window In this + case, we might end up overwriting old data for that CPU. But this is not + a problem as when the other CPU calls update_task_ravg() it will move to + the same window. This relies on maintaining synchronized windows between + CPUs, which is true today. + + To achieve all the above, we simple add the task's curr/prev_window_cpu + contributions to the per CPU load_subtractions array. These load + subtractions are subtracted from the respective CPU's + curr/prev_runnable_sums before the governor queries CPU load. Once this + is complete, the scheduler sets all curr/prev_window_cpu contributions + of the task to 0 for all CPUs in the source cluster. The destination + CPUs's curr/prev_window_cpu is updated with the tasks curr/prev_window + sums. + + Finally, we must deal with frequency aggregation. When frequency + aggregation is in effect, there is little point in dealing with per CPU + footprint since the load of all related tasks have to be reported on a + single CPU. Therefore when a task enters a related group we clear out + all per CPU contributions and add it to the task CPU's cpu_time struct. + From that point onwards we stop managing per CPU contributions upon + inter cluster migrations since that work is redundant. Finally when a + task exits a related group we must walk every CPU in reset all CPU + contributions. We then set the task CPU contribution to the respective + curr/prev sum values and add that sum to the task CPU rq runnable sum. + + Top-task management is the same as in the case of intra-cluster + migrations. + +IRQ_UPDATE + This event signifies end of execution of an interrupt handler. This + event results in update of cpu's busy time counters, curr_runnable_sum + and prev_runnable_sum, provided cpu was idle. When sched_io_is_busy = 0, + only the interrupt handling time is added to cpu's curr_runnable_sum and + prev_runnable_sum counters. When sched_io_is_busy = 1, the event mirrors + actions taken under TASK_UPDATED event i.e time since last accounting + of idle task's cpu usage is added to cpu's curr_runnable_sum and + prev_runnable_sum counters. No update is needed for top-tasks in this + case. + +*** 6.4 Tying it all together + +Now the scheduler maintains two independent quantities for load reporing 1) CPU +load as represented by prev_runnable_sum and 2) top-tasks. The reported load +is governed by tunable sched_freq_reporting_policy. The default choice is +FREQ_REPORT_MAX_CPU_LOAD_TOP_TASK. In other words: + +max(prev_runnable_sum, top_task load) + +Let's explain the rationale behind the choice. CPU load tracks the exact amount +of execution observed on a CPU. This is close to the quantity that the vanilla +governor used to track. It offers the advantages of no load over-reporting that +our earlier load fixup mechanisms had deal with. It then also tackles the part +picture problem by keeping of track of tasks that might be migrating across +CPUs leaving a small footprint on each CPU. Since we maintain one top task per +CPU, we can handle as many top tasks as the number of CPUs in a cluster. We +might miss a few cases where the combined load of the top and non-top tasks on +a CPU are more representative of the true load. However, those cases have been +deemed to rare and have little impact on overall load/frequency behavior. + + +=========== +7. TUNABLES +=========== + +*** 7.1 sched_spill_load + +Appears at: /proc/sys/kernel/sched_spill_load + +Default value: 100 + +CPU selection criteria for fair-sched class tasks is the lowest power cpu where +they can fit. When the most power-efficient cpu where a task can fit is +overloaded (aggregate demand of tasks currently queued on it exceeds +sched_spill_load), a task can be placed on a higher-performance cpu, even though +the task strictly doesn't need one. + +*** 7.2 sched_spill_nr_run + +Appears at: /proc/sys/kernel/sched_spill_nr_run + +Default value: 10 + +The intent of this tunable is similar to sched_spill_load, except it applies to +nr_running count of a cpu. A task can spill over to a higher-performance cpu +when the most power-efficient cpu where it can normally fit has more tasks than +sched_spill_nr_run. + +*** 7.3 sched_upmigrate + +Appears at: /proc/sys/kernel/sched_upmigrate + +Default value: 80 + +This tunable is a percentage. If a task consumes more than this much +of a CPU, the CPU is considered too small for the task and the +scheduler will try to find a bigger CPU to place the task on. + +*** 7.4 sched_init_task_load + +Appears at: /proc/sys/kernel/sched_init_task_load + +Default value: 15 + +This tunable is a percentage. When a task is first created it has no +history, so the task load tracking mechanism cannot determine a +historical load value to assign to it. This tunable specifies the +initial load value for newly created tasks. Also see Sec 2.8 on per-task +'initial task load' attribute. + +*** 7.5 sched_ravg_hist_size + +Appears at: /proc/sys/kernel/sched_ravg_hist_size + +Default value: 5 + +This tunable controls the number of samples used from task's sum_history[] +array for determination of its demand. + +*** 7.6 sched_window_stats_policy + +Appears at: /proc/sys/kernel/sched_window_stats_policy + +Default value: 2 + +This tunable controls the policy in how window-based load tracking +calculates an overall demand value based on the windows of CPU +utilization it has collected for a task. + +Possible values for this tunable are: +0: Just use the most recent window sample of task activity when calculating + task demand. +1: Use the maximum value of first M samples found in task's cpu demand + history (sum_history[] array), where M = sysctl_sched_ravg_hist_size +2: Use the maximum of (the most recent window sample, average of first M + samples), where M = sysctl_sched_ravg_hist_size +3. Use average of first M samples, where M = sysctl_sched_ravg_hist_size + +*** 7.7 sched_ravg_window + +Appears at: kernel command line argument + +Default value: 10000000 (10ms, units of tunable are nanoseconds) + +This specifies the duration of each window in window-based load +tracking. By default each window is 10ms long. This quantity must +currently be set at boot time on the kernel command line (or the +default value of 10ms can be used). + +*** 7.8 RAVG_HIST_SIZE + +Appears at: compile time only (see RAVG_HIST_SIZE in include/linux/sched.h) + +Default value: 5 + +This macro specifies the number of windows the window-based load +tracking mechanism maintains per task. If default values are used for +both this and sched_ravg_window then a total of 50ms of task history +would be maintained in 5 10ms windows. + +*** 7.9 sched_freq_inc_notify + +Appears at: /proc/sys/kernel/sched_freq_inc_notify + +Default value: 10 * 1024 * 1024 (10 Ghz) + +When scheduler detects that cur_freq of a cluster is insufficient to meet +demand, it sends notification to governor, provided (freq_required - cur_freq) +exceeds sched_freq_inc_notify, where freq_required is the frequency calculated +by scheduler to meet current task demand. Note that sched_freq_inc_notify is +specified in kHz units. + +*** 7.10 sched_freq_dec_notify + +Appears at: /proc/sys/kernel/sched_freq_dec_notify + +Default value: 10 * 1024 * 1024 (10 Ghz) + +When scheduler detects that cur_freq of a cluster is far greater than what is +needed to serve current task demand, it will send notification to governor. +More specifically, notification is sent when (cur_freq - freq_required) +exceeds sched_freq_dec_notify, where freq_required is the frequency calculated +by scheduler to meet current task demand. Note that sched_freq_dec_notify is +specified in kHz units. + +*** 7.11 sched_cpu_high_irqload + +Appears at: /proc/sys/kernel/sched_cpu_high_irqload + +Default value: 10000000 (10ms) + +The scheduler keeps a decaying average of the amount of irq and softirq activity +seen on each CPU within a ten millisecond window. Note that this "irqload" +(reported in the sched_cpu_load_* tracepoint) will be higher than the typical load +in a single window since every time the window rolls over, the value is decayed +by some fraction and then added to the irq/softirq time spent in the next +window. + +When the irqload on a CPU exceeds the value of this tunable, the CPU is no +longer eligible for placement. This will affect the task placement logic +described above, causing the scheduler to try and steer tasks away from +the CPU. + +*** 7.12 cpu.upmigrate_discourage + +Default value : 0 + +This is a cgroup attribute supported by the cpu resource controller. It normally +appears at [root_cpu]/[name1]/../[name2]/cpu.upmigrate_discourage. Here +"root_cpu" is the mount point for cgroup (cpu resource control) filesystem +and name1, name2 etc are names of cgroups that form a hierarchy. + +Setting this flag to 1 discourages upmigration for all tasks of a cgroup. High +demand tasks of such a cgroup will never be classified as big tasks and hence +not upmigrated. Any task of the cgroup is allowed to upmigrate only under +overcommitted scenario. See notes on sched_spill_nr_run and sched_spill_load for +how overcommitment threshold is defined. + +*** 7.13 sched_static_cpu_pwr_cost + +Default value: 0 + +Appears at /sys/devices/system/cpu/cpu<x>/sched_static_cpu_pwr_cost + +This is the power cost associated with bringing an idle CPU out of low power +mode. It ignores the actual C-state that a CPU may be in and assumes the +worst case power cost of the highest C-state. It is means of biasing task +placement away from idle CPUs when necessary. It can be defined per CPU, +however, a more appropriate usage to define the same value for every CPU +within a cluster and possibly have differing value between clusters as +needed. + + +*** 7.14 sched_static_cluster_pwr_cost + +Default value: 0 + +Appears at /sys/devices/system/cpu/cpu<x>/sched_static_cluster_pwr_cost + +This is the power cost associated with bringing an idle cluster out of low +power mode. It ignores the actual D-state that a cluster may be in and assumes +the worst case power cost of the highest D-state. It is means of biasing task +placement away from idle clusters when necessary. + +*** 7.15 sched_restrict_cluster_spill + +Default value: 0 + +Appears at /proc/sys/kernel/sched_restrict_cluster_spill + +This tunable can be used to restrict tasks spilling to the higher capacity +(higher power) cluster. When this tunable is enabled, + +- Restrict the higher capacity cluster pulling tasks from the lower capacity +cluster in the load balance path. The restriction is lifted if all of the CPUS +in the lower capacity cluster are above spill. The power cost is used to break +the ties if the capacity of clusters are same for applying this restriction. + +- The current CPU selection algorithm for RT tasks looks for the least loaded +CPU across all clusters. When this tunable is enabled, the RT tasks are +restricted to the lowest possible power cluster. + + +*** 7.16 sched_downmigrate + +Appears at: /proc/sys/kernel/sched_downmigrate + +Default value: 60 + +This tunable is a percentage. It exists to control hysteresis. Lets say a task +migrated to a high-performance cpu when it crossed 80% demand on a +power-efficient cpu. We don't let it come back to a power-efficient cpu until +its demand *in reference to the power-efficient cpu* drops less than 60% +(sched_downmigrate). + + +*** 7.17 sched_small_wakee_task_load + +Appears at: /proc/sys/kernel/sched_small_wakee_task_load + +Default value: 10 + +This tunable is a percentage. Configure the maximum demand of small wakee task. +Sync wakee tasks which have demand less than sched_small_wakee_task_load are +categorized as small wakee tasks. Scheduler places small wakee tasks on the +waker's cluster. + + +*** 7.18 sched_big_waker_task_load + +Appears at: /proc/sys/kernel/sched_big_waker_task_load + +Default value: 25 + +This tunable is a percentage. Configure the minimum demand of big sync waker +task. Scheduler places small wakee tasks woken up by big sync waker on the +waker's cluster. + +*** 7.19 sched_prefer_sync_wakee_to_waker + +Appears at: /proc/sys/kernel/sched_prefer_sync_wakee_to_waker + +Default value: 0 + +The default sync wakee policy has a preference to select an idle CPU in the +waker cluster compared to the waker CPU running only 1 task. By selecting +an idle CPU, it eliminates the chance of waker migrating to a different CPU +after the wakee preempts it. This policy is also not susceptible to the +incorrect "sync" usage i.e the waker does not goto sleep after waking up +the wakee. + +However LPM exit latency associated with an idle CPU outweigh the above +benefits on some targets. When this knob is turned on, the waker CPU is +selected if it has only 1 runnable task. + +*** 7.20 sched_freq_reporting_policy + +Appears at: /proc/sys/kernel/sched_freq_reporting_policy + +Default value: 0 + +This dictates what the load reporting policy to the governor should be. The +default value is FREQ_REPORT_MAX_CPU_LOAD_TOP_TASK. Other values include +FREQ_REPORT_CPU_LOAD which only reports CPU load to the governor and +FREQ_REPORT_TOP_TASK which only reports the load of the top task on a CPU +to the governor. + +========================= +8. HMP SCHEDULER TRACE POINTS +========================= + +*** 8.1 sched_enq_deq_task + +Logged when a task is either enqueued or dequeued on a CPU's run queue. + + <idle>-0 [004] d.h4 12700.711665: sched_enq_deq_task: cpu=4 enqueue comm=powertop pid=13227 prio=120 nr_running=1 cpu_load=0 rt_nr_running=0 affine=ff demand=13364423 + +- cpu: the CPU that the task is being enqueued on to or dequeued off of +- enqueue/dequeue: whether this was an enqueue or dequeue event +- comm: name of task +- pid: PID of task +- prio: priority of task +- nr_running: number of runnable tasks on this CPU +- cpu_load: current priority-weighted load on the CPU (note, this is *not* + the same as CPU utilization or a metric tracked by PELT/window-based tracking) +- rt_nr_running: number of real-time processes running on this CPU +- affine: CPU affinity mask in hex for this task (so ff is a task eligible to + run on CPUs 0-7) +- demand: window-based task demand computed based on selected policy (recent, + max, or average) (ns) + +*** 8.2 sched_task_load + +Logged when selecting the best CPU to run the task (select_best_cpu()). + +sched_task_load: 4004 (adbd): demand=698425 boost=0 reason=0 sync=0 need_idle=0 best_cpu=0 latency=103177 + +- demand: window-based task demand computed based on selected policy (recent, + max, or average) (ns) +- boost: whether boost is in effect +- reason: reason we are picking a new CPU: + 0: no migration - selecting a CPU for a wakeup or new task wakeup + 1: move to big CPU (migration) + 2: move to little CPU (migration) + 3: move to low irq load CPU (migration) +- sync: is the nature synchronous in nature +- need_idle: is an idle CPU required for this task based on PF_WAKE_UP_IDLE +- best_cpu: The CPU selected by the select_best_cpu() function for placement +- latency: The execution time of the function select_best_cpu() + +*** 8.3 sched_cpu_load_* + +Logged when selecting the best CPU to run a task (select_best_cpu() for fair +class tasks, find_lowest_rq_hmp() for RT tasks) and load balancing +(update_sg_lb_stats()). + +<idle>-0 [004] d.h3 12700.711541: sched_cpu_load_*: cpu 0 idle 1 nr_run 0 nr_big 0 lsf 1119 capacity 1024 cr_avg 0 irqload 3301121 fcur 729600 fmax 1459200 power_cost 5 cstate 2 temp 38 + +- cpu: the CPU being described +- idle: boolean indicating whether the CPU is idle +- nr_run: number of tasks running on CPU +- nr_big: number of BIG tasks running on CPU +- lsf: load scale factor - multiply normalized load by this factor to determine + how much load task will exert on CPU +- capacity: capacity of CPU (based on max possible frequency and efficiency) +- cr_avg: cumulative runnable average, instantaneous sum of the demand (either + PELT or window-based) of all the runnable task on a CPU (ns) +- irqload: decaying average of irq activity on CPU (ns) +- fcur: current CPU frequency (Khz) +- fmax: max CPU frequency (but not maximum _possible_ frequency) (KHz) +- power_cost: cost of running this CPU at the current frequency +- cstate: current cstate of CPU +- temp: current temperature of the CPU + +The power_cost value above differs in how it is calculated depending on the +callsite of this tracepoint. The select_best_cpu() call to this tracepoint +finds the minimum frequency required to satisfy the existing load on the CPU +as well as the task being placed, and returns the power cost of that frequency. +The load balance and real time task placement paths used a fixed frequency +(highest frequency common to all CPUs for load balancing, minimum +frequency of the CPU for real time task placement). + +*** 8.4 sched_update_task_ravg + +Logged when window-based stats are updated for a task. The update may happen +for a variety of reasons, see section 2.5, "Task Events." + +rcu_preempt-7 [000] d..3 262857.738888: sched_update_task_ravg: wc 262857521127957 ws 262857490000000 delta 31127957 event PICK_NEXT_TASK cpu 0 cur_freq 291055 cur_pid 7 task 9309 (kworker/u16:0) ms 262857520627280 delta 500677 demand 282196 sum 156201 irqtime 0 pred_demand 267103 rq_cs 478718 rq_ps 0 cur_window 78433 (78433 0 0 0 0 0 0 0 ) prev_window 146430 (0 146430 0 0 0 0 0 0 ) nt_cs 0 nt_ps 0 active_wins 149 grp_cs 0 grp_ps 0, grp_nt_cs 0, grp_nt_ps: 0 curr_top 6 prev_top 2 + +- wc: wallclock, output of sched_clock(), monotonically increasing time since + boot (will roll over in 585 years) (ns) +- ws: window start, time when the current window started (ns) +- delta: time since the window started (wc - ws) (ns) +- event: What event caused this trace event to occur (see section 2.5 for more + details) +- cpu: which CPU the task is running on +- cur_freq: CPU's current frequency in KHz +- curr_pid: PID of the current running task (current) +- task: PID and name of task being updated +- ms: mark start - timestamp of the beginning of a segment of task activity, + either sleeping or runnable/running (ns) +- delta: time since last event within the window (wc - ms) (ns) +- demand: task demand computed based on selected policy (recent, max, or + average) (ns) +- sum: the task's run time during current window scaled by frequency and + efficiency (ns) +- irqtime: length of interrupt activity (ns). A non-zero irqtime is seen + when an idle cpu handles interrupts, the time for which needs to be + accounted as cpu busy time +- cs: curr_runnable_sum of cpu (ns). See section 6.1 for more details of this + counter. +- ps: prev_runnable_sum of cpu (ns). See section 6.1 for more details of this + counter. +- cur_window: cpu demand of task in its most recently tracked window summed up + across all CPUs (ns). This is followed by a list of contributions on each + individual CPU. +- prev_window: cpu demand of task in its previous window summed up across + all CPUs (ns). This is followed by a list of contributions on each individual + CPU. +- nt_cs: curr_runnable_sum of a cpu for new tasks only (ns). +- nt_ps: prev_runnable_sum of a cpu for new tasks only (ns). +- active_wins: No. of active windows since task statistics were initialized +- grp_cs: curr_runnable_sum for colocated tasks. This is independent from + cs described above. The addition of these two fields give the total CPU + load for the most recent window +- grp_ps: prev_runnable_sum for colocated tasks. This is independent from + ps described above. The addition of these two fields give the total CPU + load for the previous window. +- grp_nt_cs: curr_runnable_sum of a cpu for grouped new tasks only (ns). +- grp_nt_ps: prev_runnable_sum for a cpu for grouped new tasks only (ns). +- curr_top: index of the top task in the top_tasks array in the current + window for a CPU. +- prev_top: index of the top task in the top_tasks array in the previous + window for a CPU + +*** 8.5 sched_update_history + +Logged when update_task_ravg() is accounting task activity into one or +more windows that have completed. This may occur more than once for a +single call into update_task_ravg(). A task that ran for 24ms spanning +four 10ms windows (the last 2ms of window 1, all of windows 2 and 3, +and the first 2ms of window 4) would result in two calls into +update_history() from update_task_ravg(). The first call would record activity +in completed window 1 and second call would record activity for windows 2 and 3 +together (samples will be 2 in second call). + +<idle>-0 [004] d.h4 12700.711489: sched_update_history: 13227 (powertop): runtime 13364423 samples 1 event TASK_WAKE demand 13364423 (hist: 13364423 9871252 2236009 6162476 10282078) cpu 4 nr_big 0 + +- runtime: task cpu demand in recently completed window(s). This value is scaled + to max_possible_freq and max_possible_efficiency. This value is pushed into + task's demand history array. The number of windows to which runtime applies is + provided by samples field. +- samples: Number of samples (windows), each having value of runtime, that is + recorded in task's demand history array. +- event: What event caused this trace event to occur (see section 2.5 for more + details) - PUT_PREV_TASK, PICK_NEXT_TASK, TASK_WAKE, TASK_MIGRATE, + TASK_UPDATE +- demand: task demand computed based on selected policy (recent, max, or + average) (ns) +- hist: last 5 windows of history for the task with the most recent window + listed first +- cpu: CPU the task is associated with +- nr_big: number of big tasks on the CPU + +*** 8.6 sched_reset_all_windows_stats + +Logged when key parameters controlling window-based statistics collection are +changed. This event signifies that all window-based statistics for tasks and +cpus are being reset. Changes to below attributes result in such a reset: + +* sched_ravg_window (See Sec 2) +* sched_window_stats_policy (See Sec 2.4) +* sched_ravg_hist_size (See Sec 7.11) + +<task>-0 [004] d.h4 12700.711489: sched_reset_all_windows_stats: time_taken 1123 window_start 0 window_size 0 reason POLICY_CHANGE old_val 0 new_val 1 + +- time_taken: time taken for the reset function to complete (ns) +- window_start: Beginning of first window following change to window size (ns) +- window_size: Size of window. Non-zero if window-size is changing (in ticks) +- reason: Reason for reset of statistics. +- old_val: Old value of variable, change of which is triggering reset +- new_val: New value of variable, change of which is triggering reset + +*** 8.7 sched_migration_update_sum + +Logged when a task is migrating to another cpu. + +<task>-0 [000] d..8 5020.404137: sched_migration_update_sum: cpu 0: cs 471278 ps 902463 nt_cs 0 nt_ps 0 pid 2645 + +- cpu: cpu, away from which or to which, task is migrating +- cs: curr_runnable_sum of cpu (ns). See Sec 6.1 for more details of this + counter. +- ps: prev_runnable_sum of cpu (ns). See Sec 6.1 for more details of this + counter. +- nt_cs: nt_curr_runnable_sum of cpu (ns). See Sec 6.1 for more details of + this counter. +- nt_ps: nt_prev_runnable_sum of cpu (ns). See Sec 6.1 for more details of + this counter +- pid: PID of migrating task + +*** 8.8 sched_get_busy + +Logged when scheduler is returning busy time statistics for a cpu. + +<...>-4331 [003] d.s3 313.700108: sched_get_busy: cpu 3 load 19076 new_task_load 0 early 0 + + +- cpu: cpu, for which busy time statistic (prev_runnable_sum) is being + returned (ns) +- load: corresponds to prev_runnable_sum (ns), scaled to fmax of cpu +- new_task_load: corresponds to nt_prev_runnable_sum to fmax of cpu +- early: A flag indicating whether the scheduler is passing regular load or early detection load + 0 - regular load + 1 - early detection load + +*** 8.9 sched_freq_alert + +Logged when scheduler is alerting cpufreq governor about need to change +frequency + +<task>-0 [004] d.h4 12700.711489: sched_freq_alert: cpu 0 old_load=XXX new_load=YYY + +- cpu: cpu in cluster that has highest load (prev_runnable_sum) +- old_load: cpu busy time last reported to governor. This is load scaled in + reference to max_possible_freq and max_possible_efficiency. +- new_load: recent cpu busy time. This is load scaled in + reference to max_possible_freq and max_possible_efficiency. + +*** 8.10 sched_set_boost + +Logged when boost settings are being changed + +<task>-0 [004] d.h4 12700.711489: sched_set_boost: ref_count=1 + +- ref_count: A non-zero value indicates boost is in effect + +======================== +9. Device Tree bindings +======================== + +The device tree bindings for the HMP scheduler are defined in +Documentation/devicetree/bindings/sched/sched_hmp.txt diff --git a/Documentation/scheduler/sched-tune.txt b/Documentation/scheduler/sched-tune.txt new file mode 100644 index 000000000000..9bd2231c01b1 --- /dev/null +++ b/Documentation/scheduler/sched-tune.txt @@ -0,0 +1,366 @@ + Central, scheduler-driven, power-performance control + (EXPERIMENTAL) + +Abstract +======== + +The topic of a single simple power-performance tunable, that is wholly +scheduler centric, and has well defined and predictable properties has come up +on several occasions in the past [1,2]. With techniques such as a scheduler +driven DVFS [3], we now have a good framework for implementing such a tunable. +This document describes the overall ideas behind its design and implementation. + + +Table of Contents +================= + +1. Motivation +2. Introduction +3. Signal Boosting Strategy +4. OPP selection using boosted CPU utilization +5. Per task group boosting +6. Question and Answers + - What about "auto" mode? + - What about boosting on a congested system? + - How CPUs are boosted when we have tasks with multiple boost values? +7. References + + +1. Motivation +============= + +Sched-DVFS [3] is a new event-driven cpufreq governor which allows the +scheduler to select the optimal DVFS operating point (OPP) for running a task +allocated to a CPU. The introduction of sched-DVFS enables running workloads at +the most energy efficient OPPs. + +However, sometimes it may be desired to intentionally boost the performance of +a workload even if that could imply a reasonable increase in energy +consumption. For example, in order to reduce the response time of a task, we +may want to run the task at a higher OPP than the one that is actually required +by it's CPU bandwidth demand. + +This last requirement is especially important if we consider that one of the +main goals of the sched-DVFS component is to replace all currently available +CPUFreq policies. Since sched-DVFS is event based, as opposed to the sampling +driven governors we currently have, it is already more responsive at selecting +the optimal OPP to run tasks allocated to a CPU. However, just tracking the +actual task load demand may not be enough from a performance standpoint. For +example, it is not possible to get behaviors similar to those provided by the +"performance" and "interactive" CPUFreq governors. + +This document describes an implementation of a tunable, stacked on top of the +sched-DVFS which extends its functionality to support task performance +boosting. + +By "performance boosting" we mean the reduction of the time required to +complete a task activation, i.e. the time elapsed from a task wakeup to its +next deactivation (e.g. because it goes back to sleep or it terminates). For +example, if we consider a simple periodic task which executes the same workload +for 5[s] every 20[s] while running at a certain OPP, a boosted execution of +that task must complete each of its activations in less than 5[s]. + +A previous attempt [5] to introduce such a boosting feature has not been +successful mainly because of the complexity of the proposed solution. The +approach described in this document exposes a single simple interface to +user-space. This single tunable knob allows the tuning of system wide +scheduler behaviours ranging from energy efficiency at one end through to +incremental performance boosting at the other end. This first tunable affects +all tasks. However, a more advanced extension of the concept is also provided +which uses CGroups to boost the performance of only selected tasks while using +the energy efficient default for all others. + +The rest of this document introduces in more details the proposed solution +which has been named SchedTune. + + +2. Introduction +=============== + +SchedTune exposes a simple user-space interface with a single power-performance +tunable: + + /proc/sys/kernel/sched_cfs_boost + +This permits expressing a boost value as an integer in the range [0..100]. + +A value of 0 (default) configures the CFS scheduler for maximum energy +efficiency. This means that sched-DVFS runs the tasks at the minimum OPP +required to satisfy their workload demand. +A value of 100 configures scheduler for maximum performance, which translates +to the selection of the maximum OPP on that CPU. + +The range between 0 and 100 can be set to satisfy other scenarios suitably. For +example to satisfy interactive response or depending on other system events +(battery level etc). + +A CGroup based extension is also provided, which permits further user-space +defined task classification to tune the scheduler for different goals depending +on the specific nature of the task, e.g. background vs interactive vs +low-priority. + +The overall design of the SchedTune module is built on top of "Per-Entity Load +Tracking" (PELT) signals and sched-DVFS by introducing a bias on the Operating +Performance Point (OPP) selection. +Each time a task is allocated on a CPU, sched-DVFS has the opportunity to tune +the operating frequency of that CPU to better match the workload demand. The +selection of the actual OPP being activated is influenced by the global boost +value, or the boost value for the task CGroup when in use. + +This simple biasing approach leverages existing frameworks, which means minimal +modifications to the scheduler, and yet it allows to achieve a range of +different behaviours all from a single simple tunable knob. +The only new concept introduced is that of signal boosting. + + +3. Signal Boosting Strategy +=========================== + +The whole PELT machinery works based on the value of a few load tracking signals +which basically track the CPU bandwidth requirements for tasks and the capacity +of CPUs. The basic idea behind the SchedTune knob is to artificially inflate +some of these load tracking signals to make a task or RQ appears more demanding +that it actually is. + +Which signals have to be inflated depends on the specific "consumer". However, +independently from the specific (signal, consumer) pair, it is important to +define a simple and possibly consistent strategy for the concept of boosting a +signal. + +A boosting strategy defines how the "abstract" user-space defined +sched_cfs_boost value is translated into an internal "margin" value to be added +to a signal to get its inflated value: + + margin := boosting_strategy(sched_cfs_boost, signal) + boosted_signal := signal + margin + +Different boosting strategies were identified and analyzed before selecting the +one found to be most effective. + +Signal Proportional Compensation (SPC) +-------------------------------------- + +In this boosting strategy the sched_cfs_boost value is used to compute a +margin which is proportional to the complement of the original signal. +When a signal has a maximum possible value, its complement is defined as +the delta from the actual value and its possible maximum. + +Since the tunable implementation uses signals which have SCHED_LOAD_SCALE as +the maximum possible value, the margin becomes: + + margin := sched_cfs_boost * (SCHED_LOAD_SCALE - signal) + +Using this boosting strategy: +- a 100% sched_cfs_boost means that the signal is scaled to the maximum value +- each value in the range of sched_cfs_boost effectively inflates the signal in + question by a quantity which is proportional to the maximum value. + +For example, by applying the SPC boosting strategy to the selection of the OPP +to run a task it is possible to achieve these behaviors: + +- 0% boosting: run the task at the minimum OPP required by its workload +- 100% boosting: run the task at the maximum OPP available for the CPU +- 50% boosting: run at the half-way OPP between minimum and maximum + +Which means that, at 50% boosting, a task will be scheduled to run at half of +the maximum theoretically achievable performance on the specific target +platform. + +A graphical representation of an SPC boosted signal is represented in the +following figure where: + a) "-" represents the original signal + b) "b" represents a 50% boosted signal + c) "p" represents a 100% boosted signal + + + ^ + | SCHED_LOAD_SCALE + +-----------------------------------------------------------------+ + |pppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp + | + | boosted_signal + | bbbbbbbbbbbbbbbbbbbbbbbb + | + | original signal + | bbbbbbbbbbbbbbbbbbbbbbbb+----------------------+ + | | + |bbbbbbbbbbbbbbbbbb | + | | + | | + | | + | +-----------------------+ + | | + | | + | | + |------------------+ + | + | + +-----------------------------------------------------------------------> + +The plot above shows a ramped load signal (titled 'original_signal') and it's +boosted equivalent. For each step of the original signal the boosted signal +corresponding to a 50% boost is midway from the original signal and the upper +bound. Boosting by 100% generates a boosted signal which is always saturated to +the upper bound. + + +4. OPP selection using boosted CPU utilization +============================================== + +It is worth calling out that the implementation does not introduce any new load +signals. Instead, it provides an API to tune existing signals. This tuning is +done on demand and only in scheduler code paths where it is sensible to do so. +The new API calls are defined to return either the default signal or a boosted +one, depending on the value of sched_cfs_boost. This is a clean an non invasive +modification of the existing existing code paths. + +The signal representing a CPU's utilization is boosted according to the +previously described SPC boosting strategy. To sched-DVFS, this allows a CPU +(ie CFS run-queue) to appear more used then it actually is. + +Thus, with the sched_cfs_boost enabled we have the following main functions to +get the current utilization of a CPU: + + cpu_util() + boosted_cpu_util() + +The new boosted_cpu_util() is similar to the first but returns a boosted +utilization signal which is a function of the sched_cfs_boost value. + +This function is used in the CFS scheduler code paths where sched-DVFS needs to +decide the OPP to run a CPU at. +For example, this allows selecting the highest OPP for a CPU which has +the boost value set to 100%. + + +5. Per task group boosting +========================== + +The availability of a single knob which is used to boost all tasks in the +system is certainly a simple solution but it quite likely doesn't fit many +utilization scenarios, especially in the mobile device space. + +For example, on battery powered devices there usually are many background +services which are long running and need energy efficient scheduling. On the +other hand, some applications are more performance sensitive and require an +interactive response and/or maximum performance, regardless of the energy cost. +To better service such scenarios, the SchedTune implementation has an extension +that provides a more fine grained boosting interface. + +A new CGroup controller, namely "schedtune", could be enabled which allows to +defined and configure task groups with different boosting values. +Tasks that require special performance can be put into separate CGroups. +The value of the boost associated with the tasks in this group can be specified +using a single knob exposed by the CGroup controller: + + schedtune.boost + +This knob allows the definition of a boost value that is to be used for +SPC boosting of all tasks attached to this group. + +The current schedtune controller implementation is really simple and has these +main characteristics: + + 1) It is only possible to create 1 level depth hierarchies + + The root control groups define the system-wide boost value to be applied + by default to all tasks. Its direct subgroups are named "boost groups" and + they define the boost value for specific set of tasks. + Further nested subgroups are not allowed since they do not have a sensible + meaning from a user-space standpoint. + + 2) It is possible to define only a limited number of "boost groups" + + This number is defined at compile time and by default configured to 16. + This is a design decision motivated by two main reasons: + a) In a real system we do not expect utilization scenarios with more then few + boost groups. For example, a reasonable collection of groups could be + just "background", "interactive" and "performance". + b) It simplifies the implementation considerably, especially for the code + which has to compute the per CPU boosting once there are multiple + RUNNABLE tasks with different boost values. + +Such a simple design should allow servicing the main utilization scenarios identified +so far. It provides a simple interface which can be used to manage the +power-performance of all tasks or only selected tasks. +Moreover, this interface can be easily integrated by user-space run-times (e.g. +Android, ChromeOS) to implement a QoS solution for task boosting based on tasks +classification, which has been a long standing requirement. + +Setup and usage +--------------- + +0. Use a kernel with CGROUP_SCHEDTUNE support enabled + +1. Check that the "schedtune" CGroup controller is available: + + root@linaro-nano:~# cat /proc/cgroups + #subsys_name hierarchy num_cgroups enabled + cpuset 0 1 1 + cpu 0 1 1 + schedtune 0 1 1 + +2. Mount a tmpfs to create the CGroups mount point (Optional) + + root@linaro-nano:~# sudo mount -t tmpfs cgroups /sys/fs/cgroup + +3. Mount the "schedtune" controller + + root@linaro-nano:~# mkdir /sys/fs/cgroup/stune + root@linaro-nano:~# sudo mount -t cgroup -o schedtune stune /sys/fs/cgroup/stune + +4. Setup the system-wide boost value (Optional) + + If not configured the root control group has a 0% boost value, which + basically disables boosting for all tasks in the system thus running in + an energy-efficient mode. + + root@linaro-nano:~# echo $SYSBOOST > /sys/fs/cgroup/stune/schedtune.boost + +5. Create task groups and configure their specific boost value (Optional) + + For example here we create a "performance" boost group configure to boost + all its tasks to 100% + + root@linaro-nano:~# mkdir /sys/fs/cgroup/stune/performance + root@linaro-nano:~# echo 100 > /sys/fs/cgroup/stune/performance/schedtune.boost + +6. Move tasks into the boost group + + For example, the following moves the tasks with PID $TASKPID (and all its + threads) into the "performance" boost group. + + root@linaro-nano:~# echo "TASKPID > /sys/fs/cgroup/stune/performance/cgroup.procs + +This simple configuration allows only the threads of the $TASKPID task to run, +when needed, at the highest OPP in the most capable CPU of the system. + + +6. Question and Answers +======================= + +What about "auto" mode? +----------------------- + +The 'auto' mode as described in [5] can be implemented by interfacing SchedTune +with some suitable user-space element. This element could use the exposed +system-wide or cgroup based interface. + +How are multiple groups of tasks with different boost values managed? +--------------------------------------------------------------------- + +The current SchedTune implementation keeps track of the boosted RUNNABLE tasks +on a CPU. Once sched-DVFS selects the OPP to run a CPU at, the CPU utilization +is boosted with a value which is the maximum of the boost values of the +currently RUNNABLE tasks in its RQ. + +This allows sched-DVFS to boost a CPU only while there are boosted tasks ready +to run and switch back to the energy efficient mode as soon as the last boosted +task is dequeued. + + +7. References +============= +[1] http://lwn.net/Articles/552889 +[2] http://lkml.org/lkml/2012/5/18/91 +[3] http://lkml.org/lkml/2015/6/26/620 diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index 630c492c3dc2..2acb3faf509c 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -176,6 +176,11 @@ This is called when end of file is reached. The userspace can inform DSP that EOF is reached and now DSP can start skipping padding delay. Also next write data would belong to next track +- set_next_track_param +This routine is called to send to DSP codec specific data of subsequent track +in gapless before first write. + + Sequence flow for gapless would be: - Open - Get caps / codec caps @@ -187,6 +192,7 @@ Sequence flow for gapless would be: - Indicaite next track data by sending set_next_track - Set metadata of the next track - then call partial_drain to flush most of buffer in DSP +- set codec specific data of subsequent track - Fill data of the next track - DSP switches to second track (note: order for partial_drain and write for next track can be reversed as well) diff --git a/Documentation/sync.txt b/Documentation/sync.txt new file mode 100644 index 000000000000..a2d05e7fa193 --- /dev/null +++ b/Documentation/sync.txt @@ -0,0 +1,75 @@ +Motivation: + +In complicated DMA pipelines such as graphics (multimedia, camera, gpu, display) +a consumer of a buffer needs to know when the producer has finished producing +it. Likewise the producer needs to know when the consumer is finished with the +buffer so it can reuse it. A particular buffer may be consumed by multiple +consumers which will retain the buffer for different amounts of time. In +addition, a consumer may consume multiple buffers atomically. +The sync framework adds an API which allows synchronization between the +producers and consumers in a generic way while also allowing platforms which +have shared hardware synchronization primitives to exploit them. + +Goals: + * provide a generic API for expressing synchronization dependencies + * allow drivers to exploit hardware synchronization between hardware + blocks + * provide a userspace API that allows a compositor to manage + dependencies. + * provide rich telemetry data to allow debugging slowdowns and stalls of + the graphics pipeline. + +Objects: + * sync_timeline + * sync_pt + * sync_fence + +sync_timeline: + +A sync_timeline is an abstract monotonically increasing counter. In general, +each driver/hardware block context will have one of these. They can be backed +by the appropriate hardware or rely on the generic sw_sync implementation. +Timelines are only ever created through their specific implementations +(i.e. sw_sync.) + +sync_pt: + +A sync_pt is an abstract value which marks a point on a sync_timeline. Sync_pts +have a single timeline parent. They have 3 states: active, signaled, and error. +They start in active state and transition, once, to either signaled (when the +timeline counter advances beyond the sync_pt’s value) or error state. + +sync_fence: + +Sync_fences are the primary primitives used by drivers to coordinate +synchronization of their buffers. They are a collection of sync_pts which may +or may not have the same timeline parent. A sync_pt can only exist in one fence +and the fence's list of sync_pts is immutable once created. Fences can be +waited on synchronously or asynchronously. Two fences can also be merged to +create a third fence containing a copy of the two fences’ sync_pts. Fences are +backed by file descriptors to allow userspace to coordinate the display pipeline +dependencies. + +Use: + +A driver implementing sync support should have a work submission function which: + * takes a fence argument specifying when to begin work + * asynchronously queues that work to kick off when the fence is signaled + * returns a fence to indicate when its work will be done. + * signals the returned fence once the work is completed. + +Consider an imaginary display driver that has the following API: +/* + * assumes buf is ready to be displayed. + * blocks until the buffer is on screen. + */ + void display_buffer(struct dma_buf *buf); + +The new API will become: +/* + * will display buf when fence is signaled. + * returns immediately with a fence that will signal when buf + * is no longer displayed. + */ +struct sync_fence* display_buffer(struct dma_buf *buf, + struct sync_fence *fence); diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index af70d1541d3a..6475fa234065 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -23,8 +23,10 @@ show up in /proc/sys/kernel: - auto_msgmni - bootloader_type [ X86 only ] - bootloader_version [ X86 only ] +- boot_reason [ ARM and ARM64 only ] - callhome [ S390 only ] - cap_last_cap +- cold_boot [ ARM and ARM64 only ] - core_pattern - core_pipe_limit - core_uses_pid @@ -58,6 +60,8 @@ show up in /proc/sys/kernel: - panic_on_stackoverflow - panic_on_unrecovered_nmi - panic_on_warn +- perf_cpu_time_max_percent +- perf_event_paranoid - pid_max - powersave-nap [ PPC only ] - printk @@ -158,6 +162,19 @@ Documentation/x86/boot.txt for additional information. ============================================================== +boot_reason: + +ARM and ARM64 -- reason for device boot + +A single bit will be set in the unsigned integer value to identify the +reason the device was booted / powered on. The value will be zero if this +feature is not supported on the ARM device being booted. + +See the power-on-status field definitions in +Documentation/arm/msm/boot.txt for Qualcomm's family of devices. + +============================================================== + callhome: Controls the kernel's callhome behavior in case of a kernel panic. @@ -178,6 +195,16 @@ cap_last_cap Highest valid capability of the running kernel. Exports CAP_LAST_CAP from the kernel. +=============================================================== + +cold_boot + +ARM and ARM64 -- indicator for system cold boot + +A single bit will be set in the unsigned integer value to identify +whether the device was booted from a cold or warm state. Zero +indicating a warm boot and one indicating a cold boot. + ============================================================== core_pattern: @@ -574,19 +601,6 @@ This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled. ============================================================== -panic_on_unrecovered_nmi: - -The default Linux behaviour on an NMI of either memory or unknown is -to continue operation. For many environments such as scientific -computing it is preferable that the box is taken out and the error -dealt with than an uncorrected parity/ECC error get propagated. - -A small number of systems do generate NMI's for bizarre random reasons -such as power management so the default is off. That sysctl works like -the existing panic controls already in that directory. - -============================================================== - panic_on_warn: Calls panic() in the WARN() path when set to 1. This is useful to avoid @@ -624,6 +638,32 @@ allowed to execute. ============================================================== +panic_on_unrecovered_nmi: + +The default Linux behaviour on an NMI of either memory or unknown is +to continue operation. For many environments such as scientific +computing it is preferable that the box is taken out and the error +dealt with than an uncorrected parity/ECC error get propagated. + +A small number of systems do generate NMI's for bizarre random reasons +such as power management so the default is off. That sysctl works like +the existing panic controls already in that directory. + +============================================================== + +perf_event_paranoid: + +Controls use of the performance events system by unprivileged +users (without CAP_SYS_ADMIN). The default value is 3 if +CONFIG_SECURITY_PERF_EVENTS_RESTRICT is set, or 1 otherwise. + + -1: Allow use of (almost) all events by all users +>=0: Disallow raw tracepoint access by users without CAP_IOC_LOCK +>=1: Disallow CPU event access by users without CAP_SYS_ADMIN +>=2: Disallow kernel profiling by users without CAP_SYS_ADMIN +>=3: Disallow all event access by users without CAP_SYS_ADMIN + +============================================================== pid_max: @@ -810,14 +850,13 @@ via the /proc/sys interface: Each write syscall must fully contain the sysctl value to be written, and multiple writes on the same sysctl file descriptor will rewrite the sysctl value, regardless of file position. - 0 - (default) Same behavior as above, but warn about processes that - perform writes to a sysctl file descriptor when the file position - is not 0. - 1 - Respect file position when writing sysctl strings. Multiple writes - will append to the sysctl value buffer. Anything past the max length - of the sysctl value buffer will be ignored. Writes to numeric sysctl - entries must always be at file position 0 and the value must be - fully contained in the buffer sent in the write syscall. + 0 - Same behavior as above, but warn about processes that perform writes + to a sysctl file descriptor when the file position is not 0. + 1 - (default) Respect file position when writing sysctl strings. Multiple + writes will append to the sysctl value buffer. Anything past the max + length of the sysctl value buffer will be ignored. Writes to numeric + sysctl entries must always be at file position 0 and the value must + be fully contained in the buffer sent in the write syscall. ============================================================== diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index f72370b440b1..c0397afe6a1d 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -30,6 +30,7 @@ Currently, these files are in /proc/sys/vm: - dirty_writeback_centisecs - drop_caches - extfrag_threshold +- extra_free_kbytes - hugepages_treat_as_movable - hugetlb_shm_group - laptop_mode @@ -42,6 +43,8 @@ Currently, these files are in /proc/sys/vm: - min_slab_ratio - min_unmapped_ratio - mmap_min_addr +- mmap_rnd_bits +- mmap_rnd_compat_bits - nr_hugepages - nr_overcommit_hugepages - nr_trim_pages (only if CONFIG_MMU=n) @@ -236,6 +239,21 @@ fragmentation index is <= extfrag_threshold. The default value is 500. ============================================================== +extra_free_kbytes + +This parameter tells the VM to keep extra free memory between the threshold +where background reclaim (kswapd) kicks in, and the threshold where direct +reclaim (by allocating processes) kicks in. + +This is useful for workloads that require low latency memory allocations +and have a bounded burstiness in memory allocations, for example a +realtime application that receives and transmits network traffic +(causing in-kernel memory allocations) with a maximum total message burst +size of 200MB may need 200MB of extra free memory to avoid direct reclaim +related latencies. + +============================================================== + hugepages_treat_as_movable This parameter controls whether we can allocate hugepages from ZONE_MOVABLE @@ -485,6 +503,33 @@ against future potential kernel bugs. ============================================================== +mmap_rnd_bits: + +This value can be used to select the number of bits to use to +determine the random offset to the base address of vma regions +resulting from mmap allocations on architectures which support +tuning address space randomization. This value will be bounded +by the architecture's minimum and maximum supported values. + +This value can be changed after boot using the +/proc/sys/vm/mmap_rnd_bits tunable + +============================================================== + +mmap_rnd_compat_bits: + +This value can be used to select the number of bits to use to +determine the random offset to the base address of vma regions +resulting from mmap allocations for applications run in +compatibility mode on architectures which support tuning address +space randomization. This value will be bounded by the +architecture's minimum and maximum supported values. + +This value can be changed after boot using the +/proc/sys/vm/mmap_rnd_compat_bits tunable + +============================================================== + nr_hugepages Change the minimum size of the hugepage pool. diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt index 21d514ced212..4d817d5acc40 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.txt @@ -25,6 +25,7 @@ cpufreq. cpu_idle "state=%lu cpu_id=%lu" cpu_frequency "state=%lu cpu_id=%lu" +cpu_frequency_limits "min=%lu max=%lu cpu_id=%lu" A suspend event is used to indicate the system going in and out of the suspend mode: diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index f52f297cb406..fa16fb2302a5 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -357,6 +357,26 @@ of ftrace. Here is a list of some of the key files: to correlate events across hypervisor/guest if tb_offset is known. + mono: This uses the fast monotonic clock (CLOCK_MONOTONIC) + which is monotonic and is subject to NTP rate adjustments. + + mono_raw: + This is the raw monotonic clock (CLOCK_MONOTONIC_RAW) + which is montonic but is not subject to any rate adjustments + and ticks at the same rate as the hardware clocksource. + + boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the + fast monotonic clock, but also accounts for time spent in + suspend. Since the clock access is designed for use in + tracing in the suspend path, some side effects are possible + if clock is accessed after the suspend time is accounted before + the fast mono clock is updated. In this case, the clock update + appears to happen slightly sooner than it normally would have. + Also on 32-bit systems, its possible that the 64-bit boot offset + sees a partial update. These effects are rare and post + processing should be able to handle them. See comments on + ktime_get_boot_fast_ns function for more information. + To set a clock, simply echo the clock name into this file. echo global > trace_clock @@ -2088,6 +2108,35 @@ will produce: 1) 1.449 us | } +You can disable the hierarchical function call formatting and instead print a +flat list of function entry and return events. This uses the format described +in the Output Formatting section and respects all the trace options that +control that formatting. Hierarchical formatting is the default. + + hierachical: echo nofuncgraph-flat > trace_options + flat: echo funcgraph-flat > trace_options + + ie: + + # tracer: function_graph + # + # entries-in-buffer/entries-written: 68355/68355 #P:2 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + sh-1806 [001] d... 198.843443: graph_ent: func=_raw_spin_lock + sh-1806 [001] d... 198.843445: graph_ent: func=__raw_spin_lock + sh-1806 [001] d..1 198.843447: graph_ret: func=__raw_spin_lock + sh-1806 [001] d..1 198.843449: graph_ret: func=_raw_spin_lock + sh-1806 [001] d..1 198.843451: graph_ent: func=_raw_spin_unlock_irqrestore + sh-1806 [001] d... 198.843453: graph_ret: func=_raw_spin_unlock_irqrestore + + You might find other useful features for this tracer in the following "dynamic ftrace" section such as tracing only specific functions or tasks. diff --git a/Documentation/ubsan.txt b/Documentation/ubsan.txt new file mode 100644 index 000000000000..f58215ef5797 --- /dev/null +++ b/Documentation/ubsan.txt @@ -0,0 +1,84 @@ +Undefined Behavior Sanitizer - UBSAN + +Overview +-------- + +UBSAN is a runtime undefined behaviour checker. + +UBSAN uses compile-time instrumentation to catch undefined behavior (UB). +Compiler inserts code that perform certain kinds of checks before operations +that may cause UB. If check fails (i.e. UB detected) __ubsan_handle_* +function called to print error message. + +GCC has that feature since 4.9.x [1] (see -fsanitize=undefined option and +its suboptions). GCC 5.x has more checkers implemented [2]. + +Report example +--------------- + + ================================================================================ + UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33 + shift exponent 32 is to large for 32-bit type 'unsigned int' + CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc1+ #26 + 0000000000000000 ffffffff82403cc8 ffffffff815e6cd6 0000000000000001 + ffffffff82403cf8 ffffffff82403ce0 ffffffff8163a5ed 0000000000000020 + ffffffff82403d78 ffffffff8163ac2b ffffffff815f0001 0000000000000002 + Call Trace: + [<ffffffff815e6cd6>] dump_stack+0x45/0x5f + [<ffffffff8163a5ed>] ubsan_epilogue+0xd/0x40 + [<ffffffff8163ac2b>] __ubsan_handle_shift_out_of_bounds+0xeb/0x130 + [<ffffffff815f0001>] ? radix_tree_gang_lookup_slot+0x51/0x150 + [<ffffffff8173c586>] _mix_pool_bytes+0x1e6/0x480 + [<ffffffff83105653>] ? dmi_walk_early+0x48/0x5c + [<ffffffff8173c881>] add_device_randomness+0x61/0x130 + [<ffffffff83105b35>] ? dmi_save_one_device+0xaa/0xaa + [<ffffffff83105653>] dmi_walk_early+0x48/0x5c + [<ffffffff831066ae>] dmi_scan_machine+0x278/0x4b4 + [<ffffffff8111d58a>] ? vprintk_default+0x1a/0x20 + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830b2240>] setup_arch+0x405/0xc2c + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830ae053>] start_kernel+0x83/0x49a + [<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120 + [<ffffffff830ad386>] x86_64_start_reservations+0x2a/0x2c + [<ffffffff830ad4f3>] x86_64_start_kernel+0x16b/0x17a + ================================================================================ + +Usage +----- + +To enable UBSAN configure kernel with: + + CONFIG_UBSAN=y + +and to check the entire kernel: + + CONFIG_UBSAN_SANITIZE_ALL=y + +To enable instrumentation for specific files or directories, add a line +similar to the following to the respective kernel Makefile: + + For a single file (e.g. main.o): + UBSAN_SANITIZE_main.o := y + + For all files in one directory: + UBSAN_SANITIZE := y + +To exclude files from being instrumented even if +CONFIG_UBSAN_SANITIZE_ALL=y, use: + + UBSAN_SANITIZE_main.o := n + and: + UBSAN_SANITIZE := n + +Detection of unaligned accesses controlled through the separate option - +CONFIG_UBSAN_ALIGNMENT. It's off by default on architectures that support +unaligned accesses (CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y). One could +still enable it in config, just note that it will produce a lot of UBSAN +reports. + +References +---------- + +[1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html +[2] - https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt index f34a8ee6f860..f40b965d7667 100644 --- a/Documentation/vm/ksm.txt +++ b/Documentation/vm/ksm.txt @@ -87,6 +87,13 @@ pages_sharing - how many more sites are sharing them i.e. how much saved pages_unshared - how many pages unique but repeatedly checked for merging pages_volatile - how many pages changing too fast to be placed in a tree full_scans - how many times all mergeable areas have been scanned +deferred_timer - whether to use deferred timers or not + e.g. "echo 1 > /sys/kernel/mm/ksm/deferred_timer" + Default: 0 (means, we are not using deferred timers. Users + might want to set deferred_timer option if they donot want + ksm thread to wakeup CPU to carryout ksm activities thus + gaining on battery while compromising slightly on memory + that could have been saved.) A high ratio of pages_sharing to pages_shared indicates good sharing, but a high ratio of pages_unshared to pages_sharing indicates wasted effort. diff --git a/Documentation/vm/page_migration b/Documentation/vm/page_migration index fea5c0864170..94bd9c11c4e0 100644 --- a/Documentation/vm/page_migration +++ b/Documentation/vm/page_migration @@ -142,5 +142,111 @@ Steps: 20. The new page is moved to the LRU and can be scanned by the swapper etc again. -Christoph Lameter, May 8, 2006. +C. Non-LRU page migration +------------------------- + +Although original migration aimed for reducing the latency of memory access +for NUMA, compaction who want to create high-order page is also main customer. + +Current problem of the implementation is that it is designed to migrate only +*LRU* pages. However, there are potential non-lru pages which can be migrated +in drivers, for example, zsmalloc, virtio-balloon pages. + +For virtio-balloon pages, some parts of migration code path have been hooked +up and added virtio-balloon specific functions to intercept migration logics. +It's too specific to a driver so other drivers who want to make their pages +movable would have to add own specific hooks in migration path. + +To overclome the problem, VM supports non-LRU page migration which provides +generic functions for non-LRU movable pages without driver specific hooks +migration path. + +If a driver want to make own pages movable, it should define three functions +which are function pointers of struct address_space_operations. + +1. bool (*isolate_page) (struct page *page, isolate_mode_t mode); + +What VM expects on isolate_page function of driver is to return *true* +if driver isolates page successfully. On returing true, VM marks the page +as PG_isolated so concurrent isolation in several CPUs skip the page +for isolation. If a driver cannot isolate the page, it should return *false*. + +Once page is successfully isolated, VM uses page.lru fields so driver +shouldn't expect to preserve values in that fields. + +2. int (*migratepage) (struct address_space *mapping, + struct page *newpage, struct page *oldpage, enum migrate_mode); + +After isolation, VM calls migratepage of driver with isolated page. +The function of migratepage is to move content of the old page to new page +and set up fields of struct page newpage. Keep in mind that you should +indicate to the VM the oldpage is no longer movable via __ClearPageMovable() +under page_lock if you migrated the oldpage successfully and returns +MIGRATEPAGE_SUCCESS. If driver cannot migrate the page at the moment, driver +can return -EAGAIN. On -EAGAIN, VM will retry page migration in a short time +because VM interprets -EAGAIN as "temporal migration failure". On returning +any error except -EAGAIN, VM will give up the page migration without retrying +in this time. + +Driver shouldn't touch page.lru field VM using in the functions. + +3. void (*putback_page)(struct page *); + +If migration fails on isolated page, VM should return the isolated page +to the driver so VM calls driver's putback_page with migration failed page. +In this function, driver should put the isolated page back to the own data +structure. +4. non-lru movable page flags + +There are two page flags for supporting non-lru movable page. + +* PG_movable + +Driver should use the below function to make page movable under page_lock. + + void __SetPageMovable(struct page *page, struct address_space *mapping) + +It needs argument of address_space for registering migration family functions +which will be called by VM. Exactly speaking, PG_movable is not a real flag of +struct page. Rather than, VM reuses page->mapping's lower bits to represent it. + + #define PAGE_MAPPING_MOVABLE 0x2 + page->mapping = page->mapping | PAGE_MAPPING_MOVABLE; + +so driver shouldn't access page->mapping directly. Instead, driver should +use page_mapping which mask off the low two bits of page->mapping under +page lock so it can get right struct address_space. + +For testing of non-lru movable page, VM supports __PageMovable function. +However, it doesn't guarantee to identify non-lru movable page because +page->mapping field is unified with other variables in struct page. +As well, if driver releases the page after isolation by VM, page->mapping +doesn't have stable value although it has PAGE_MAPPING_MOVABLE +(Look at __ClearPageMovable). But __PageMovable is cheap to catch whether +page is LRU or non-lru movable once the page has been isolated. Because +LRU pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also +good for just peeking to test non-lru movable pages before more expensive +checking with lock_page in pfn scanning to select victim. + +For guaranteeing non-lru movable page, VM provides PageMovable function. +Unlike __PageMovable, PageMovable functions validates page->mapping and +mapping->a_ops->isolate_page under lock_page. The lock_page prevents sudden +destroying of page->mapping. + +Driver using __SetPageMovable should clear the flag via __ClearMovablePage +under page_lock before the releasing the page. + +* PG_isolated + +To prevent concurrent isolation among several CPUs, VM marks isolated page +as PG_isolated under lock_page. So if a CPU encounters PG_isolated non-lru +movable page, it can skip it. Driver doesn't need to manipulate the flag +because VM will set/clear it automatically. Keep in mind that if driver +sees PG_isolated page, it means the page have been isolated by VM so it +shouldn't touch page.lru field. +PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag +for own purpose. + +Christoph Lameter, May 8, 2006. +Minchan Kim, Mar 28, 2016. diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index 699d8ea5c230..802dbe5027ff 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -252,6 +252,10 @@ After reporting the details of the issue encountered the FIX SLUB message tells us that SLUB has restored the Redzone to its proper value and then system operations continue. +If it is required to only report the details of the issue and panic immediately +after in order to possibly catch any scribblers one can set the +CONFIG_DEBUG_SLUB_PANIC_ON option. + Emergency operations: --------------------- |