diff options
Diffstat (limited to 'Documentation')
322 files changed, 11211 insertions, 3066 deletions
diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index b5bebf642db6..1af9c4175213 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -1,47 +1,47 @@ -What: sys/bus/dsa/devices/dsa<m>/version +What: /sys/bus/dsa/devices/dsa<m>/version Date: Apr 15, 2020 KernelVersion: 5.8.0 Contact: dmaengine@vger.kernel.org Description: The hardware version number. -What: sys/bus/dsa/devices/dsa<m>/cdev_major +What: /sys/bus/dsa/devices/dsa<m>/cdev_major Date: Oct 25, 2019 -KernelVersion: 5.6.0 +KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The major number that the character device driver assigned to this device. -What: sys/bus/dsa/devices/dsa<m>/errors +What: /sys/bus/dsa/devices/dsa<m>/errors Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The error information for this device. -What: sys/bus/dsa/devices/dsa<m>/max_batch_size +What: /sys/bus/dsa/devices/dsa<m>/max_batch_size Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The largest number of work descriptors in a batch. -What: sys/bus/dsa/devices/dsa<m>/max_work_queues_size +What: /sys/bus/dsa/devices/dsa<m>/max_work_queues_size Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The maximum work queue size supported by this device. -What: sys/bus/dsa/devices/dsa<m>/max_engines +What: /sys/bus/dsa/devices/dsa<m>/max_engines Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The maximum number of engines supported by this device. -What: sys/bus/dsa/devices/dsa<m>/max_groups +What: /sys/bus/dsa/devices/dsa<m>/max_groups Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The maximum number of groups can be created under this device. -What: sys/bus/dsa/devices/dsa<m>/max_tokens +What: /sys/bus/dsa/devices/dsa<m>/max_tokens Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org @@ -50,7 +50,7 @@ Description: The total number of bandwidth tokens supported by this device. implementation, and these resources are allocated by engines to support operations. -What: sys/bus/dsa/devices/dsa<m>/max_transfer_size +What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org @@ -58,57 +58,57 @@ Description: The number of bytes to be read from the source address to perform the operation. The maximum transfer size is dependent on the workqueue the descriptor was submitted to. -What: sys/bus/dsa/devices/dsa<m>/max_work_queues +What: /sys/bus/dsa/devices/dsa<m>/max_work_queues Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The maximum work queue number that this device supports. -What: sys/bus/dsa/devices/dsa<m>/numa_node +What: /sys/bus/dsa/devices/dsa<m>/numa_node Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The numa node number for this device. -What: sys/bus/dsa/devices/dsa<m>/op_cap +What: /sys/bus/dsa/devices/dsa<m>/op_cap Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The operation capability bit mask specify the operation types supported by the this device. -What: sys/bus/dsa/devices/dsa<m>/state +What: /sys/bus/dsa/devices/dsa<m>/state Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The state information of this device. It can be either enabled or disabled. -What: sys/bus/dsa/devices/dsa<m>/group<m>.<n> +What: /sys/bus/dsa/devices/dsa<m>/group<m>.<n> Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The assigned group under this device. -What: sys/bus/dsa/devices/dsa<m>/engine<m>.<n> +What: /sys/bus/dsa/devices/dsa<m>/engine<m>.<n> Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The assigned engine under this device. -What: sys/bus/dsa/devices/dsa<m>/wq<m>.<n> +What: /sys/bus/dsa/devices/dsa<m>/wq<m>.<n> Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The assigned work queue under this device. -What: sys/bus/dsa/devices/dsa<m>/configurable +What: /sys/bus/dsa/devices/dsa<m>/configurable Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: To indicate if this device is configurable or not. -What: sys/bus/dsa/devices/dsa<m>/token_limit +What: /sys/bus/dsa/devices/dsa<m>/token_limit Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org @@ -116,19 +116,19 @@ Description: The maximum number of bandwidth tokens that may be in use at one time by operations that access low bandwidth memory in the device. -What: sys/bus/dsa/devices/wq<m>.<n>/group_id +What: /sys/bus/dsa/devices/wq<m>.<n>/group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The group id that this work queue belongs to. -What: sys/bus/dsa/devices/wq<m>.<n>/size +What: /sys/bus/dsa/devices/wq<m>.<n>/size Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The work queue size for this work queue. -What: sys/bus/dsa/devices/wq<m>.<n>/type +What: /sys/bus/dsa/devices/wq<m>.<n>/type Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org @@ -136,20 +136,20 @@ Description: The type of this work queue, it can be "kernel" type for work queue usages in the kernel space or "user" type for work queue usages by applications in user space. -What: sys/bus/dsa/devices/wq<m>.<n>/cdev_minor +What: /sys/bus/dsa/devices/wq<m>.<n>/cdev_minor Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The minor number assigned to this work queue by the character device driver. -What: sys/bus/dsa/devices/wq<m>.<n>/mode +What: /sys/bus/dsa/devices/wq<m>.<n>/mode Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The work queue mode type for this work queue. -What: sys/bus/dsa/devices/wq<m>.<n>/priority +What: /sys/bus/dsa/devices/wq<m>.<n>/priority Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org @@ -157,20 +157,20 @@ Description: The priority value of this work queue, it is a vlue relative to other work queue in the same group to control quality of service for dispatching work from multiple workqueues in the same group. -What: sys/bus/dsa/devices/wq<m>.<n>/state +What: /sys/bus/dsa/devices/wq<m>.<n>/state Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The current state of the work queue. -What: sys/bus/dsa/devices/wq<m>.<n>/threshold +What: /sys/bus/dsa/devices/wq<m>.<n>/threshold Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org Description: The number of entries in this work queue that may be filled via a limited portal. -What: sys/bus/dsa/devices/engine<m>.<n>/group_id +What: /sys/bus/dsa/devices/engine<m>.<n>/group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 Contact: dmaengine@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-driver-speakup b/Documentation/ABI/stable/sysfs-driver-speakup new file mode 100644 index 000000000000..c6a32c434ce9 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-speakup @@ -0,0 +1,375 @@ +What: /sys/accessibility/speakup/attrib_bleep +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Beeps the PC speaker when there is an attribute change such as + foreground or background color when using speakup review + commands. One = on, zero = off. + +What: /sys/accessibility/speakup/bell_pos +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This works much like a typewriter bell. If for example 72 is + echoed to bell_pos, it will beep the PC speaker when typing on + a line past character 72. + +What: /sys/accessibility/speakup/bleeps +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This controls whether one hears beeps through the PC speaker + when using speakup's review commands. + TODO: what values does it accept? + +What: /sys/accessibility/speakup/bleep_time +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This controls the duration of the PC speaker beeps speakup + produces. + TODO: What are the units? Jiffies? + +What: /sys/accessibility/speakup/cursor_time +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This controls cursor delay when using arrow keys. When a + connection is very slow, with the default setting, when moving + with the arrows, or backspacing etc. speakup says the incorrect + characters. Set this to a higher value to adjust for the delay + and better synchronisation between cursor position and speech. + +What: /sys/accessibility/speakup/delimiters +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Delimit a word from speakup. + TODO: add more info + +What: /sys/accessibility/speakup/ex_num +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/key_echo +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Controls if speakup speaks keys when they are typed. One = on, + zero = off or don't echo keys. + +What: /sys/accessibility/speakup/keymap +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Speakup keymap remaps keys to Speakup functions. + It uses a binary + format. A special program called genmap is needed to compile a + textual keymap into the binary format which is then loaded into + /sys/accessibility/speakup/keymap. + +What: /sys/accessibility/speakup/no_interrupt +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Controls if typing interrupts output from speakup. With + no_interrupt set to zero, typing on the keyboard will interrupt + speakup if for example + the say screen command is used before the + entire screen is read. + With no_interrupt set to one, if the say + screen command is used, and one then types on the keyboard, + speakup will continue to say the whole screen regardless until + it finishes. + +What: /sys/accessibility/speakup/punc_all +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This is a list of all the punctuation speakup should speak when + punc_level is set to four. + +What: /sys/accessibility/speakup/punc_level +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Controls the level of punctuation spoken as the screen is + displayed, not reviewed. Levels range from zero no punctuation, + to four, all punctuation. One corresponds to punc_some, two + corresponds to punc_most, and three as well as four both + correspond to punc_all. Some hardware synthesizers may have + different levels each corresponding to three and four for + punc_level. Also note that if punc_level is set to zero, and + key_echo is set to one, typed punctuation is still spoken as it + is typed. + +What: /sys/accessibility/speakup/punc_most +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This is a list of all the punctuation speakup should speak when + punc_level is set to two. + +What: /sys/accessibility/speakup/punc_some +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This is a list of all the punctuation speakup should speak when + punc_level is set to one. + +What: /sys/accessibility/speakup/reading_punc +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Almost the same as punc_level, the differences being that + reading_punc controls the level of punctuation when reviewing + the screen with speakup's screen review commands. The other + difference is that reading_punc set to three speaks punc_all, + and reading_punc set to four speaks all punctuation, including + spaces. + +What: /sys/accessibility/speakup/repeats +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: A list of characters speakup repeats. Normally, when there are + more than three characters in a row, speakup + just reads three of + those characters. For example, "......" would be read as dot, + dot, dot. If a . is added to the list of characters in repeats, + "......" would be read as dot, dot, dot, times six. + +What: /sys/accessibility/speakup/say_control +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: If set to one, speakup speaks shift, alt and control when those + keys are pressed. If say_control is set to zero, shift, ctrl, + and alt are not spoken when they are pressed. + +What: /sys/accessibility/speakup/say_word_ctl +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/silent +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/spell_delay +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This controls how fast a word is spelled + when speakup's say word + review command is pressed twice quickly to speak the current + word being reviewed. Zero just speaks the letters one after + another, while values one through four + seem to introduce more of + a pause between the spelling of each letter by speakup. + +What: /sys/accessibility/speakup/synth +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the synthesizer driver currently in use. Reading + synth returns the synthesizer driver currently in use. Writing + synth switches to the given synthesizer driver, provided it is + either built into the kernel, or already loaded as a module. + +What: /sys/accessibility/speakup/synth_direct +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Sends whatever is written to synth_direct + directly to the speech synthesizer in use, bypassing speakup. + This could be used to make the synthesizer speak + a string, or to + send control sequences to the synthesizer to change how the + synthesizer behaves. + +What: /sys/accessibility/speakup/version +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Reading version returns the version of speakup, and the version + of the synthesizer driver currently in use. + +What: /sys/accessibility/speakup/i18n/announcements +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This file contains various general announcements, most of which + cannot be categorized. You will find messages such as "You + killed Speakup", "I'm alive", "leaving help", "parked", + "unparked", and others. You will also find the names of the + screen edges and cursor tracking modes here. + +What: /sys/accessibility/speakup/i18n/chartab +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO + +What: /sys/accessibility/speakup/i18n/ctl_keys +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Here, you will find names of control keys. These are used with + Speakup's say_control feature. + +What: /sys/accessibility/speakup/i18n/function_names +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Here, you will find a list of names for Speakup functions. + These are used by the help system. For example, suppose that + you have activated help mode, and you pressed + keypad 3. Speakup + says: "keypad 3 is character, say next." + The message "character, say next" names a Speakup function, and + it comes from this function_names file. + +What: /sys/accessibility/speakup/i18n/states +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This file contains names for key states. + Again, these are part of the help system. For instance, if you + had pressed speakup + keypad 3, you would hear: + "speakup keypad 3 is go to bottom edge." + The speakup key is depressed, so the name of the key state is + speakup. + This part of the message comes from the states collection. + +What: /sys/accessibility/speakup/i18n/characters +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Through this sys entry, Speakup gives you the ability to change + how Speakup pronounces a given character. You could, for + example, change how some punctuation characters are spoken. You + can even change how Speakup will pronounce certain letters. For + further details see '12. Changing the Pronunciation of + Characters' in Speakup User's Guide (file spkguide.txt in + source). + +What: /sys/accessibility/speakup/i18n/colors +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: When you use the "say attributes" function, Speakup says the + name of the foreground and background colors. These names come + from the i18n/colors file. + +What: /sys/accessibility/speakup/i18n/formatted +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This group of messages contains embedded formatting codes, to + specify the type and width of displayed data. If you change + these, you must preserve all of the formatting codes, and they + must appear in the order used by the default messages. + +What: /sys/accessibility/speakup/i18n/key_names +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Again, key_names is used by Speakup's help system. In the + previous example, Speakup said that you pressed "keypad 3." + This name came from the key_names file. + +What: /sys/accessibility/speakup/<synth-name>/ +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: In `/sys/accessibility/speakup` is a directory corresponding to + the synthesizer driver currently in use (E.G) `soft` for the + soft driver. This directory contains files which control the + speech synthesizer itself, + as opposed to controlling the speakup + screen reader. The parameters in this directory have the same + names and functions across all + supported synthesizers. The range + of values for freq, pitch, rate, and vol is the same for all + supported synthesizers, with the given range being internally + mapped by the driver to more or less fit the range of values + supported for a given parameter by the individual synthesizer. + Below is a description of values and parameters for soft + synthesizer, which is currently the most commonly used. + +What: /sys/accessibility/speakup/soft/caps_start +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This is the string that is sent to the synthesizer to cause it + to start speaking uppercase letters. For the soft synthesizer + and most others, this causes the pitch of the voice to rise + above the currently set pitch. + +What: /sys/accessibility/speakup/soft/caps_stop +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This is the string sent to the synthesizer to cause it to stop + speaking uppercase letters. In the case of the soft synthesizer + and most others, this returns the pitch of the voice + down to the + currently set pitch. + +What: /sys/accessibility/speakup/soft/delay_time +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/soft/direct +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Controls if punctuation is spoken by speakup, or by the + synthesizer. + For example, speakup speaks ">" as "greater", while + the espeak synthesizer used by the soft driver speaks "greater + than". Zero lets speakup speak the punctuation. One lets the + synthesizer itself speak punctuation. + +What: /sys/accessibility/speakup/soft/freq +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the frequency of the speech synthesizer. Range is + 0-9. + +What: /sys/accessibility/speakup/soft/full_time +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/soft/jiffy_delta +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: This controls how many jiffys the kernel gives to the + synthesizer. Setting this too high can make a system unstable, + or even crash it. + +What: /sys/accessibility/speakup/soft/pitch +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the pitch of the synthesizer. The range is 0-9. + +What: /sys/accessibility/speakup/soft/inflection +KernelVersion: 5.8 +Contact: speakup@linux-speakup.org +Description: Gets or sets the inflection of the synthesizer, i.e. the pitch + range. The range is 0-9. + +What: /sys/accessibility/speakup/soft/punct +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the amount of punctuation spoken by the + synthesizer. The range for the soft driver seems to be 0-2. + TODO: How is this related to speakup's punc_level, or + reading_punc. + +What: /sys/accessibility/speakup/soft/rate +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the rate of the synthesizer. Range is from zero + slowest, to nine fastest. + +What: /sys/accessibility/speakup/soft/tone +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the tone of the speech synthesizer. The range for + the soft driver seems to be 0-2. This seems to make no + difference if using espeak and the espeakup connector. + TODO: does espeakup support different tonalities? + +What: /sys/accessibility/speakup/soft/trigger_time +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: TODO: + +What: /sys/accessibility/speakup/soft/voice +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the voice used by the synthesizer if the + synthesizer can speak in more than one voice. The range for the + soft driver is 0-7. Note that while espeak supports multiple + voices, this parameter will not set the voice when the espeakup + connector is used between speakup and espeak. + +What: /sys/accessibility/speakup/soft/vol +KernelVersion: 2.6 +Contact: speakup@linux-speakup.org +Description: Gets or sets the volume of the speech synthesizer. Range is 0-9, + with zero being the softest, and nine being the loudest. + diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 index e8698afcd952..f7e32f218f73 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 @@ -43,6 +43,13 @@ Description: read only This sysfs interface exposes the number of cores per chip present in the system. +What: /sys/devices/hv_24x7/interface/cpumask +Date: July 2020 +Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> +Description: read only + This sysfs file exposes the cpumask which is designated to make + HCALLs to retrieve hv-24x7 pmu event counter data. + What: /sys/bus/event_source/devices/hv_24x7/event_descs/<event-name> Date: February 2014 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index d3e53a6d8331..5c62bfb0f3f5 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1569,7 +1569,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw KernelVersion: 4.3 Contact: linux-iio@vger.kernel.org Description: - Raw (unscaled no offset etc.) percentage reading of a substance. + Raw (unscaled no offset etc.) reading of a substance. Units + after application of scale and offset are percents. What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw diff --git a/Documentation/ABI/testing/sysfs-bus-iio-icm42600 b/Documentation/ABI/testing/sysfs-bus-iio-icm42600 new file mode 100644 index 000000000000..0bf1fd4f5bf1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-icm42600 @@ -0,0 +1,20 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Hardware applied calibration offset (assumed to fix production + inaccuracies). Values represent a real physical offset expressed + in SI units (m/s^2 for accelerometer and rad/s for gyroscope). + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Range of available values for hardware offset. Values in SI + units (m/s^2 for accelerometer and rad/s for gyroscope). diff --git a/Documentation/ABI/testing/sysfs-bus-iio-scd30 b/Documentation/ABI/testing/sysfs-bus-iio-scd30 new file mode 100644 index 000000000000..b9712f390bec --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-scd30 @@ -0,0 +1,34 @@ +What: /sys/bus/iio/devices/iio:deviceX/calibration_auto_enable +Date: June 2020 +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Contaminants build-up in the measurement chamber or optical + elements deterioration leads to sensor drift. + + One can compensate for sensor drift by using automatic self + calibration procedure (asc). + + Writing 1 or 0 to this attribute will respectively activate or + deactivate asc. + + Upon reading current asc status is returned. + +What: /sys/bus/iio/devices/iio:deviceX/calibration_forced_value +Date: June 2020 +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Contaminants build-up in the measurement chamber or optical + elements deterioration leads to sensor drift. + + One can compensate for sensor drift by using forced + recalibration (frc). This is useful in case there's known + co2 reference available nearby the sensor. + + Picking value from the range [400 1 2000] and writing it to the + sensor will set frc. + + Upon reading current frc value is returned. Note that after + power cycling default value (i.e 400) is returned even though + internally sensor had recalibrated itself. diff --git a/Documentation/ABI/testing/sysfs-bus-nfit b/Documentation/ABI/testing/sysfs-bus-nfit index a1cb44dcb908..e4f76e7eab93 100644 --- a/Documentation/ABI/testing/sysfs-bus-nfit +++ b/Documentation/ABI/testing/sysfs-bus-nfit @@ -202,6 +202,25 @@ Description: functions. See the section named 'NVDIMM Root Device _DSMs' in the ACPI specification. +What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle +Date: Apr, 2020 +KernelVersion: v5.8 +Contact: linux-nvdimm@lists.01.org +Description: + (RW) The Intel platform implementation of firmware activate + support exposes an option let the platform force idle devices in + the system over the activation event, or trust that the OS will + do it. The safe default is to let the platform force idle + devices since the kernel is already in a suspend state, and on + the chance that a driver does not properly quiesce bus-mastering + after a suspend callback the platform will handle it. However, + the activation might abort if, for example, platform firmware + determines that the activation time exceeds the max PCI-E + completion timeout. Since the platform does not know whether the + OS is running the activation from a suspend context it aborts, + but if the system owner trusts driver suspend callback to be + sufficient then 'firmware_activation_noidle' can be + enabled to bypass the activation abort. What: /sys/bus/nd/devices/regionX/nfit/range_index Date: Jun, 2015 diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm new file mode 100644 index 000000000000..d64380262be8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -0,0 +1,2 @@ +The libnvdimm sub-system implements a common sysfs interface for +platform nvdimm resources. See Documentation/driver-api/nvdimm/. diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 5b10d036a8d4..c1a67275c43f 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -25,3 +25,30 @@ Description: NVDIMM have been scrubbed. * "locked" : Indicating that NVDIMM contents cant be modified until next power cycle. + +What: /sys/bus/nd/devices/nmemX/papr/perf_stats +Date: May, 2020 +KernelVersion: v5.9 +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, linux-nvdimm@lists.01.org, +Description: + (RO) Report various performance stats related to papr-scm NVDIMM + device. Each stat is reported on a new line with each line + composed of a stat-identifier followed by it value. Below are + currently known dimm performance stats which are reported: + + * "CtlResCt" : Controller Reset Count + * "CtlResTm" : Controller Reset Elapsed Time + * "PonSecs " : Power-on Seconds + * "MemLife " : Life Remaining + * "CritRscU" : Critical Resource Utilization + * "HostLCnt" : Host Load Count + * "HostSCnt" : Host Store Count + * "HostSDur" : Host Store Duration + * "HostLDur" : Host Load Duration + * "MedRCnt " : Media Read Count + * "MedWCnt " : Media Write Count + * "MedRDur " : Media Read Duration + * "MedWDur " : Media Write Duration + * "CchRHCnt" : Cache Read Hit Count + * "CchWHCnt" : Cache Write Hit Count + * "FastWCnt" : Fast Write Count
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-class-ocxl b/Documentation/ABI/testing/sysfs-class-ocxl index b5b1fa197592..ae1276efa45a 100644 --- a/Documentation/ABI/testing/sysfs-class-ocxl +++ b/Documentation/ABI/testing/sysfs-class-ocxl @@ -33,3 +33,14 @@ Date: January 2018 Contact: linuxppc-dev@lists.ozlabs.org Description: read/write Give access the global mmio area for the AFU + +What: /sys/class/ocxl/<afu name>/reload_on_reset +Date: February 2020 +Contact: linuxppc-dev@lists.ozlabs.org +Description: read/write + Control whether the FPGA is reloaded on a link reset. Enabled + through a vendor-specific logic block on the FPGA. + 0 Do not reload FPGA image from flash + 1 Reload FPGA image from flash + unavailable + The device does not support this capability diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 216d61a22f1e..40213c73bc9c 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -205,7 +205,8 @@ Description: Valid values: "Unknown", "Good", "Overheat", "Dead", "Over voltage", "Unspecified failure", "Cold", "Watchdog timer expire", "Safety timer expire", - "Over current", "Calibration required" + "Over current", "Calibration required", "Warm", + "Cool", "Hot" What: /sys/class/power_supply/<supply_name>/precharge_current Date: June 2017 diff --git a/Documentation/ABI/testing/sysfs-class-power-wilco b/Documentation/ABI/testing/sysfs-class-power-wilco index da1d6ffe5e3c..84fde1d0ada0 100644 --- a/Documentation/ABI/testing/sysfs-class-power-wilco +++ b/Documentation/ABI/testing/sysfs-class-power-wilco @@ -14,6 +14,10 @@ Description: Charging begins when level drops below charge_control_start_threshold, and ceases when level is above charge_control_end_threshold. + Long Life: Customized charge rate for last longer battery life. + On Wilco device this mode is pre-configured in the factory + through EC's private PID. Swiching to a different mode will + be denied by Wilco EC when Long Life mode is enabled. What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold Date: April 2019 diff --git a/Documentation/ABI/testing/sysfs-driver-input-exc3000 b/Documentation/ABI/testing/sysfs-driver-input-exc3000 new file mode 100644 index 000000000000..3d316d54f81c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-input-exc3000 @@ -0,0 +1,15 @@ +What: /sys/bus/i2c/devices/xxx/fw_version +Date: Aug 2020 +Contact: linux-input@vger.kernel.org +Description: Reports the firmware version provided by the touchscreen, for example "00_T6" on a EXC80H60 + + Access: Read + Valid values: Represented as string + +What: /sys/bus/i2c/devices/xxx/model +Date: Aug 2020 +Contact: linux-input@vger.kernel.org +Description: Reports the model identification provided by the touchscreen, for example "Orion_1320" on a EXC80H60 + + Access: Read + Valid values: Represented as string diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index 016724ec26d5..d1a352194d2e 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -883,3 +883,139 @@ Contact: Subhash Jadavani <subhashj@codeaurora.org> Description: This entry shows the target state of an UFS UIC link for the chosen system power management level. The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows if preserve user-space was configured + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_shared_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the shared allocated units of WB buffer + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the configured WB type. + 0x1 for shared buffer mode. 0x0 for dedicated buffer mode. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_buff_cap_adj +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the total user-space decrease in shared + buffer mode. + The value of this parameter is 3 for TLC NAND when SLC mode + is used as WriteBooster Buffer. 2 for MLC NAND. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the Maximum total WriteBooster Buffer size + which is supported by the entire device. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_max_wb_luns +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the maximum number of luns that can support + WriteBooster. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_red_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: The supportability of user space reduction mode + and preserve user space mode. + 00h: WriteBooster Buffer can be configured only in + user space reduction type. + 01h: WriteBooster Buffer can be configured only in + preserve user space type. + 02h: Device can be configured in either user space + reduction type or preserve user space type. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/wb_sup_wb_type +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: The supportability of WriteBooster Buffer type. + 00h: LU based WriteBooster Buffer configuration + 01h: Single shared WriteBooster Buffer + configuration + 02h: Supporting both LU based WriteBooster + Buffer and Single shared WriteBooster Buffer + configuration + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_enable +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the status of WriteBooster. + 0: WriteBooster is not enabled. + 1: WriteBooster is enabled + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_en +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows if flush is enabled. + 0: Flush operation is not performed. + 1: Flush operation is performed. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/flags/wb_flush_during_h8 +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: Flush WriteBooster Buffer during hibernate state. + 0: Device is not allowed to flush the + WriteBooster Buffer during link hibernate + state. + 1: Device is allowed to flush the + WriteBooster Buffer during link hibernate + state + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_avail_buf +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the amount of unused WriteBooster buffer + available. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_cur_buf +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the amount of unused current buffer. + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_flush_status +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the flush operation status. + 00h: idle + 01h: Flush operation in progress + 02h: Flush operation stopped prematurely. + 03h: Flush operation completed successfully + 04h: Flush operation general failure + The file is read only. + +What: /sys/bus/platform/drivers/ufshcd/*/attributes/wb_life_time_est +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows an indication of the WriteBooster Buffer + lifetime based on the amount of performed program/erase cycles + 01h: 0% - 10% WriteBooster Buffer life time used + ... + 0Ah: 90% - 100% WriteBooster Buffer life time used + The file is read only. + +What: /sys/class/scsi_device/*/device/unit_descriptor/wb_buf_alloc_units +Date: June 2020 +Contact: Asutosh Das <asutoshd@codeaurora.org> +Description: This entry shows the configured size of WriteBooster buffer. + 0400h corresponds to 4GB. + The file is read only. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 4bb93a06d8ab..7f730c4c8df2 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -229,7 +229,9 @@ Date: August 2017 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> Description: Do background GC agressively when set. When gc_urgent = 1, background thread starts to do GC by given gc_urgent_sleep_time - interval. It is set to 0 by default. + interval. When gc_urgent = 2, F2FS will lower the bar of + checking idle in order to process outstanding discard commands + and GC a little bit aggressively. It is set to 0 by default. What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time Date: August 2017 diff --git a/Documentation/PCI/pci-error-recovery.rst b/Documentation/PCI/pci-error-recovery.rst index 9fa49a6ece85..84ceebb08cac 100644 --- a/Documentation/PCI/pci-error-recovery.rst +++ b/Documentation/PCI/pci-error-recovery.rst @@ -79,7 +79,7 @@ This structure has the form:: struct pci_error_handlers { - int (*error_detected)(struct pci_dev *dev, enum pci_channel_state); + int (*error_detected)(struct pci_dev *dev, pci_channel_state_t); int (*mmio_enabled)(struct pci_dev *dev); int (*slot_reset)(struct pci_dev *dev); void (*resume)(struct pci_dev *dev); @@ -87,11 +87,11 @@ This structure has the form:: The possible channel states are:: - enum pci_channel_state { + typedef enum { pci_channel_io_normal, /* I/O channel is in normal state */ pci_channel_io_frozen, /* I/O to channel is blocked */ pci_channel_io_perm_failure, /* PCI card is dead */ - }; + } pci_channel_state_t; Possible return values are:: @@ -348,7 +348,7 @@ STEP 6: Permanent Failure ------------------------- A "permanent failure" has occurred, and the platform cannot recover the device. The platform will call error_detected() with a -pci_channel_state value of pci_channel_io_perm_failure. +pci_channel_state_t value of pci_channel_io_perm_failure. The device driver should, at this point, assume the worst. It should cancel all pending I/O, refuse all new I/O, returning -EIO to diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index c35b187d5479..814b40f8360b 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -17,7 +17,7 @@ PCI device drivers. A more complete resource is the third edition of "Linux Device Drivers" by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. LDD3 is available for free (under Creative Commons License) from: -http://lwn.net/Kernel/LDD3/. +https://lwn.net/Kernel/LDD3/. However, keep in mind that all documents are subject to "bit rot". Refer to the source code if things are not working as described here. @@ -214,7 +214,7 @@ the PCI device by calling pci_enable_device(). This will: problem and unlikely to get fixed soon. This has been discussed before but not changed as of 2.6.19: - http://lkml.org/lkml/2006/3/2/194 + https://lore.kernel.org/r/20060302180025.GC28895@flint.arm.linux.org.uk/ pci_set_master() will enable DMA by setting the bus master bit @@ -514,9 +514,8 @@ your driver if they're helpful, or just use plain hex constants. The device IDs are arbitrary hex numbers (vendor controlled) and normally used only in a single location, the pci_device_id table. -Please DO submit new vendor/device IDs to http://pci-ids.ucw.cz/. -There are mirrors of the pci.ids file at http://pciids.sourceforge.net/ -and https://github.com/pciutils/pciids. +Please DO submit new vendor/device IDs to https://pci-ids.ucw.cz/. +There's a mirror of the pci.ids file at https://github.com/pciutils/pciids. Obsolete functions diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index d6b3b77a4129..a22024f9175e 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -71,6 +71,16 @@ For example,:: foo = bar, baz foo = qux # !ERROR! we can not re-define same key +If you want to update the value, you must use the override operator +``:=`` explicitly. For example:: + + foo = bar, baz + foo := qux + +then, the ``qux`` is assigned to ``foo`` key. This is useful for +overriding the default value by adding (partial) custom bootconfigs +without parsing the default bootconfig. + If you want to append the value to existing key as an array member, you can use ``+=`` operator. For example:: @@ -84,6 +94,7 @@ For example, following config is NOT allowed.:: foo = value1 foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist + foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed. Comments diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index fa4018afa5a4..6be43781ec7f 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back. Amount of memory used for storing in-kernel data structures. + percpu + Amount of memory used for storing per-cpu kernel + data structures. + sock Amount of memory used in network transmission buffers diff --git a/Documentation/admin-guide/device-mapper/dm-dust.rst b/Documentation/admin-guide/device-mapper/dm-dust.rst index b6e7e7ead831..e35ec8cd2f88 100644 --- a/Documentation/admin-guide/device-mapper/dm-dust.rst +++ b/Documentation/admin-guide/device-mapper/dm-dust.rst @@ -69,10 +69,11 @@ Create the dm-dust device: $ sudo dmsetup create dust1 --table '0 33552384 dust /dev/vdb1 0 4096' Check the status of the read behavior ("bypass" indicates that all I/O -will be passed through to the underlying device):: +will be passed through to the underlying device; "verbose" indicates that +bad block additions, removals, and remaps will be verbosely logged):: $ sudo dmsetup status dust1 - 0 33552384 dust 252:17 bypass + 0 33552384 dust 252:17 bypass verbose $ sudo dd if=/dev/mapper/dust1 of=/dev/null bs=512 count=128 iflag=direct 128+0 records in @@ -164,7 +165,7 @@ following message command:: A message will print with the number of bad blocks currently configured on the device:: - kernel: device-mapper: dust: countbadblocks: 895 badblock(s) found + countbadblocks: 895 badblock(s) found Querying for specific bad blocks -------------------------------- @@ -176,11 +177,11 @@ following message command:: The following message will print if the block is in the list:: - device-mapper: dust: queryblock: block 72 found in badblocklist + dust_query_block: block 72 found in badblocklist The following message will print if the block is not in the list:: - device-mapper: dust: queryblock: block 72 not found in badblocklist + dust_query_block: block 72 not found in badblocklist The "queryblock" message command will work in both the "enabled" and "disabled" modes, allowing the verification of whether a block @@ -198,12 +199,28 @@ following message command:: After clearing the bad block list, the following message will appear:: - kernel: device-mapper: dust: clearbadblocks: badblocks cleared + dust_clear_badblocks: badblocks cleared If there were no bad blocks to clear, the following message will appear:: - kernel: device-mapper: dust: clearbadblocks: no badblocks found + dust_clear_badblocks: no badblocks found + +Listing the bad block list +-------------------------- + +To list all bad blocks in the bad block list (using an example device +with blocks 1 and 2 in the bad block list), run the following message +command:: + + $ sudo dmsetup message dust1 0 listbadblocks + 1 + 2 + +If there are no bad blocks in the bad block list, the command will +execute with no output:: + + $ sudo dmsetup message dust1 0 listbadblocks Message commands list --------------------- @@ -223,6 +240,7 @@ Single argument message commands:: countbadblocks clearbadblocks + listbadblocks disable enable quiet diff --git a/Documentation/admin-guide/device-mapper/verity.rst b/Documentation/admin-guide/device-mapper/verity.rst index bb02caa45289..66f71f0dab1b 100644 --- a/Documentation/admin-guide/device-mapper/verity.rst +++ b/Documentation/admin-guide/device-mapper/verity.rst @@ -83,6 +83,10 @@ restart_on_corruption not compatible with ignore_corruption and requires user space support to avoid restart loops. +panic_on_corruption + Panic the device when a corrupted block is discovered. This option is + not compatible with ignore_corruption and restart_on_corruption. + 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 diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 254bfafdcbcd..bdc1f33fd3d1 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -724,7 +724,7 @@ memory region [offset, offset + size] for that kernel image. If '@offset' is omitted, then a suitable offset is selected automatically. - [KNL, x86_64] select a region under 4G first, and + [KNL, X86-64] Select a region under 4G first, and fall back to reserve region above 4G when '@offset' hasn't been specified. See Documentation/admin-guide/kdump/kdump.rst for further details. @@ -737,14 +737,14 @@ Documentation/admin-guide/kdump/kdump.rst for an example. crashkernel=size[KMG],high - [KNL, x86_64] range could be above 4G. Allow kernel + [KNL, X86-64] range could be above 4G. Allow kernel to allocate physical memory region from top, so could be above 4G if system have more than 4G ram installed. Otherwise memory region will be allocated below 4G, if available. It will be ignored if crashkernel=X is specified. crashkernel=size[KMG],low - [KNL, x86_64] range under 4G. When crashkernel=X,high + [KNL, X86-64] range under 4G. When crashkernel=X,high is passed, kernel could allocate physical memory region above 4G, that cause second kernel crash on system that require some amount of low memory, e.g. swiotlb @@ -916,6 +916,10 @@ disable_radix [PPC] Disable RADIX MMU mode on POWER9 + radix_hcall_invalidate=on [PPC/PSERIES] + Disable RADIX GTSE feature and use hcall for TLB + invalidate. + disable_tlbie [PPC] Disable TLBIE instruction. Currently does not work with KVM, with HASH MMU, or with coherent accelerators. @@ -1423,7 +1427,7 @@ gamma= [HW,DRM] - gart_fix_e820= [X86_64] disable the fix e820 for K8 GART + gart_fix_e820= [X86-64] disable the fix e820 for K8 GART Format: off | on default: on @@ -1810,7 +1814,7 @@ Format: 0 | 1 Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON. - init_pkru= [x86] Specify the default memory protection keys rights + init_pkru= [X86] Specify the default memory protection keys rights register contents for all processes. 0x55555554 by default (disallow access to all but pkey 0). Can override in debugfs after boot. @@ -1818,7 +1822,7 @@ inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver Format: <irq> - int_pln_enable [x86] Enable power limit notification interrupt + int_pln_enable [X86] Enable power limit notification interrupt integrity_audit=[IMA] Format: { "0" | "1" } @@ -1836,7 +1840,7 @@ bypassed by not enabling DMAR with this option. In this case, gfx device will use physical address for DMA. - forcedac [x86_64] + forcedac [X86-64] With this option iommu will not optimize to look for io virtual address below 32-bit forcing dual address cycle on pci bus for cards supporting greater @@ -1921,7 +1925,7 @@ strict regions from userspace. relaxed - iommu= [x86] + iommu= [X86] off force noforce @@ -1931,8 +1935,8 @@ merge nomerge soft - pt [x86] - nopt [x86] + pt [X86] + nopt [X86] nobypass [PPC/POWERNV] Disable IOMMU bypass, using IOMMU for PCI devices. @@ -2075,21 +2079,21 @@ iucv= [HW,NET] - ivrs_ioapic [HW,X86_64] + ivrs_ioapic [HW,X86-64] Provide an override to the IOAPIC-ID<->DEVICE-ID mapping provided in the IVRS ACPI table. For example, to map IOAPIC-ID decimal 10 to PCI device 00:14.0 write the parameter as: ivrs_ioapic[10]=00:14.0 - ivrs_hpet [HW,X86_64] + ivrs_hpet [HW,X86-64] Provide an override to the HPET-ID<->DEVICE-ID mapping provided in the IVRS ACPI table. For example, to map HPET-ID decimal 0 to PCI device 00:14.0 write the parameter as: ivrs_hpet[0]=00:14.0 - ivrs_acpihid [HW,X86_64] + ivrs_acpihid [HW,X86-64] Provide an override to the ACPI-HID:UID<->DEVICE-ID mapping provided in the IVRS ACPI table. For example, to map UART-HID:UID AMD0020:0 to @@ -2366,7 +2370,7 @@ lapic [X86-32,APIC] Enable the local APIC even if BIOS disabled it. - lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline + lapic= [X86,APIC] "notscdeadline" Do not use TSC deadline value for LAPIC timer one-shot implementation. Default back to the programmable timer unit in the LAPIC. @@ -3184,12 +3188,12 @@ register save and restore. The kernel will only save legacy floating-point registers on task switch. - nohugeiomap [KNL,x86,PPC] Disable kernel huge I/O mappings. + nohugeiomap [KNL,X86,PPC] Disable kernel huge I/O mappings. nosmt [KNL,S390] Disable symmetric multithreading (SMT). Equivalent to smt=1. - [KNL,x86] Disable symmetric multithreading (SMT). + [KNL,X86] Disable symmetric multithreading (SMT). nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. @@ -3951,7 +3955,7 @@ pt. [PARIDE] See Documentation/admin-guide/blockdev/paride.rst. - pti= [X86_64] Control Page Table Isolation of user and + pti= [X86-64] Control Page Table Isolation of user and kernel address spaces. Disabling this feature removes hardening, but improves performance of system calls and interrupts. @@ -3963,7 +3967,7 @@ Not specifying this option is equivalent to pti=auto. - nopti [X86_64] + nopti [X86-64] Equivalent to pti=off pty.legacy_count= @@ -4689,7 +4693,7 @@ fragmentation. Defaults to 1 for systems with more than 32MB of RAM, 0 otherwise. - slub_debug[=options[,slabs]] [MM, SLUB] + slub_debug[=options[,slabs][;[options[,slabs]]...] [MM, SLUB] Enabling slub_debug allows one to determine the culprit if slab objects become corrupted. Enabling slub_debug can create guard zones around objects and @@ -5804,8 +5808,9 @@ panic() code such as dumping handler. xen_nopvspin [X86,XEN] - Disables the ticketlock slowpath using Xen PV - optimizations. + Disables the qspinlock slowpath using Xen PV optimizations. + This parameter is obsoleted by "nopvspin" parameter, which + has equivalent effect for XEN platform. xen_nopv [X86] Disables the PV optimizations forcing the HVM guest to @@ -5831,6 +5836,11 @@ as generic guest with no PV drivers. Currently support XEN HVM, KVM, HYPER_V and VMWARE guest. + nopvspin [X86,XEN,KVM] + Disables the qspinlock slow path using PV optimizations + which allow the hypervisor to 'idle' the guest on lock + contention. + xirc2ps_cs= [NET,PCMCIA] Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] diff --git a/Documentation/admin-guide/media/fimc.rst b/Documentation/admin-guide/media/fimc.rst index 0b8ddc4a3008..56b149d9a527 100644 --- a/Documentation/admin-guide/media/fimc.rst +++ b/Documentation/admin-guide/media/fimc.rst @@ -2,7 +2,7 @@ .. include:: <isonum.txt> -The Samsung S5P/EXYNOS4 FIMC driver +The Samsung S5P/Exynos4 FIMC driver =================================== Copyright |copy| 2012 - 2013 Samsung Electronics Co., Ltd. @@ -19,7 +19,7 @@ drivers/media/platform/exynos4-is directory. Supported SoCs -------------- -S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210 +S5PC100 (mem-to-mem only), S5PV210, Exynos4210 Supported features ------------------ @@ -45,7 +45,7 @@ Media device interface ~~~~~~~~~~~~~~~~~~~~~~ The driver supports Media Controller API as defined at :ref:`media_controller`. -The media device driver name is "SAMSUNG S5P FIMC". +The media device driver name is "Samsung S5P FIMC". The purpose of this interface is to allow changing assignment of FIMC instances to the SoC peripheral camera input at runtime and optionally to control internal diff --git a/Documentation/admin-guide/media/vivid.rst b/Documentation/admin-guide/media/vivid.rst index 52e57b773f07..6d7175f96f74 100644 --- a/Documentation/admin-guide/media/vivid.rst +++ b/Documentation/admin-guide/media/vivid.rst @@ -293,6 +293,15 @@ all configurable using the following module options: - 0: vmalloc - 1: dma-contig +- cache_hints: + + specifies if the device should set queues' user-space cache and memory + consistency hint capability (V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS). + The hints are valid only when using MMAP streaming I/O. Default is 0. + + - 0: forbid hints + - 1: allow hints + Taken together, all these module options allow you to precisely customize the driver behavior and test your application with all sorts of permutations. It is also very suitable to emulate hardware that is not yet available, e.g. diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt new file mode 100644 index 000000000000..3782f6a09e97 --- /dev/null +++ b/Documentation/admin-guide/spkguide.txt @@ -0,0 +1,1575 @@ + +The Speakup User's Guide +For Speakup 3.1.2 and Later +By Gene Collins +Updated by others +Last modified on Mon Sep 27 14:26:31 2010 +Document version 1.3 + +Copyright (c) 2005 Gene Collins +Copyright (c) 2008 Samuel Thibault +Copyright (c) 2009, 2010 the Speakup Team + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no +Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A +copy of the license is included in the section entitled "GNU Free +Documentation License". + +Preface + +The purpose of this document is to familiarize users with the user +interface to Speakup, a Linux Screen Reader. If you need instructions +for installing or obtaining Speakup, visit the web site at +http://linux-speakup.org/. Speakup is a set of patches to the standard +Linux kernel source tree. It can be built as a series of modules, or as +a part of a monolithic kernel. These details are beyond the scope of +this manual, but the user may need to be aware of the module +capabilities, depending on how your system administrator has installed +Speakup. If Speakup is built as a part of a monolithic kernel, and the +user is using a hardware synthesizer, then Speakup will be able to +provide speech access from the time the kernel is loaded, until the time +the system is shutdown. This means that if you have obtained Linux +installation media for a distribution which includes Speakup as a part +of its kernel, you will be able, as a blind person, to install Linux +with speech access unaided by a sighted person. Again, these details +are beyond the scope of this manual, but the user should be aware of +them. See the web site mentioned above for further details. + +1. Starting Speakup + +If your system administrator has installed Speakup to work with your +specific synthesizer by default, then all you need to do to use Speakup +is to boot your system, and Speakup should come up talking. This +assumes of course that your synthesizer is a supported hardware +synthesizer, and that it is either installed in or connected to your +system, and is if necessary powered on. + +It is possible, however, that Speakup may have been compiled into the +kernel with no default synthesizer. It is even possible that your +kernel has been compiled with support for some of the supported +synthesizers and not others. If you find that this is the case, and +your synthesizer is supported but not available, complain to the person +who compiled and installed your kernel. Or better yet, go to the web +site, and learn how to patch Speakup into your own kernel source, and +build and install your own kernel. + +If your kernel has been compiled with Speakup, and has no default +synthesizer set, or you would like to use a different synthesizer than +the default one, then you may issue the following command at the boot +prompt of your boot loader. + +linux speakup.synth=ltlk + +This command would tell Speakup to look for and use a LiteTalk or +DoubleTalk LT at boot up. You may replace the ltlk synthesizer keyword +with the keyword for whatever synthesizer you wish to use. The +speakup.synth parameter will accept the following keywords, provided +that support for the related synthesizers has been built into the +kernel. + +acntsa -- Accent SA +acntpc -- Accent PC +apollo -- Apollo +audptr -- Audapter +bns -- Braille 'n Speak +dectlk -- DecTalk Express (old and new, db9 serial only) +decext -- DecTalk (old) External +dtlk -- DoubleTalk PC +keypc -- Keynote Gold PC +ltlk -- DoubleTalk LT, LiteTalk, or external Tripletalk (db9 serial only) +spkout -- Speak Out +txprt -- Transport +dummy -- Plain text terminal + +Note: Speakup does * NOT * support usb connections! Speakup also does * +NOT * support the internal Tripletalk! + +Speakup does support two other synthesizers, but because they work in +conjunction with other software, they must be loaded as modules after +their related software is loaded, and so are not available at boot up. +These are as follows: + +decpc -- DecTalk PC (not available at boot up) +soft -- One of several software synthesizers (not available at boot up) + +See the sections on loading modules and software synthesizers later in +this manual for further details. It should be noted here that the +speakup.synth boot parameter will have no effect if Speakup has been +compiled as modules. In order for Speakup modules to be loaded during +the boot process, such action must be configured by your system +administrator. This will mean that you will hear some, but not all, of +the bootup messages. + +2. Basic operation + +Once you have booted the system, and if necessary, have supplied the +proper bootup parameter for your synthesizer, Speakup will begin +talking as soon as the kernel is loaded. In fact, it will talk a lot! +It will speak all the boot up messages that the kernel prints on the +screen during the boot process. This is because Speakup is not a +separate screen reader, but is actually built into the operating +system. Since almost all console applications must print text on the +screen using the kernel, and must get their keyboard input through the +kernel, they are automatically handled properly by Speakup. There are a +few exceptions, but we'll come to those later. + +Note: In this guide I will refer to the numeric keypad as the keypad. +This is done because the speakupmap.map file referred to later in this +manual uses the term keypad instead of numeric keypad. Also I'm lazy +and would rather only type one word. So keypad it is. Got it? Good. + +Most of the Speakup review keys are located on the keypad at the far +right of the keyboard. The numlock key should be off, in order for these +to work. If you toggle the numlock on, the keypad will produce numbers, +which is exactly what you want for spreadsheets and such. For the +purposes of this guide, you should have the numlock turned off, which is +its default state at bootup. + +You probably won't want to listen to all the bootup messages every time +you start your system, though it's a good idea to listen to them at +least once, just so you'll know what kind of information is available to +you during the boot process. You can always review these messages after +bootup with the command: + +dmesg | more + +In order to speed the boot process, and to silence the speaking of the +bootup messages, just press the keypad enter key. This key is located +in the bottom right corner of the keypad. Speakup will shut up and stay +that way, until you press another key. + +You can check to see if the boot process has completed by pressing the 8 +key on the keypad, which reads the current line. This also has the +effect of starting Speakup talking again, so you can press keypad enter +to silence it again if the boot process has not completed. + +When the boot process is complete, you will arrive at a "login" prompt. +At this point, you'll need to type in your user id and password, as +provided by your system administrator. You will hear Speakup speak the +letters of your user id as you type it, but not the password. This is +because the password is not displayed on the screen for security +reasons. This has nothing to do with Speakup, it's a Linux security +feature. + +Once you've logged in, you can run any Linux command or program which is +allowed by your user id. Normal users will not be able to run programs +which require root privileges. + +When you are running a program or command, Speakup will automatically +speak new text as it arrives on the screen. You can at any time silence +the speech with keypad enter, or use any of the Speakup review keys. + +Here are some basic Speakup review keys, and a short description of what +they do. + +keypad 1 -- read previous character +keypad 2 -- read current character (pressing keypad 2 twice rapidly will speak + the current character phonetically) +keypad 3 -- read next character +keypad 4 -- read previous word +keypad 5 -- read current word (press twice rapidly to spell the current word) +keypad 6 -- read next word +keypad 7 -- read previous line +keypad 8 -- read current line (press twice rapidly to hear how much the + text on the current line is indented) +keypad 9 -- read next line +keypad period -- speak current cursor position and announce current + virtual console + +It's also worth noting that the insert key on the keypad is mapped +as the speakup key. Instead of pressing and releasing this key, as you +do under DOS or Windows, you hold it like a shift key, and press other +keys in combination with it. For example, repeatedly holding keypad +insert, from now on called speakup, and keypad enter will toggle the +speaking of new text on the screen on and off. This is not the same as +just pressing keypad enter by itself, which just silences the speech +until you hit another key. When you hit speakup plus keypad enter, +Speakup will say, "You turned me off.", or "Hey, that's better." When +Speakup is turned off, no new text on the screen will be spoken. You +can still use the reading controls to review the screen however. + +3. Using the Speakup Help System + +In order to enter the Speakup help system, press and hold the speakup +key (remember that this is the keypad insert key), and press the f1 key. +You will hear the message: + +"Press space to leave help, cursor up or down to scroll, or a letter to +go to commands in list." + +When you press the spacebar to leave the help system, you will hear: + +"Leaving help." + +While you are in the Speakup help system, you can scroll up or down +through the list of available commands using the cursor keys. The list +of commands is arranged in alphabetical order. If you wish to jump to +commands in a specific part of the alphabet, you may press the letter of +the alphabet you wish to jump to. + +You can also just explore by typing keyboard keys. Pressing keys will +cause Speakup to speak the command associated with that key. For +example, if you press the keypad 8 key, you will hear: + +"Keypad 8 is line, say current." + +You'll notice that some commands do not have keys assigned to them. +This is because they are very infrequently used commands, and are also +accessible through the sys system. We'll discuss the sys system later +in this manual. + +You'll also notice that some commands have two keys assigned to them. +This is because Speakup has a built in set of alternative key bindings +for laptop users. The alternate speakup key is the caps lock key. You +can press and hold the caps lock key, while pressing an alternate +speakup command key to activate the command. On most laptops, the +numeric keypad is defined as the keys in the j k l area of the keyboard. + +There is usually a function key which turns this keypad function on and +off, and some other key which controls the numlock state. Toggling the +keypad functionality on and off can become a royal pain. So, Speakup +gives you a simple way to get at an alternative set of key mappings for +your laptop. These are also available by default on desktop systems, +because Speakup does not know whether it is running on a desktop or +laptop. So you may choose which set of Speakup keys to use. Some +system administrators may have chosen to compile Speakup for a desktop +system without this set of alternate key bindings, but these details are +beyond the scope of this manual. To use the caps lock for its normal +purpose, hold the shift key while toggling the caps lock on and off. We +should note here, that holding the caps lock key and pressing the z key +will toggle the alternate j k l keypad on and off. + +4. Keys and Their Assigned Commands + +In this section, we'll go through a list of all the speakup keys and +commands. You can also get a list of commands and assigned keys from +the help system. + +The following list was taken from the speakupmap.map file. Key +assignments are on the left of the equal sign, and the associated +Speakup commands are on the right. The designation "spk" means to press +and hold the speakup key, a.k.a. keypad insert, a.k.a. caps lock, while +pressing the other specified key. + +spk key_f9 = punc_level_dec +spk key_f10 = punc_level_inc +spk key_f11 = reading_punc_dec +spk key_f12 = reading_punc_inc +spk key_1 = vol_dec +spk key_2 = vol_inc +spk key_3 = pitch_dec +spk key_4 = pitch_inc +spk key_5 = rate_dec +spk key_6 = rate_inc +key_kpasterisk = toggle_cursoring +spk key_kpasterisk = speakup_goto +spk key_f1 = speakup_help +spk key_f2 = set_win +spk key_f3 = clear_win +spk key_f4 = enable_win +spk key_f5 = edit_some +spk key_f6 = edit_most +spk key_f7 = edit_delim +spk key_f8 = edit_repeat +shift spk key_f9 = edit_exnum + key_kp7 = say_prev_line +spk key_kp7 = left_edge + key_kp8 = say_line +double key_kp8 = say_line_indent +spk key_kp8 = say_from_top + key_kp9 = say_next_line +spk key_kp9 = top_edge + key_kpminus = speakup_parked +spk key_kpminus = say_char_num + key_kp4 = say_prev_word +spk key_kp4 = say_from_left + key_kp5 = say_word +double key_kp5 = spell_word +spk key_kp5 = spell_phonetic + key_kp6 = say_next_word +spk key_kp6 = say_to_right + key_kpplus = say_screen +spk key_kpplus = say_win + key_kp1 = say_prev_char +spk key_kp1 = right_edge + key_kp2 = say_char +spk key_kp2 = say_to_bottom +double key_kp2 = say_phonetic_char + key_kp3 = say_next_char +spk key_kp3 = bottom_edge + key_kp0 = spk_key + key_kpdot = say_position +spk key_kpdot = say_attributes +key_kpenter = speakup_quiet +spk key_kpenter = speakup_off +key_sysrq = speech_kill + key_kpslash = speakup_cut +spk key_kpslash = speakup_paste +spk key_pageup = say_first_char +spk key_pagedown = say_last_char +key_capslock = spk_key + spk key_z = spk_lock +key_leftmeta = spk_key +ctrl spk key_0 = speakup_goto +spk key_u = say_prev_line +spk key_i = say_line +double spk key_i = say_line_indent +spk key_o = say_next_line +spk key_minus = speakup_parked +shift spk key_minus = say_char_num +spk key_j = say_prev_word +spk key_k = say_word +double spk key_k = spell_word +spk key_l = say_next_word +spk key_m = say_prev_char +spk key_comma = say_char +double spk key_comma = say_phonetic_char +spk key_dot = say_next_char +spk key_n = say_position + ctrl spk key_m = left_edge + ctrl spk key_y = top_edge + ctrl spk key_dot = right_edge +ctrl spk key_p = bottom_edge +spk key_apostrophe = say_screen +spk key_h = say_from_left +spk key_y = say_from_top +spk key_semicolon = say_to_right +spk key_p = say_to_bottom +spk key_slash = say_attributes + spk key_enter = speakup_quiet + ctrl spk key_enter = speakup_off + spk key_9 = speakup_cut +spk key_8 = speakup_paste +shift spk key_m = say_first_char + ctrl spk key_semicolon = say_last_char + +5. The Speakup Sys System + +The Speakup screen reader also creates a speakup subdirectory as a part +of the sys system. + +As a convenience, run as root + +ln -s /sys/accessibility/speakup /speakup + +to directly access speakup parameters from /speakup. +You can see these entries by typing the command: + +ls -1 /speakup/* + +If you issue the above ls command, you will get back something like +this: + +/speakup/attrib_bleep +/speakup/bell_pos +/speakup/bleep_time +/speakup/bleeps +/speakup/cursor_time +/speakup/delimiters +/speakup/ex_num +/speakup/key_echo +/speakup/keymap +/speakup/no_interrupt +/speakup/punc_all +/speakup/punc_level +/speakup/punc_most +/speakup/punc_some +/speakup/reading_punc +/speakup/repeats +/speakup/say_control +/speakup/say_word_ctl +/speakup/silent +/speakup/spell_delay +/speakup/synth +/speakup/synth_direct +/speakup/version + +/speakup/i18n: +announcements +characters +chartab +colors +ctl_keys +formatted +function_names +key_names +states + +/speakup/soft: +caps_start +caps_stop +delay_time +direct +freq +full_time +jiffy_delta +pitch +inflection +punct +rate +tone +trigger_time +voice +vol + +Notice the two subdirectories of /speakup: /speakup/i18n and +/speakup/soft. +The i18n subdirectory is described in a later section. +The files under /speakup/soft represent settings that are specific to the +driver for the software synthesizer. If you use the LiteTalk, your +synthesizer-specific settings would be found in /speakup/ltlk. In other words, +a subdirectory named /speakup/KWD is created to hold parameters specific +to the device whose keyword is KWD. +These parameters include volume, rate, pitch, and others. + +In addition to using the Speakup hot keys to change such things as +volume, pitch, and rate, you can also echo values to the appropriate +entry in the /speakup directory. This is very useful, since it +lets you control Speakup parameters from within a script. How you +would write such scripts is somewhat beyond the scope of this manual, +but I will include a couple of simple examples here to give you a +general idea of what such scripts can do. + +Suppose for example, that you wanted to control both the punctuation +level and the reading punctuation level at the same time. For +simplicity, we'll call them punc0, punc1, punc2, and punc3. The scripts +might look something like this: + +#!/bin/bash +# punc0 +# set punc and reading punc levels to 0 +echo 0 >/speakup/punc_level +echo 0 >/speakup/reading_punc +echo Punctuation level set to 0. + +#!/bin/bash +# punc1 +# set punc and reading punc levels to 1 +echo 1 >/speakup/punc_level +echo 1 >/speakup/reading_punc +echo Punctuation level set to 1. + +#!/bin/bash +# punc2 +# set punc and reading punc levels to 2 +echo 2 >/speakup/punc_level +echo 2 >/speakup/reading_punc +echo Punctuation level set to 2. + +#!/bin/bash +# punc3 +# set punc and reading punc levels to 3 +echo 3 >/speakup/punc_level +echo 3 >/speakup/reading_punc +echo Punctuation level set to 3. + +If you were to store these four small scripts in a directory in your +path, perhaps /usr/local/bin, and set the permissions to 755 with the +chmod command, then you could change the default reading punc and +punctuation levels at the same time by issuing just one command. For +example, if you were to execute the punc3 command at your shell prompt, +then the reading punc and punc level would both get set to 3. + +I should note that the above scripts were written to work with bash, but +regardless of which shell you use, you should be able to do something +similar. + +The Speakup sys system also has another interesting use. You can echo +Speakup parameters into the sys system in a script during system +startup, and speakup will return to your preferred parameters every time +the system is rebooted. + +Most of the Speakup sys parameters can be manipulated by a regular user +on the system. However, there are a few parameters that are dangerous +enough that they should only be manipulated by the root user on your +system. There are even some parameters that are read only, and cannot +be written to at all. For example, the version entry in the Speakup +sys system is read only. This is because there is no reason for a user +to tamper with the version number which is reported by Speakup. Doing +an ls -l on /speakup/version will return this: + +-r--r--r-- 1 root root 0 Mar 21 13:46 /speakup/version + +As you can see, the version entry in the Speakup sys system is read +only, is owned by root, and belongs to the root group. Doing a cat of +/speakup/version will display the Speakup version number, like +this: + +cat /speakup/version +Speakup v-2.00 CVS: Thu Oct 21 10:38:21 EDT 2004 +synth dtlk version 1.1 + +The display shows the Speakup version number, along with the version +number of the driver for the current synthesizer. + +Looking at entries in the Speakup sys system can be useful in many +ways. For example, you might wish to know what level your volume is set +at. You could type: + +cat /speakup/KWD/vol +# Replace KWD with the keyword for your synthesizer, E.G., ltlk for LiteTalk. +5 + +The number five which comes back is the level at which the synthesizer +volume is set at. + +All the entries in the Speakup sys system are readable, some are +writable by root only, and some are writable by everyone. Unless you +know what you are doing, you should probably leave the ones that are +writable by root only alone. Most of the names are self explanatory. +Vol for controlling volume, pitch for pitch, inflection for pitch range, rate +for controlling speaking rate, etc. If you find one you aren't sure about, you +can post a query on the Speakup list. + +6. Changing Synthesizers + +It is possible to change to a different synthesizer while speakup is +running. In other words, it is not necessary to reboot the system +in order to use a different synthesizer. You can simply echo the +synthesizer keyword to the /speakup/synth sys entry. +Depending on your situation, you may wish to echo none to the synth +sys entry, to disable speech while one synthesizer is disconnected and +a second one is connected in its place. Then echo the keyword for the +new synthesizer into the synth sys entry in order to start speech +with the newly connected synthesizer. See the list of synthesizer +keywords in section 1 to find the keyword which matches your synth. + +7. Loading modules + +As mentioned earlier, Speakup can either be completely compiled into the +kernel, with the exception of the help module, or it can be compiled as +a series of modules. When compiled as modules, Speakup will only be +able to speak some of the bootup messages if your system administrator +has configured the system to load the modules at boo time. The modules +can be loaded after the file systems have been checked and mounted, or +from an initrd. There is a third possibility. Speakup can be compiled +with some components built into the kernel, and others as modules. As +we'll see in the next section, this is particularly useful when you are +working with software synthesizers. + +If Speakup is completely compiled as modules, then you must use the +modprobe command to load Speakup. You do this by loading the module for +the synthesizer driver you wish to use. The driver modules are all +named speakup_<keyword>, where <keyword> is the keyword for the +synthesizer you want. So, in order to load the driver for the DecTalk +Express, you would type the following command: + +modprobe speakup_dectlk + +Issuing this command would load the DecTalk Express driver and all other +related Speakup modules necessary to get Speakup up and running. + +To completely unload Speakup, again presuming that it is entirely built +as modules, you would give the command: + +modprobe -r speakup_dectlk + +The above command assumes you were running a DecTalk Express. If you +were using a different synth, then you would substitute its keyword in +place of dectlk. + +If you have multiple drivers loaded, you need to unload all of them, in +order to completely unload Speakup. +For example, if you have loaded both the dectlk and ltlk drivers, use the +command: +modprobe -r speakup_dectlk speakup_ltlk + +You cannot unload the driver for software synthesizers when a user-space +daemon is using /dev/softsynth. First, kill the daemon. Next, remove +the driver with the command: +modprobe -r speakup_soft + +Now, suppose we have a situation where the main Speakup component +is built into the kernel, and some or all of the drivers are built as +modules. Since the main part of Speakup is compiled into the kernel, a +partial Speakup sys system has been created which we can take advantage +of by simply echoing the synthesizer keyword into the +/speakup/synth sys entry. This will cause the kernel to +automatically load the appropriate driver module, and start Speakup +talking. To switch to another synth, just echo a new keyword to the +synth sys entry. For example, to load the DoubleTalk LT driver, +you would type: + +echo ltlk >/speakup/synth + +You can use the modprobe -r command to unload driver modules, regardless +of whether the main part of Speakup has been built into the kernel or +not. + +8. Using Software Synthesizers + +Using a software synthesizer requires that some other software be +installed and running on your system. For this reason, software +synthesizers are not available for use at bootup, or during a system +installation process. +There are two freely-available solutions for software speech: Espeakup and +Speech Dispatcher. +These are described in subsections 8.1 and 8.2, respectively. + +During the rest of this section, we assume that speakup_soft is either +built in to your kernel, or loaded as a module. + +If your system does not have udev installed , before you can use a +software synthesizer, you must have created the /dev/softsynth device. +If you have not already done so, issue the following commands as root: + +cd /dev +mknod softsynth c 10 26 + +While we are at it, we might just as well create the /dev/synth device, +which can be used to let user space programs send information to your +synthesizer. To create /dev/synth, change to the /dev directory, and +issue the following command as root: + +mknod synth c 10 25 + +of both. + +8.1. Espeakup + +Espeakup is a connector between Speakup and the eSpeak software synthesizer. +Espeakup may already be available as a package for your distribution +of Linux. If it is not packaged, you need to install it manually. +You can find it in the contrib/ subdirectory of the Speakup sources. +The filename is espeakup-$VERSION.tar.bz2, where $VERSION +depends on the current release of Espeakup. The Speakup 3.1.2 source +ships with version 0.71 of Espeakup. +The README file included with the Espeakup sources describes the process +of manual installation. + +Assuming that Espeakup is installed, either by the user or by the distributor, +follow these steps to use it. + +Tell Speakup to use the "soft driver: +echo soft > /speakup/synth + +Finally, start the espeakup program. There are two ways to do it. +Both require root privileges. + +If Espeakup was installed as a package for your Linux distribution, +you probably have a distribution-specific script that controls the operation +of the daemon. Look for a file named espeakup under /etc/init.d or +/etc/rc.d. Execute the following command with root privileges: +/etc/init.d/espeakup start +Replace init.d with rc.d, if your distribution uses scripts located under +/etc/rc.d. +Your distribution will also have a procedure for starting daemons at +boot-time, so it is possible to have software speech as soon as user-space +daemons are started by the bootup scripts. +These procedures are not described in this document. + +If you built Espeakup manually, the "make install" step placed the binary +under /usr/bin. +Run the following command as root: +/usr/bin/espeakup +Espeakup should start speaking. + +8.2. Speech Dispatcher + +For this option, you must have a package called +Speech Dispatcher running on your system, and it must be configured to +work with one of its supported software synthesizers. + +Two open source synthesizers you might use are Flite and Festival. You +might also choose to purchase the Software DecTalk from Fonix Sales Inc. +If you run a google search for Fonix, you'll find their web site. + +You can obtain a copy of Speech Dispatcher from free(b)soft at +http://www.freebsoft.org/. Follow the installation instructions that +come with Speech Dispatcher in order to install and configure Speech +Dispatcher. You can check out the web site for your Linux distribution +in order to get a copy of either Flite or Festival. Your Linux +distribution may also have a precompiled Speech Dispatcher package. + +Once you've installed, configured, and tested Speech Dispatcher with your +chosen software synthesizer, you still need one more piece of software +in order to make things work. You need a package called speechd-up. +You get it from the free(b)soft web site mentioned above. After you've +compiled and installed speechd-up, you are almost ready to begin using +your software synthesizer. + +Now you can begin using your software synthesizer. In order to do so, +echo the soft keyword to the synth sys entry like this: + +echo soft >/speakup/synth + +Next run the speechd_up command like this: + +speechd_up & + +Your synth should now start talking, and you should be able to adjust +the pitch, rate, etc. + +9. Using The DecTalk PC Card + +The DecTalk PC card is an ISA card that is inserted into one of the ISA +slots in your computer. It requires that the DecTalk PC software be +installed on your computer, and that the software be loaded onto the +Dectalk PC card before it can be used. + +You can get the dec_pc.tgz file from the linux-speakup.org site. The +dec_pc.tgz file is in the ~ftp/pub/linux/speakup directory. + +After you have downloaded the dec_pc.tgz file, untar it in your home +directory, and read the Readme file in the newly created dec_pc +directory. + +The easiest way to get the software working is to copy the entire dec_pc +directory into /user/local/lib. To do this, su to root in your home +directory, and issue the command: + +cp dec_pc /usr/local/lib + +You will need to copy the dtload command from the dec_pc directory to a +directory in your path. Either /usr/bin or /usr/local/bin is a good +choice. + +You can now run the dtload command in order to load the DecTalk PC +software onto the card. After you have done this, echo the decpc +keyword to the synth entry in the sys system like this: + +echo decpc >/speakup/synth + +Your DecTalk PC should start talking, and then you can adjust the pitch, +rate, volume, voice, etc. The voice entry in the Speakup sys system +will accept a number from 0 through 7 for the DecTalk PC synthesizer, +which will give you access to some of the DecTalk voices. + +10. Using Cursor Tracking + +In Speakup version 2.0 and later, cursor tracking is turned on by +default. This means that when you are using an editor, Speakup will +automatically speak characters as you move left and right with the +cursor keys, and lines as you move up and down with the cursor keys. +This is the traditional sort of cursor tracking. +Recent versions of Speakup provide two additional ways to control the +text that is spoken when the cursor is moved: +"highlight tracking" and "read window." +They are described later in this section. +Sometimes, these modes get in your way, so you can disable cursor tracking +altogether. + +You may select among the various forms of cursor tracking using the keypad +asterisk key. +Each time you press this key, a new mode is selected, and Speakup speaks +the name of the new mode. The names for the four possible states of cursor +tracking are: "cursoring on", "highlight tracking", "read window", +and "cursoring off." The keypad asterisk key moves through the list of +modes in a circular fashion. + +If highlight tracking is enabled, Speakup tracks highlighted text, +rather than the cursor itself. When you move the cursor with the arrow keys, +Speakup speaks the currently highlighted information. +This is useful when moving through various menus and dialog boxes. +If cursor tracking isn't helping you while navigating a menu, +try highlight tracking. + +With the "read window" variety of cursor tracking, you can limit the text +that Speakup speaks by specifying a window of interest on the screen. +See section 15 for a description of the process of defining windows. +When you move the cursor via the arrow keys, Speakup only speaks +the contents of the window. This is especially helpful when you are hearing +superfluous speech. Consider the following example. + +Suppose that you are at a shell prompt. You use bash, and you want to +explore your command history using the up and down arrow keys. If you +have enabled cursor tracking, you will hear two pieces of information. +Speakup speaks both your shell prompt and the current entry from the +command history. You may not want to hear the prompt repeated +each time you move, so you can silence it by specifying a window. Find +the last line of text on the screen. Clear the current window by pressing +the key combination speakup f3. Use the review cursor to find the first +character that follows your shell prompt. Press speakup + f2 twice, to +define a one-line window. The boundaries of the window are the +character following the shell prompt and the end of the line. Now, cycle +through the cursor tracking modes using keypad asterisk, until Speakup +says "read window." Move through your history using your arrow keys. +You will notice that Speakup no longer speaks the redundant prompt. + +Some folks like to turn cursor tracking off while they are using the +lynx web browser. You definitely want to turn cursor tracking off when +you are using the alsamixer application. Otherwise, you won't be able +to hear your mixer settings while you are using the arrow keys. + +11. Cut and Paste + +One of Speakup's more useful features is the ability to cut and paste +text on the screen. This means that you can capture information from a +program, and paste that captured text into a different place in the +program, or into an entirely different program, which may even be +running on a different console. + +For example, in this manual, we have made references to several web +sites. It would be nice if you could cut and paste these urls into your +web browser. Speakup does this quite nicely. Suppose you wanted to +past the following url into your browser: + +http://linux-speakup.org/ + +Use the speakup review keys to position the reading cursor on the first +character of the above url. When the reading cursor is in position, +press the keypad slash key once. Speakup will say, "mark". Next, +position the reading cursor on the rightmost character of the above +url. Press the keypad slash key once again to actually cut the text +from the screen. Speakup will say, "cut". Although we call this +cutting, Speakup does not actually delete the cut text from the screen. +It makes a copy of the text in a special buffer for later pasting. + +Now that you have the url cut from the screen, you can paste it into +your browser, or even paste the url on a command line as an argument to +your browser. + +Suppose you want to start lynx and go to the Speakup site. + +You can switch to a different console with the alt left and right +arrows, or you can switch to a specific console by typing alt and a +function key. These are not Speakup commands, just standard Linux +console capabilities. + +Once you've changed to an appropriate console, and are at a shell prompt, +type the word lynx, followed by a space. Now press and hold the speakup +key, while you type the keypad slash character. The url will be pasted +onto the command line, just as though you had typed it in. Press the +enter key to execute the command. + +The paste buffer will continue to hold the cut information, until a new +mark and cut operation is carried out. This means you can paste the cut +information as many times as you like before doing another cut +operation. + +You are not limited to cutting and pasting only one line on the screen. +You can also cut and paste rectangular regions of the screen. Just +position the reading cursor at the top left corner of the text to be +cut, mark it with the keypad slash key, then position the reading cursor +at the bottom right corner of the region to be cut, and cut it with the +keypad slash key. + +12. Changing the Pronunciation of Characters + +Through the /speakup/i18n/characters sys entry, Speakup gives you the +ability to change how Speakup pronounces a given character. You could, +for example, change how some punctuation characters are spoken. You can +even change how Speakup will pronounce certain letters. + +You may, for example, wish to change how Speakup pronounces the z +character. The author of Speakup, Kirk Reiser, is Canadian, and thus +believes that the z should be pronounced zed. If you are an American, +you might wish to use the zee pronunciation instead of zed. You can +change the pronunciation of both the upper and lower case z with the +following two commands: + +echo 90 zee >/speakup/characters +echo 122 zee >/speakup/characters + +Let's examine the parts of the two previous commands. They are issued +at the shell prompt, and could be placed in a startup script. + +The word echo tells the shell that you want to have it display the +string of characters that follow the word echo. If you were to just +type: + +echo hello. + +You would get the word hello printed on your screen as soon as you +pressed the enter key. In this case, we are echoing strings that we +want to be redirected into the sys system. + +The numbers 90 and 122 in the above echo commands are the ascii numeric +values for the upper and lower case z, the characters we wish to change. + +The string zee is the pronunciation that we want Speakup to use for the +upper and lower case z. + +The > symbol redirects the output of the echo command to a file, just +like in DOS, or at the Windows command prompt. + +And finally, /speakup/i18n/characters is the file entry in the sys system +where we want the output to be directed. Speakup looks at the numeric +value of the character we want to change, and inserts the pronunciation +string into an internal table. + +You can look at the whole table with the following command: + +cat /speakup/i18n/characters + +Speakup will then print out the entire character pronunciation table. I +won't display it here, but leave you to look at it at your convenience. + +13. Mapping Keys + +Speakup has the capability of allowing you to assign or "map" keys to +internal Speakup commands. This section necessarily assumes you have a +Linux kernel source tree installed, and that it has been patched and +configured with Speakup. How you do this is beyond the scope of this +manual. For this information, visit the Speakup web site at +http://linux-speakup.org/. The reason you'll need the kernel source +tree patched with Speakup is that the genmap utility you'll need for +processing keymaps is in the +/usr/src/linux-<version_number>/drivers/char/speakup directory. The +<version_number> in the above directory path is the version number of +the Linux source tree you are working with. + +So ok, you've gone off and gotten your kernel source tree, and patched +and configured it. Now you can start manipulating keymaps. + +You can either use the +/usr/src/linux-<version_number>/drivers/char/speakup/speakupmap.map file +included with the Speakup source, or you can cut and paste the copy in +section 4 into a separate file. If you use the one in the Speakup +source tree, make sure you make a backup of it before you start making +changes. You have been warned! + +Suppose that you want to swap the key assignments for the Speakup +say_last_char and the Speakup say_first_char commands. The +speakupmap.map lists the key mappings for these two commands as follows: + +spk key_pageup = say_first_char +spk key_pagedown = say_last_char + +You can edit your copy of the speakupmap.map file and swap the command +names on the right side of the = (equals) sign. You did make a backup, +right? The new keymap lines would look like this: + +spk key_pageup = say_last_char +spk key_pagedown = say_first_char + +After you edit your copy of the speakupmap.map file, save it under a new +file name, perhaps newmap.map. Then exit your editor and return to the +shell prompt. + +You are now ready to load your keymap with your swapped key assignments. + Assuming that you saved your new keymap as the file newmap.map, you +would load your keymap into the sys system like this: + +/usr/src/linux-<version_number>/drivers/char/speakup/genmap newmap.map +>/speakup/keymap + +Remember to substitute your kernel version number for the +<version_number> in the above command. Also note that although the +above command wrapped onto two lines in this document, you should type +it all on one line. + +Your say first and say last characters should now be swapped. Pressing +speakup pagedown should read you the first non-whitespace character on +the line your reading cursor is in, and pressing speakup pageup should +read you the last character on the line your reading cursor is in. + +You should note that these new mappings will only stay in effect until +you reboot, or until you load another keymap. + +One final warning. If you try to load a partial map, you will quickly +find that all the mappings you didn't include in your file got deleted +from the working map. Be extremely careful, and always make a backup! +You have been warned! + +14. Internationalizing Speakup + +Speakup indicates various conditions to the user by speaking messages. +For instance, when you move to the left edge of the screen with the +review keys, Speakup says, "left." +Prior to version 3.1.0 of Speakup, all of these messages were in English, +and they could not be changed. If you used a non-English synthesizer, +you still heard English messages, such as "left" and "cursoring on." +In version 3.1.0 or higher, one may load translations for the various +messages via the /sys filesystem. + +The directory /speakup/i18n contains several collections of messages. +Each group of messages is stored in its own file. +The following section lists all of these files, along with a brief description +of each. + +14.1. Files Under the i18n Subdirectory + +* announcements: +This file contains various general announcements, most of which cannot +be categorized. You will find messages such as "You killed Speakup", +"I'm alive", "leaving help", "parked", "unparked", and others. +You will also find the names of the screen edges and cursor tracking modes +here. + +* characters: +See section 12 for a description of this file. + +* chartab: +See section 12. Unlike the rest of the files in the i18n subdirectory, +this one does not contain messages to be spoken. + +* colors: +When you use the "say attributes" function, Speakup says the name of the +foreground and background colors. These names come from the i18n/colors +file. + +* ctl_keys: +Here, you will find names of control keys. These are used with Speakup's +say_control feature. + +* formatted: +This group of messages contains embedded formatting codes, to specify +the type and width of displayed data. If you change these, you must +preserve all of the formatting codes, and they must appear in the order +used by the default messages. + +* function_names: +Here, you will find a list of names for Speakup functions. These are used +by the help system. For example, suppose that you have activated help mode, +and you pressed keypad 3. Speakup says: +"keypad 3 is character, say next." +The message "character, say next" names a Speakup function, and it +comes from this function_names file. + +* key_names: +Again, key_names is used by Speakup's help system. In the previous +example, Speakup said that you pressed "keypad 3." +This name came from the key_names file. + +* states: +This file contains names for key states. +Again, these are part of the help system. For instance, if you had pressed +speakup + keypad 3, you would hear: +"speakup keypad 3 is go to bottom edge." +The speakup key is depressed, so the name of the key state is speakup. +This part of the message comes from the states collection. + +14.2. Loading Your Own Messages + +The files under the i18n subdirectory all follow the same format. +They consist of lines, with one message per line. +Each message is represented by a number, followed by the text of the message. +The number is the position of the message in the given collection. +For example, if you view the file /speakup/i18n/colors, you will see the +following list: + +0 black +1 blue +2 green +3 cyan +4 red +5 magenta +6 yellow +7 white +8 grey + +You can change one message, or you can change a whole group. +To load a whole collection of messages from a new source, simply use +the cp command: +cp ~/my_colors /speakup/i18n/colors +You can change an individual message with the echo command, +as shown in the following example. + +The Spanish name for the color blue is azul. +Looking at the colors file, we see that the name "blue" is at position 1 +within the colors group. Let's change blue to azul: +echo '1 azul' > /speakup/i18n/colors +The next time that Speakup says message 1 from the colors group, it will +say "azul", rather than "blue." + +In the future, translations into various languages will be made available, +and most users will just load the files necessary for their language. + +14.3. No Support for Non-Western-European Languages + +As of the current release, Speakup only supports Western European languages. +Support for the extended characters used by languages outside of the Western +European family of languages is a work in progress. + +15. Using Speakup's Windowing Capability + +Speakup has the capability of defining and manipulating windows on the +screen. Speakup uses the term "Window", to mean a user defined area of +the screen. The key strokes for defining and manipulating Speakup +windows are as follows: + +speakup + f2 -- Set the bounds of the window. +Speakup + f3 -- clear the current window definition. +speakup + f4 -- Toggle window silence on and off. +speakup + keypad plus -- Say the currently defined window. + +These capabilities are useful for tracking a certain part of the screen +without rereading the whole screen, or for silencing a part of the +screen that is constantly changing, such as a clock or status line. + +There is no way to save these window settings, and you can only have one +window defined for each virtual console. There is also no way to have +windows automatically defined for specific applications. + +In order to define a window, use the review keys to move your reading +cursor to the beginning of the area you want to define. Then press +speakup + f2. Speakup will tell you that the window starts at the +indicated row and column position. Then move the reading cursor to the +end of the area to be defined as a window, and press speakup + f2 again. + If there is more than one line in the window, Speakup will tell you +that the window ends at the indicated row and column position. If there +is only one line in the window, then Speakup will tell you that the +window is the specified line on the screen. If you are only defining a +one line window, you can just press speakup + f2 twice after placing the +reading cursor on the line you want to define as a window. It is not +necessary to position the reading cursor at the end of the line in order +to define the whole line as a window. + +16. Tools for Controlling Speakup + +The speakup distribution includes extra tools (in the tools directory) +which were written to make speakup easier to use. This section will +briefly describe the use of these tools. + +16.1. Speakupconf + +speakupconf began life as a contribution from Steve Holmes, a member of +the speakup community. We would like to thank him for his work on the +early versions of this project. + +This script may be installed as part of your linux distribution, but if +it isn't, the recommended places to put it are /usr/local/bin or +/usr/bin. This script can be run by any user, so it does not require +root privileges. + +Speakupconf allows you to save and load your Speakup settings. It works +by reading and writing the /sys files described above. + +The directory that speakupconf uses to store your settings depends on +whether it is run from the root account. If you execute speakupconf as +root, it uses the directory /etc/speakup. Otherwise, it uses the directory +~/.speakup, where ~ is your home directory. +Anyone who needs to use Speakup from your console can load his own custom +settings with this script. + +speakupconf takes one required argument: load or save. +Use the command +speakupconf save +to save your Speakup settings, and +speakupconf load +to load them into Speakup. +A second argument may be specified to use an alternate directory to +load or save the speakup parameters. + +16.2. Talkwith + +Charles Hallenbeck, another member of the speakup community, wrote the +initial versions of this script, and we would also like to thank him for +his work on it. + +This script needs root privileges to run, so if it is not installed as +part of your linux distribution, the recommended places to install it +are /usr/local/sbin or /usr/sbin. + +Talkwith allows you to switch synthesizers on the fly. It takes a synthesizer +name as an argument. For instance, +talkwith dectlk +causes Speakup to use the DecTalk Express. If you wish to switch to a +software synthesizer, you must also indicate which daemon you wish to +use. There are two possible choices: +spd and espeakup. spd is an abbreviation for speechd-up. +If you wish to use espeakup for software synthesis, give the command +talkwith soft espeakup +To use speechd-up, type: +talkwith soft spd +Any arguments that follow the name of the daemon are passed to the daemon +when it is invoked. For instance: +talkwith espeakup --default-voice=fr +causes espeakup to use the French voice. +Note that talkwith must always be executed with root privileges. + +Talkwith does not attempt to load your settings after the new +synthesizer is activated. You can use speakupconf to load your settings +if desired. + + GNU Free Documentation License + Version 1.2, November 2002 + + + Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + +0. PREAMBLE + +The purpose of this License is to make a manual, textbook, or other +functional and useful document "free" in the sense of freedom: to +assure everyone the effective freedom to copy and redistribute it, +with or without modifying it, either commercially or noncommercially. +Secondarily, this License preserves for the author and publisher a way +to get credit for their work, while not being considered responsible +for modifications made by others. + +This License is a kind of "copyleft", which means that derivative +works of the document must themselves be free in the same sense. It +complements the GNU General Public License, which is a copyleft +license designed for free software. + +We have designed this License in order to use it for manuals for free +software, because free software needs free documentation: a free +program should come with manuals providing the same freedoms that the +software does. But this License is not limited to software manuals; +it can be used for any textual work, regardless of subject matter or +whether it is published as a printed book. We recommend this License +principally for works whose purpose is instruction or reference. + + +1. APPLICABILITY AND DEFINITIONS + +This License applies to any manual or other work, in any medium, that +contains a notice placed by the copyright holder saying it can be +distributed under the terms of this License. Such a notice grants a +world-wide, royalty-free license, unlimited in duration, to use that +work under the conditions stated herein. The "Document", below, +refers to any such manual or work. Any member of the public is a +licensee, and is addressed as "you". You accept the license if you +copy, modify or distribute the work in a way requiring permission +under copyright law. + +A "Modified Version" of the Document means any work containing the +Document or a portion of it, either copied verbatim, or with +modifications and/or translated into another language. + +A "Secondary Section" is a named appendix or a front-matter section of +the Document that deals exclusively with the relationship of the +publishers or authors of the Document to the Document's overall subject +(or to related matters) and contains nothing that could fall directly +within that overall subject. (Thus, if the Document is in part a +textbook of mathematics, a Secondary Section may not explain any +mathematics.) The relationship could be a matter of historical +connection with the subject or with related matters, or of legal, +commercial, philosophical, ethical or political position regarding +them. + +The "Invariant Sections" are certain Secondary Sections whose titles +are designated, as being those of Invariant Sections, in the notice +that says that the Document is released under this License. If a +section does not fit the above definition of Secondary then it is not +allowed to be designated as Invariant. The Document may contain zero +Invariant Sections. If the Document does not identify any Invariant +Sections then there are none. + +The "Cover Texts" are certain short passages of text that are listed, +as Front-Cover Texts or Back-Cover Texts, in the notice that says that +the Document is released under this License. A Front-Cover Text may +be at most 5 words, and a Back-Cover Text may be at most 25 words. + +A "Transparent" copy of the Document means a machine-readable copy, +represented in a format whose specification is available to the +general public, that is suitable for revising the document +straightforwardly with generic text editors or (for images composed of +pixels) generic paint programs or (for drawings) some widely available +drawing editor, and that is suitable for input to text formatters or +for automatic translation to a variety of formats suitable for input +to text formatters. A copy made in an otherwise Transparent file +format whose markup, or absence of markup, has been arranged to thwart +or discourage subsequent modification by readers is not Transparent. +An image format is not Transparent if used for any substantial amount +of text. A copy that is not "Transparent" is called "Opaque". + +Examples of suitable formats for Transparent copies include plain +ASCII without markup, Texinfo input format, LaTeX input format, SGML +or XML using a publicly available DTD, and standard-conforming simple +HTML, PostScript or PDF designed for human modification. Examples of +transparent image formats include PNG, XCF and JPG. Opaque formats +include proprietary formats that can be read and edited only by +proprietary word processors, SGML or XML for which the DTD and/or +processing tools are not generally available, and the +machine-generated HTML, PostScript or PDF produced by some word +processors for output purposes only. + +The "Title Page" means, for a printed book, the title page itself, +plus such following pages as are needed to hold, legibly, the material +this License requires to appear in the title page. For works in +formats which do not have any title page as such, "Title Page" means +the text near the most prominent appearance of the work's title, +preceding the beginning of the body of the text. + +A section "Entitled XYZ" means a named subunit of the Document whose +title either is precisely XYZ or contains XYZ in parentheses following +text that translates XYZ in another language. (Here XYZ stands for a +specific section name mentioned below, such as "Acknowledgements", +"Dedications", "Endorsements", or "History".) To "Preserve the Title" +of such a section when you modify the Document means that it remains a +section "Entitled XYZ" according to this definition. + +The Document may include Warranty Disclaimers next to the notice which +states that this License applies to the Document. These Warranty +Disclaimers are considered to be included by reference in this +License, but only as regards disclaiming warranties: any other +implication that these Warranty Disclaimers may have is void and has +no effect on the meaning of this License. + + +2. VERBATIM COPYING + +You may copy and distribute the Document in any medium, either +commercially or noncommercially, provided that this License, the +copyright notices, and the license notice saying this License applies +to the Document are reproduced in all copies, and that you add no other +conditions whatsoever to those of this License. You may not use +technical measures to obstruct or control the reading or further +copying of the copies you make or distribute. However, you may accept +compensation in exchange for copies. If you distribute a large enough +number of copies you must also follow the conditions in section 3. + +You may also lend copies, under the same conditions stated above, and +you may publicly display copies. + + +3. COPYING IN QUANTITY + +If you publish printed copies (or copies in media that commonly have +printed covers) of the Document, numbering more than 100, and the +Document's license notice requires Cover Texts, you must enclose the +copies in covers that carry, clearly and legibly, all these Cover +Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on +the back cover. Both covers must also clearly and legibly identify +you as the publisher of these copies. The front cover must present +the full title with all words of the title equally prominent and +visible. You may add other material on the covers in addition. +Copying with changes limited to the covers, as long as they preserve +the title of the Document and satisfy these conditions, can be treated +as verbatim copying in other respects. + +If the required texts for either cover are too voluminous to fit +legibly, you should put the first ones listed (as many as fit +reasonably) on the actual cover, and continue the rest onto adjacent +pages. + +If you publish or distribute Opaque copies of the Document numbering +more than 100, you must either include a machine-readable Transparent +copy along with each Opaque copy, or state in or with each Opaque copy +a computer-network location from which the general network-using +public has access to download using public-standard network protocols +a complete Transparent copy of the Document, free of added material. +If you use the latter option, you must take reasonably prudent steps, +when you begin distribution of Opaque copies in quantity, to ensure +that this Transparent copy will remain thus accessible at the stated +location until at least one year after the last time you distribute an +Opaque copy (directly or through your agents or retailers) of that +edition to the public. + +It is requested, but not required, that you contact the authors of the +Document well before redistributing any large number of copies, to give +them a chance to provide you with an updated version of the Document. + + +4. MODIFICATIONS + +You may copy and distribute a Modified Version of the Document under +the conditions of sections 2 and 3 above, provided that you release +the Modified Version under precisely this License, with the Modified +Version filling the role of the Document, thus licensing distribution +and modification of the Modified Version to whoever possesses a copy +of it. In addition, you must do these things in the Modified Version: + +A. Use in the Title Page (and on the covers, if any) a title distinct + from that of the Document, and from those of previous versions + (which should, if there were any, be listed in the History section + of the Document). You may use the same title as a previous version + if the original publisher of that version gives permission. +B. List on the Title Page, as authors, one or more persons or entities + responsible for authorship of the modifications in the Modified + Version, together with at least five of the principal authors of the + Document (all of its principal authors, if it has fewer than five), + unless they release you from this requirement. +C. State on the Title page the name of the publisher of the + Modified Version, as the publisher. +D. Preserve all the copyright notices of the Document. +E. Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. +F. Include, immediately after the copyright notices, a license notice + giving the public permission to use the Modified Version under the + terms of this License, in the form shown in the Addendum below. +G. Preserve in that license notice the full lists of Invariant Sections + and required Cover Texts given in the Document's license notice. +H. Include an unaltered copy of this License. +I. Preserve the section Entitled "History", Preserve its Title, and add + to it an item stating at least the title, year, new authors, and + publisher of the Modified Version as given on the Title Page. If + there is no section Entitled "History" in the Document, create one + stating the title, year, authors, and publisher of the Document as + given on its Title Page, then add an item describing the Modified + Version as stated in the previous sentence. +J. Preserve the network location, if any, given in the Document for + public access to a Transparent copy of the Document, and likewise + the network locations given in the Document for previous versions + it was based on. These may be placed in the "History" section. + You may omit a network location for a work that was published at + least four years before the Document itself, or if the original + publisher of the version it refers to gives permission. +K. For any section Entitled "Acknowledgements" or "Dedications", + Preserve the Title of the section, and preserve in the section all + the substance and tone of each of the contributor acknowledgements + and/or dedications given therein. +L. Preserve all the Invariant Sections of the Document, + unaltered in their text and in their titles. Section numbers + or the equivalent are not considered part of the section titles. +M. Delete any section Entitled "Endorsements". Such a section + may not be included in the Modified Version. +N. Do not retitle any existing section to be Entitled "Endorsements" + or to conflict in title with any Invariant Section. +O. Preserve any Warranty Disclaimers. + +If the Modified Version includes new front-matter sections or +appendices that qualify as Secondary Sections and contain no material +copied from the Document, you may at your option designate some or all +of these sections as invariant. To do this, add their titles to the +list of Invariant Sections in the Modified Version's license notice. +These titles must be distinct from any other section titles. + +You may add a section Entitled "Endorsements", provided it contains +nothing but endorsements of your Modified Version by various +parties--for example, statements of peer review or that the text has +been approved by an organization as the authoritative definition of a +standard. + +You may add a passage of up to five words as a Front-Cover Text, and a +passage of up to 25 words as a Back-Cover Text, to the end of the list +of Cover Texts in the Modified Version. Only one passage of +Front-Cover Text and one of Back-Cover Text may be added by (or +through arrangements made by) any one entity. If the Document already +includes a cover text for the same cover, previously added by you or +by arrangement made by the same entity you are acting on behalf of, +you may not add another; but you may replace the old one, on explicit +permission from the previous publisher that added the old one. + +The author(s) and publisher(s) of the Document do not by this License +give permission to use their names for publicity for or to assert or +imply endorsement of any Modified Version. + + +5. COMBINING DOCUMENTS + +You may combine the Document with other documents released under this +License, under the terms defined in section 4 above for modified +versions, provided that you include in the combination all of the +Invariant Sections of all of the original documents, unmodified, and +list them all as Invariant Sections of your combined work in its +license notice, and that you preserve all their Warranty Disclaimers. + +The combined work need only contain one copy of this License, and +multiple identical Invariant Sections may be replaced with a single +copy. If there are multiple Invariant Sections with the same name but +different contents, make the title of each such section unique by +adding at the end of it, in parentheses, the name of the original +author or publisher of that section if known, or else a unique number. +Make the same adjustment to the section titles in the list of +Invariant Sections in the license notice of the combined work. + +In the combination, you must combine any sections Entitled "History" +in the various original documents, forming one section Entitled +"History"; likewise combine any sections Entitled "Acknowledgements", +and any sections Entitled "Dedications". You must delete all sections +Entitled "Endorsements". + + +6. COLLECTIONS OF DOCUMENTS + +You may make a collection consisting of the Document and other documents +released under this License, and replace the individual copies of this +License in the various documents with a single copy that is included in +the collection, provided that you follow the rules of this License for +verbatim copying of each of the documents in all other respects. + +You may extract a single document from such a collection, and distribute +it individually under this License, provided you insert a copy of this +License into the extracted document, and follow this License in all +other respects regarding verbatim copying of that document. + + +7. AGGREGATION WITH INDEPENDENT WORKS + +A compilation of the Document or its derivatives with other separate +and independent documents or works, in or on a volume of a storage or +distribution medium, is called an "aggregate" if the copyright +resulting from the compilation is not used to limit the legal rights +of the compilation's users beyond what the individual works permit. +When the Document is included in an aggregate, this License does not +apply to the other works in the aggregate which are not themselves +derivative works of the Document. + +If the Cover Text requirement of section 3 is applicable to these +copies of the Document, then if the Document is less than one half of +the entire aggregate, the Document's Cover Texts may be placed on +covers that bracket the Document within the aggregate, or the +electronic equivalent of covers if the Document is in electronic form. +Otherwise they must appear on printed covers that bracket the whole +aggregate. + + +8. TRANSLATION + +Translation is considered a kind of modification, so you may +distribute translations of the Document under the terms of section 4. +Replacing Invariant Sections with translations requires special +permission from their copyright holders, but you may include +translations of some or all Invariant Sections in addition to the +original versions of these Invariant Sections. You may include a +translation of this License, and all the license notices in the +Document, and any Warranty Disclaimers, provided that you also include +the original English version of this License and the original versions +of those notices and disclaimers. In case of a disagreement between +the translation and the original version of this License or a notice +or disclaimer, the original version will prevail. + +If a section in the Document is Entitled "Acknowledgements", +"Dedications", or "History", the requirement (section 4) to Preserve +its Title (section 1) will typically require changing the actual +title. + + +9. TERMINATION + +You may not copy, modify, sublicense, or distribute the Document except +as expressly provided for under this License. Any other attempt to +copy, modify, sublicense or distribute the Document is void, and will +automatically terminate your rights under this License. However, +parties who have received copies, or rights, from you under this +License will not have their licenses terminated so long as such +parties remain in full compliance. + + +10. FUTURE REVISIONS OF THIS LICENSE + +The Free Software Foundation may publish new, revised versions +of the GNU Free Documentation License from time to time. Such new +versions will be similar in spirit to the present version, but may +differ in detail to address new problems or concerns. See +https://www.gnu.org/copyleft/. + +Each version of the License is given a distinguishing version number. +If the Document specifies that a particular numbered version of this +License "or any later version" applies to it, you have the option of +following the terms and conditions either of that specified version or +of any later version that has been published (not as a draft) by the +Free Software Foundation. If the Document does not specify a version +number of this License, you may choose any version ever published (not +as a draft) by the Free Software Foundation. + + +ADDENDUM: How to use this License for your documents + +To use this License in a document you have written, include a copy of +the License in the document and put the following copyright and +license notices just after the title page: + + Copyright (c) YEAR YOUR NAME. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.2 + or any later version published by the Free Software Foundation; + with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. + A copy of the license is included in the section entitled "GNU + Free Documentation License". + +If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, +replace the "with...Texts." line with this: + + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. + +If you have Invariant Sections without Cover Texts, or some other +combination of the three, merge those two alternatives to suit the +situation. + +If your document contains nontrivial examples of program code, we +recommend releasing these examples in parallel under your choice of +free software license, such as the GNU General Public License, +to permit their use in free software. + +The End. diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 2ae9669eb22c..d4b32cc32bb7 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -164,7 +164,8 @@ core_pattern %s signal number %t UNIX time of dump %h hostname - %e executable filename (may be shortened) + %e executable filename (may be shortened, could be changed by prctl etc) + %f executable filename %E executable path %c maximum size of core file by resource limit RLIMIT_CORE %<OTHER> both are dropped diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index d997cc3c26d0..4b9d2e8e9142 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -119,6 +119,21 @@ all zones are compacted such that free memory is available in contiguous blocks where possible. This can be important for example in the allocation of huge pages although processes will also directly compact memory as required. +compaction_proactiveness +======================== + +This tunable takes a value in the range [0, 100] with a default value of +20. This tunable determines how aggressively compaction is done in the +background. Setting it to 0 disables proactive compaction. + +Note that compaction has a non-trivial system-wide impact as pages +belonging to different processes are moved around, which could also lead +to latency spikes in unsuspecting applications. The kernel employs +various heuristics to avoid wasting CPU cycles if it detects that +proactive compaction is not being effective. + +Be careful when setting it to extreme values like 100, as that may +cause excessive background compaction activity. compact_unevictable_allowed =========================== diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 3f7c3a7e8a2b..d3587805de64 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -125,6 +125,9 @@ stable kernels. | Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| Marvell | ARM-MMU-500 | #582743 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/cdrom/cdrom-standard.rst b/Documentation/cdrom/cdrom-standard.rst index 2de905810590..70500b189cc8 100644 --- a/Documentation/cdrom/cdrom-standard.rst +++ b/Documentation/cdrom/cdrom-standard.rst @@ -557,7 +557,7 @@ phase. Currently, the capabilities are any of:: CDC_DRIVE_STATUS /* driver implements drive status */ The capability flag is declared *const*, to prevent drivers from -accidentally tampering with the contents. The capability fags actually +accidentally tampering with the contents. The capability flags actually inform `cdrom.c` of what the driver can do. If the drive found by the driver does not have the capability, is can be masked out by the *cdrom_device_info* variable *mask*. For instance, the SCSI CD-ROM @@ -736,7 +736,7 @@ Description of routines in `cdrom.c` Only a few routines in `cdrom.c` are exported to the drivers. In this new section we will discuss these, as well as the functions that `take -over' the CD-ROM interface to the kernel. The header file belonging +over` the CD-ROM interface to the kernel. The header file belonging to `cdrom.c` is called `cdrom.h`. Formerly, some of the contents of this file were placed in the file `ucdrom.h`, but this file has now been merged back into `cdrom.h`. diff --git a/Documentation/core-api/cpu_hotplug.rst b/Documentation/core-api/cpu_hotplug.rst index f64668759b6a..298c9c8bea9a 100644 --- a/Documentation/core-api/cpu_hotplug.rst +++ b/Documentation/core-api/cpu_hotplug.rst @@ -50,13 +50,6 @@ Command Line Switches This option is limited to the X86 and S390 architecture. -``cede_offline={"off","on"}`` - Use this option to disable/enable putting offlined processors to an extended - ``H_CEDE`` state on supported pseries platforms. If nothing is specified, - ``cede_offline`` is set to "on". - - This option is limited to the PowerPC architecture. - ``cpu0_hotplug`` Allow to shutdown CPU0. diff --git a/Documentation/core-api/idr.rst b/Documentation/core-api/idr.rst index a2738050c4f0..2eb5afdb9931 100644 --- a/Documentation/core-api/idr.rst +++ b/Documentation/core-api/idr.rst @@ -20,48 +20,48 @@ only ID allocation, and as a result is much more memory-efficient. IDR usage ========= -Start by initialising an IDR, either with :c:func:`DEFINE_IDR` -for statically allocated IDRs or :c:func:`idr_init` for dynamically +Start by initialising an IDR, either with DEFINE_IDR() +for statically allocated IDRs or idr_init() for dynamically allocated IDRs. -You can call :c:func:`idr_alloc` to allocate an unused ID. Look up -the pointer you associated with the ID by calling :c:func:`idr_find` -and free the ID by calling :c:func:`idr_remove`. +You can call idr_alloc() to allocate an unused ID. Look up +the pointer you associated with the ID by calling idr_find() +and free the ID by calling idr_remove(). If you need to change the pointer associated with an ID, you can call -:c:func:`idr_replace`. One common reason to do this is to reserve an +idr_replace(). One common reason to do this is to reserve an ID by passing a ``NULL`` pointer to the allocation function; initialise the object with the reserved ID and finally insert the initialised object into the IDR. Some users need to allocate IDs larger than ``INT_MAX``. So far all of these users have been content with a ``UINT_MAX`` limit, and they use -:c:func:`idr_alloc_u32`. If you need IDs that will not fit in a u32, +idr_alloc_u32(). If you need IDs that will not fit in a u32, we will work with you to address your needs. If you need to allocate IDs sequentially, you can use -:c:func:`idr_alloc_cyclic`. The IDR becomes less efficient when dealing +idr_alloc_cyclic(). The IDR becomes less efficient when dealing with larger IDs, so using this function comes at a slight cost. To perform an action on all pointers used by the IDR, you can -either use the callback-based :c:func:`idr_for_each` or the -iterator-style :c:func:`idr_for_each_entry`. You may need to use -:c:func:`idr_for_each_entry_continue` to continue an iteration. You can -also use :c:func:`idr_get_next` if the iterator doesn't fit your needs. +either use the callback-based idr_for_each() or the +iterator-style idr_for_each_entry(). You may need to use +idr_for_each_entry_continue() to continue an iteration. You can +also use idr_get_next() if the iterator doesn't fit your needs. -When you have finished using an IDR, you can call :c:func:`idr_destroy` +When you have finished using an IDR, you can call idr_destroy() to release the memory used by the IDR. This will not free the objects pointed to from the IDR; if you want to do that, use one of the iterators to do it. -You can use :c:func:`idr_is_empty` to find out whether there are any +You can use idr_is_empty() to find out whether there are any IDs currently allocated. If you need to take a lock while allocating a new ID from the IDR, you may need to pass a restrictive set of GFP flags, which can lead to the IDR being unable to allocate memory. To work around this, -you can call :c:func:`idr_preload` before taking the lock, and then -:c:func:`idr_preload_end` after the allocation. +you can call idr_preload() before taking the lock, and then +idr_preload_end() after the allocation. .. kernel-doc:: include/linux/idr.h :doc: idr sync diff --git a/Documentation/dev-tools/coccinelle.rst b/Documentation/dev-tools/coccinelle.rst index 6c791af1c859..74c5e6aeeff5 100644 --- a/Documentation/dev-tools/coccinelle.rst +++ b/Documentation/dev-tools/coccinelle.rst @@ -175,13 +175,20 @@ For example, to check drivers/net/wireless/ one may write:: make coccicheck M=drivers/net/wireless/ To apply Coccinelle on a file basis, instead of a directory basis, the -following command may be used:: +C variable is used by the makefile to select which files to work with. +This variable can be used to run scripts for the entire kernel, a +specific directory, or for a single file. - make C=1 CHECK="scripts/coccicheck" +For example, to check drivers/bluetooth/bfusb.c, the value 1 is +passed to the C variable to check files that make considers +need to be compiled.:: -To check only newly edited code, use the value 2 for the C flag, i.e.:: + make C=1 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o - make C=2 CHECK="scripts/coccicheck" +The value 2 is passed to the C variable to check files regardless of +whether they need to be compiled or not.:: + + make C=2 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o In these modes, which work on a file basis, there is no information about semantic patches displayed, and no commit message proposed. diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c652d740735d..38fd5681fade 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -13,11 +13,8 @@ KASAN uses compile-time instrumentation to insert validity checks before every memory access, and therefore requires a compiler version that supports that. Generic KASAN is supported in both GCC and Clang. With GCC it requires version -4.9.2 or later for basic support and version 5.0 or later for detection of -out-of-bounds accesses for stack and global variables and for inline -instrumentation mode (see the Usage section). With Clang it requires version -7.0.0 or later and it doesn't support detection of out-of-bounds accesses for -global variables yet. +8.3.0 or later. With Clang it requires version 7.0.0 or later, but detection of +out-of-bounds accesses for global variables is only supported since Clang 11. Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later. @@ -193,6 +190,9 @@ function calls GCC directly inserts the code to check the shadow memory. This option significantly enlarges kernel but it gives x1.1-x2 performance boost over outline instrumented kernel. +Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one +and the second to last. + Software tag-based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst index 0e52e966a153..c908ef4d3f04 100644 --- a/Documentation/dev-tools/kgdb.rst +++ b/Documentation/dev-tools/kgdb.rst @@ -316,7 +316,7 @@ driver as a loadable kernel module kgdbwait will not do anything. Kernel parameter: ``kgdbcon`` ----------------------------- -The ``kgdbcon`` feature allows you to see :c:func:`printk` messages inside gdb +The ``kgdbcon`` feature allows you to see printk() messages inside gdb while gdb is connected to the kernel. Kdb does not make use of the kgdbcon feature. @@ -432,7 +432,7 @@ This is a quick example of how to use kdb. ``ps`` Displays only the active processes ``ps A`` Shows all the processes ``summary`` Shows kernel version info and memory usage - ``bt`` Get a backtrace of the current process using :c:func:`dump_stack` + ``bt`` Get a backtrace of the current process using dump_stack() ``dmesg`` View the kernel syslog buffer ``go`` Continue the system =========== ================================================================= @@ -724,7 +724,7 @@ The kernel debugger is organized into a number of components: The arch-specific portion implements: - contains an arch-specific trap catcher which invokes - :c:func:`kgdb_handle_exception` to start kgdb about doing its work + kgdb_handle_exception() to start kgdb about doing its work - translation to and from gdb specific packet format to :c:type:`pt_regs` @@ -769,7 +769,7 @@ The kernel debugger is organized into a number of components: config. Later run ``modprobe kdb_hello`` and the next time you enter the kdb shell, you can run the ``hello`` command. - - The implementation for :c:func:`kdb_printf` which emits messages directly + - The implementation for kdb_printf() which emits messages directly to I/O drivers, bypassing the kernel log. - SW / HW breakpoint management for the kdb shell @@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration. The core polled keyboard driver for PS/2 type keyboards is in ``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core when kgdboc populates the callback in the array called -:c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level +:c:type:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level function which polls hardware for single character input. kgdboc and kms @@ -887,10 +887,10 @@ that you have a video driver which has a frame buffer console and atomic kernel mode setting support. Every time the kernel debugger is entered it calls -:c:func:`kgdboc_pre_exp_handler` which in turn calls :c:func:`con_debug_enter` +kgdboc_pre_exp_handler() which in turn calls con_debug_enter() in the virtual console layer. On resuming kernel execution, the kernel -debugger calls :c:func:`kgdboc_post_exp_handler` which in turn calls -:c:func:`con_debug_leave`. +debugger calls kgdboc_post_exp_handler() which in turn calls +con_debug_leave(). Any video driver that wants to be compatible with the kernel debugger and the atomic kms callbacks must implement the ``mode_set_base_atomic``, diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt index 1f293ea24cd8..55deb68230eb 100644 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scmi.txt @@ -102,7 +102,7 @@ Required sub-node properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/power/power-domain.yaml -[3] Documentation/devicetree/bindings/thermal/thermal.txt +[3] Documentation/devicetree/bindings/thermal/thermal*.yaml [4] Documentation/devicetree/bindings/sram/sram.yaml [5] Documentation/devicetree/bindings/reset/reset.txt diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index dd04d9d9a1b8..bcd6c3ec471e 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -108,7 +108,7 @@ Required properties: [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/thermal/thermal.txt +[2] Documentation/devicetree/bindings/thermal/thermal*.yaml [3] Documentation/devicetree/bindings/sram/sram.yaml [4] Documentation/devicetree/bindings/power/power-domain.yaml diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt deleted file mode 100644 index 6824b3180ffb..000000000000 --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt +++ /dev/null @@ -1,14 +0,0 @@ -Raspberry Pi VideoCore firmware driver - -Required properties: - -- compatible: Should be "raspberrypi,bcm2835-firmware" -- mboxes: Phandle to the firmware device's Mailbox. - (See: ../mailbox/mailbox.txt for more information) - -Example: - -firmware { - compatible = "raspberrypi,bcm2835-firmware"; - mboxes = <&mailbox>; -}; diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml new file mode 100644 index 000000000000..17e4f20c8d39 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Raspberry Pi VideoCore firmware driver + +maintainers: + - Eric Anholt <eric@anholt.net> + - Stefan Wahren <wahrenst@gmx.net> + +select: + properties: + compatible: + contains: + const: raspberrypi,bcm2835-firmware + + required: + - compatible + +properties: + compatible: + items: + - const: raspberrypi,bcm2835-firmware + - const: simple-bus + + mboxes: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Phandle to the firmware device's Mailbox. + (See: ../mailbox/mailbox.txt for more information) + + clocks: + type: object + + properties: + compatible: + const: raspberrypi,firmware-clocks + + "#clock-cells": + const: 1 + description: > + The argument is the ID of the clocks contained by the + firmware messages. + + required: + - compatible + - "#clock-cells" + + additionalProperties: false + +required: + - compatible + - mboxes + +examples: + - | + firmware { + compatible = "raspberrypi,bcm2835-firmware", "simple-bus"; + mboxes = <&mailbox>; + + firmware_clocks: clocks { + compatible = "raspberrypi,firmware-clocks"; + #clock-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 10b8459e49f8..6064d98b1031 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -176,7 +176,7 @@ Required properties: "fsl,imx8qxp-sc-thermal" followed by "fsl,imx-sc-thermal"; -- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt +- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example (imx8qxp): diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml new file mode 100644 index 000000000000..7597bc93a55f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common K3 TI-SCI bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +description: | + The TI K3 family of SoCs usually have a central System Controller Processor + that is responsible for managing various SoC-level resources like clocks, + resets, interrupts etc. The communication with that processor is performed + through the TI-SCI protocol. + + Each specific device management node like a clock controller node, a reset + controller node or an interrupt-controller node should define a common set + of properties that enables them to implement the corresponding functionality + over the TI-SCI protocol. The following are some of the common properties + needed by such individual nodes. The required properties for each device + management node is defined in the respective binding. + +properties: + ti,sci: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Should be a phandle to the TI-SCI System Controller node + + ti,sci-dev-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Should contain the TI-SCI device id corresponding to the device. Please + refer to the corresponding System Controller documentation for valid + values for the desired device. + + ti,sci-proc-ids: + description: Should contain a single tuple of <proc_id host_id>. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: TI-SCI processor id for the remote processor device + - description: TI-SCI host id to which processor control ownership + should be transferred to diff --git a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt index 098d932fc963..e31511255d8e 100644 --- a/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/ap80x-system-controller.txt @@ -111,7 +111,7 @@ Thermal: -------- For common binding part and usage, refer to -Documentation/devicetree/bindings/thermal/thermal.txt +Documentation/devicetree/bindings/thermal/thermal*.yaml The thermal IP can probe the temperature all around the processor. It may feature several channels, each of them wired to one sensor. diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt index f982a8ed9396..a21f7709596c 100644 --- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt @@ -203,7 +203,7 @@ It is possible to setup an overheat interrupt by giving at least one critical point to any subnode of the thermal-zone node. For common binding part and usage, refer to -Documentation/devicetree/bindings/thermal/thermal.txt +Documentation/devicetree/bindings/thermal/thermal*.yaml Required properties: - compatible: must be one of: diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml new file mode 100644 index 000000000000..1043e4be4fca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra194 CPU Complex device tree bindings + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jonathan Hunter <jonathanh@nvidia.com> + - Sumit Gupta <sumitg@nvidia.com> + +description: |+ + Tegra194 SOC has homogeneous architecture where each cluster has two + symmetric cores. Compatible string in "cpus" node represents the CPU + Complex having all clusters. + +properties: + $nodename: + const: cpus + + compatible: + enum: + - nvidia,tegra194-ccplex + + nvidia,bpmp: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Specifies the bpmp node that needs to be queried to get + operating point data for all CPUs. + +examples: + - | + cpus { + compatible = "nvidia,tegra194-ccplex"; + nvidia,bpmp = <&bpmp>; + #address-cells = <1>; + #size-cells = <0>; + + cpu0_0: cpu@0 { + compatible = "nvidia,tegra194-carmel"; + device_type = "cpu"; + reg = <0x0>; + enable-method = "psci"; + }; + + cpu0_1: cpu@1 { + compatible = "nvidia,tegra194-carmel"; + device_type = "cpu"; + reg = <0x001>; + enable-method = "psci"; + }; + + cpu1_0: cpu@100 { + compatible = "nvidia,tegra194-carmel"; + device_type = "cpu"; + reg = <0x100>; + enable-method = "psci"; + }; + + cpu1_1: cpu@101 { + compatible = "nvidia,tegra194-carmel"; + device_type = "cpu"; + reg = <0x101>; + enable-method = "psci"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml new file mode 100644 index 000000000000..08543ecbe35b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/brcm,bcm2711-dvp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2711 HDMI DVP Device Tree Bindings + +maintainers: + - Maxime Ripard <mripard@kernel.org> + +properties: + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + compatible: + const: brcm,brcm2711-dvp + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - "#clock-cells" + - "#reset-cells" + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + dvp: clock@7ef00000 { + compatible = "brcm,brcm2711-dvp"; + reg = <0x7ef00000 0x10>; + clocks = <&clk_108MHz>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt index 3041657e2f96..3e7ca5530775 100644 --- a/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt +++ b/Documentation/devicetree/bindings/clock/brcm,bcm63xx-clocks.txt @@ -3,6 +3,8 @@ Gated Clock Controller Bindings for MIPS based BCM63XX SoCs Required properties: - compatible: must be one of: "brcm,bcm3368-clocks" + "brcm,bcm6318-clocks" + "brcm,bcm6318-ubus-clocks" "brcm,bcm6328-clocks" "brcm,bcm6358-clocks" "brcm,bcm6362-clocks" diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt index 8a55fdcf96ee..f2ea53832ac6 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -9,7 +9,7 @@ specifier is an array of zero, one or more cells identifying the clock output on a device. The length of a clock specifier is defined by the value of a #clock-cells property in the clock provider node. -[1] http://patchwork.ozlabs.org/patch/31551/ +[1] https://patchwork.ozlabs.org/patch/31551/ ==Clock providers== diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt deleted file mode 100644 index bcff681a4bd0..000000000000 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt +++ /dev/null @@ -1,92 +0,0 @@ -Binding for IDT VersaClock 5,6 programmable i2c clock generators. - -The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock -generators providing from 3 to 12 output clocks. - -==I2C device node== - -Required properties: -- compatible: shall be one of - "idt,5p49v5923" - "idt,5p49v5925" - "idt,5p49v5933" - "idt,5p49v5935" - "idt,5p49v6901" - "idt,5p49v6965" -- reg: i2c device address, shall be 0x68 or 0x6a. -- #clock-cells: from common clock binding; shall be set to 1. -- clocks: from common clock binding; list of parent clock handles, - - 5p49v5923 and - 5p49v5925 and - 5p49v6901: (required) either or both of XTAL or CLKIN - reference clock. - - 5p49v5933 and - - 5p49v5935: (optional) property not present (internal - Xtal used) or CLKIN reference - clock. -- clock-names: from common clock binding; clock input names, can be - - 5p49v5923 and - 5p49v5925 and - 5p49v6901: (required) either or both of "xin", "clkin". - - 5p49v5933 and - - 5p49v5935: (optional) property not present or "clkin". - -==Mapping between clock specifier and physical pins== - -When referencing the provided clock in the DT using phandle and -clock specifier, the following mapping applies: - -5P49V5923: - 0 -- OUT0_SEL_I2CB - 1 -- OUT1 - 2 -- OUT2 - -5P49V5933: - 0 -- OUT0_SEL_I2CB - 1 -- OUT1 - 2 -- OUT4 - -5P49V5925 and -5P49V5935: - 0 -- OUT0_SEL_I2CB - 1 -- OUT1 - 2 -- OUT2 - 3 -- OUT3 - 4 -- OUT4 - -5P49V6901: - 0 -- OUT0_SEL_I2CB - 1 -- OUT1 - 2 -- OUT2 - 3 -- OUT3 - 4 -- OUT4 - -==Example== - -/* 25MHz reference crystal */ -ref25: ref25m { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <25000000>; -}; - -i2c-master-node { - - /* IDT 5P49V5923 i2c clock generator */ - vc5: clock-generator@6a { - compatible = "idt,5p49v5923"; - reg = <0x6a>; - #clock-cells = <1>; - - /* Connect XIN input to 25MHz reference */ - clocks = <&ref25m>; - clock-names = "xin"; - }; -}; - -/* Consumer referencing the 5P49V5923 pin OUT1 */ -consumer { - ... - clocks = <&vc5 1>; - ... -} diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml new file mode 100644 index 000000000000..3d4e1685cc55 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/idt,versaclock5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for IDT VersaClock 5 and 6 programmable I2C clock generators + +description: | + The IDT VersaClock 5 and VersaClock 6 are programmable I2C + clock generators providing from 3 to 12 output clocks. + + When referencing the provided clock in the DT using phandle and clock + specifier, the following mapping applies: + + - 5P49V5923: + 0 -- OUT0_SEL_I2CB + 1 -- OUT1 + 2 -- OUT2 + + - 5P49V5933: + 0 -- OUT0_SEL_I2CB + 1 -- OUT1 + 2 -- OUT4 + + - other parts: + 0 -- OUT0_SEL_I2CB + 1 -- OUT1 + 2 -- OUT2 + 3 -- OUT3 + 4 -- OUT4 + +maintainers: + - Luca Ceresoli <luca@lucaceresoli.net> + +properties: + compatible: + enum: + - idt,5p49v5923 + - idt,5p49v5925 + - idt,5p49v5933 + - idt,5p49v5935 + - idt,5p49v6901 + - idt,5p49v6965 + + reg: + description: I2C device address + enum: [ 0x68, 0x6a ] + + '#clock-cells': + const: 1 + +patternProperties: + "^OUT[1-4]$": + type: object + description: + Description of one of the outputs (OUT1..OUT4). See "Clock1 Output + Configuration" in the Versaclock 5/6/6E Family Register Description + and Programming Guide. + properties: + idt,mode: + description: + The output drive mode. Values defined in dt-bindings/clk/versaclock.h + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 6 + idt,voltage-microvolt: + description: The output drive voltage. + enum: [ 1800000, 2500000, 3300000 ] + idt,slew-percent: + description: The Slew rate control for CMOS single-ended. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 80, 85, 90, 100 ] + +required: + - compatible + - reg + - '#clock-cells' + +allOf: + - if: + properties: + compatible: + enum: + - idt,5p49v5933 + - idt,5p49v5935 + then: + # Devices with builtin crystal + optional external input + properties: + clock-names: + const: clkin + clocks: + maxItems: 1 + else: + # Devices without builtin crystal + properties: + clock-names: + minItems: 1 + maxItems: 2 + items: + enum: [ xin, clkin ] + clocks: + minItems: 1 + maxItems: 2 + required: + - clock-names + - clocks + +examples: + - | + #include <dt-bindings/clk/versaclock.h> + + /* 25MHz reference crystal */ + ref25: ref25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + }; + + i2c@0 { + reg = <0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + + /* IDT 5P49V5923 I2C clock generator */ + vc5: clock-generator@6a { + compatible = "idt,5p49v5923"; + reg = <0x6a>; + #clock-cells = <1>; + + /* Connect XIN input to 25MHz reference */ + clocks = <&ref25m>; + clock-names = "xin"; + + OUT1 { + idt,drive-mode = <VC5_CMOSD>; + idt,voltage-microvolts = <1800000>; + idt,slew-percent = <80>; + }; + + OUT4 { + idt,drive-mode = <VC5_LVDS>; + }; + }; + }; + + /* Consumer referencing the 5P49V5923 pin OUT1 */ + consumer { + /* ... */ + clocks = <&vc5 1>; + /* ... */ + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index 20d2638b4cd2..db3d0ea6bc7a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -15,7 +15,9 @@ description: properties: compatible: - const: qcom,msm8916-a53pll + enum: + - qcom,ipq6018-a53pll + - qcom,msm8916-a53pll reg: maxItems: 1 @@ -23,6 +25,14 @@ properties: '#clock-cells': const: 0 + clocks: + items: + - description: board XO clock + + clock-names: + items: + - const: xo + required: - compatible - reg @@ -38,3 +48,12 @@ examples: reg = <0xb016000 0x40>; #clock-cells = <0>; }; + #Example 2 - A53 PLL found on IPQ6018 devices + - | + a53pll_ipq: clock-controller@b116000 { + compatible = "qcom,ipq6018-a53pll"; + reg = <0x0b116000 0x40>; + #clock-cells = <0>; + clocks = <&xo>; + clock-names = "xo"; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 8a0c576ba8b3..df943c4c3234 100644 --- a/Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -1,23 +1,31 @@ # SPDX-License-Identifier: GPL-2.0-only %YAML 1.2 --- -$id: http://devicetree.org/schemas/clock/qcom,sdm845-gpucc.yaml# +$id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Graphics Clock & Reset Controller Binding for SDM845 +title: Qualcomm Graphics Clock & Reset Controller Binding maintainers: - Taniya Das <tdas@codeaurora.org> description: | Qualcomm graphics clock control module which supports the clocks, resets and - power domains on SDM845. + power domains on SDM845/SC7180/SM8150/SM8250. - See also dt-bindings/clock/qcom,gpucc-sdm845.h. + See also: + dt-bindings/clock/qcom,gpucc-sdm845.h + dt-bindings/clock/qcom,gpucc-sc7180.h + dt-bindings/clock/qcom,gpucc-sm8150.h + dt-bindings/clock/qcom,gpucc-sm8250.h properties: compatible: - const: qcom,sdm845-gpucc + enum: + - qcom,sdm845-gpucc + - qcom,sc7180-gpucc + - qcom,sm8150-gpucc + - qcom,sm8250-gpucc clocks: items: diff --git a/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml new file mode 100644 index 000000000000..a20cb10636dd --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,msm8996-apcc.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,msm8996-apcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm clock controller for MSM8996 CPUs + +maintainers: + - Loic Poulain <loic.poulain@linaro.org> + +description: | + Qualcomm CPU clock controller for MSM8996 CPUs, clock 0 is for Power cluster + and clock 1 is for Perf cluster. + +properties: + compatible: + enum: + - qcom,msm8996-apcc + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: Primary PLL clock for power cluster (little) + - description: Primary PLL clock for perf cluster (big) + - description: Alternate PLL clock for power cluster (little) + - description: Alternate PLL clock for perf cluster (big) + + clock-names: + items: + - const: pwrcl_pll + - const: perfcl_pll + - const: pwrcl_alt_pll + - const: perfcl_alt_pll + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + kryocc: clock-controller@6400000 { + compatible = "qcom,msm8996-apcc"; + reg = <0x6400000 0x90000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index 90a1349bc713..b44a0622fb3a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -13,13 +13,17 @@ Required properties : "qcom,rpmcc-msm8660", "qcom,rpmcc" "qcom,rpmcc-apq8060", "qcom,rpmcc" "qcom,rpmcc-msm8916", "qcom,rpmcc" + "qcom,rpmcc-msm8936", "qcom,rpmcc" "qcom,rpmcc-msm8974", "qcom,rpmcc" "qcom,rpmcc-msm8976", "qcom,rpmcc" "qcom,rpmcc-apq8064", "qcom,rpmcc" "qcom,rpmcc-ipq806x", "qcom,rpmcc" + "qcom,rpmcc-msm8992",·"qcom,rpmcc" + "qcom,rpmcc-msm8994",·"qcom,rpmcc" "qcom,rpmcc-msm8996", "qcom,rpmcc" "qcom,rpmcc-msm8998", "qcom,rpmcc" "qcom,rpmcc-qcs404", "qcom,rpmcc" + "qcom,rpmcc-sdm660", "qcom,rpmcc" - #clock-cells : shall contain 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml deleted file mode 100644 index fe08461fce05..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml +++ /dev/null @@ -1,74 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0-only -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/clock/qcom,sc7180-gpucc.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm Graphics Clock & Reset Controller Binding for SC7180 - -maintainers: - - Taniya Das <tdas@codeaurora.org> - -description: | - Qualcomm graphics clock control module which supports the clocks, resets and - power domains on SC7180. - - See also dt-bindings/clock/qcom,gpucc-sc7180.h. - -properties: - compatible: - const: qcom,sc7180-gpucc - - clocks: - items: - - description: Board XO source - - description: GPLL0 main branch source - - description: GPLL0 div branch source - - clock-names: - items: - - const: bi_tcxo - - const: gcc_gpu_gpll0_clk_src - - const: gcc_gpu_gpll0_div_clk_src - - '#clock-cells': - const: 1 - - '#reset-cells': - const: 1 - - '#power-domain-cells': - const: 1 - - reg: - maxItems: 1 - -required: - - compatible - - reg - - clocks - - clock-names - - '#clock-cells' - - '#reset-cells' - - '#power-domain-cells' - -additionalProperties: false - -examples: - - | - #include <dt-bindings/clock/qcom,gcc-sc7180.h> - #include <dt-bindings/clock/qcom,rpmh.h> - clock-controller@5090000 { - compatible = "qcom,sc7180-gpucc"; - reg = <0x05090000 0x9000>; - clocks = <&rpmhcc RPMH_CXO_CLK>, - <&gcc GCC_GPU_GPLL0_CLK_SRC>, - <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; - clock-names = "bi_tcxo", - "gcc_gpu_gpll0_clk_src", - "gcc_gpu_gpll0_div_clk_src"; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - }; -... diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml new file mode 100644 index 000000000000..c54172fbf29f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-lpasscorecc.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7180-lpasscorecc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm LPASS Core Clock Controller Binding for SC7180 + +maintainers: + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm LPASS core clock control module which supports the clocks and + power domains on SC7180. + + See also: + - dt-bindings/clock/qcom,lpasscorecc-sc7180.h + +properties: + compatible: + enum: + - qcom,sc7180-lpasshm + - qcom,sc7180-lpasscorecc + + clocks: + items: + - description: gcc_lpass_sway clock from GCC + - description: Board XO source + + clock-names: + items: + - const: iface + - const: bi_tcxo + + power-domains: + maxItems: 1 + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + minItems: 1 + items: + - description: lpass core cc register + - description: lpass audio cc register + + reg-names: + items: + - const: lpass_core_cc + - const: lpass_audio_cc + +if: + properties: + compatible: + contains: + const: qcom,sc7180-lpasshm +then: + properties: + reg: + maxItems: 1 + +else: + properties: + reg: + minItems: 2 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h> + clock-controller@63000000 { + compatible = "qcom,sc7180-lpasshm"; + reg = <0x63000000 0x28>; + clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "bi_tcxo"; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h> + clock-controller@62d00000 { + compatible = "qcom,sc7180-lpasscorecc"; + reg = <0x62d00000 0x50000>, <0x62780000 0x30000>; + reg-names = "lpass_core_cc", "lpass_audio_cc"; + clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "bi_tcxo"; + power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml new file mode 100644 index 000000000000..b83f4138f2f8 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-clocks.yaml @@ -0,0 +1,241 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,cpg-clocks.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas Clock Pulse Generator (CPG) + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The Clock Pulse Generator (CPG) generates core clocks for the SoC. It + includes PLLs, and fixed and variable ratio dividers. + + The CPG may also provide a Clock Domain for SoC devices, in combination with + the CPG Module Stop (MSTP) Clocks. + +properties: + compatible: + oneOf: + - const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6 + - const: renesas,r8a7740-cpg-clocks # R-Mobile A1 + - const: renesas,r8a7778-cpg-clocks # R-Car M1 + - const: renesas,r8a7779-cpg-clocks # R-Car H1 + - items: + - enum: + - renesas,r7s72100-cpg-clocks # RZ/A1H + - const: renesas,rz-cpg-clocks # RZ/A1 + - const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5 + + reg: + maxItems: 1 + + clocks: true + + '#clock-cells': + const: 1 + + clock-output-names: true + + renesas,mode: + description: Board-specific settings of the MD_CK* bits on R-Mobile A1 + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + '#power-domain-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - clock-output-names + +allOf: + - if: + properties: + compatible: + contains: + const: renesas,r8a73a4-cpg-clocks + then: + properties: + clocks: + items: + - description: extal1 + - description: extal2 + + clock-output-names: + items: + - const: main + - const: pll0 + - const: pll1 + - const: pll2 + - const: pll2s + - const: pll2h + - const: z + - const: z2 + - const: i + - const: m3 + - const: b + - const: m1 + - const: m2 + - const: zx + - const: zs + - const: hp + + - if: + properties: + compatible: + contains: + const: renesas,r8a7740-cpg-clocks + then: + properties: + clocks: + items: + - description: extal1 + - description: extal2 + - description: extalr + + clock-output-names: + items: + - const: system + - const: pllc0 + - const: pllc1 + - const: pllc2 + - const: r + - const: usb24s + - const: i + - const: zg + - const: b + - const: m1 + - const: hp + - const: hpp + - const: usbp + - const: s + - const: zb + - const: m3 + - const: cp + + required: + - renesas,mode + + - if: + properties: + compatible: + contains: + const: renesas,r8a7778-cpg-clocks + then: + properties: + clocks: + maxItems: 1 + + clock-output-names: + items: + - const: plla + - const: pllb + - const: b + - const: out + - const: p + - const: s + - const: s1 + + - if: + properties: + compatible: + contains: + const: renesas,r8a7779-cpg-clocks + then: + properties: + clocks: + maxItems: 1 + + clock-output-names: + items: + - const: plla + - const: z + - const: zs + - const: s + - const: s1 + - const: p + - const: b + - const: out + + - if: + properties: + compatible: + contains: + const: renesas,r7s72100-cpg-clocks + then: + properties: + clocks: + items: + - description: extal1 + - description: usb_x1 + + clock-output-names: + items: + - const: pll + - const: i + - const: g + + - if: + properties: + compatible: + contains: + const: renesas,sh73a0-cpg-clocks + then: + properties: + clocks: + items: + - description: extal1 + - description: extal2 + + clock-output-names: + items: + - const: main + - const: pll0 + - const: pll1 + - const: pll2 + - const: pll3 + - const: dsi0phy + - const: dsi1phy + - const: zg + - const: m3 + - const: b + - const: m1 + - const: m2 + - const: z + - const: zx + - const: hp + + - if: + properties: + compatible: + contains: + enum: + - renesas,r8a7778-cpg-clocks + - renesas,r8a7779-cpg-clocks + - renesas,rz-cpg-clocks + then: + required: + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7740-clock.h> + cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a7740-cpg-clocks"; + reg = <0xe6150000 0x10000>; + clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>; + #clock-cells = <1>; + clock-output-names = "system", "pllc0", "pllc1", "pllc2", "r", + "usb24s", "i", "zg", "b", "m1", "hp", "hpp", + "usbp", "s", "zb", "m3", "cp"; + renesas,mode = <0x05>; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index c745bd60719a..e13aee8ab61a 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -33,6 +33,7 @@ properties: - renesas,r8a774a1-cpg-mssr # RZ/G2M - renesas,r8a774b1-cpg-mssr # RZ/G2N - renesas,r8a774c0-cpg-mssr # RZ/G2E + - renesas,r8a774e1-cpg-mssr # RZ/G2H - renesas,r8a7790-cpg-mssr # R-Car H2 - renesas,r8a7791-cpg-mssr # R-Car M2-W - renesas,r8a7792-cpg-mssr # R-Car V2H diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt deleted file mode 100644 index ece92393e80d..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r8a73a4-cpg-clocks.txt +++ /dev/null @@ -1,33 +0,0 @@ -* Renesas R8A73A4 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the R8A73A4 SoC. It includes five PLLs -and several fixed ratio dividers. - -Required Properties: - - - compatible: Must be "renesas,r8a73a4-cpg-clocks" - - - reg: Base address and length of the memory resource used by the CPG - - - clocks: Reference to the parent clocks ("extal1" and "extal2") - - - #clock-cells: Must be 1 - - - clock-output-names: The names of the clocks. Supported clocks are "main", - "pll0", "pll1", "pll2", "pll2s", "pll2h", "z", "z2", "i", "m3", "b", - "m1", "m2", "zx", "zs", and "hp". - - -Example -------- - - cpg_clocks: cpg_clocks@e6150000 { - compatible = "renesas,r8a73a4-cpg-clocks"; - reg = <0 0xe6150000 0 0x10000>; - clocks = <&extal1_clk>, <&extal2_clk>; - #clock-cells = <1>; - clock-output-names = "main", "pll0", "pll1", "pll2", - "pll2s", "pll2h", "z", "z2", - "i", "m3", "b", "m1", "m2", - "zx", "zs", "hp"; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt deleted file mode 100644 index 2c03302f86ed..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt +++ /dev/null @@ -1,41 +0,0 @@ -These bindings should be considered EXPERIMENTAL for now. - -* Renesas R8A7740 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the R8A7740 SoC. It includes three PLLs -and several fixed ratio and variable ratio dividers. - -Required Properties: - - - compatible: Must be "renesas,r8a7740-cpg-clocks" - - - reg: Base address and length of the memory resource used by the CPG - - - clocks: Reference to the three parent clocks - - #clock-cells: Must be 1 - - clock-output-names: The names of the clocks. Supported clocks are - "system", "pllc0", "pllc1", "pllc2", "r", "usb24s", "i", "zg", "b", - "m1", "hp", "hpp", "usbp", "s", "zb", "m3", and "cp". - - - renesas,mode: board-specific settings of the MD_CK* bits - - -Example -------- - -cpg_clocks: cpg_clocks@e6150000 { - compatible = "renesas,r8a7740-cpg-clocks"; - reg = <0xe6150000 0x10000>; - clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>; - #clock-cells = <1>; - clock-output-names = "system", "pllc0", "pllc1", - "pllc2", "r", - "usb24s", - "i", "zg", "b", "m1", "hp", - "hpp", "usbp", "s", "zb", "m3", - "cp"; -}; - -&cpg_clocks { - renesas,mode = <0x05>; -}; diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt deleted file mode 100644 index 7cc4c0330b53..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt +++ /dev/null @@ -1,47 +0,0 @@ -* Renesas R8A7778 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the R8A7778. It includes two PLLs and -several fixed ratio dividers. -The CPG also provides a Clock Domain for SoC devices, in combination with the -CPG Module Stop (MSTP) Clocks. - -Required Properties: - - - compatible: Must be "renesas,r8a7778-cpg-clocks" - - reg: Base address and length of the memory resource used by the CPG - - #clock-cells: Must be 1 - - clock-output-names: The names of the clocks. Supported clocks are - "plla", "pllb", "b", "out", "p", "s", and "s1". - - #power-domain-cells: Must be 0 - -SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed -through an MSTP clock should refer to the CPG device node in their -"power-domains" property, as documented by the generic PM domain bindings in -Documentation/devicetree/bindings/power/power_domain.txt. - - -Examples --------- - - - CPG device node: - - cpg_clocks: cpg_clocks@ffc80000 { - compatible = "renesas,r8a7778-cpg-clocks"; - reg = <0xffc80000 0x80>; - #clock-cells = <1>; - clocks = <&extal_clk>; - clock-output-names = "plla", "pllb", "b", - "out", "p", "s", "s1"; - #power-domain-cells = <0>; - }; - - - - CPG/MSTP Clock Domain member device node: - - sdhi0: sd@ffe4c000 { - compatible = "renesas,sdhi-r8a7778"; - reg = <0xffe4c000 0x100>; - interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7778_CLK_SDHI0>; - power-domains = <&cpg_clocks>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt deleted file mode 100644 index 8c81547c29f5..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Renesas R8A7779 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the R8A7779. It includes one PLL and -several fixed ratio dividers. -The CPG also provides a Clock Domain for SoC devices, in combination with the -CPG Module Stop (MSTP) Clocks. - -Required Properties: - - - compatible: Must be "renesas,r8a7779-cpg-clocks" - - reg: Base address and length of the memory resource used by the CPG - - - clocks: Reference to the parent clock - - #clock-cells: Must be 1 - - clock-output-names: The names of the clocks. Supported clocks are "plla", - "z", "zs", "s", "s1", "p", "b", "out". - - #power-domain-cells: Must be 0 - -SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed -through an MSTP clock should refer to the CPG device node in their -"power-domains" property, as documented by the generic PM domain bindings in -Documentation/devicetree/bindings/power/power_domain.txt. - - -Examples --------- - - - CPG device node: - - cpg_clocks: cpg_clocks@ffc80000 { - compatible = "renesas,r8a7779-cpg-clocks"; - reg = <0xffc80000 0x30>; - clocks = <&extal_clk>; - #clock-cells = <1>; - clock-output-names = "plla", "z", "zs", "s", "s1", "p", - "b", "out"; - #power-domain-cells = <0>; - }; - - - - CPG/MSTP Clock Domain member device node: - - sata: sata@fc600000 { - compatible = "renesas,sata-r8a7779", "renesas,rcar-sata"; - reg = <0xfc600000 0x2000>; - interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp1_clks R8A7779_CLK_SATA>; - power-domains = <&cpg_clocks>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt deleted file mode 100644 index 8ff3e2774ed8..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Renesas RZ/A1 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the RZ/A1 SoCs. It includes the PLL, variable -CPU and GPU clocks, and several fixed ratio dividers. -The CPG also provides a Clock Domain for SoC devices, in combination with the -CPG Module Stop (MSTP) Clocks. - -Required Properties: - - - compatible: Must be one of - - "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG - and "renesas,rz-cpg-clocks" as a fallback. - - reg: Base address and length of the memory resource used by the CPG - - clocks: References to possible parent clocks. Order must match clock modes - in the datasheet. For the r7s72100, this is extal, usb_x1. - - #clock-cells: Must be 1 - - clock-output-names: The names of the clocks. Supported clocks are "pll", - "i", and "g" - - #power-domain-cells: Must be 0 - -SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed -through an MSTP clock should refer to the CPG device node in their -"power-domains" property, as documented by the generic PM domain bindings in -Documentation/devicetree/bindings/power/power_domain.txt. - - -Examples --------- - - - CPG device node: - - cpg_clocks: cpg_clocks@fcfe0000 { - #clock-cells = <1>; - compatible = "renesas,r7s72100-cpg-clocks", - "renesas,rz-cpg-clocks"; - reg = <0xfcfe0000 0x18>; - clocks = <&extal_clk>, <&usb_x1_clk>; - clock-output-names = "pll", "i", "g"; - #power-domain-cells = <0>; - }; - - - - CPG/MSTP Clock Domain member device node: - - mtu2: timer@fcff0000 { - compatible = "renesas,mtu2-r7s72100", "renesas,mtu2"; - reg = <0xfcff0000 0x400>; - interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "tgi0a"; - clocks = <&mstp3_clks R7S72100_CLK_MTU2>; - clock-names = "fck"; - power-domains = <&cpg_clocks>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt deleted file mode 100644 index a8978ec94831..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,sh73a0-cpg-clocks.txt +++ /dev/null @@ -1,35 +0,0 @@ -These bindings should be considered EXPERIMENTAL for now. - -* Renesas SH73A0 Clock Pulse Generator (CPG) - -The CPG generates core clocks for the SH73A0 SoC. It includes four PLLs -and several fixed ratio dividers. - -Required Properties: - - - compatible: Must be "renesas,sh73a0-cpg-clocks" - - - reg: Base address and length of the memory resource used by the CPG - - - clocks: Reference to the parent clocks ("extal1" and "extal2") - - - #clock-cells: Must be 1 - - - clock-output-names: The names of the clocks. Supported clocks are "main", - "pll0", "pll1", "pll2", "pll3", "dsi0phy", "dsi1phy", "zg", "m3", "b", - "m1", "m2", "z", "zx", and "hp". - - -Example -------- - - cpg_clocks: cpg_clocks@e6150000 { - compatible = "renesas,sh73a0-cpg-clocks"; - reg = <0 0xe6150000 0 0x10000>; - clocks = <&extal1_clk>, <&extal2_clk>; - #clock-cells = <1>; - clock-output-names = "main", "pll0", "pll1", "pll2", - "pll3", "dsi0phy", "dsi1phy", - "zg", "m3", "b", "m1", "m2", - "z", "zx", "hp"; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt index 8cb47c39ba53..bf3a9ec19241 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt @@ -4,9 +4,15 @@ The RK3288 clock controller generates and supplies clock to various controllers within the SoC and also implements a reset controller for SoC peripherals. +A revision of this SoC is available: rk3288w. The clock tree is a bit +different so another dt-compatible is available. Noticed that it is only +setting the difference but there is no automatic revision detection. This +should be performed by bootloaders. + Required Properties: -- compatible: should be "rockchip,rk3288-cru" +- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in + case of this revision of Rockchip rk3288. - reg: physical base address of the controller and length of memory mapped region. - #clock-cells: should be 1. diff --git a/Documentation/devicetree/bindings/clock/silabs,si514.txt b/Documentation/devicetree/bindings/clock/silabs,si514.txt index ea1a9dbc63b6..a4f28ec86f35 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si514.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si514.txt @@ -6,7 +6,7 @@ found in the datasheet[2]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Si514 datasheet - http://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf + https://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf Required properties: - compatible: Shall be "silabs,si514" diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt index f00191cad8cd..8fe6f80afade 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt @@ -2,7 +2,7 @@ Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator. Reference [1] Si5351A/B/C Data Sheet - http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf + https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf The Si5351a/b/c are programmable i2c clock generators with up to 8 output clocks. Si5351a also has a reduced pin-count package (MSOP10) where only diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt b/Documentation/devicetree/bindings/clock/silabs,si570.txt index c09f21e1d98f..901935e929d2 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si570.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si570.txt @@ -7,9 +7,9 @@ found in the data sheets[2][3]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Si570/571 Data Sheet - http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf + https://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf [3] Si598/599 Data Sheet - http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf + https://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf Required properties: - compatible: Shall be one of "silabs,si570", "silabs,si571", diff --git a/Documentation/devicetree/bindings/clock/ti,cdce706.txt b/Documentation/devicetree/bindings/clock/ti,cdce706.txt index 959d96632f5d..21c3ff764788 100644 --- a/Documentation/devicetree/bindings/clock/ti,cdce706.txt +++ b/Documentation/devicetree/bindings/clock/ti,cdce706.txt @@ -1,7 +1,7 @@ Bindings for Texas Instruments CDCE706 programmable 3-PLL clock synthesizer/multiplier/divider. -Reference: http://www.ti.com/lit/ds/symlink/cdce706.pdf +Reference: https://www.ti.com/lit/ds/symlink/cdce706.pdf I2C device node required properties: - compatible: shall be "ti,cdce706". diff --git a/Documentation/devicetree/bindings/clock/ti,cdce925.txt b/Documentation/devicetree/bindings/clock/ti,cdce925.txt index 26544c85202a..df42ab72718f 100644 --- a/Documentation/devicetree/bindings/clock/ti,cdce925.txt +++ b/Documentation/devicetree/bindings/clock/ti,cdce925.txt @@ -4,10 +4,10 @@ Reference This binding uses the common clock binding[1]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] http://www.ti.com/product/cdce913 -[3] http://www.ti.com/product/cdce925 -[4] http://www.ti.com/product/cdce937 -[5] http://www.ti.com/product/cdce949 +[2] https://www.ti.com/product/cdce913 +[3] https://www.ti.com/product/cdce925 +[4] https://www.ti.com/product/cdce937 +[5] https://www.ti.com/product/cdce949 The driver provides clock sources for each output Y1 through Y5. diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt index 332aed8f4597..56f442374383 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt @@ -18,7 +18,8 @@ Optional properties: in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. - #cooling-cells: - Please refer to Documentation/devicetree/bindings/thermal/thermal.txt. + Please refer to + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. Examples: diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index 0551c78619de..ea4994b35207 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -21,8 +21,8 @@ Optional properties: flow is handled by hardware, hence no software "voltage tracking" is needed. - #cooling-cells: - Please refer to Documentation/devicetree/bindings/thermal/thermal.txt - for detail. + For details, please refer to + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml Example 1 (MT7623 SoC): diff --git a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt index daeca6ae6b76..52a24b82fd86 100644 --- a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt @@ -5,7 +5,7 @@ Required properties: - clocks: Must contain an entry for the CPU clock. See ../clocks/clock-bindings.txt for details. - operating-points-v2: See ../bindings/opp/opp.txt for details. -- #cooling-cells: Should be 2. See ../thermal/thermal.txt for details. +- #cooling-cells: Should be 2. See ../thermal/thermal-cooling-devices.yaml for details. For each opp entry in 'operating-points-v2' table: - opp-supported-hw: Two bitfields indicating: diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt index 2c7fd1941abb..315e90122afa 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt @@ -16,6 +16,7 @@ Optional properties: - dma-channels: contains the total number of DMA channels supported by the DMAC - dma-requests: contains the total number of DMA requests supported by the DMAC - arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP + - arm,pl330-periph-burst: quirk for performing burst transfer only - resets: contains an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names: must contain at least "dma", and optional is "dma-ocp". diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt deleted file mode 100644 index 03e9bb12b75f..000000000000 --- a/Documentation/devicetree/bindings/dma/owl-dma.txt +++ /dev/null @@ -1,47 +0,0 @@ -* Actions Semi Owl SoCs DMA controller - -This binding follows the generic DMA bindings defined in dma.txt. - -Required properties: -- compatible: Should be "actions,s900-dma". -- reg: Should contain DMA registers location and length. -- interrupts: Should contain 4 interrupts shared by all channel. -- #dma-cells: Must be <1>. Used to represent the number of integer - cells in the dmas property of client device. -- dma-channels: Physical channels supported. -- dma-requests: Number of DMA request signals supported by the controller. - Refer to Documentation/devicetree/bindings/dma/dma.txt -- clocks: Phandle and Specifier of the clock feeding the DMA controller. - -Example: - -Controller: - dma: dma-controller@e0260000 { - compatible = "actions,s900-dma"; - reg = <0x0 0xe0260000 0x0 0x1000>; - interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>; - #dma-cells = <1>; - dma-channels = <12>; - dma-requests = <46>; - clocks = <&clock CLK_DMAC>; - }; - -Client: - -DMA clients connected to the Actions Semi Owl SoCs DMA controller must -use the format described in the dma.txt file, using a two-cell specifier -for each channel. - -The two cells in order are: -1. A phandle pointing to the DMA controller. -2. The channel id. - -uart5: serial@e012a000 { - ... - dma-names = "tx", "rx"; - dmas = <&dma 26>, <&dma 27>; - ... -}; diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml new file mode 100644 index 000000000000..256d62af2c64 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/owl-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Actions Semi Owl SoCs DMA controller + +description: | + The OWL DMA is a general-purpose direct memory access controller capable of + supporting 10 and 12 independent DMA channels for S700 and S900 SoCs + respectively. + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + enum: + - actions,s900-dma + - actions,s700-dma + + reg: + maxItems: 1 + + interrupts: + description: + controller supports 4 interrupts, which are freely assignable to the + DMA channels. + maxItems: 4 + + "#dma-cells": + const: 1 + + dma-channels: + maximum: 12 + + dma-requests: + maximum: 46 + + clocks: + maxItems: 1 + description: + Phandle and Specifier of the clock feeding the DMA controller. + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - "#dma-cells" + - dma-channels + - dma-requests + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + dma: dma-controller@e0260000 { + compatible = "actions,s900-dma"; + reg = <0xe0260000 0x1000>; + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + dma-channels = <12>; + dma-requests = <46>; + clocks = <&clock 22>; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index b842dfd96a89..13f1a46be40d 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -23,6 +23,7 @@ properties: - renesas,dmac-r8a774a1 # RZ/G2M - renesas,dmac-r8a774b1 # RZ/G2N - renesas,dmac-r8a774c0 # RZ/G2E + - renesas,dmac-r8a774e1 # RZ/G2H - renesas,dmac-r8a7790 # R-Car H2 - renesas,dmac-r8a7791 # R-Car M2-W - renesas,dmac-r8a7792 # R-Car V2H diff --git a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml index 9ca6d8ddf232..ab287c652b2c 100644 --- a/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml @@ -16,6 +16,7 @@ properties: compatible: items: - enum: + - renesas,r8a7742-usb-dmac # RZ/G1H - renesas,r8a7743-usb-dmac # RZ/G1M - renesas,r8a7744-usb-dmac # RZ/G1N - renesas,r8a7745-usb-dmac # RZ/G1E @@ -23,6 +24,7 @@ properties: - renesas,r8a774a1-usb-dmac # RZ/G2M - renesas,r8a774b1-usb-dmac # RZ/G2N - renesas,r8a774c0-usb-dmac # RZ/G2E + - renesas,r8a774e1-usb-dmac # RZ/G2H - renesas,r8a7790-usb-dmac # R-Car H2 - renesas,r8a7791-usb-dmac # R-Car M2-W - renesas,r8a7793-usb-dmac # R-Car M2-N diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml new file mode 100644 index 000000000000..20870f5c14dd --- /dev/null +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/snps,dma-spear1340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys Designware DMA Controller + +maintainers: + - Viresh Kumar <vireshk@kernel.org> + - Andy Shevchenko <andriy.shevchenko@linux.intel.com> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + const: snps,dma-spear1340 + + "#dma-cells": + const: 3 + description: | + First cell is a phandle pointing to the DMA controller. Second one is + the DMA request line number. Third cell is the memory master identifier + for transfers on dynamically allocated channel. Fourth cell is the + peripheral master identifier for transfers on an allocated channel. + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + description: AHB interface reference clock. + const: hclk + + dma-channels: + description: | + Number of DMA channels supported by the controller. In case if + not specified the driver will try to auto-detect this and + the rest of the optional parameters. + minimum: 1 + maximum: 8 + + dma-requests: + minimum: 1 + maximum: 16 + + dma-masters: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Number of DMA masters supported by the controller. In case if + not specified the driver will try to auto-detect this and + the rest of the optional parameters. + minimum: 1 + maximum: 4 + + chan_allocation_order: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + DMA channels allocation order specifier. Zero means ascending order + (first free allocated), while one - descending (last free allocated). + default: 0 + enum: [0, 1] + + chan_priority: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + DMA channels priority order. Zero means ascending channels priority + so the very first channel has the highest priority. While 1 means + descending priority (the last channel has the highest priority). + default: 0 + enum: [0, 1] + + block_size: + $ref: /schemas/types.yaml#definitions/uint32 + description: Maximum block size supported by the DMA controller. + enum: [3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095] + + data-width: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Data bus width per each DMA master in bytes. + items: + maxItems: 4 + items: + enum: [4, 8, 16, 32] + + data_width: + $ref: /schemas/types.yaml#/definitions/uint32-array + deprecated: true + description: | + Data bus width per each DMA master in (2^n * 8) bits. This property is + deprecated. It' usage is discouraged in favor of data-width one. Moreover + the property incorrectly permits to define data-bus width of 8 and 16 + bits, which is impossible in accordance with DW DMAC IP-core data book. + items: + maxItems: 4 + items: + enum: + - 0 # 8 bits + - 1 # 16 bits + - 2 # 32 bits + - 3 # 64 bits + - 4 # 128 bits + - 5 # 256 bits + default: 0 + + multi-block: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + LLP-based multi-block transfer supported by hardware per + each DMA channel. + items: + maxItems: 8 + items: + enum: [0, 1] + default: 1 + + snps,max-burst-len: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Maximum length of the burst transactions supported by the controller. + This property defines the upper limit of the run-time burst setting + (CTLx.SRC_MSIZE/CTLx.DST_MSIZE fields) so the allowed burst length + will be from 1 to max-burst-len words. It's an array property with one + cell per channel in the units determined by the value set in the + CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width). + items: + maxItems: 8 + items: + enum: [4, 8, 16, 32, 64, 128, 256] + default: 256 + + snps,dma-protection-control: + $ref: /schemas/types.yaml#definitions/uint32 + description: | + Bits one-to-one passed to the AHB HPROT[3:1] bus. Each bit setting + indicates the following features: bit 0 - privileged mode, + bit 1 - DMA is bufferable, bit 2 - DMA is cacheable. + default: 0 + minimum: 0 + maximum: 7 + +unevaluatedProperties: false + +required: + - compatible + - "#dma-cells" + - reg + - interrupts + +examples: + - | + dma-controller@fc000000 { + compatible = "snps,dma-spear1340"; + reg = <0xfc000000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <12>; + + dma-channels = <8>; + dma-requests = <16>; + dma-masters = <4>; + #dma-cells = <3>; + + chan_allocation_order = <1>; + chan_priority = <1>; + block_size = <0xfff>; + data-width = <8 8>; + multi-block = <0 0 0 0 0 0 0 0>; + snps,max-burst-len = <16 16 4 4 4 4 4 4>; + }; +... diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt deleted file mode 100644 index 0bedceed1963..000000000000 --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ /dev/null @@ -1,69 +0,0 @@ -* Synopsys Designware DMA Controller - -Required properties: -- compatible: "snps,dma-spear1340" -- reg: Address range of the DMAC registers -- interrupt: Should contain the DMAC interrupt number -- dma-channels: Number of channels supported by hardware -- dma-requests: Number of DMA request lines supported, up to 16 -- dma-masters: Number of AHB masters supported by the controller -- #dma-cells: must be <3> -- chan_allocation_order: order of allocation of channel, 0 (default): ascending, - 1: descending -- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1: - increase from chan n->0 -- block_size: Maximum block size supported by the controller -- data-width: Maximum data width supported by hardware per AHB master - (in bytes, power of 2) - - -Deprecated properties: -- data_width: Maximum data width supported by hardware per AHB master - (0 - 8bits, 1 - 16bits, ..., 5 - 256bits) - - -Optional properties: -- multi-block: Multi block transfers supported by hardware. Array property with - one cell per channel. 0: not supported, 1 (default): supported. -- snps,dma-protection-control: AHB HPROT[3:1] protection setting. - The default value is 0 (for non-cacheable, non-buffered, - unprivileged data access). - Refer to include/dt-bindings/dma/dw-dmac.h for possible values. - -Example: - - dmahost: dma@fc000000 { - compatible = "snps,dma-spear1340"; - reg = <0xfc000000 0x1000>; - interrupt-parent = <&vic1>; - interrupts = <12>; - - dma-channels = <8>; - dma-requests = <16>; - dma-masters = <2>; - #dma-cells = <3>; - chan_allocation_order = <1>; - chan_priority = <1>; - block_size = <0xfff>; - data-width = <8 8>; - }; - -DMA clients connected to the Designware DMA controller must use the format -described in the dma.txt file, using a four-cell specifier for each channel. -The four cells in order are: - -1. A phandle pointing to the DMA controller -2. The DMA request line number -3. Memory master for transfers on allocated channel -4. Peripheral master for transfers on allocated channel - -Example: - - serial@e0000000 { - compatible = "arm,pl011", "arm,primecell"; - reg = <0xe0000000 0x1000>; - interrupts = <0 35 0x4>; - dmas = <&dmahost 12 0 1>, - <&dmahost 13 1 0>; - dma-names = "rx", "rx"; - }; diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt deleted file mode 100644 index 4563f524556b..000000000000 --- a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt +++ /dev/null @@ -1,39 +0,0 @@ -Qualcomm Hardware Mutex Block: - -The hardware block provides mutexes utilized between different processors on -the SoC as part of the communication protocol used by these processors. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,sfpb-mutex", - "qcom,tcsr-mutex" - -- syscon: - Usage: required - Value type: <prop-encoded-array> - Definition: one cell containing: - syscon phandle - offset of the hwmutex block within the syscon - stride of the hwmutex registers - -- #hwlock-cells: - Usage: required - Value type: <u32> - Definition: must be 1, the specified cell represent the lock id - (hwlock standard property, see hwlock.txt) - -Example: - - tcsr_mutex_block: syscon@fd484000 { - compatible = "syscon"; - reg = <0xfd484000 0x2000>; - }; - - hwlock@fd484000 { - compatible = "qcom,tcsr-mutex"; - syscon = <&tcsr_mutex_block 0 0x80>; - - #hwlock-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml new file mode 100644 index 000000000000..1c7149f7d171 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Hardware Mutex Block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + The hardware block provides mutexes utilized between different processors on + the SoC as part of the communication protocol used by these processors. + +properties: + compatible: + enum: + - qcom,sfpb-mutex + - qcom,tcsr-mutex + + reg: + maxItems: 1 + + '#hwlock-cells': + const: 1 + +required: + - compatible + - reg + - '#hwlock-cells' + +additionalProperties: false + +examples: + - | + tcsr_mutex: hwlock@1f40000 { + compatible = "qcom,tcsr-mutex"; + reg = <0x01f40000 0x40000>; + #hwlock-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt index 2becdcfdc840..f4cfa350f6a1 100644 --- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt @@ -12,7 +12,8 @@ Optional properties: - alarm-gpios: This pin going active indicates something is wrong with the fan, and a udev event will be fired. - #cooling-cells: If used as a cooling device, must be <2> - Also see: Documentation/devicetree/bindings/thermal/thermal.txt + Also see: + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml min and max states are derived from the speed-map of the fan. Note: At least one the "gpios" or "alarm-gpios" properties must be set. diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt b/Documentation/devicetree/bindings/hwmon/lm90.txt index c76a7ac47c34..398dcb965751 100644 --- a/Documentation/devicetree/bindings/hwmon/lm90.txt +++ b/Documentation/devicetree/bindings/hwmon/lm90.txt @@ -34,8 +34,8 @@ Optional properties: LM90 "-ALERT" pin output. See interrupt-controller/interrupts.txt for the format. -- #thermal-sensor-cells: should be set to 1. See thermal/thermal.txt for - details. See <include/dt-bindings/thermal/lm90.h> for the +- #thermal-sensor-cells: should be set to 1. See thermal/thermal-sensor.yaml + for details. See <include/dt-bindings/thermal/lm90.h> for the definition of the local, remote and 2nd remote sensor index constants. diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 88b71c1b32c9..7f0194fdd0cc 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -14,6 +14,7 @@ Required properties: "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629 "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 + "mediatek,mt8192-i2c": for MediaTek MT8192 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 - reg: physical base address of the controller and dma base, length of memory mapped region. diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index 438ae123107e..a21c359b9f02 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -72,6 +72,16 @@ wants to support one of the below features, it should adapt these bindings. this information to adapt power management to keep the arbitration awake all the time, for example. Can not be combined with 'single-master'. +- pinctrl + add extra pinctrl to configure SCL/SDA pins to GPIO function for bus + recovery, call it "gpio" or "recovery" (deprecated) state + +- scl-gpios + specify the gpio related to SCL pin. Used for GPIO bus recovery. + +- sda-gpios + specify the gpio related to SDA pin. Optional for GPIO bus recovery. + - single-master states that there is no other master active on this bus. The OS can use this information to detect a stalled bus more reliably, for example. diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index 2ceb05ba2df5..5b5ae402f97a 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -27,6 +27,9 @@ properties: - const: allwinner,sun50i-a64-i2c - const: allwinner,sun6i-a31-i2c - items: + - const: allwinner,sun50i-a100-i2c + - const: allwinner,sun6i-a31-i2c + - items: - const: allwinner,sun50i-h6-i2c - const: allwinner,sun6i-a31-i2c diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt index a03f9f5cb378..96d869ac3839 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt @@ -10,6 +10,7 @@ Required properties: "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC. "renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC. "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC. + "renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC. "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt index 89facb09337a..93d412832e66 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ b/Documentation/devicetree/bindings/i2c/renesas,iic.txt @@ -11,6 +11,7 @@ Required properties: - "renesas,iic-r8a774a1" (RZ/G2M) - "renesas,iic-r8a774b1" (RZ/G2N) - "renesas,iic-r8a774c0" (RZ/G2E) + - "renesas,iic-r8a774e1" (RZ/G2H) - "renesas,iic-r8a7790" (R-Car H2) - "renesas,iic-r8a7791" (R-Car M2-W) - "renesas,iic-r8a7792" (R-Car V2H) diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml index d124eba1ce54..fd4eaa3d0ab4 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml @@ -12,8 +12,8 @@ maintainers: description: | Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports both I2C & SPI interfaces. - http://www.analog.com/en/products/mems/accelerometers/adxl345.html - http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html + https://www.analog.com/en/products/mems/accelerometers/adxl345.html + https://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.txt b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.txt deleted file mode 100644 index b25bf3a77e0f..000000000000 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.txt +++ /dev/null @@ -1,22 +0,0 @@ -Kionix KXSD9 Accelerometer device tree bindings - -Required properties: - - compatible: should be set to "kionix,kxsd9" - - reg: i2c slave address - -Optional properties: - - vdd-supply: The input supply for VDD - - iovdd-supply: The input supply for IOVDD - - interrupts: The movement detection interrupt - - mount-matrix: See mount-matrix.txt - -Example: - -kxsd9@18 { - compatible = "kionix,kxsd9"; - reg = <0x18>; - interrupt-parent = <&foo>; - interrupts = <57 IRQ_TYPE_EDGE_FALLING>; - iovdd-supply = <&bar>; - vdd-supply = <&baz>; -}; diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml new file mode 100644 index 000000000000..d61ab4fa3d71 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxsd9.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/kionix,kxsd9.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Kionix KXSD9 Accelerometer + +maintainers: + - Jonathan Cameron <jic23@kernel.org> + +description: | + 3 axis 12 bit accelerometer with +-8G range on all axes. Also has a + 12 bit auxiliary ADC channel. Interface is either SPI or I2C. + +properties: + compatible: + const: kionix,kxsd9 + + reg: + maxItems: 1 + + vdd-supply: true + iovdd-supply: true + + interrupts: + maxItems: 1 + + mount-matrix: + description: an optional 3x3 mounting rotation matrix. + +required: + - compatible + - reg + +examples: + - | + # include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accel@18 { + compatible = "kionix,kxsd9"; + reg = <0x18>; + iovdd-supply = <&iovdd>; + vdd-supply = <&vdd>; + interrupts = <57 IRQ_TYPE_EDGE_FALLING>; + mount-matrix = "-0.984807753012208", "0", "-0.173648177666930", + "0", "-1", "0", + "-0.173648177666930", "0", "0.984807753012208"; + }; + }; + - | + # include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + accel@0 { + compatible = "kionix,kxsd9"; + reg = <0>; + spi-max-frequency = <10000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt deleted file mode 100644 index cd9048cf9dcf..000000000000 --- a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Ingenic JZ47xx ADC controller IIO bindings - -Required properties: - -- compatible: Should be one of: - * ingenic,jz4725b-adc - * ingenic,jz4740-adc - * ingenic,jz4770-adc -- reg: ADC controller registers location and length. -- clocks: phandle to the SoC's ADC clock. -- clock-names: Must be set to "adc". -- #io-channel-cells: Must be set to <1> to indicate channels are selected - by index. - -ADC clients must use the format described in iio-bindings.txt, giving -a phandle and IIO specifier pair ("io-channels") to the ADC controller. - -Example: - -#include <dt-bindings/iio/adc/ingenic,adc.h> - -adc: adc@10070000 { - compatible = "ingenic,jz4740-adc"; - #io-channel-cells = <1>; - - reg = <0x10070000 0x30>; - - clocks = <&cgu JZ4740_CLK_ADC>; - clock-names = "adc"; - - interrupt-parent = <&intc>; - interrupts = <18>; -}; - -adc-keys { - ... - compatible = "adc-keys"; - io-channels = <&adc INGENIC_ADC_AUX>; - io-channel-names = "buttons"; - ... -}; - -battery { - ... - compatible = "ingenic,jz4740-battery"; - io-channels = <&adc INGENIC_ADC_BATTERY>; - io-channel-names = "battery"; - ... -}; diff --git a/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml new file mode 100644 index 000000000000..9f414dbdae86 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019-2020 Artur Rojek +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/iio/adc/ingenic,adc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Ingenic JZ47xx ADC controller IIO bindings + +maintainers: + - Artur Rojek <contact@artur-rojek.eu> + +description: > + Industrial I/O subsystem bindings for ADC controller found in + Ingenic JZ47xx SoCs. + + ADC clients must use the format described in iio-bindings.txt, giving + a phandle and IIO specifier pair ("io-channels") to the ADC controller. + +properties: + compatible: + enum: + - ingenic,jz4725b-adc + - ingenic,jz4740-adc + - ingenic,jz4770-adc + + '#io-channel-cells': + const: 1 + description: + Must be set to <1> to indicate channels are selected by index. + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: adc + + interrupts: + maxItems: 1 + +required: + - compatible + - '#io-channel-cells' + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4740-cgu.h> + #include <dt-bindings/iio/adc/ingenic,adc.h> + + adc@10070000 { + compatible = "ingenic,jz4740-adc"; + #io-channel-cells = <1>; + + reg = <0x10070000 0x30>; + + clocks = <&cgu JZ4740_CLK_ADC>; + clock-names = "adc"; + + interrupt-parent = <&intc>; + interrupts = <18>; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt deleted file mode 100644 index c8787688122a..000000000000 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt +++ /dev/null @@ -1,173 +0,0 @@ -Qualcomm's SPMI PMIC ADC - -- SPMI PMIC voltage ADC (VADC) provides interface to clients to read - voltage. The VADC is a 15-bit sigma-delta ADC. -- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read - voltage. The VADC is a 16-bit sigma-delta ADC. - -VADC node: - -- compatible: - Usage: required - Value type: <string> - Definition: Should contain "qcom,spmi-vadc". - Should contain "qcom,spmi-adc5" for PMIC5 ADC driver. - Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC driver. - Should contain "qcom,pms405-adc" for PMS405 PMIC - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: VADC base address in the SPMI PMIC register map. - -- #address-cells: - Usage: required - Value type: <u32> - Definition: Must be one. Child node 'reg' property should define ADC - channel number. - -- #size-cells: - Usage: required - Value type: <u32> - Definition: Must be zero. - -- #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 - -- interrupts: - Usage: optional - Value type: <prop-encoded-array> - Definition: End of conversion interrupt. - -Channel node properties: - -- reg: - Usage: required - Value type: <u32> - Definition: ADC channel number. - See include/dt-bindings/iio/qcom,spmi-vadc.h - -- label: - Usage: required for "qcom,spmi-adc5" and "qcom,spmi-adc-rev2" - Value type: <empty> - Definition: ADC input of the platform as seen in the schematics. - For thermistor inputs connected to generic AMUX or GPIO inputs - these can vary across platform for the same pins. Hence select - the platform schematics name for this channel. - -- qcom,decimation: - Usage: optional - Value type: <u32> - Definition: This parameter is used to decrease ADC sampling rate. - Quicker measurements can be made by reducing decimation ratio. - - For compatible property "qcom,spmi-vadc", valid values are - 512, 1024, 2048, 4096. If property is not found, default value - of 512 will be used. - - For compatible property "qcom,spmi-adc5", valid values are 250, 420 - and 840. If property is not found, default value of 840 is used. - - For compatible property "qcom,spmi-adc-rev2", valid values are 256, - 512 and 1024. If property is not present, default value is 1024. - -- qcom,pre-scaling: - Usage: optional - Value type: <u32 array> - Definition: Used for scaling the channel input signal before the signal is - fed to VADC. The configuration for this node is to know the - pre-determined ratio and use it for post scaling. Select one from - the following options. - <1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10> - If property is not found default value depending on chip will be used. - -- qcom,ratiometric: - Usage: optional - Value type: <empty> - Definition: Channel calibration type. - - For compatible property "qcom,spmi-vadc", if this property is - specified VADC will use the VDD reference (1.8V) and GND for - channel calibration. If property is not found, channel will be - calibrated with 0.625V and 1.25V reference channels, also - known as absolute calibration. - - For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2", - if this property is specified VADC will use the VDD reference - (1.875V) and GND for channel calibration. If property is not found, - channel will be calibrated with 0V and 1.25V reference channels, - also known as absolute calibration. - -- qcom,hw-settle-time: - Usage: optional - Value type: <u32> - Definition: Time between AMUX getting configured and the ADC starting - conversion. The 'hw_settle_time' is an index used from valid values - and programmed in hardware to achieve the hardware settling delay. - - For compatible property "qcom,spmi-vadc" and "qcom,spmi-adc-rev2", - Delay = 100us * (hw_settle_time) for hw_settle_time < 11, - and 2ms * (hw_settle_time - 10) otherwise. - Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800, - 900 us and 1, 2, 4, 6, 8, 10 ms. - If property is not found, channel will use 0us. - - For compatible property "qcom,spmi-adc5", delay = 15us for - value 0, 100us * (value) for values < 11, - and 2ms * (value - 10) otherwise. - Valid values are: 15, 100, 200, 300, 400, 500, 600, 700, 800, - 900 us and 1, 2, 4, 6, 8, 10 ms - Certain controller digital versions have valid values of - 15, 100, 200, 300, 400, 500, 600, 700, 1, 2, 4, 8, 16, 32, 64, 128 ms - If property is not found, channel will use 15us. - -- qcom,avg-samples: - Usage: optional - Value type: <u32> - Definition: Number of samples to be used for measurement. - 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). - - For compatible property "qcom,spmi-vadc", valid values - are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 - If property is not found, 1 sample will be used. - - For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2", - valid values are: 1, 2, 4, 8, 16 - If property is not found, 1 sample will be used. - -NOTE: - -For compatible property "qcom,spmi-vadc" following channels, also known as -reference point channels, are used for result calibration and their channel -configuration nodes should be defined: -VADC_REF_625MV and/or VADC_SPARE1(based on PMIC version) VADC_REF_1250MV, -VADC_GND_REF and VADC_VDD_VADC. - -Example: - -#include <dt-bindings/iio/qcom,spmi-vadc.h> -#include <linux/irq.h> -/* ... */ - - /* VADC node */ - pmic_vadc: vadc@3100 { - compatible = "qcom,spmi-vadc"; - reg = <0x3100>; - interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>; - #address-cells = <1>; - #size-cells = <0>; - #io-channel-cells = <1>; - io-channel-ranges; - - /* Channel node */ - adc-chan@VADC_LR_MUX10_USB_ID { - reg = <VADC_LR_MUX10_USB_ID>; - qcom,decimation = <512>; - qcom,ratiometric; - qcom,hw-settle-time = <200>; - qcom,avg-samples = <1>; - qcom,pre-scaling = <1 3>; - }; - }; - - /* IIO client node */ - usb { - io-channels = <&pmic_vadc VADC_LR_MUX10_USB_ID>; - io-channel-names = "vadc"; - }; diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml new file mode 100644 index 000000000000..e6263b617941 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml @@ -0,0 +1,278 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/qcom,spmi-vadc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's SPMI PMIC ADC + +maintainers: + - Andy Gross <agross@kernel.org> + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + SPMI PMIC voltage ADC (VADC) provides interface to clients to read + voltage. The VADC is a 15-bit sigma-delta ADC. + SPMI PMIC5/PMIC7 voltage ADC (ADC) provides interface to clients to read + voltage. The VADC is a 16-bit sigma-delta ADC. + +properties: + compatible: + oneOf: + - items: + - const: qcom,pms405-adc + - const: qcom,spmi-adc-rev2 + + - items: + - enum: + - qcom,spmi-vadc + - qcom,spmi-adc5 + - qcom,spmi-adc-rev2 + - qcom,spmi-adc7 + + reg: + description: VADC base address in the SPMI PMIC register map + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#io-channel-cells': + const: 1 + + interrupts: + maxItems: 1 + description: + End of conversion interrupt. + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + - '#io-channel-cells' + +patternProperties: + "^.*@[0-9a-f]+$": + type: object + description: | + Represents the external channels which are connected to the ADC. + For compatible property "qcom,spmi-vadc" following channels, also known as + reference point channels, are used for result calibration and their channel + configuration nodes should be defined: + VADC_REF_625MV and/or VADC_SPARE1(based on PMIC version) VADC_REF_1250MV, + VADC_GND_REF and VADC_VDD_VADC. + + properties: + reg: + description: | + ADC channel number. + See include/dt-bindings/iio/qcom,spmi-vadc.h + For PMIC7 ADC, the channel numbers are specified separately per PMIC + in the PMIC-specific files in include/dt-bindings/iio/. + + label: + $ref: /schemas/types.yaml#/definitions/string + description: | + ADC input of the platform as seen in the schematics. + For thermistor inputs connected to generic AMUX or GPIO inputs + these can vary across platform for the same pins. Hence select + the platform schematics name for this channel. + + qcom,decimation: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + This parameter is used to decrease ADC sampling rate. + Quicker measurements can be made by reducing decimation ratio. + + qcom,pre-scaling: + description: | + Used for scaling the channel input signal before the signal is + fed to VADC. The configuration for this node is to know the + pre-determined ratio and use it for post scaling. It is a pair of + integers, denoting the numerator and denominator of the fraction by which + input signal is multiplied. For example, <1 3> indicates the signal is scaled + down to 1/3 of its value before ADC measurement. + If property is not found default value depending on chip will be used. + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array + oneOf: + - items: + - const: 1 + - enum: [ 1, 3, 4, 6, 20, 8, 10 ] + + - items: + - const: 10 + - const: 81 + + qcom,ratiometric: + description: | + Channel calibration type. + - For compatible property "qcom,spmi-vadc", if this property is + specified VADC will use the VDD reference (1.8V) and GND for + channel calibration. If property is not found, channel will be + calibrated with 0.625V and 1.25V reference channels, also + known as absolute calibration. + - For compatible property "qcom,spmi-adc5", "qcom,spmi-adc7" and + "qcom,spmi-adc-rev2", if this property is specified VADC will use + the VDD reference (1.875V) and GND for channel calibration. If + property is not found, channel will be calibrated with 0V and 1.25V + reference channels, also known as absolute calibration. + type: boolean + + qcom,hw-settle-time: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Time between AMUX getting configured and the ADC starting + conversion. The 'hw_settle_time' is an index used from valid values + and programmed in hardware to achieve the hardware settling delay. + + qcom,avg-samples: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Number of samples to be used for measurement. + 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). + + required: + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: qcom,spmi-vadc + + then: + patternProperties: + "^.*@[0-9a-f]+$": + properties: + qcom,decimation: + enum: [ 512, 1024, 2048, 4096 ] + default: 512 + + qcom,hw-settle-time: + enum: [ 0, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1, 2, + 4, 6, 8, 10 ] + default: 0 + + qcom,avg-samples: + enum: [ 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 ] + default: 1 + + - if: + properties: + compatible: + contains: + const: qcom,spmi-adc-rev2 + + then: + patternProperties: + "^.*@[0-9a-f]+$": + properties: + qcom,decimation: + enum: [ 256, 512, 1024 ] + default: 1024 + + qcom,hw-settle-time: + enum: [ 0, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1, 2, + 4, 6, 8, 10 ] + default: 0 + + qcom,avg-samples: + enum: [ 1, 2, 4, 8, 16 ] + default: 1 + + - if: + properties: + compatible: + contains: + const: qcom,spmi-adc5 + + then: + patternProperties: + "^.*@[0-9a-f]+$": + properties: + qcom,decimation: + enum: [ 250, 420, 840 ] + default: 840 + + qcom,hw-settle-time: + enum: [ 15, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1, 2, + 4, 6, 8, 10, 16, 32, 64, 128 ] + default: 15 + + qcom,avg-samples: + enum: [ 1, 2, 4, 8, 16 ] + default: 1 + + - if: + properties: + compatible: + contains: + const: qcom,spmi-adc7 + + then: + patternProperties: + "^.*@[0-9a-f]+$": + properties: + qcom,decimation: + enum: [ 85, 340, 1360 ] + default: 1360 + + qcom,hw-settle-time: + enum: [ 15, 100, 200, 300, 400, 500, 600, 700, 1000, 2000, 4000, + 8000, 16000, 32000, 64000, 128000 ] + default: 15 + + qcom,avg-samples: + enum: [ 1, 2, 4, 8, 16 ] + default: 1 + +examples: + - | + spmi_bus { + #address-cells = <1>; + #size-cells = <0>; + /* VADC node */ + pmic_vadc: adc@3100 { + compatible = "qcom,spmi-vadc"; + reg = <0x3100>; + interrupts = <0x0 0x31 0x0 0x1>; + #address-cells = <1>; + #size-cells = <0>; + #io-channel-cells = <1>; + io-channel-ranges; + + /* Channel node */ + adc-chan@39 { + reg = <0x39>; + qcom,decimation = <512>; + qcom,ratiometric; + qcom,hw-settle-time = <200>; + qcom,avg-samples = <1>; + qcom,pre-scaling = <1 3>; + }; + + adc-chan@9 { + reg = <0x9>; + }; + + adc-chan@a { + reg = <0xa>; + }; + + adc-chan@e { + reg = <0xe>; + }; + + adc-chan@f { + reg = <0xf>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml new file mode 100644 index 000000000000..97fe6cbb2efa --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads8688.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,ads8688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments' ADS8684 and ADS8688 ADC chip + +maintainers: + - Sean Nyekjaer <sean@geanix.com> + +description: | + SPI 16bit ADCs with 4/8 channels. + +properties: + compatible: + enum: + - ti,ads8684 + - ti,ads8688 + + reg: + maxItems: 1 + + vref-supply: + description: Optional external reference. If not supplied, assume + REFSEL input tied low to enable the internal reference. + +required: + - compatible + - reg + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "ti,ads8688"; + reg = <0>; + vref-supply = <&vdd_supply>; + spi-max-frequency = <1000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt deleted file mode 100644 index a02337d7efa4..000000000000 --- a/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Texas Instruments' ADS8684 and ADS8688 ADC chip - -Required properties: - - compatible: Should be "ti,ads8684" or "ti,ads8688" - - reg: spi chip select number for the device - -Recommended properties: - - spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Optional properties: - - vref-supply: The regulator supply for ADC reference voltage - -Example: -adc@0 { - compatible = "ti,ads8688"; - reg = <0>; - vref-supply = <&vdd_supply>; - spi-max-frequency = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml new file mode 100644 index 000000000000..40d87346ff4c --- /dev/null +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/chemical/sensirion,scd30.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sensirion SCD30 carbon dioxide sensor + +maintainers: + - Tomasz Duszynski <tomasz.duszynski@octakon.com> + +description: | + Air quality sensor capable of measuring co2 concentration, temperature + and relative humidity. + +properties: + compatible: + enum: + - sensirion,scd30 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: true + + sensirion,sel-gpios: + description: GPIO connected to the SEL line + maxItems: 1 + + sensirion,pwm-gpios: + description: GPIO connected to the PWM line + maxItems: 1 + +required: + - compatible + +additionalProperties: false + +examples: + - | + # include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + co2-sensor@61 { + compatible = "sensirion,scd30"; + reg = <0x61>; + vdd-supply = <&vdd>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + - | + # include <dt-bindings/interrupt-controller/irq.h> + serial { + co2-sensor { + compatible = "sensirion,scd30"; + vdd-supply = <&vdd>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt index 639c94ed83e9..17af395b99d9 100644 --- a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt @@ -6,7 +6,7 @@ Is is programmable through an SPI interface. The internal DACs are loaded when the LOADDACS pin is pulled down. -http://www.ti.com/lit/ds/sbas106/sbas106.pdf +https://www.ti.com/lit/ds/sbas106/sbas106.pdf Required Properties: - compatible: Should be one of: diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt index af33267727f4..aa63cac7323e 100644 --- a/Documentation/devicetree/bindings/iio/iio-bindings.txt +++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt @@ -9,7 +9,7 @@ specifier is an array of one or more cells identifying the IIO output on a device. The length of an IIO specifier is defined by the value of a #io-channel-cells property in the IIO provider node. -[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2 +[1] https://marc.info/?l=linux-iio&m=135902119507483&w=2 ==IIO providers== diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml index 0d0ef84e22b9..33d8e9fd14b7 100644 --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml @@ -37,6 +37,15 @@ properties: set if the specified interrupt pin should be configured as open drain. If not set, defaults to push-pull. + vdd-supply: + description: provide VDD power to the sensor. + + vddio-supply: + description: provide VDD IO power to the sensor. + + mount-matrix: + description: an optional 3x3 mounting rotation matrix + required: - compatible - reg @@ -52,9 +61,14 @@ examples: bmi160@68 { compatible = "bosch,bmi160"; reg = <0x68>; + vdd-supply = <&pm8916_l17>; + vddio-supply = <&pm8916_l6>; interrupt-parent = <&gpio4>; interrupts = <12 IRQ_TYPE_EDGE_RISING>; interrupt-names = "INT1"; + mount-matrix = "0", "1", "0", + "-1", "0", "0", + "0", "0", "1"; }; }; - | diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml new file mode 100644 index 000000000000..abd8d25e1136 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/imu/invensense,icm42600.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: InvenSense ICM-426xx Inertial Measurement Unit + +maintainers: + - Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> + +description: | + 6-axis MotionTracking device that combines a 3-axis gyroscope and a 3-axis + accelerometer. + + It has a configurable host interface that supports I3C, I2C and SPI serial + communication, features a 2kB FIFO and 2 programmable interrupts with + ultra-low-power wake-on-motion support to minimize system power consumption. + + Other industry-leading features include InvenSense on-chip APEX Motion + Processing engine for gesture recognition, activity classification, and + pedometer, along with programmable digital filters, and an embedded + temperature sensor. + + https://invensense.tdk.com/wp-content/uploads/2020/03/DS-000292-ICM-42605-v1.4.pdf + +properties: + compatible: + enum: + - invensense,icm42600 + - invensense,icm42602 + - invensense,icm42605 + - invensense,icm42622 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + drive-open-drain: + type: boolean + + vdd-supply: + description: Regulator that provides power to the sensor + + vddio-supply: + description: Regulator that provides power to the bus + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + icm42605@68 { + compatible = "invensense,icm42605"; + reg = <0x68>; + interrupt-parent = <&gpio2>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&vdd>; + vddio-supply = <&vddio>; + }; + }; + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + icm42602@0 { + compatible = "invensense,icm42602"; + reg = <0>; + spi-max-frequency = <24000000>; + spi-cpha; + spi-cpol; + interrupt-parent = <&gpio1>; + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&vdd>; + vddio-supply = <&vddio>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/light/apds9300.txt b/Documentation/devicetree/bindings/iio/light/apds9300.txt index aa199e09a493..3aa6db3ee99d 100644 --- a/Documentation/devicetree/bindings/iio/light/apds9300.txt +++ b/Documentation/devicetree/bindings/iio/light/apds9300.txt @@ -1,6 +1,6 @@ * Avago APDS9300 ambient light sensor -http://www.avagotech.com/docs/AV02-1077EN +https://www.avagotech.com/docs/AV02-1077EN Required properties: diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt b/Documentation/devicetree/bindings/iio/light/apds9960.txt index 3af325ad194b..c53ddb81c4aa 100644 --- a/Documentation/devicetree/bindings/iio/light/apds9960.txt +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt @@ -1,6 +1,6 @@ * Avago APDS9960 gesture/RGB/ALS/proximity sensor -http://www.avagotech.com/docs/AV02-4191EN +https://www.avagotech.com/docs/AV02-4191EN Required properties: diff --git a/Documentation/devicetree/bindings/iio/light/opt3001.txt b/Documentation/devicetree/bindings/iio/light/opt3001.txt index 47b13eb8f4ec..9e6f2998e751 100644 --- a/Documentation/devicetree/bindings/iio/light/opt3001.txt +++ b/Documentation/devicetree/bindings/iio/light/opt3001.txt @@ -6,7 +6,7 @@ the optional generation of IIO events on rising/falling light threshold changes requires the use of interrupts. Without interrupts, only the simple reading of the current light value is supported through the IIO API. -http://www.ti.com/product/opt3001 +https://www.ti.com/product/opt3001 Required properties: - compatible: should be "ti,opt3001" diff --git a/Documentation/devicetree/bindings/iio/light/vl6180.txt b/Documentation/devicetree/bindings/iio/light/vl6180.txt index 2c52952715a0..fb9137d85df9 100644 --- a/Documentation/devicetree/bindings/iio/light/vl6180.txt +++ b/Documentation/devicetree/bindings/iio/light/vl6180.txt @@ -1,6 +1,6 @@ STMicro VL6180 - ALS, range and proximity sensor -Link to datasheet: http://www.st.com/resource/en/datasheet/vl6180x.pdf +Link to datasheet: https://www.st.com/resource/en/datasheet/vl6180x.pdf Required properties: diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt deleted file mode 100644 index aa67ceb0d4e0..000000000000 --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt +++ /dev/null @@ -1,30 +0,0 @@ -* AsahiKASEI AK8975 magnetometer sensor - -Required properties: - - - compatible : should be "asahi-kasei,ak8975" - - reg : the I2C address of the magnetometer - -Optional properties: - - - gpios : should be device tree identifier of the magnetometer DRDY pin - - vdd-supply: an optional regulator that needs to be on to provide VDD - - mount-matrix: an optional 3x3 mounting rotation matrix - -Example: - -ak8975@c { - compatible = "asahi-kasei,ak8975"; - reg = <0x0c>; - gpios = <&gpj0 7 0>; - vdd-supply = <&ldo_3v3_gnss>; - mount-matrix = "-0.984807753012208", /* x0 */ - "0", /* y0 */ - "-0.173648177666930", /* z0 */ - "0", /* x1 */ - "-1", /* y1 */ - "0", /* z1 */ - "-0.173648177666930", /* x2 */ - "0", /* y2 */ - "0.984807753012208"; /* z2 */ -}; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml new file mode 100644 index 000000000000..f4393bfbf355 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/magnetometer/asahi-kasei,ak8975.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AsahiKASEI AK8975 magnetometer sensor + +maintainers: + - Jonathan Albrieux <jonathan.albrieux@gmail.com> + +properties: + compatible: + oneOf: + - enum: + - asahi-kasei,ak8975 + - asahi-kasei,ak8963 + - asahi-kasei,ak09911 + - asahi-kasei,ak09912 + - enum: + - ak8975 + - ak8963 + - ak09911 + - ak09912 + deprecated: true + + reg: + maxItems: 1 + + gpios: + maxItems: 1 + description: | + AK8975 has a "Data ready" pin (DRDY) which informs that data + is ready to be read and is possible to listen on it. If used, + this should be active high. Prefer interrupt over this. + + interrupts: + maxItems: 1 + description: interrupt for DRDY pin. Triggered on rising edge. + + vdd-supply: + description: | + an optional regulator that needs to be on to provide VDD power to + the sensor. + + mount-matrix: + description: an optional 3x3 mounting rotation matrix. + + reset-gpios: + description: | + an optional pin needed for AK09911 to set the reset state. This should + be usually active low + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + magnetometer@c { + compatible = "asahi-kasei,ak8975"; + reg = <0x0c>; + interrupt-parent = <&gpio6>; + interrupts = <15 IRQ_TYPE_EDGE_RISING>; + vdd-supply = <&ldo_3v3_gnss>; + reset-gpios = <&msmgpio 111 GPIO_ACTIVE_LOW>; + mount-matrix = "-0.984807753012208", /* x0 */ + "0", /* y0 */ + "-0.173648177666930", /* z0 */ + "0", /* x1 */ + "-1", /* y1 */ + "0", /* z1 */ + "-0.173648177666930", /* x2 */ + "0", /* y2 */ + "0.984807753012208"; /* z2 */ + }; + }; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt index fd5fca90fb39..22912e43b60c 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt +++ b/Documentation/devicetree/bindings/iio/magnetometer/bmc150_magn.txt @@ -4,7 +4,11 @@ http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS00 Required properties: - - compatible : should be "bosch,bmc150_magn" + - compatible : should be one of: + "bosch,bmc150_magn" + "bosch,bmc156_magn" + "bosch,bmm150" + "bosch,bmm150_magn" (DEPRECATED, use bosch,bmm150) - reg : the I2C address of the magnetometer Optional properties: diff --git a/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt b/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt index 566711b9950c..4f245e8469fd 100644 --- a/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt +++ b/Documentation/devicetree/bindings/iio/potentiometer/mcp41010.txt @@ -1,7 +1,7 @@ * Microchip MCP41010/41050/41100/42010/42050/42100 Digital Potentiometer Datasheet publicly available at: -http://ww1.microchip.com/downloads/en/devicedoc/11195c.pdf +https://ww1.microchip.com/downloads/en/devicedoc/11195c.pdf The node for this driver must be a child node of a SPI controller, hence all mandatory properties described in diff --git a/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt b/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt index e6d0c2eb345c..f3ab02b0dd41 100644 --- a/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt +++ b/Documentation/devicetree/bindings/iio/potentiostat/lmp91000.txt @@ -1,7 +1,7 @@ * Texas Instruments LMP91000 series of potentiostats -LMP91000: http://www.ti.com/lit/ds/symlink/lmp91000.pdf -LMP91002: http://www.ti.com/lit/ds/symlink/lmp91002.pdf +LMP91000: https://www.ti.com/lit/ds/symlink/lmp91000.pdf +LMP91002: https://www.ti.com/lit/ds/symlink/lmp91002.pdf Required properties: diff --git a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml index 64c18f1693f0..be2be4b556db 100644 --- a/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/asc,dlhl60d.yaml @@ -13,7 +13,7 @@ description: | Bindings for the All Sensors DLH series pressure sensors. Specifications about the sensors can be found at: - http://www.allsensors.com/cad/DS-0355_Rev_B.PDF + https://www.allsensors.com/cad/DS-0355_Rev_B.PDF properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml index f86f8b23ef18..ce795279839e 100644 --- a/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml @@ -17,9 +17,9 @@ description: | until it is received once again Specifications about the devices can be found at: - http://www.robot-electronics.co.uk/htm/srf04tech.htm + https://www.robot-electronics.co.uk/htm/srf04tech.htm - http://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf + https://www.maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf properties: compatible: diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml new file mode 100644 index 000000000000..007adbc89c14 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/eeti,exc3000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EETI EXC3000 series touchscreen controller + +maintainers: + - Dmitry Torokhov <dmitry.torokhov@gmail.com> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - eeti,exc3000 + - eeti,exc80h60 + - eeti,exc80h84 + reg: + const: 0x2a + interrupts: + maxItems: 1 + reset-gpios: + maxItems: 1 + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-swapped-x-y: true + +required: + - compatible + - reg + - interrupts + - touchscreen-size-x + - touchscreen-size-y + +additionalProperties: false + +examples: + - | + #include "dt-bindings/interrupt-controller/irq.h" + i2c { + #address-cells = <1>; + #size-cells = <0>; + touchscreen@2a { + compatible = "eeti,exc3000"; + reg = <0x2a>; + interrupt-parent = <&gpio1>; + interrupts = <9 IRQ_TYPE_LEVEL_LOW>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt b/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt deleted file mode 100644 index 68291b94fec2..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/exc3000.txt +++ /dev/null @@ -1,26 +0,0 @@ -* EETI EXC3000 Multiple Touch Controller - -Required properties: -- compatible: must be "eeti,exc3000" -- reg: i2c slave address -- interrupts: touch controller interrupt -- touchscreen-size-x: See touchscreen.txt -- touchscreen-size-y: See touchscreen.txt - -Optional properties: -- touchscreen-inverted-x: See touchscreen.txt -- touchscreen-inverted-y: See touchscreen.txt -- touchscreen-swapped-x-y: See touchscreen.txt - -Example: - - touchscreen@2a { - compatible = "eeti,exc3000"; - reg = <0x2a>; - interrupt-parent = <&gpio1>; - interrupts = <9 IRQ_TYPE_LEVEL_LOW>; - touchscreen-size-x = <4096>; - touchscreen-size-y = <4096>; - touchscreen-inverted-x; - touchscreen-swapped-x-y; - }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index d7ceb4c34423..503160a7b9a0 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -37,7 +37,18 @@ properties: - enum: - qcom,sc7180-smmu-500 - qcom,sdm845-smmu-500 + - qcom,sm8150-smmu-500 + - qcom,sm8250-smmu-500 - const: arm,mmu-500 + - description: Marvell SoCs implementing "arm,mmu-500" + items: + - const: marvell,ap806-smmu-500 + - const: arm,mmu-500 + - description: NVIDIA SoCs that program two ARM MMU-500s identically + items: + - enum: + - nvidia,tegra194-smmu + - const: nvidia,smmu-500 - items: - const: arm,mmu-500 - const: arm,smmu-v2 @@ -55,7 +66,8 @@ properties: - cavium,smmu-v2 reg: - maxItems: 1 + minItems: 1 + maxItems: 2 '#global-interrupts': description: The number of global interrupts exposed by the device. @@ -138,6 +150,23 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra194-smmu + then: + properties: + reg: + minItems: 2 + maxItems: 2 + else: + properties: + reg: + maxItems: 1 + examples: - |+ /* SMMU with stream matching or stream indexing */ diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt index ce59a505f5a4..c1ccd8582eb2 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt @@ -58,6 +58,7 @@ Required properties: - compatible : must be one of the following string: "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW. "mediatek,mt2712-m4u" for mt2712 which uses generation two m4u HW. + "mediatek,mt6779-m4u" for mt6779 which uses generation two m4u HW. "mediatek,mt7623-m4u", "mediatek,mt2701-m4u" for mt7623 which uses generation one m4u HW. "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW. @@ -78,6 +79,7 @@ Required properties: Specifies the mtk_m4u_id as defined in dt-binding/memory/mt2701-larb-port.h for mt2701, mt7623 dt-binding/memory/mt2712-larb-port.h for mt2712, + dt-binding/memory/mt6779-larb-port.h for mt6779, dt-binding/memory/mt8173-larb-port.h for mt8173, and dt-binding/memory/mt8183-larb-port.h for mt8183. diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index 5e4fe54f51cd..6bfa090fd73a 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -36,6 +36,7 @@ properties: - renesas,ipmmu-r8a774c0 # RZ/G2E - renesas,ipmmu-r8a7795 # R-Car H3 - renesas,ipmmu-r8a7796 # R-Car M3-W + - renesas,ipmmu-r8a77961 # R-Car M3-W+ - renesas,ipmmu-r8a77965 # R-Car M3-N - renesas,ipmmu-r8a77970 # R-Car V3M - renesas,ipmmu-r8a77980 # R-Car V3H diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 0b5b2a6bcc48..cf48cd806e00 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to mailbox.txt for generic information about mailbox device-tree bindings. Required properties: -- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce" +- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or + "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -34,8 +35,9 @@ Optional properties for a client device: start_offset: the start offset of register address that GCE can access. size: the total size of register address that GCE can access. -Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h' -or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids. +Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', +'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as +sub-system ids, thread priority, event ids. Example: diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 12eff942708d..8f810fc5c183 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -18,10 +18,12 @@ properties: enum: - qcom,ipq8074-apcs-apps-global - qcom,msm8916-apcs-kpss-global + - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global - qcom,qcs404-apcs-apps-global - qcom,sc7180-apss-shared + - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared - qcom,sm8150-apss-shared diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml new file mode 100644 index 000000000000..daa2869377c5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Chrontel HDMI-CEC Controller + +maintainers: + - Jeff Chase <jnchase@google.com> + +description: + The Chrontel CH7322 is a discrete HDMI-CEC controller. It is + programmable through I2C and drives a single CEC line. + +properties: + compatible: + const: chrontel,ch7322 + + reg: + description: I2C device address + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + description: + Reference to the GPIO connected to the RESET pin, if any. This + pin is active-low. + maxItems: 1 + + standby-gpios: + description: + Reference to the GPIO connected to the OE pin, if any. When low + the device will respond to power status requests with "standby" + if in auto mode. + maxItems: 1 + + # see ../cec.txt + hdmi-phandle: + description: phandle to the HDMI controller + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + ch7322@75 { + compatible = "chrontel,ch7322"; + reg = <0x75>; + interrupts = <47 IRQ_TYPE_EDGE_RISING>; + standby-gpios = <&gpio 16 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio 15 GPIO_ACTIVE_LOW>; + hdmi-phandle = <&hdmi>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml new file mode 100644 index 000000000000..cb96e95d7e81 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9768.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dongwoon Anatech DW9768 Voice Coil Motor (VCM) Lens Device Tree Bindings + +maintainers: + - Dongchun Zhu <dongchun.zhu@mediatek.com> + +description: |- + The Dongwoon DW9768 is a single 10-bit digital-to-analog (DAC) converter + with 100 mA output current sink capability. VCM current is controlled with + a linear mode driver. The DAC is controlled via a 2-wire (I2C-compatible) + serial interface that operates at clock rates up to 1MHz. This chip + integrates Advanced Actuator Control (AAC) technology and is intended for + driving voice coil lenses in camera modules. + +properties: + compatible: + enum: + - dongwoon,dw9768 # for DW9768 VCM + - giantec,gt9769 # for GT9769 VCM + + reg: + maxItems: 1 + + vin-supply: + description: + Definition of the regulator used as Digital I/O voltage supply. + + vdd-supply: + description: + Definition of the regulator used as Digital core voltage supply. + + dongwoon,aac-mode: + description: + Indication of AAC mode select. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 1 # AAC2 mode(operation time# 0.48 x Tvib) + - 2 # AAC3 mode(operation time# 0.70 x Tvib) + - 3 # AAC4 mode(operation time# 0.75 x Tvib) + - 5 # AAC8 mode(operation time# 1.13 x Tvib) + default: 2 + + dongwoon,aac-timing: + description: + Number of AAC Timing count that controlled by one 6-bit period of + vibration register AACT[5:0], the unit of which is 100 us. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - default: 0x20 + minimum: 0x00 + maximum: 0x3f + + dongwoon,clock-presc: + description: + Indication of VCM internal clock dividing rate select, as one multiple + factor to calculate VCM ring periodic time Tvib. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 0 # Dividing Rate - 2 + - 1 # Dividing Rate - 1 + - 2 # Dividing Rate - 1/2 + - 3 # Dividing Rate - 1/4 + - 4 # Dividing Rate - 8 + - 5 # Dividing Rate - 4 + default: 1 + +required: + - compatible + - reg + - vin-supply + - vdd-supply + +additionalProperties: false + +examples: + - | + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + dw9768: camera-lens@c { + compatible = "dongwoon,dw9768"; + reg = <0x0c>; + + vin-supply = <&mt6358_vcamio_reg>; + vdd-supply = <&mt6358_vcama2_reg>; + dongwoon,aac-timing = <0x39>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml new file mode 100644 index 000000000000..5ad4b8c356cf --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/imi,rdacm2x-gmsl.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +# Copyright (C) 2019 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/imi,rdacm2x-gmsl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IMI D&D RDACM20 and RDACM21 Automotive Camera Platforms + +maintainers: + - Jacopo Mondi <jacopo+renesas@jmondi.org> + - Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + - Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> + +description: -| + The IMI D&D RDACM20 and RDACM21 are GMSL-compatible camera designed for + automotive applications. + + The RDACM20 camera module encloses a Maxim Integrated MAX9271 GMSL serializer, + coupled with an OV10635 image sensor and an embedded MCU. Both the MCU and + the image sensor are connected to the serializer local I2C bus and are + accessible by the host SoC by direct addressing. + + The RDACM21 camera module encloses the same serializer, coupled with an + OV10640 image sensor and an OV490 ISP. Only the OV490 ISP is interfaced to + the serializer local I2C bus while the image sensor is not accessible from + the host SoC. + + They both connect to a remote GMSL endpoint through a coaxial cable. + + IMI RDACM20 + +---------------+ +--------------------------------+ + | GMSL | <- Video Stream | <- Video--------\ | + | |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV10635 | + | de-serializer | <- I2C messages -> | \<-->MCU | + +---------------+ +--------------------------------+ + + IMI RDACM21 + +---------------+ +--------------------------------+ + | GMSL | <- Video Stream | <- Video--------\ | + | |< === GMSL Link ====== >|MAX9271<- I2C bus-> <-->OV490 | + | | <- I2C messages -> | | | + | de-serializer | | OV10640 <-------| | + +---------------+ +--------------------------------+ + + Both camera modules serialize video data generated by the embedded camera + sensor on the GMSL serial channel to a remote GMSL de-serializer. They also + receive and transmit I2C messages encapsulated and transmitted on the GMSL + bidirectional control channel. + + All I2C traffic received on the GMSL link not directed to the serializer is + propagated on the local I2C bus to the remote device there connected. All the + I2C traffic generated on the local I2C bus not directed to the serializer is + propagated to the remote de-serializer encapsulated in the GMSL control + channel. + + The RDACM20 and RDACM21 DT node should be a direct child of the GMSL + deserializer's I2C bus corresponding to the GMSL link that the camera is + attached to. + +properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + compatible: + enum: + - imi,rdacm20 + - imi,rdacm21 + + reg: + description: -| + I2C device addresses, the first to be assigned to the serializer, the + following ones to be assigned to the remote devices. + + For RDACM20 the second entry of the property is assigned to the + OV10635 image sensor and the optional third one to the embedded MCU. + + For RDACM21 the second entry is assigned to the OV490 ISP and the optional + third one ignored. + + minItems: 2 + maxItems: 3 + + port: + type: object + additionalProperties: false + description: -| + Connection to the remote GMSL endpoint are modelled using the OF graph + bindings in accordance with the video interface bindings defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + + The device node contains a single "port" child node with a single + "endpoint" sub-device. + + properties: + endpoint: + type: object + additionalProperties: false + + properties: + remote-endpoint: + description: -| + phandle to the remote GMSL endpoint sub-node in the remote node + port. + maxItems: 1 + + required: + - remote-endpoint + + required: + - endpoint + +required: + - compatible + - reg + - port + +examples: + - | + i2c@e66d8000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe66d8000>; + + camera@31 { + compatible = "imi,rdacm20"; + reg = <0x31>, <0x41>, <0x51>; + + port { + rdacm20_out0: endpoint { + remote-endpoint = <&max9286_in0>; + }; + }; + }; + }; + + - | + i2c@e66d8000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe66d8000>; + + camera@31 { + compatible = "imi,rdacm21"; + reg = <0x31>, <0x41>; + + port { + rdacm21_out0: endpoint { + remote-endpoint = <&max9286_in0>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml new file mode 100644 index 000000000000..e7b543159d15 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -0,0 +1,366 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/maxim,max9286.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated Quad GMSL Deserializer + +maintainers: + - Jacopo Mondi <jacopo+renesas@jmondi.org> + - Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + - Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> + +description: | + The MAX9286 deserializer receives video data on up to 4 Gigabit Multimedia + Serial Links (GMSL) and outputs them on a CSI-2 D-PHY port using up to 4 data + lanes. + + In addition to video data, the GMSL links carry a bidirectional control + channel that encapsulates I2C messages. The MAX9286 forwards all I2C traffic + not addressed to itself to the other side of the links, where a GMSL + serializer will output it on a local I2C bus. In the other direction all I2C + traffic received over GMSL by the MAX9286 is output on the local I2C bus. + +properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + compatible: + const: maxim,max9286 + + reg: + description: I2C device address + maxItems: 1 + + poc-supply: + description: Regulator providing Power over Coax to the cameras + maxItems: 1 + + enable-gpios: + description: GPIO connected to the \#PWDN pin with inverted polarity + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + ports: + type: object + description: | + The connections to the MAX9286 GMSL and its endpoint nodes are modelled + using the OF graph bindings in accordance with the video interface + bindings defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + + The following table lists the port number corresponding to each device + port. + + Port Description + ---------------------------------------- + Port 0 GMSL Input 0 + Port 1 GMSL Input 1 + Port 2 GMSL Input 2 + Port 3 GMSL Input 3 + Port 4 CSI-2 Output + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@[0-3]: + type: object + properties: + reg: + enum: [ 0, 1, 2, 3 ] + + endpoint: + type: object + + properties: + remote-endpoint: + description: | + phandle to the remote GMSL source endpoint subnode in the + remote node port. + + required: + - remote-endpoint + + required: + - reg + - endpoint + + additionalProperties: false + + port@4: + type: object + properties: + reg: + const: 4 + + endpoint: + type: object + + properties: + remote-endpoint: + description: phandle to the remote CSI-2 sink endpoint. + + data-lanes: + description: array of physical CSI-2 data lane indexes. + + required: + - remote-endpoint + - data-lanes + + required: + - reg + - endpoint + + additionalProperties: false + + required: + - port@4 + + i2c-mux: + type: object + description: | + Each GMSL link is modelled as a child bus of an i2c bus + multiplexer/switch, in accordance with bindings described in + Documentation/devicetree/bindings/i2c/i2c-mux.txt. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + "^i2c@[0-3]$": + type: object + description: | + Child node of the i2c bus multiplexer which represents a GMSL link. + Each serializer device on the GMSL link remote end is represented with + an i2c-mux child node. The MAX9286 chip supports up to 4 GMSL + channels. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + reg: + description: The index of the GMSL channel. + maxItems: 1 + + patternProperties: + "^camera@[a-f0-9]+$": + type: object + description: | + The remote camera device, composed by a GMSL serializer and a + connected video source. + + properties: + compatible: + description: The remote device compatible string. + + reg: + minItems: 2 + maxItems: 3 + description: | + The I2C addresses to be assigned to the remote devices through + address reprogramming. The number of entries depends on the + requirements of the currently connected remote device. + + port: + type: object + + properties: + endpoint: + type: object + + properties: + remote-endpoint: + description: phandle to the MAX9286 sink endpoint. + + required: + - remote-endpoint + + additionalProperties: false + + required: + - endpoint + + additionalProperties: false + + required: + - compatible + - reg + - port + + additionalProperties: false + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - ports + - i2c-mux + - gpio-controller + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c@e66d8000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe66d8000>; + + gmsl-deserializer@2c { + compatible = "maxim,max9286"; + reg = <0x2c>; + poc-supply = <&camera_poc_12v>; + enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + max9286_in0: endpoint { + remote-endpoint = <&rdacm20_out0>; + }; + }; + + port@1 { + reg = <1>; + + max9286_in1: endpoint { + remote-endpoint = <&rdacm20_out1>; + }; + }; + + port@2 { + reg = <2>; + + max9286_in2: endpoint { + remote-endpoint = <&rdacm20_out2>; + }; + }; + + port@3 { + reg = <3>; + + max9286_in3: endpoint { + remote-endpoint = <&rdacm20_out3>; + }; + }; + + port@4 { + reg = <4>; + + max9286_out: endpoint { + data-lanes = <1 2 3 4>; + remote-endpoint = <&csi40_in>; + }; + }; + }; + + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + camera@51 { + compatible = "imi,rdacm20"; + reg = <0x51>, <0x61>; + + port { + rdacm20_out0: endpoint { + remote-endpoint = <&max9286_in0>; + }; + }; + + }; + }; + + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + camera@52 { + compatible = "imi,rdacm20"; + reg = <0x52>, <0x62>; + + port { + rdacm20_out1: endpoint { + remote-endpoint = <&max9286_in1>; + }; + }; + }; + }; + + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + camera@53 { + compatible = "imi,rdacm20"; + reg = <0x53>, <0x63>; + + port { + rdacm20_out2: endpoint { + remote-endpoint = <&max9286_in2>; + }; + }; + }; + }; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + camera@54 { + compatible = "imi,rdacm20"; + reg = <0x54>, <0x64>; + + port { + rdacm20_out3: endpoint { + remote-endpoint = <&max9286_in3>; + }; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt b/Documentation/devicetree/bindings/media/renesas,fcp.txt deleted file mode 100644 index 79c37395b396..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt +++ /dev/null @@ -1,34 +0,0 @@ -Renesas R-Car Frame Compression Processor (FCP) ------------------------------------------------ - -The FCP is a companion module of video processing modules in the Renesas R-Car -Gen3 and RZ/G2 SoCs. It provides data compression and decompression, data -caching, and conversion of AXI transactions in order to reduce the memory -bandwidth. - -There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and FCP -for FDP (FCPF). Their configuration and behaviour depend on the module they -are paired with. These DT bindings currently support the FCPV and FCPF. - - - compatible: Must be one or more of the following - - - "renesas,fcpv" for generic compatible 'FCP for VSP' - - "renesas,fcpf" for generic compatible 'FCP for FDP' - - - reg: the register base and size for the device registers - - clocks: Reference to the functional clock - -Optional properties: - - power-domains : power-domain property defined with a power domain specifier - to respective power domain. - - -Device node example -------------------- - - fcpvd1: fcp@fea2f000 { - compatible = "renesas,fcpv"; - reg = <0 0xfea2f000 0 0x200>; - clocks = <&cpg CPG_MOD 602>; - power-domains = <&sysc R8A7795_PD_A3VP>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml new file mode 100644 index 000000000000..43f2fed8cd33 --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,fcp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Frame Compression Processor (FCP) + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The FCP is a companion module of video processing modules in the Renesas + R-Car Gen3 and RZ/G2 SoCs. It provides data compression and decompression, + data caching, and conversion of AXI transactions in order to reduce the + memory bandwidth. + + There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and + FCP for FDP (FCPF). Their configuration and behaviour depend on the module + they are paired with. These DT bindings currently support the FCPV and FCPF. + +properties: + compatible: + enum: + - renesas,fcpv # FCP for VSP + - renesas,fcpf # FCP for FDP + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + # R8A7795 (R-Car H3) FCP for VSP-D1 + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + fcp@fea2f000 { + compatible = "renesas,fcpv"; + reg = <0xfea2f000 0x200>; + clocks = <&cpg CPG_MOD 602>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 602>; + iommus = <&ipmmu_vi0 9>; + }; +... diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.txt b/Documentation/devicetree/bindings/media/renesas,fdp1.txt deleted file mode 100644 index 8dd1007bb573..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,fdp1.txt +++ /dev/null @@ -1,37 +0,0 @@ -Renesas R-Car Fine Display Processor (FDP1) -------------------------------------------- - -The FDP1 is a de-interlacing module which converts interlaced video to -progressive video. It is capable of performing pixel format conversion between -YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are supported as -an input to the module. - -Required properties: - - - compatible: must be "renesas,fdp1" - - reg: the register base and size for the device registers - - interrupts : interrupt specifier for the FDP1 instance - - clocks: reference to the functional clock - -Optional properties: - - - power-domains: reference to the power domain that the FDP1 belongs to, if - any. - - renesas,fcp: a phandle referencing the FCP that handles memory accesses - for the FDP1. Not needed on Gen2, mandatory on Gen3. - -Please refer to the binding documentation for the clock and/or power domain -providers for more details. - - -Device node example -------------------- - - fdp1@fe940000 { - compatible = "renesas,fdp1"; - reg = <0 0xfe940000 0 0x2400>; - interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 119>; - power-domains = <&sysc R8A7795_PD_A3VP>; - renesas,fcp = <&fcpf0>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,fdp1.yaml b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml new file mode 100644 index 000000000000..2a27a7296fea --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,fdp1.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,fdp1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Fine Display Processor (FDP1) + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: + The FDP1 is a de-interlacing module which converts interlaced video to + progressive video. It is capable of performing pixel format conversion + between YCbCr/YUV formats and RGB formats. Only YCbCr/YUV formats are + supported as an input to the module. + +properties: + compatible: + enum: + - renesas,fdp1 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,fcp: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle referencing the FCP that handles memory accesses for the FDP1. + Not allowed on R-Car Gen2, mandatory on R-Car Gen3. + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + fdp1@fe940000 { + compatible = "renesas,fdp1"; + reg = <0xfe940000 0x2400>; + interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 119>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 119>; + renesas,fcp = <&fcpf0>; + }; +... diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt deleted file mode 100644 index cd5a955b2ea0..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Renesas VSP Video Processing Engine - -The VSP is a video processing engine that supports up-/down-scaling, alpha -blending, color space conversion and various other image processing features. -It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs. - -Required properties: - - - compatible: Must contain one of the following values - - "renesas,vsp1" for the R-Car Gen2 and RZ/G1 VSP1 - - "renesas,vsp2" for the R-Car Gen3 and RZ/G2 VSP2 - - - reg: Base address and length of the registers block for the VSP. - - interrupts: VSP interrupt specifier. - - clocks: A phandle + clock-specifier pair for the VSP functional clock. - -Optional properties: - - - renesas,fcp: A phandle referencing the FCP that handles memory accesses - for the VSP. Not needed on Gen2, mandatory on Gen3. - - -Example: R8A7790 (R-Car H2) VSP1-S node - - vsp@fe928000 { - compatible = "renesas,vsp1"; - reg = <0 0xfe928000 0 0x8000>; - interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml new file mode 100644 index 000000000000..990e9c1dbc43 --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,vsp1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas VSP Video Processing Engine + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: + The VSP is a video processing engine that supports up-/down-scaling, alpha + blending, color space conversion and various other image processing features. + It can be found in the Renesas R-Car Gen2, R-Car Gen3, RZ/G1, and RZ/G2 SoCs. + +properties: + compatible: + enum: + - renesas,vsp1 # R-Car Gen2 and RZ/G1 + - renesas,vsp2 # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,fcp: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle referencing the FCP that handles memory accesses for the VSP. + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +if: + properties: + compatible: + items: + - const: renesas,vsp1 +then: + properties: + renesas,fcp: false +else: + required: + - renesas,fcp + +examples: + # R8A7790 (R-Car H2) VSP1-S + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + vsp@fe928000 { + compatible = "renesas,vsp1"; + reg = <0xfe928000 0x8000>; + interrupts = <GIC_SPI 267 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 131>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 131>; + }; + + # R8A77951 (R-Car H3) VSP2-BC + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + vsp@fe920000 { + compatible = "renesas,vsp2"; + reg = <0xfe920000 0x8000>; + interrupts = <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 624>; + power-domains = <&sysc R8A7795_PD_A3VP>; + resets = <&cpg 624>; + + renesas,fcp = <&fcpvb1>; + }; +... diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml new file mode 100644 index 000000000000..7b9407c0520e --- /dev/null +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml @@ -0,0 +1,237 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx MIPI CSI-2 Receiver Subsystem + +maintainers: + - Vishal Sagar <vishal.sagar@xilinx.com> + +description: | + The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI CSI-2 + traffic from compliant camera sensors and send the output as AXI4 Stream + video data for image processing. + The subsystem consists of a MIPI D-PHY in slave mode which captures the + data packets. This is passed along the MIPI CSI-2 Rx IP which extracts the + packet data. The optional Video Format Bridge (VFB) converts this data to + AXI4 Stream video data. + For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver Subsystem. + Please note that this bindings includes only the MIPI CSI-2 Rx controller + and Video Format Bridge and not D-PHY. + +properties: + compatible: + items: + - enum: + - xlnx,mipi-csi2-rx-subsystem-5.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: List of clock specifiers + items: + - description: AXI Lite clock + - description: Video clock + + clock-names: + items: + - const: lite_aclk + - const: video_aclk + + xlnx,csi-pxl-format: + description: | + This denotes the CSI Data type selected in hw design. + Packets other than this data type (except for RAW8 and + User defined data types) will be filtered out. + Possible values are as below - + 0x1e - YUV4228B + 0x1f - YUV42210B + 0x20 - RGB444 + 0x21 - RGB555 + 0x22 - RGB565 + 0x23 - RGB666 + 0x24 - RGB888 + 0x28 - RAW6 + 0x29 - RAW7 + 0x2a - RAW8 + 0x2b - RAW10 + 0x2c - RAW12 + 0x2d - RAW14 + 0x2e - RAW16 + 0x2f - RAW20 + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - anyOf: + - minimum: 0x1e + - maximum: 0x24 + - minimum: 0x28 + - maximum: 0x2f + + xlnx,vfb: + type: boolean + description: Present when Video Format Bridge is enabled in IP configuration + + xlnx,en-csi-v2-0: + type: boolean + description: Present if CSI v2 is enabled in IP configuration. + + xlnx,en-vcx: + type: boolean + description: | + When present, there are maximum 16 virtual channels, else only 4. + + xlnx,en-active-lanes: + type: boolean + description: | + Present if the number of active lanes can be re-configured at + runtime in the Protocol Configuration Register. Otherwise all lanes, + as set in IP configuration, are always active. + + video-reset-gpios: + description: Optional specifier for a GPIO that asserts video_aresetn. + maxItems: 1 + + ports: + type: object + + properties: + port@0: + type: object + description: | + Input / sink port node, single endpoint describing the + CSI-2 transmitter. + + properties: + reg: + const: 0 + + endpoint: + type: object + + properties: + + data-lanes: + description: | + This is required only in the sink port 0 endpoint which + connects to MIPI CSI-2 source like sensor. + The possible values are - + 1 - For 1 lane enabled in IP. + 1 2 - For 2 lanes enabled in IP. + 1 2 3 - For 3 lanes enabled in IP. + 1 2 3 4 - For 4 lanes enabled in IP. + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + remote-endpoint: true + + required: + - data-lanes + - remote-endpoint + + additionalProperties: false + + additionalProperties: false + + port@1: + type: object + description: | + Output / source port node, endpoint describing modules + connected the CSI-2 receiver. + + properties: + + reg: + const: 1 + + endpoint: + type: object + + properties: + + remote-endpoint: true + + required: + - remote-endpoint + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - ports + +allOf: + - if: + required: + - xlnx,vfb + then: + required: + - xlnx,csi-pxl-format + else: + properties: + xlnx,csi-pxl-format: false + + - if: + not: + required: + - xlnx,en-csi-v2-0 + then: + properties: + xlnx,en-vcx: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + xcsi2rxss_1: csi2rx@a0020000 { + compatible = "xlnx,mipi-csi2-rx-subsystem-5.0"; + reg = <0xa0020000 0x10000>; + interrupt-parent = <&gic>; + interrupts = <0 95 4>; + xlnx,csi-pxl-format = <0x2a>; + xlnx,vfb; + xlnx,en-active-lanes; + xlnx,en-csi-v2-0; + xlnx,en-vcx; + clock-names = "lite_aclk", "video_aclk"; + clocks = <&misc_clk_0>, <&misc_clk_1>; + video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + /* Sink port */ + reg = <0>; + csiss_in: endpoint { + data-lanes = <1 2 3 4>; + /* MIPI CSI-2 Camera handle */ + remote-endpoint = <&camera_out>; + }; + }; + port@1 { + /* Source port */ + reg = <1>; + csiss_out: endpoint { + remote-endpoint = <&vproc_in>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt index b478ade4da65..b64573680b42 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt @@ -5,7 +5,7 @@ The hardware block diagram please check bindings/iommu/mediatek,iommu.txt Mediatek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. -generation 2: mt2712, mt8173 and mt8183. +generation 2: mt2712, mt6779, mt8173 and mt8183. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -18,6 +18,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-common" "mediatek,mt2712-smi-common" + "mediatek,mt6779-smi-common" "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" "mediatek,mt8173-smi-common" "mediatek,mt8183-smi-common" @@ -35,7 +36,7 @@ Required properties: and these 2 option clocks for generation 2 smi HW: - "gals0": the path0 clock of GALS(Global Async Local Sync). - "gals1": the path1 clock of GALS(Global Async Local Sync). - Here is the list which has this GALS: mt8183. + Here is the list which has this GALS: mt6779 and mt8183. Example: smi_common: smi@14022000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt index 4b369b3e1a69..8f19dfe7d80e 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt @@ -6,6 +6,7 @@ Required properties: - compatible : must be one of : "mediatek,mt2701-smi-larb" "mediatek,mt2712-smi-larb" + "mediatek,mt6779-smi-larb" "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" "mediatek,mt8173-smi-larb" "mediatek,mt8183-smi-larb" @@ -21,7 +22,7 @@ Required properties: - "gals": the clock for GALS(Global Async Local Sync). Here is the list which has this GALS: mt8183. -Required property for mt2701, mt2712 and mt7623: +Required property for mt2701, mt2712, mt6779 and mt7623: - mediatek,larb-id :the hardware id of this larb. Example: diff --git a/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml new file mode 100644 index 000000000000..70eaf739036b --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml @@ -0,0 +1,252 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/st,stm32-fmc2-ebi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings + +description: | + The FMC2 functional block makes the interface with: synchronous and + asynchronous static devices (such as PSNOR, PSRAM or other memory-mapped + peripherals) and NAND flash memories. + Its main purposes are: + - to translate AXI transactions into the appropriate external device + protocol + - to meet the access time requirements of the external devices + All external devices share the addresses, data and control signals with the + controller. Each external device is accessed by means of a unique Chip + Select. The FMC2 performs only one access at a time to an external device. + +maintainers: + - Christophe Kerello <christophe.kerello@st.com> + +properties: + compatible: + const: st,stm32mp1-fmc2-ebi + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + ranges: + description: | + Reflects the memory layout with four integer values per bank. Format: + <bank-number> 0 <address of the bank> <size> + +patternProperties: + "^.*@[0-4],[a-f0-9]+$": + type: object + + properties: + reg: + description: Bank number, base address and size of the device. + + st,fmc2-ebi-cs-transaction-type: + description: | + Select one of the transactions type supported + 0: Asynchronous mode 1 SRAM/FRAM. + 1: Asynchronous mode 1 PSRAM. + 2: Asynchronous mode A SRAM/FRAM. + 3: Asynchronous mode A PSRAM. + 4: Asynchronous mode 2 NOR. + 5: Asynchronous mode B NOR. + 6: Asynchronous mode C NOR. + 7: Asynchronous mode D NOR. + 8: Synchronous read synchronous write PSRAM. + 9: Synchronous read asynchronous write PSRAM. + 10: Synchronous read synchronous write NOR. + 11: Synchronous read asynchronous write NOR. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 11 + + st,fmc2-ebi-cs-cclk-enable: + description: Continuous clock enable (first bank must be configured + in synchronous mode). The FMC_CLK is generated continuously + during asynchronous and synchronous access. By default, the + FMC_CLK is only generated during synchronous access. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-mux-enable: + description: Address/Data multiplexed on databus (valid only with + NOR and PSRAM transactions type). By default, Address/Data + are not multiplexed. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-buswidth: + description: Data bus width + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 16 ] + default: 16 + + st,fmc2-ebi-cs-waitpol-high: + description: Wait signal polarity (NWAIT signal active high). + By default, NWAIT is active low. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-waitcfg-enable: + description: The NWAIT signal indicates wheither the data from the + device are valid or if a wait state must be inserted when accessing + the device in synchronous mode. By default, the NWAIT signal is + active one data cycle before wait state. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-wait-enable: + description: The NWAIT signal is enabled (its level is taken into + account after the programmed latency period to insert wait states + if asserted). By default, the NWAIT signal is disabled. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-asyncwait-enable: + description: The NWAIT signal is taken into account during asynchronous + transactions. By default, the NWAIT signal is not taken into account + during asynchronous transactions. + $ref: /schemas/types.yaml#/definitions/flag + + st,fmc2-ebi-cs-cpsize: + description: CRAM page size. The controller splits the burst access + when the memory page is reached. By default, no burst split when + crossing page boundary. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 128, 256, 512, 1024 ] + default: 0 + + st,fmc2-ebi-cs-byte-lane-setup-ns: + description: This property configures the byte lane setup timing + defined in nanoseconds from NBLx low to Chip Select NEx low. + + st,fmc2-ebi-cs-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed read/write + transactions. + + st,fmc2-ebi-cs-data-setup-ns: + description: This property defines the duration of the data setup phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-bus-turnaround-ns: + description: This property defines the delay in nanoseconds between the + end of current read/write transaction and the next transaction. + + st,fmc2-ebi-cs-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous read/write transactions. + + st,fmc2-ebi-cs-clk-period-ns: + description: This property defines the FMC_CLK output signal period in + nanoseconds. + + st,fmc2-ebi-cs-data-latency-ns: + description: This property defines the data latency before reading or + writing the first data in nanoseconds. + + st,fmc2_ebi-cs-write-address-setup-ns: + description: This property defines the duration of the address setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-address-hold-ns: + description: This property defines the duration of the address hold + phase in nanoseconds used for asynchronous multiplexed write + transactions. + + st,fmc2-ebi-cs-write-data-setup-ns: + description: This property defines the duration of the data setup + phase in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-write-bus-turnaround-ns: + description: This property defines the delay between the end of current + write transaction and the next transaction in nanoseconds. + + st,fmc2-ebi-cs-write-data-hold-ns: + description: This property defines the duration of the data hold phase + in nanoseconds used for asynchronous write transactions. + + st,fmc2-ebi-cs-max-low-pulse-ns: + description: This property defines the maximum chip select low pulse + duration in nanoseconds for synchronous transactions. When this timing + reaches 0, the controller splits the current access, toggles NE to + allow device refresh and restarts a new access. + + required: + - reg + +required: + - "#address-cells" + - "#size-cells" + - compatible + - reg + - clocks + - ranges + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/stm32mp1-clks.h> + #include <dt-bindings/reset/stm32mp1-resets.h> + memory-controller@58002000 { + #address-cells = <2>; + #size-cells = <1>; + compatible = "st,stm32mp1-fmc2-ebi"; + reg = <0x58002000 0x1000>; + clocks = <&rcc FMC_K>; + resets = <&rcc FMC_R>; + + ranges = <0 0 0x60000000 0x04000000>, /* EBI CS 1 */ + <1 0 0x64000000 0x04000000>, /* EBI CS 2 */ + <2 0 0x68000000 0x04000000>, /* EBI CS 3 */ + <3 0 0x6c000000 0x04000000>, /* EBI CS 4 */ + <4 0 0x80000000 0x10000000>; /* NAND */ + + psram@0,0 { + compatible = "mtd-ram"; + reg = <0 0x00000000 0x100000>; + bank-width = <2>; + + st,fmc2-ebi-cs-transaction-type = <1>; + st,fmc2-ebi-cs-address-setup-ns = <60>; + st,fmc2-ebi-cs-data-setup-ns = <30>; + st,fmc2-ebi-cs-bus-turnaround-ns = <5>; + }; + + nand-controller@4,0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "st,stm32mp1-fmc2-nfc"; + reg = <4 0x00000000 0x1000>, + <4 0x08010000 0x1000>, + <4 0x08020000 0x1000>, + <4 0x01000000 0x1000>, + <4 0x09010000 0x1000>, + <4 0x09020000 0x1000>; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>, + <&mdma1 20 0x2 0x12000a08 0x0 0x0>, + <&mdma1 21 0x2 0x12000a0a 0x0 0x0>; + dma-names = "tx", "rx", "ecc"; + + nand@0 { + reg = <0>; + nand-on-flash-bbt; + #address-cells = <1>; + #size-cells = <1>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt index cfb18abe6001..edebeae1f5b3 100644 --- a/Documentation/devicetree/bindings/mtd/davinci-nand.txt +++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt @@ -4,8 +4,8 @@ This file provides information, what the device node for the davinci/keystone NAND interface contains. Documentation: -Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf -Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf +Davinci DM646x - https://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf +Kestone - https://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf Required properties: diff --git a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt index fce4894f5a98..25f07c1f9e44 100644 --- a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt +++ b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt @@ -7,14 +7,16 @@ Required properties: - fsl,upm-cmd-offset : UPM pattern offset for the command latch. Optional properties: -- fsl,upm-wait-flags : add chip-dependent short delays after running the - UPM pattern (0x1), after writing a data byte (0x2) or after - writing out a buffer (0x4). - fsl,upm-addr-line-cs-offsets : address offsets for multi-chip support. The corresponding address lines are used to select the chip. - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins (R/B#). For multi-chip devices, "n" GPIO definitions are required according to the number of chips. + +Deprecated properties: +- fsl,upm-wait-flags : add chip-dependent short delays after running the + UPM pattern (0x1), after writing a data byte (0x2) or after + writing out a buffer (0x4). - chip-delay : chip dependent delay for transferring data from array to read registers (tR). Required if property "gpios" is not used (R/B# pins not connected). @@ -52,8 +54,6 @@ upm@3,0 { fsl,upm-cmd-offset = <0x08>; /* Multi-chip NAND device */ fsl,upm-addr-line-cs-offsets = <0x0 0x200>; - fsl,upm-wait-flags = <0x5>; - chip-delay = <25>; // in micro-seconds nand@0 { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index cde7c4d79efe..40fc5b0b2b8c 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -114,6 +114,13 @@ patternProperties: description: Contains the native Ready/Busy IDs. + rb-gpios: + description: + Contains one or more GPIO descriptor (the numper of descriptor + depends on the number of R/B pins exposed by the flash) for the + Ready/Busy pins. Active state refers to the NAND ready state and + should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + required: - reg diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml index b059267f6d20..6ae7de15d172 100644 --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml @@ -9,32 +9,19 @@ title: STMicroelectronics Flexible Memory Controller 2 (FMC2) Bindings maintainers: - Christophe Kerello <christophe.kerello@st.com> -allOf: - - $ref: "nand-controller.yaml#" - properties: compatible: - const: st,stm32mp15-fmc2 + enum: + - st,stm32mp15-fmc2 + - st,stm32mp1-fmc2-nfc reg: - items: - - description: Registers - - description: Chip select 0 data - - description: Chip select 0 command - - description: Chip select 0 address space - - description: Chip select 1 data - - description: Chip select 1 command - - description: Chip select 1 address space + minItems: 6 + maxItems: 7 interrupts: maxItems: 1 - clocks: - maxItems: 1 - - resets: - maxItems: 1 - dmas: items: - description: tx DMA channel @@ -57,11 +44,55 @@ patternProperties: nand-ecc-strength: enum: [1, 4 ,8 ] +allOf: + - $ref: "nand-controller.yaml#" + + - if: + properties: + compatible: + contains: + const: st,stm32mp15-fmc2 + then: + properties: + reg: + items: + - description: Registers + - description: Chip select 0 data + - description: Chip select 0 command + - description: Chip select 0 address space + - description: Chip select 1 data + - description: Chip select 1 command + - description: Chip select 1 address space + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + required: + - clocks + + - if: + properties: + compatible: + contains: + const: st,stm32mp1-fmc2-nfc + then: + properties: + reg: + items: + - description: Chip select 0 data + - description: Chip select 0 command + - description: Chip select 0 address space + - description: Chip select 1 data + - description: Chip select 1 command + - description: Chip select 1 address space + required: - compatible - reg - interrupts - - clocks examples: - | @@ -77,13 +108,13 @@ examples: <0x81000000 0x1000>, <0x89010000 0x1000>, <0x89020000 0x1000>; - interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&mdma1 20 0x10 0x12000a02 0x0 0x0>, - <&mdma1 20 0x10 0x12000a08 0x0 0x0>, - <&mdma1 21 0x10 0x12000a0a 0x0 0x0>; - dma-names = "tx", "rx", "ecc"; - clocks = <&rcc FMC_K>; - resets = <&rcc FMC_R>; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&mdma1 20 0x2 0x12000a02 0x0 0x0>, + <&mdma1 20 0x2 0x12000a08 0x0 0x0>, + <&mdma1 21 0x2 0x12000a0a 0x0 0x0>; + dma-names = "tx", "rx", "ecc"; + clocks = <&rcc FMC_K>; + resets = <&rcc FMC_R>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml index 84a8f095d031..6d67067843bf 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml @@ -18,13 +18,12 @@ properties: const: cdns,cdns-pcie-host reg: - maxItems: 3 + maxItems: 2 reg-names: items: - const: reg - const: cfg - - const: mem msi-parent: true @@ -49,9 +48,8 @@ examples: device-id = <0x0200>; reg = <0x0 0xfb000000 0x0 0x01000000>, - <0x0 0x41000000 0x0 0x00001000>, - <0x0 0x40000000 0x0 0x04000000>; - reg-names = "reg", "cfg", "mem"; + <0x0 0x41000000 0x0 0x00001000>; + reg-names = "reg", "cfg"; ranges = <0x02000000 0x0 0x42000000 0x0 0x42000000 0x0 0x1000000>, <0x01000000 0x0 0x43000000 0x0 0x43000000 0x0 0x0010000>; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 7939bca47861..d099f3476ccc 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -112,28 +112,16 @@ Power supplies for Tegra124: - Required: - avddio-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V. - dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. - - avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must - supply 1.05 V. - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks. Must supply 3.3 V. - - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3). - Must supply 3.3 V. - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must supply 2.8-3.3 V. - - avdd-pll-erefe-supply: Power supply for PLLE (shared with USB3). Must - supply 1.05 V. Power supplies for Tegra210: - Required: - - avdd-pll-uerefe-supply: Power supply for PLLE (shared with USB3). Must - supply 1.05 V. - hvddio-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks. Must supply 1.8 V. - dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. - - dvdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must - supply 1.05 V. - - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3). - Must supply 3.3 V. - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must supply 1.8 V. diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt index 29bcbd88f457..6a8f2874a24d 100644 --- a/Documentation/devicetree/bindings/pci/pci.txt +++ b/Documentation/devicetree/bindings/pci/pci.txt @@ -1,12 +1,12 @@ PCI bus bridges have standardized Device Tree bindings: PCI Bus Binding to: IEEE Std 1275-1994 -http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf +https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf And for the interrupt mapping part: Open Firmware Recommended Practice: Interrupt Mapping -http://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf +https://www.devicetree.org/open-firmware/practice/imap/imap0_9d.pdf Additionally to the properties specified in the above standards a host bridge driver implementation may support the following properties: diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 981b4de12807..02bc81bb8b2d 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -5,6 +5,7 @@ Value type: <stringlist> Definition: Value should contain - "qcom,pcie-ipq8064" for ipq8064 + - "qcom,pcie-ipq8064-v2" for ipq8064 rev 2 or ipq8065 - "qcom,pcie-apq8064" for apq8064 - "qcom,pcie-apq8084" for apq8084 - "qcom,pcie-msm8996" for msm8996 or apq8096 @@ -90,6 +91,8 @@ Definition: Should contain the following entries - "core" Clocks the pcie hw block - "phy" Clocks the pcie PHY block + - "aux" Clocks the pcie AUX block + - "ref" Clocks the pcie ref block - clock-names: Usage: required for apq8084/ipq4019 Value type: <stringlist> @@ -177,6 +180,7 @@ - "pwr" PWR reset - "ahb" AHB reset - "phy_ahb" PHY AHB reset + - "ext" EXT reset - reset-names: Usage: required for ipq8074 @@ -277,14 +281,17 @@ <0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ clocks = <&gcc PCIE_A_CLK>, <&gcc PCIE_H_CLK>, - <&gcc PCIE_PHY_CLK>; - clock-names = "core", "iface", "phy"; + <&gcc PCIE_PHY_CLK>, + <&gcc PCIE_AUX_CLK>, + <&gcc PCIE_ALT_REF_CLK>; + clock-names = "core", "iface", "phy", "aux", "ref"; resets = <&gcc PCIE_ACLK_RESET>, <&gcc PCIE_HCLK_RESET>, <&gcc PCIE_POR_RESET>, <&gcc PCIE_PCI_RESET>, - <&gcc PCIE_PHY_RESET>; - reset-names = "axi", "ahb", "por", "pci", "phy"; + <&gcc PCIE_PHY_RESET>, + <&gcc PCIE_EXT_RESET>; + reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; pinctrl-0 = <&pcie_pins_default>; pinctrl-names = "default"; }; diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml new file mode 100644 index 000000000000..cfe25cface21 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-ep.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TI J721E PCI EP (PCIe Wrapper) + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: "cdns-pcie-ep.yaml#" + +properties: + compatible: + enum: + - ti,j721e-pcie-ep + + reg: + maxItems: 4 + + reg-names: + items: + - const: intd_cfg + - const: user_cfg + - const: reg + - const: mem + + ti,syscon-pcie-ctrl: + description: Phandle to the SYSCON entry required for configuring PCIe mode + and link speed. + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + power-domains: + maxItems: 1 + + clocks: + maxItems: 1 + description: clock-specifier to represent input to the PCIe + + clock-names: + items: + - const: fck + + dma-coherent: + description: Indicates that the PCIe IP block can ensure the coherency + +required: + - compatible + - reg + - reg-names + - ti,syscon-pcie-ctrl + - max-link-speed + - num-lanes + - power-domains + - clocks + - clock-names + - cdns,max-outbound-regions + - dma-coherent + - max-functions + - phys + - phy-names + +examples: + - | + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + pcie0_ep: pcie-ep@d000000 { + compatible = "ti,j721e-pcie-ep"; + reg = <0x00 0x02900000 0x00 0x1000>, + <0x00 0x02907000 0x00 0x400>, + <0x00 0x0d000000 0x00 0x00800000>, + <0x00 0x10000000 0x00 0x08000000>; + reg-names = "intd_cfg", "user_cfg", "reg", "mem"; + ti,syscon-pcie-ctrl = <&pcie0_ctrl>; + max-link-speed = <3>; + num-lanes = <2>; + power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>; + clocks = <&k3_clks 239 1>; + clock-names = "fck"; + cdns,max-outbound-regions = <16>; + max-functions = /bits/ 8 <6>; + dma-coherent; + phys = <&serdes0_pcie_link>; + phy-names = "pcie-phy"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml new file mode 100644 index 000000000000..d7b60487c6c3 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/pci/ti,j721e-pci-host.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TI J721E PCI Host (PCIe Wrapper) + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: "cdns-pcie-host.yaml#" + +properties: + compatible: + enum: + - ti,j721e-pcie-host + + reg: + maxItems: 4 + + reg-names: + items: + - const: intd_cfg + - const: user_cfg + - const: reg + - const: cfg + + ti,syscon-pcie-ctrl: + description: Phandle to the SYSCON entry required for configuring PCIe mode + and link speed. + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + power-domains: + maxItems: 1 + + clocks: + maxItems: 1 + description: clock-specifier to represent input to the PCIe + + clock-names: + items: + - const: fck + + vendor-id: + const: 0x104c + + device-id: + const: 0xb00d + + msi-map: true + +required: + - compatible + - reg + - reg-names + - ti,syscon-pcie-ctrl + - max-link-speed + - num-lanes + - power-domains + - clocks + - clock-names + - vendor-id + - device-id + - msi-map + - dma-coherent + - dma-ranges + - ranges + - reset-gpios + - phys + - phy-names + +examples: + - | + #include <dt-bindings/soc/ti,sci_pm_domain.h> + #include <dt-bindings/gpio/gpio.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + + pcie0_rc: pcie@2900000 { + compatible = "ti,j721e-pcie-host"; + reg = <0x00 0x02900000 0x00 0x1000>, + <0x00 0x02907000 0x00 0x400>, + <0x00 0x0d000000 0x00 0x00800000>, + <0x00 0x10000000 0x00 0x00001000>; + reg-names = "intd_cfg", "user_cfg", "reg", "cfg"; + ti,syscon-pcie-ctrl = <&pcie0_ctrl>; + max-link-speed = <3>; + num-lanes = <2>; + power-domains = <&k3_pds 239 TI_SCI_PD_EXCLUSIVE>; + clocks = <&k3_clks 239 1>; + clock-names = "fck"; + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x0 0xf>; + vendor-id = <0x104c>; + device-id = <0xb00d>; + msi-map = <0x0 &gic_its 0x0 0x10000>; + dma-coherent; + reset-gpios = <&exp1 6 GPIO_ACTIVE_HIGH>; + phys = <&serdes0_pcie_link>; + phy-names = "pcie-phy"; + ranges = <0x01000000 0x0 0x10001000 0x00 0x10001000 0x0 0x0010000>, + <0x02000000 0x0 0x10011000 0x00 0x10011000 0x0 0x7fef000>; + dma-ranges = <0x02000000 0x0 0x0 0x0 0x0 0x10000 0x0>; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml new file mode 100644 index 000000000000..a2bbc0eb7220 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/xilinx-versal-cpm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CPM Host Controller device tree for Xilinx Versal SoCs + +maintainers: + - Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + const: xlnx,versal-cpm-host-1.00 + + reg: + items: + - description: Configuration space region and bridge registers. + - description: CPM system level control and status registers. + + reg-names: + items: + - const: cfg + - const: cpm_slcr + + interrupts: + maxItems: 1 + + msi-map: + description: + Maps a Requester ID to an MSI controller and associated MSI sideband data. + + ranges: + maxItems: 2 + + "#interrupt-cells": + const: 1 + + interrupt-controller: + description: Interrupt controller node for handling legacy PCI interrupts. + type: object + properties: + "#address-cells": + const: 0 + "#interrupt-cells": + const: 1 + "interrupt-controller": true + additionalProperties: false + +required: + - reg + - reg-names + - "#interrupt-cells" + - interrupts + - interrupt-parent + - interrupt-map + - interrupt-map-mask + - bus-range + - msi-map + - interrupt-controller + +unevaluatedProperties: false + +examples: + - | + + versal { + #address-cells = <2>; + #size-cells = <2>; + cpm_pcie: pcie@fca10000 { + compatible = "xlnx,versal-cpm-host-1.00"; + device_type = "pci"; + #address-cells = <3>; + #interrupt-cells = <1>; + #size-cells = <2>; + interrupts = <0 72 4>; + interrupt-parent = <&gic>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc_0 0>, + <0 0 0 2 &pcie_intc_0 1>, + <0 0 0 3 &pcie_intc_0 2>, + <0 0 0 4 &pcie_intc_0 3>; + bus-range = <0x00 0xff>; + ranges = <0x02000000 0x0 0xe0000000 0x0 0xe0000000 0x0 0x10000000>, + <0x43000000 0x80 0x00000000 0x80 0x00000000 0x0 0x80000000>; + msi-map = <0x0 &its_gic 0x0 0x10000>; + reg = <0x6 0x00000000 0x0 0x10000000>, + <0x0 0xfca10000 0x0 0x1000>; + reg-names = "cfg", "cpm_slcr"; + pcie_intc_0: interrupt-controller { + #address-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt deleted file mode 100644 index d9b2100c98e8..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt +++ /dev/null @@ -1,81 +0,0 @@ -Ingenic XBurst pin controller - -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". - -For the XBurst SoCs, pin control is tightly bound with GPIO ports. All pins may -be used as GPIOs, multiplexed device functions are configured within the -GPIO port configuration registers and it is typical to refer to pins using the -naming scheme "PxN" where x is a character identifying the GPIO port with -which the pin is associated and N is an integer from 0 to 31 identifying the -pin within that GPIO port. For example PA0 is the first pin in GPIO port A, and -PB31 is the last pin in GPIO port B. The jz4740, the x1000 and the x1830 -contains 4 GPIO ports, PA to PD, for a total of 128 pins. The jz4760, the -jz4770 and the jz4780 contains 6 GPIO ports, PA to PF, for a total of 192 pins. - - -Required properties: --------------------- - - - compatible: One of: - - "ingenic,jz4740-pinctrl" - - "ingenic,jz4725b-pinctrl" - - "ingenic,jz4760-pinctrl" - - "ingenic,jz4760b-pinctrl" - - "ingenic,jz4770-pinctrl" - - "ingenic,jz4780-pinctrl" - - "ingenic,x1000-pinctrl" - - "ingenic,x1000e-pinctrl" - - "ingenic,x1500-pinctrl" - - "ingenic,x1830-pinctrl" - - reg: Address range of the pinctrl registers. - - -Required properties for sub-nodes (GPIO chips): ------------------------------------------------ - - - compatible: Must contain one of: - - "ingenic,jz4740-gpio" - - "ingenic,jz4760-gpio" - - "ingenic,jz4770-gpio" - - "ingenic,jz4780-gpio" - - "ingenic,x1000-gpio" - - "ingenic,x1830-gpio" - - reg: The GPIO bank number. - - interrupt-controller: Marks the device node as an interrupt controller. - - interrupts: Interrupt specifier for the controllers interrupt. - - #interrupt-cells: Should be 2. Refer to - ../interrupt-controller/interrupts.txt for more details. - - gpio-controller: Marks the device node as a GPIO controller. - - #gpio-cells: Should be 2. The first cell is the GPIO number and the second - cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the - GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - - gpio-ranges: Range of pins managed by the GPIO controller. Refer to - ../gpio/gpio.txt for more details. - - -Example: --------- - -pinctrl: pin-controller@10010000 { - compatible = "ingenic,jz4740-pinctrl"; - reg = <0x10010000 0x400>; - #address-cells = <1>; - #size-cells = <0>; - - gpa: gpio@0 { - compatible = "ingenic,jz4740-gpio"; - reg = <0>; - - gpio-controller; - gpio-ranges = <&pinctrl 0 0 32>; - #gpio-cells = <2>; - - interrupt-controller; - #interrupt-cells = <2>; - - interrupt-parent = <&intc>; - interrupts = <28>; - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml new file mode 100644 index 000000000000..18163fb69ce7 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -0,0 +1,176 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs pin controller devicetree bindings + +description: > + 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". + + For the Ingenic SoCs, pin control is tightly bound with GPIO ports. All pins + may be used as GPIOs, multiplexed device functions are configured within the + GPIO port configuration registers and it is typical to refer to pins using the + naming scheme "PxN" where x is a character identifying the GPIO port with + which the pin is associated and N is an integer from 0 to 31 identifying the + pin within that GPIO port. For example PA0 is the first pin in GPIO port A, + and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the X1830 + contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the + JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192 + pins. + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + nodename: + pattern: "^pinctrl@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - ingenic,jz4740-pinctrl + - ingenic,jz4725b-pinctrl + - ingenic,jz4760-pinctrl + - ingenic,jz4770-pinctrl + - ingenic,jz4780-pinctrl + - ingenic,x1000-pinctrl + - ingenic,x1500-pinctrl + - ingenic,x1830-pinctrl + - items: + - const: ingenic,jz4760b-pinctrl + - const: ingenic,jz4760-pinctrl + - items: + - const: ingenic,x1000e-pinctrl + - const: ingenic,x1000-pinctrl + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^gpio@[0-9]$": + type: object + properties: + compatible: + enum: + - ingenic,jz4740-gpio + - ingenic,jz4725b-gpio + - ingenic,jz4760-gpio + - ingenic,jz4770-gpio + - ingenic,jz4780-gpio + - ingenic,x1000-gpio + - ingenic,x1500-gpio + - ingenic,x1830-gpio + + reg: + items: + - description: The GPIO bank number + + gpio-controller: true + + "#gpio-cells": + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + description: + Refer to ../interrupt-controller/interrupts.txt for more details. + + interrupts: + maxItems: 1 + + required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupts + - interrupt-controller + - "#interrupt-cells" + + additionalProperties: false + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: + anyOf: + - type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + phandle: true + function: true + groups: true + pins: true + bias-disable: true + bias-pull-up: true + bias-pull-down: true + output-low: true + output-high: true + additionalProperties: false + + - type: object + properties: + phandle: true + additionalProperties: + type: object + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + phandle: true + function: true + groups: true + pins: true + bias-disable: true + bias-pull-up: true + bias-pull-down: true + output-low: true + output-high: true + additionalProperties: false + +examples: + - | + pin-controller@10010000 { + compatible = "ingenic,jz4770-pinctrl"; + reg = <0x10010000 0x600>; + + #address-cells = <1>; + #size-cells = <0>; + + gpio@0 { + compatible = "ingenic,jz4770-gpio"; + reg = <0>; + + gpio-controller; + gpio-ranges = <&pinctrl 0 0 32>; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&intc>; + interrupts = <17>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml new file mode 100644 index 000000000000..152c151c27ad --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml @@ -0,0 +1,202 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,mt6779-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT6779 Pin Controller Device Tree Bindings + +maintainers: + - Andy Teng <andy.teng@mediatek.com> + +description: |+ + The pin controller node should be the child of a syscon node with the + required property: + - compatible: "syscon" + +properties: + compatible: + const: mediatek,mt6779-pinctrl + + reg: + minItems: 9 + maxItems: 9 + + reg-names: + items: + - const: "gpio" + - const: "iocfg_rm" + - const: "iocfg_br" + - const: "iocfg_lm" + - const: "iocfg_lb" + - const: "iocfg_rt" + - const: "iocfg_lt" + - const: "iocfg_tl" + - const: "eint" + + gpio-controller: true + + "#gpio-cells": + const: 2 + description: | + Number of cells in GPIO specifier. Since the generic GPIO + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + gpio-ranges: + minItems: 1 + maxItems: 5 + description: | + GPIO valid number range. + + interrupt-controller: true + + interrupts: + maxItems: 1 + description: | + Specifies the summary IRQ. + + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + - gpio-ranges + - interrupt-controller + - interrupts + - "#interrupt-cells" + +patternProperties: + '-[0-9]*$': + type: object + patternProperties: + '-pins*$': + type: object + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and input schmitt. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pinmux: + description: + integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are defined + as macros in boot/dts/<soc>-pinfunc.h directly. + + bias-disable: true + + bias-pull-up: true + + bias-pull-down: true + + input-enable: true + + input-disable: true + + output-low: true + + output-high: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + mediatek,pull-up-adv: + description: | + Pull up setings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Pull down settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + required: + - pinmux + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/mt6779-pinfunc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt6779-pinctrl"; + reg = <0 0x10005000 0 0x1000>, + <0 0x11c20000 0 0x1000>, + <0 0x11d10000 0 0x1000>, + <0 0x11e20000 0 0x1000>, + <0 0x11e70000 0 0x1000>, + <0 0x11ea0000 0 0x1000>, + <0 0x11f20000 0 0x1000>, + <0 0x11f30000 0 0x1000>, + <0 0x1000b000 0 0x1000>; + reg-names = "gpio", "iocfg_rm", + "iocfg_br", "iocfg_lm", + "iocfg_lb", "iocfg_rt", + "iocfg_lt", "iocfg_tl", + "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 210>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH>; + + mmc0_pins_default: mmc0-0 { + cmd-dat-pins { + pinmux = <PINMUX_GPIO168__FUNC_MSDC0_DAT0>, + <PINMUX_GPIO172__FUNC_MSDC0_DAT1>, + <PINMUX_GPIO169__FUNC_MSDC0_DAT2>, + <PINMUX_GPIO177__FUNC_MSDC0_DAT3>, + <PINMUX_GPIO170__FUNC_MSDC0_DAT4>, + <PINMUX_GPIO173__FUNC_MSDC0_DAT5>, + <PINMUX_GPIO171__FUNC_MSDC0_DAT6>, + <PINMUX_GPIO174__FUNC_MSDC0_DAT7>, + <PINMUX_GPIO167__FUNC_MSDC0_CMD>; + input-enable; + mediatek,pull-up-adv = <1>; + }; + clk-pins { + pinmux = <PINMUX_GPIO176__FUNC_MSDC0_CLK>; + mediatek,pull-down-adv = <2>; + }; + rst-pins { + pinmux = <PINMUX_GPIO178__FUNC_MSDC0_RSTB>; + mediatek,pull-up-adv = <0>; + }; + }; + }; + + mmc0 { + pinctrl-0 = <&mmc0_pins_default>; + pinctrl-names = "default"; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt index 84be0f2c6f3b..0861afeccfc9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt @@ -44,7 +44,8 @@ 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, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength. + pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-open-drain, + drive-strength. Non-empty subnodes must specify the 'pins' property. Note that not all properties are valid for all pins. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index 7be5de8d253f..c3d1914381ae 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -23,6 +23,8 @@ PMIC's from Qualcomm. "qcom,pmi8994-gpio" "qcom,pmi8998-gpio" "qcom,pms405-gpio" + "qcom,pm660-gpio" + "qcom,pm660l-gpio" "qcom,pm8150-gpio" "qcom,pm8150b-gpio" "qcom,pm6150-gpio" diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index 1b8e8b4a6379..d75476e24514 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -21,6 +21,7 @@ Required Properties: - "renesas,pfc-r8a774a1": for R8A774A1 (RZ/G2M) compatible pin-controller. - "renesas,pfc-r8a774b1": for R8A774B1 (RZ/G2N) compatible pin-controller. - "renesas,pfc-r8a774c0": for R8A774C0 (RZ/G2E) compatible pin-controller. + - "renesas,pfc-r8a774e1": for R8A774E1 (RZ/G2H) compatible pin-controller. - "renesas,pfc-r8a7778": for R8A7778 (R-Car M1) compatible pin-controller. - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt deleted file mode 100644 index a63ccd476cda..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.txt +++ /dev/null @@ -1,87 +0,0 @@ -Renesas RZ/A2 combined Pin and GPIO controller - -The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO controller. -Pin multiplexing and GPIO configuration is performed on a per-pin basis. -Each port features up to 8 pins, each of them configurable for GPIO -function (port mode) or in alternate function mode. -Up to 8 different alternate function modes exist for each single pin. - -Pin controller node -------------------- - -Required properties: - - compatible: shall be: - - "renesas,r7s9210-pinctrl": for RZ/A2M - - reg - Address base and length of the memory area where the pin controller - hardware is mapped to. - - gpio-controller - This pin controller also controls pins as GPIO - - #gpio-cells - Must be 2 - - gpio-ranges - Expresses the total number of GPIO ports/pins in this SoC - -Example: Pin controller node for RZ/A2M SoC (r7s9210) - - pinctrl: pin-controller@fcffe000 { - compatible = "renesas,r7s9210-pinctrl"; - reg = <0xfcffe000 0x1000>; - - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pinctrl 0 0 176>; - }; - -Sub-nodes ---------- - -The child nodes of the pin controller designate pins to be used for -specific peripheral functions or as GPIO. - -- Pin multiplexing sub-nodes: - A pin multiplexing sub-node describes how to configure a set of - (or a single) pin in some desired alternate function mode. - The values for the pinmux properties are a combination of port name, pin - number and the desired function index. Use the RZA2_PINMUX macro located - in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily define these. - For assigning GPIO pins, use the macro RZA2_PIN also in r7s9210-pinctrl.h - to express the desired port pin. - - Required properties: - - pinmux: - integer array representing pin number and pin multiplexing configuration. - When a pin has to be configured in alternate function mode, use this - property to identify the pin by its global index, and provide its - alternate function configuration number along with it. - When multiple pins are required to be configured as part of the same - alternate function they shall be specified as members of the same - argument list of a single "pinmux" property. - Helper macros to ease assembling the pin index from its position - (port where it sits on and pin number) and alternate function identifier - are provided by the pin controller header file at: - <dt-bindings/pinctrl/r7s9210-pinctrl.h> - Integers values in "pinmux" argument list are assembled as: - ((PORT * 8 + PIN) | MUX_FUNC << 16) - - Example: Board specific pins configuration - - &pinctrl { - /* Serial Console */ - scif4_pins: serial4 { - pinmux = <RZA2_PINMUX(PORT9, 0, 4)>, /* TxD4 */ - <RZA2_PINMUX(PORT9, 1, 4)>; /* RxD4 */ - }; - }; - - Example: Assigning a GPIO: - - leds { - status = "okay"; - compatible = "gpio-leds"; - - led0 { - /* P6_0 */ - gpios = <&pinctrl RZA2_PIN(PORT6, 0) GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml new file mode 100644 index 000000000000..b7911a994f3a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/renesas,rza2-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A2 combined Pin and GPIO controller + +maintainers: + - Chris Brandt <chris.brandt@renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: + The Renesas SoCs of the RZ/A2 series feature a combined Pin and GPIO + controller. + Pin multiplexing and GPIO configuration is performed on a per-pin basis. + Each port features up to 8 pins, each of them configurable for GPIO function + (port mode) or in alternate function mode. + Up to 8 different alternate function modes exist for each single pin. + +properties: + compatible: + const: "renesas,r7s9210-pinctrl" # RZ/A2M + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell contains the global GPIO port index, constructed using the + RZA2_PIN() helper macro in r7s9210-pinctrl.h. + E.g. "RZA2_PIN(PORT6, 0)" for P6_0. + + gpio-ranges: + maxItems: 1 + +patternProperties: + "^.*$": + if: + type: object + then: + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + description: + The child nodes of the pin controller designate pins to be used for + specific peripheral functions or as GPIO. + + A pin multiplexing sub-node describes how to configure a set of + (or a single) pin in some desired alternate function mode. + The values for the pinmux properties are a combination of port name, + pin number and the desired function index. Use the RZA2_PINMUX macro + located in include/dt-bindings/pinctrl/r7s9210-pinctrl.h to easily + define these. + For assigning GPIO pins, use the macro RZA2_PIN also in + to express the desired port pin. + + properties: + phandle: true + + pinmux: + description: + Values are constructed from GPIO port number, pin number, and + alternate function configuration number using the RZA2_PINMUX() + helper macro in r7s9210-pinctrl.h. + + required: + - pinmux + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/r7s9210-pinctrl.h> + pinctrl: pin-controller@fcffe000 { + compatible = "renesas,r7s9210-pinctrl"; + reg = <0xfcffe000 0x1000>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 176>; + + /* Serial Console */ + scif4_pins: serial4 { + pinmux = <RZA2_PINMUX(PORT9, 0, 4)>, /* TxD4 */ + <RZA2_PINMUX(PORT9, 1, 4)>; /* RxD4 */ + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt index 5e29595edd74..a9f80cc49068 100644 --- a/Documentation/devicetree/bindings/power/supply/battery.txt +++ b/Documentation/devicetree/bindings/power/supply/battery.txt @@ -1,87 +1,3 @@ -Battery Characteristics - -The devicetree battery node provides static battery characteristics. -In smart batteries, these are typically stored in non-volatile memory -on a fuel gauge chip. The battery node should be used where there is -no appropriate non-volatile memory, or it is unprogrammed/incorrect. - -Upstream dts files should not include battery nodes, unless the battery -represented cannot easily be replaced in the system by one of a -different type. This prevents unpredictable, potentially harmful, -behavior should a replacement that changes the battery type occur -without a corresponding update to the dtb. +The contents of this file has been moved to battery.yaml Please note that not all charger drivers respect all of the properties. - -Required Properties: - - compatible: Must be "simple-battery" - -Optional Properties: - - over-voltage-threshold-microvolt: battery over-voltage limit - - re-charge-voltage-microvolt: limit to automatically start charging again - - voltage-min-design-microvolt: drained battery voltage - - voltage-max-design-microvolt: fully charged battery voltage - - energy-full-design-microwatt-hours: battery design energy - - charge-full-design-microamp-hours: battery design capacity - - trickle-charge-current-microamp: current for trickle-charge phase - - precharge-current-microamp: current for pre-charge phase - - precharge-upper-limit-microvolt: limit when to change to constant charging - - charge-term-current-microamp: current for charge termination phase - - constant-charge-current-max-microamp: maximum constant input current - - constant-charge-voltage-max-microvolt: maximum constant input voltage - - factory-internal-resistance-micro-ohms: battery factory internal resistance - - ocv-capacity-table-0: An array providing the open circuit voltage (OCV) - of the battery and corresponding battery capacity percent, which is used - to look up battery capacity according to current OCV value. And the open - circuit voltage unit is microvolt. - - ocv-capacity-table-1: Same as ocv-capacity-table-0 - ...... - - ocv-capacity-table-n: Same as ocv-capacity-table-0 - - ocv-capacity-celsius: An array containing the temperature in degree Celsius, - for each of the battery capacity lookup table. The first temperature value - specifies the OCV table 0, and the second temperature value specifies the - OCV table 1, and so on. - - resistance-temp-table: An array providing the temperature in degree Celsius - and corresponding battery internal resistance percent, which is used to look - up the resistance percent according to current temperature to get a accurate - batterty internal resistance in different temperatures. - -Battery properties are named, where possible, for the corresponding -elements in enum power_supply_property, defined in -https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h - -Batteries must be referenced by chargers and/or fuel-gauges -using a phandle. The phandle's property should be named -"monitored-battery". - -Example: - - bat: battery { - compatible = "simple-battery"; - voltage-min-design-microvolt = <3200000>; - voltage-max-design-microvolt = <4200000>; - energy-full-design-microwatt-hours = <5290000>; - charge-full-design-microamp-hours = <1430000>; - precharge-current-microamp = <256000>; - charge-term-current-microamp = <128000>; - constant-charge-current-max-microamp = <900000>; - constant-charge-voltage-max-microvolt = <4200000>; - factory-internal-resistance-micro-ohms = <250000>; - ocv-capacity-celsius = <(-10) 0 10>; - ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...; - ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>, ...; - ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>, ...; - resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>; - }; - - charger: charger@11 { - .... - monitored-battery = <&bat>; - ... - }; - - fuel_gauge: fuel-gauge@22 { - .... - monitored-battery = <&bat>; - ... - }; diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml new file mode 100644 index 000000000000..932b736ce5c0 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/battery.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/battery.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Battery Characteristics + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: | + The devicetree battery node provides static battery characteristics. + In smart batteries, these are typically stored in non-volatile memory + on a fuel gauge chip. The battery node should be used where there is + no appropriate non-volatile memory, or it is unprogrammed/incorrect. + + Upstream dts files should not include battery nodes, unless the battery + represented cannot easily be replaced in the system by one of a + different type. This prevents unpredictable, potentially harmful, + behavior should a replacement that changes the battery type occur + without a corresponding update to the dtb. + + Battery properties are named, where possible, for the corresponding elements + in enum power_supply_property, defined in include/linux/power_supply.h + + Batteries must be referenced by chargers and/or fuel-gauges using a phandle. + The phandle's property should be named "monitored-battery". + +properties: + compatible: + const: simple-battery + + over-voltage-threshold-microvolt: + description: battery over-voltage limit + + re-charge-voltage-microvolt: + description: limit to automatically start charging again + + voltage-min-design-microvolt: + description: drained battery voltage + + voltage-max-design-microvolt: + description: fully charged battery voltage + + energy-full-design-microwatt-hours: + description: battery design energy + + charge-full-design-microamp-hours: + description: battery design capacity + + trickle-charge-current-microamp: + description: current for trickle-charge phase + + precharge-current-microamp: + description: current for pre-charge phase + + precharge-upper-limit-microvolt: + description: limit when to change to constant charging + + charge-term-current-microamp: + description: current for charge termination phase + + constant-charge-current-max-microamp: + description: maximum constant input current + + constant-charge-voltage-max-microvolt: + description: maximum constant input voltage + + factory-internal-resistance-micro-ohms: + description: battery factory internal resistance + + resistance-temp-table: + description: | + An array providing the temperature in degree Celsius + and corresponding battery internal resistance percent, which is used to + look up the resistance percent according to current temperature to get an + accurate batterty internal resistance in different temperatures. + + ocv-capacity-celsius: + description: | + An array containing the temperature in degree Celsius, + for each of the battery capacity lookup table. + +required: + - compatible + +patternProperties: + '^ocv-capacity-table-[0-9]+$': + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + An array providing the open circuit voltage (OCV) + of the battery and corresponding battery capacity percent, which is used + to look up battery capacity according to current OCV value. And the open + circuit voltage unit is microvolt. + maxItems: 100 + items: + items: + - description: open circuit voltage (OCV) in microvolts + - description: battery capacity percent + maximum: 100 + +additionalProperties: false + +examples: + - | + power { + #address-cells = <1>; + #size-cells = <0>; + + battery: battery { + compatible = "simple-battery"; + over-voltage-threshold-microvolt = <4500000>; + re-charge-voltage-microvolt = <250000>; + voltage-min-design-microvolt = <3200000>; + voltage-max-design-microvolt = <4200000>; + energy-full-design-microwatt-hours = <5290000>; + charge-full-design-microamp-hours = <1430000>; + precharge-current-microamp = <256000>; + precharge-upper-limit-microvolt = <2500000>; + charge-term-current-microamp = <128000>; + constant-charge-current-max-microamp = <900000>; + constant-charge-voltage-max-microvolt = <4200000>; + factory-internal-resistance-micro-ohms = <250000>; + ocv-capacity-celsius = <(-10) 0 10>; + /* table for -10 degree Celsius */ + ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>; + /* table for 0 degree Celsius */ + ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>; + /* table for 10 degree Celsius */ + ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>; + resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>; + }; + + charger@11 { + reg = <0x11>; + monitored-battery = <&battery>; + }; + + fuel-gauge@22 { + reg = <0x22>; + monitored-battery = <&battery>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml new file mode 100644 index 000000000000..75a56773be4a --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) 2020 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TI bq2515x 500-mA Linear charger family + +maintainers: + - Dan Murphy <dmurphy@ti.com> + - Ricardo Rivera-Matos <r-rivera-matos@ti.com> + +description: | + The BQ2515x family is a highly integrated battery charge management IC that + integrates the most common functions for wearable devices, namely a charger, + an output voltage rail, ADC for battery and system monitoring, and + push-button controller. + + Specifications about the charger can be found at: + http://www.ti.com/lit/ds/symlink/bq25150.pdf + http://www.ti.com/lit/ds/symlink/bq25155.pdf + +properties: + compatible: + enum: + - ti,bq25150 + - ti,bq25155 + + reg: + maxItems: 1 + description: I2C address of the charger. + + ac-detect-gpios: + description: | + GPIO used for connecting the bq2515x device PG (AC Detect) + pin. + maxItems: 1 + + reset-gpios: + description: GPIO used for hardware reset. + maxItems: 1 + + powerdown-gpios: + description: GPIO used for low power mode of IC. + maxItems: 1 + + charge-enable-gpios: + description: GPIO used to turn on and off charging. + maxItems: 1 + + input-current-limit-microamp: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Maximum input current in micro Amps. + minimum: 50000 + maximum: 500000 + + monitored-battery: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the battery node being monitored + +required: + - compatible + - reg + - monitored-battery + +additionalProperties: false + +examples: + - | + bat: battery { + compatible = "simple-battery"; + constant-charge-current-max-microamp = <50000>; + precharge-current-microamp = <2500>; + constant-charge-voltage-max-microvolt = <4000000>; + }; + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + bq25150: charger@6b { + compatible = "ti,bq25150"; + reg = <0x6b>; + monitored-battery = <&bat>; + input-current-limit-microamp = <100000>; + + ac-detect-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; + powerdown-gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>; + charge-enable-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/bq25890.txt b/Documentation/devicetree/bindings/power/supply/bq25890.txt index dc9c8f76e06c..3b4c69a7fa70 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25890.txt +++ b/Documentation/devicetree/bindings/power/supply/bq25890.txt @@ -10,6 +10,7 @@ Required properties: * "ti,bq25895" * "ti,bq25896" - reg: integer, i2c address of the device. +- interrupts: interrupt line; - ti,battery-regulation-voltage: integer, maximum charging voltage (in uV); - ti,charge-current: integer, maximum charging current (in uA); - ti,termination-current: integer, charge will be terminated when current in @@ -36,17 +37,20 @@ Optional properties: Example: bq25890 { - compatible = "ti,bq25890"; - reg = <0x6a>; - - ti,battery-regulation-voltage = <4200000>; - ti,charge-current = <1000000>; - ti,termination-current = <50000>; - ti,precharge-current = <128000>; - ti,minimum-sys-voltage = <3600000>; - ti,boost-voltage = <5000000>; - ti,boost-max-current = <1000000>; - - ti,use-ilim-pin; - ti,thermal-regulation-threshold = <120>; + compatible = "ti,bq25890"; + reg = <0x6a>; + + interrupt-parent = <&gpio1>; + interrupts = <16 IRQ_TYPE_EDGE_FALLING>; + + ti,battery-regulation-voltage = <4200000>; + ti,charge-current = <1000000>; + ti,termination-current = <50000>; + ti,precharge-current = <128000>; + ti,minimum-sys-voltage = <3600000>; + ti,boost-voltage = <5000000>; + ti,boost-max-current = <1000000>; + + ti,use-ilim-pin; + ti,thermal-regulation-threshold = <120>; }; diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml index 03d1020a2e47..82f682705f44 100644 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml @@ -49,6 +49,8 @@ properties: - ti,bq27426 - ti,bq27441 - ti,bq27621 + - ti,bq27z561 + - ti,bq28z610 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt b/Documentation/devicetree/bindings/power/supply/gpio-charger.txt deleted file mode 100644 index 0fb33b2c62a6..000000000000 --- a/Documentation/devicetree/bindings/power/supply/gpio-charger.txt +++ /dev/null @@ -1,31 +0,0 @@ -gpio-charger - -Required properties : - - compatible : "gpio-charger" - - gpios : GPIO indicating the charger presence. - See GPIO binding in bindings/gpio/gpio.txt . - - charger-type : power supply type, one of - unknown - battery - ups - mains - usb-sdp (USB standard downstream port) - usb-dcp (USB dedicated charging port) - usb-cdp (USB charging downstream port) - usb-aca (USB accessory charger adapter) - -Optional properties: - - charge-status-gpios: GPIO indicating whether a battery is charging. - -Example: - - usb_charger: charger { - compatible = "gpio-charger"; - charger-type = "usb-sdp"; - gpios = <&gpd 28 GPIO_ACTIVE_LOW>; - charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>; - }; - - battery { - power-supplies = <&usb_charger>; - }; diff --git a/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml new file mode 100644 index 000000000000..30eabbb14ef3 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/gpio-charger.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/gpio-charger.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: simple battery chargers only communicating through GPIOs + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: + This binding is for all chargers, which are working more or less + autonomously, only providing some status GPIOs and possibly some + GPIOs for limited control over the charging process. + +properties: + compatible: + const: gpio-charger + + charger-type: + enum: + - unknown + - battery + - ups + - mains + - usb-sdp # USB standard downstream port + - usb-dcp # USB dedicated charging port + - usb-cdp # USB charging downstream port + - usb-aca # USB accessory charger adapter + description: + Type of the charger, e.g. "mains" for a wall charger. + + gpios: + maxItems: 1 + description: GPIO indicating the charger presence + + charge-status-gpios: + maxItems: 1 + description: GPIO indicating the charging status + +required: + - compatible + +anyOf: + - required: + - gpios + - required: + - charge-status-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + charger { + compatible = "gpio-charger"; + charger-type = "usb-sdp"; + + gpios = <&gpd 28 GPIO_ACTIVE_LOW>; + charge-status-gpios = <&gpc 27 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml new file mode 100644 index 000000000000..87c52316ddbd --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm peripheral image loader relocation info binding + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + The Qualcomm peripheral image loader relocation memory region, in IMEM, is + used for communicating remoteproc relocation information to post mortem + debugging tools. + +properties: + compatible: + const: qcom,pil-reloc-info + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + imem@146bf000 { + compatible = "syscon", "simple-mfd"; + reg = <0x146bf000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0 0x146bf000 0x1000>; + + pil-reloc@94c { + compatible = "qcom,pil-reloc-info"; + reg = <0x94c 0xc8>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml new file mode 100644 index 000000000000..24b0c50fa436 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/ti,k3-dsp-rproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI K3 DSP devices + +maintainers: + - Suman Anna <s-anna@ti.com> + +description: | + The TI K3 family of SoCs usually have one or more TI DSP Core sub-systems + that are used to offload some of the processor-intensive tasks or algorithms, + for achieving various system level goals. + + These processor sub-systems usually contain additional sub-modules like + L1 and/or L2 caches/SRAMs, an Interrupt Controller, an external memory + controller, a dedicated local power/sleep controller etc. The DSP processor + cores in the K3 SoCs are usually either a TMS320C66x CorePac processor or a + TMS320C71x CorePac processor. + + Each DSP Core sub-system is represented as a single DT node. Each node has a + number of required or optional properties that enable the OS running on the + host processor (Arm CorePac) to perform the device management of the remote + processor and to communicate with the remote processor. + +allOf: + - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# + +properties: + compatible: + enum: + - ti,j721e-c66-dsp + - ti,j721e-c71-dsp + description: + Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs + Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs + + resets: + description: | + Should contain the phandle to the reset controller node managing the + local resets for this device, and a reset specifier. + maxItems: 1 + + firmware-name: + description: | + Should contain the name of the default firmware image + file located on the firmware search path + + mboxes: + description: | + OMAP Mailbox specifier denoting the sub-mailbox, to be used for + communication with the remote processor. This property should match + with the sub-mailbox node used in the firmware image. + maxItems: 1 + + memory-region: + minItems: 2 + maxItems: 8 + description: | + phandle to the reserved memory nodes to be associated with the remoteproc + device. There should be at least two reserved memory nodes defined. The + reserved memory nodes should be carveout nodes, and should be defined as + per the bindings in + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + items: + - description: region used for dynamic DMA allocations like vrings and + vring buffers + - description: region reserved for firmware image sections + additionalItems: true + +# Optional properties: +# -------------------- + + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 + description: | + phandles to one or more reserved on-chip SRAM regions. The regions + should be defined as child nodes of the respective SRAM node, and + should be defined as per the generic bindings in, + Documentation/devicetree/bindings/sram/sram.yaml + +if: + properties: + compatible: + enum: + - ti,j721e-c66-dsp +then: + properties: + reg: + items: + - description: Address and Size of the L2 SRAM internal memory region + - description: Address and Size of the L1 PRAM internal memory region + - description: Address and Size of the L1 DRAM internal memory region + reg-names: + items: + - const: l2sram + - const: l1pram + - const: l1dram +else: + if: + properties: + compatible: + enum: + - ti,j721e-c71-dsp + then: + properties: + reg: + items: + - description: Address and Size of the L2 SRAM internal memory region + - description: Address and Size of the L1 DRAM internal memory region + reg-names: + items: + - const: l2sram + - const: l1dram + +required: + - compatible + - reg + - reg-names + - ti,sci + - ti,sci-dev-id + - ti,sci-proc-ids + - resets + - firmware-name + - mboxes + - memory-region + +unevaluatedProperties: false + +examples: + - | + / { + model = "Texas Instruments K3 J721E SoC"; + compatible = "ti,j721e"; + #address-cells = <2>; + #size-cells = <2>; + + bus@100000 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */ + <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71_0 */ + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */ + <0x4d 0x81800000 0x4d 0x81800000 0x00 0x00800000>; /* C66_1 */ + + /* J721E C66_0 DSP node */ + dsp@4d80800000 { + compatible = "ti,j721e-c66-dsp"; + reg = <0x4d 0x80800000 0x00 0x00048000>, + <0x4d 0x80e00000 0x00 0x00008000>, + <0x4d 0x80f00000 0x00 0x00008000>; + reg-names = "l2sram", "l1pram", "l1dram"; + ti,sci = <&dmsc>; + ti,sci-dev-id = <142>; + ti,sci-proc-ids = <0x03 0xFF>; + resets = <&k3_reset 142 1>; + firmware-name = "j7-c66_0-fw"; + memory-region = <&c66_0_dma_memory_region>, + <&c66_0_memory_region>; + mboxes = <&mailbox0_cluster3 &mbox_c66_0>; + }; + + /* J721E C71_0 DSP node */ + c71_0: dsp@64800000 { + compatible = "ti,j721e-c71-dsp"; + reg = <0x00 0x64800000 0x00 0x00080000>, + <0x00 0x64e00000 0x00 0x0000c000>; + reg-names = "l2sram", "l1dram"; + ti,sci = <&dmsc>; + ti,sci-dev-id = <15>; + ti,sci-proc-ids = <0x30 0xFF>; + resets = <&k3_reset 15 1>; + firmware-name = "j7-c71_0-fw"; + memory-region = <&c71_0_dma_memory_region>, + <&c71_0_memory_region>; + mboxes = <&mailbox0_cluster4 &mbox_c71_0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml index 18cb456752f6..c7d14de214c4 100644 --- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml @@ -52,6 +52,8 @@ properties: - nxp,pcf2127 # Real-time clock - nxp,pcf2129 + # Real-time clock + - nxp,pca2129 # Real-time Clock Module - pericom,pt7c4338 # I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 75b8521eb7cb..06d5f251ec88 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -35,9 +35,11 @@ properties: description: label associated with this uart st,hw-flow-ctrl: - description: enable hardware flow control + description: enable hardware flow control (deprecated) $ref: /schemas/types.yaml#/definitions/flag + uart-has-rtscts: true + dmas: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml index d226fd7d5258..3cd0b70cd6cf 100644 --- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml +++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml @@ -52,14 +52,20 @@ properties: patternProperties: "^timer@[0-2]$": - description: The timer block channels that are used as timers. + description: The timer block channels that are used as timers or counters. type: object properties: compatible: - const: atmel,tcb-timer + items: + - enum: + - atmel,tcb-timer + - microchip,tcb-capture reg: description: - List of channels to use for this particular timer. + List of channels to use for this particular timer. In Microchip TCB capture + mode channels are registered as a counter devices, for the qdec mode TCB0's + channel <0> and <1> are required. + minItems: 1 maxItems: 3 @@ -153,3 +159,23 @@ examples: reg = <1>; }; }; + /* TCB0 Capture with QDEC: */ + timer@f800c000 { + compatible = "atmel,at91rm9200-tcb", "simple-mfd", "syscon"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfff7c000 0x100>; + interrupts = <18 4>; + clocks = <&tcb0_clk>, <&clk32k>; + clock-names = "t0_clk", "slow_clk"; + + timer@0 { + compatible = "microchip,tcb-capture"; + reg = <0>, <1>; + }; + + timer@2 { + compatible = "atmel,tcb-timer"; + reg = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/adi,adau1977.txt b/Documentation/devicetree/bindings/sound/adi,adau1977.txt index 9225472c80b4..37f8aad01203 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1977.txt +++ b/Documentation/devicetree/bindings/sound/adi,adau1977.txt @@ -1,9 +1,9 @@ Analog Devices ADAU1977/ADAU1978/ADAU1979 Datasheets: -http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf -http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf -http://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf +https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1977.pdf +https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1978.pdf +https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1979.pdf This driver supports both the I2C and SPI bus. diff --git a/Documentation/devicetree/bindings/sound/ak4613.txt b/Documentation/devicetree/bindings/sound/ak4613.txt deleted file mode 100644 index 49a2e74fd9cb..000000000000 --- a/Documentation/devicetree/bindings/sound/ak4613.txt +++ /dev/null @@ -1,27 +0,0 @@ -AK4613 I2C transmitter - -This device supports I2C mode only. - -Required properties: - -- compatible : "asahi-kasei,ak4613" -- reg : The chip select number on the I2C bus - -Optional properties: -- asahi-kasei,in1-single-end : Boolean. Indicate input / output pins are single-ended. -- asahi-kasei,in2-single-end rather than differential. -- asahi-kasei,out1-single-end -- asahi-kasei,out2-single-end -- asahi-kasei,out3-single-end -- asahi-kasei,out4-single-end -- asahi-kasei,out5-single-end -- asahi-kasei,out6-single-end - -Example: - -&i2c { - ak4613: ak4613@10 { - compatible = "asahi-kasei,ak4613"; - reg = <0x10>; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/ak4613.yaml b/Documentation/devicetree/bindings/sound/ak4613.yaml new file mode 100644 index 000000000000..ef4055ef0ccd --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4613.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ak4613.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AK4613 I2C transmitter Device Tree Bindings + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +properties: + compatible: + const: asahi-kasei,ak4613 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + +patternProperties: + "^asahi-kasei,in[1-2]-single-end$": + description: Input Pin 1 - 2. + $ref: /schemas/types.yaml#/definitions/flag + + "^asahi-kasei,out[1-6]-single-end$": + description: Output Pin 1 - 6. + $ref: /schemas/types.yaml#/definitions/flag + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + ak4613: codec@10 { + compatible = "asahi-kasei,ak4613"; + reg = <0x10>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt b/Documentation/devicetree/bindings/sound/ak4642.txt deleted file mode 100644 index 58e48ee97175..000000000000 --- a/Documentation/devicetree/bindings/sound/ak4642.txt +++ /dev/null @@ -1,37 +0,0 @@ -AK4642 I2C transmitter - -This device supports I2C mode only. - -Required properties: - - - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or "asahi-kasei,ak4648" - - reg : The chip select number on the I2C bus - -Optional properties: - - - #clock-cells : common clock binding; shall be set to 0 - - clocks : common clock binding; MCKI clock - - clock-frequency : common clock binding; frequency of MCKO - - clock-output-names : common clock binding; MCKO clock name - -Example 1: - -&i2c { - ak4648: ak4648@12 { - compatible = "asahi-kasei,ak4642"; - reg = <0x12>; - }; -}; - -Example 2: - -&i2c { - ak4643: codec@12 { - compatible = "asahi-kasei,ak4643"; - reg = <0x12>; - #clock-cells = <0>; - clocks = <&audio_clock>; - clock-frequency = <12288000>; - clock-output-names = "ak4643_mcko"; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/ak4642.yaml b/Documentation/devicetree/bindings/sound/ak4642.yaml new file mode 100644 index 000000000000..6cd213be2266 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4642.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ak4642.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AK4642 I2C transmitter Device Tree Bindings + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +properties: + compatible: + enum: + - asahi-kasei,ak4642 + - asahi-kasei,ak4643 + - asahi-kasei,ak4648 + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + "#sound-dai-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-frequency: + description: common clock binding; frequency of MCKO + $ref: /schemas/types.yaml#/definitions/uint32 + + clock-output-names: + description: common clock name + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + ak4643: codec@12 { + compatible = "asahi-kasei,ak4643"; + #sound-dai-cells = <0>; + reg = <0x12>; + #clock-cells = <0>; + clocks = <&audio_clock>; + clock-frequency = <12288000>; + clock-output-names = "ak4643_mcko"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.txt b/Documentation/devicetree/bindings/sound/everest,es8316.txt deleted file mode 100644 index 1bf03c5f2af4..000000000000 --- a/Documentation/devicetree/bindings/sound/everest,es8316.txt +++ /dev/null @@ -1,23 +0,0 @@ -Everest ES8316 audio CODEC - -This device supports both I2C and SPI. - -Required properties: - - - compatible : should be "everest,es8316" - - reg : the I2C address of the device for I2C - -Optional properties: - - - clocks : a list of phandle, should contain entries for clock-names - - clock-names : should include as follows: - "mclk" : master clock (MCLK) of the device - -Example: - -es8316: codec@11 { - compatible = "everest,es8316"; - reg = <0x11>; - clocks = <&clks 10>; - clock-names = "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/everest,es8316.yaml b/Documentation/devicetree/bindings/sound/everest,es8316.yaml new file mode 100644 index 000000000000..3b752bba748b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/everest,es8316.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/everest,es8316.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Everest ES8316 audio CODEC + +maintainers: + - Daniel Drake <drake@endlessm.com> + - Katsuhiro Suzuki <katsuhiro@katsuster.net> + +properties: + compatible: + const: everest,es8316 + + reg: + maxItems: 1 + + clocks: + items: + - description: clock for master clock (MCLK) + + clock-names: + items: + - const: mclk + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + es8316: codec@11 { + compatible = "everest,es8316"; + reg = <0x11>; + clocks = <&clks 10>; + clock-names = "mclk"; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt index 8b324f82a782..e1365b0ee1e9 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt @@ -6,7 +6,11 @@ a fibre cable. Required properties: - - compatible : Compatible list, must contain "fsl,imx35-spdif". + - compatible : Compatible list, should contain one of the following + compatibles: + "fsl,imx35-spdif", + "fsl,vf610-spdif", + "fsl,imx6sx-spdif", - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index c60a5732d29c..63ebf52b43e8 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -34,6 +34,10 @@ The compatible list for this generic sound card currently: "fsl,imx-audio-wm8960" + "fsl,imx-audio-mqs" + + "fsl,imx-audio-wm8524" + Required properties: - compatible : Contains one of entries in the compatible list. @@ -44,6 +48,11 @@ Required properties: - audio-codec : The phandle of an audio codec +Optional properties: + + - audio-asrc : The phandle of ASRC. It can be absent if there's no + need to add ASRC support via DPCM. + - 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 @@ -60,10 +69,13 @@ Required properties: coexisting in order to support the old bindings of wm8962 and sgtl5000. -Optional properties: - - - audio-asrc : The phandle of ASRC. It can be absent if there's no - need to add ASRC support via DPCM. + - hp-det-gpio : The GPIO that detect headphones are plugged in + - mic-det-gpio : The GPIO that detect microphones are plugged in + - bitclock-master : Indicates dai-link bit clock master; for details see simple-card.yaml. + - frame-master : Indicates dai-link frame master; for details see simple-card.yaml. + - dai-format : audio format, for details see simple-card.yaml. + - frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml. + - bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml. Optional unless SSI is selected as a CPU DAI: diff --git a/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml new file mode 100644 index 000000000000..2e0bbc1c868a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/intel,keembay-i2s.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 Intel Corporation +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/intel,keembay-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel KeemBay I2S Device Tree Bindings + +maintainers: + - Sia, Jee Heng <jee.heng.sia@intel.com> + +description: | + Intel KeemBay I2S + +properties: + compatible: + enum: + - intel,keembay-i2s + + "#sound-dai-cells": + const: 0 + + reg: + items: + - description: I2S registers + - description: I2S gen configuration + + reg-names: + items: + - const: i2s-regs + - const: i2s_gen_cfg + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: osc + - const: apb_clk + +required: + - compatible + - "#sound-dai-cells" + - reg + - clocks + - clock-names + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #define KEEM_BAY_PSS_AUX_I2S3 + #define KEEM_BAY_PSS_I2S3 + i2s3: i2s@20140000 { + compatible = "intel,keembay-i2s"; + #sound-dai-cells = <0>; + reg = <0x20140000 0x200>, /* I2S registers */ + <0x202a00a4 0x4>; /* I2S gen configuration */ + reg-names = "i2s-regs", "i2s_gen_cfg"; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "osc", "apb_clk"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_I2S3>, <&scmi_clk KEEM_BAY_PSS_I2S3>; + }; diff --git a/Documentation/devicetree/bindings/sound/max98357a.txt b/Documentation/devicetree/bindings/sound/max98357a.txt index 4bce14ce806f..75db84d06240 100644 --- a/Documentation/devicetree/bindings/sound/max98357a.txt +++ b/Documentation/devicetree/bindings/sound/max98357a.txt @@ -1,9 +1,10 @@ -Maxim MAX98357A audio DAC +Maxim MAX98357A/MAX98360A audio DAC -This node models the Maxim MAX98357A DAC. +This node models the Maxim MAX98357A/MAX98360A DAC. Required properties: -- compatible : "maxim,max98357a" +- compatible : "maxim,max98357a" for MAX98357A. + "maxim,max98360a" for MAX98360A. Optional properties: - sdmode-gpios : GPIO specifier for the chip's SD_MODE pin. @@ -20,3 +21,8 @@ max98357a { compatible = "maxim,max98357a"; sdmode-gpios = <&qcom_pinmux 25 0>; }; + +max98360a { + compatible = "maxim,max98360a"; + sdmode-gpios = <&qcom_pinmux 25 0>; +}; diff --git a/Documentation/devicetree/bindings/sound/maxim,max98390.yaml b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml new file mode 100644 index 000000000000..e5ac35280da3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/maxim,max98390.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/maxim,max98390.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX98390 Speaker Amplifier with Integrated Dynamic Speaker Management + +maintainers: + - Steve Lee <steves.lee@maximintegrated.com> + +properties: + compatible: + const: maxim,max98390 + + reg: + maxItems: 1 + description: I2C address of the device. + + maxim,temperature_calib: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + description: The calculated temperature data was measured while doing the calibration. + minimum: 0 + maximum: 65535 + + maxim,r0_calib: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + description: This is r0 calibration data which was measured in factory mode. + minimum: 1 + maximum: 8388607 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + max98390: amplifier@38 { + compatible = "maxim,max98390"; + reg = <0x38>; + maxim,temperature_calib = <1024>; + maxim,r0_calib = <100232>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/mt6358.txt b/Documentation/devicetree/bindings/sound/mt6358.txt index 5465730013a1..59a73ffdf1d3 100644 --- a/Documentation/devicetree/bindings/sound/mt6358.txt +++ b/Documentation/devicetree/bindings/sound/mt6358.txt @@ -10,9 +10,15 @@ Required properties: - compatible : "mediatek,mt6358-sound". - Avdd-supply : power source of AVDD +Optional properties: +- mediatek,dmic-mode : Indicates how many data pins are used to transmit two + channels of PDM signal. 0 means two wires, 1 means one wire. Default + value is 0. + Example: mt6358_snd { compatible = "mediatek,mt6358-sound"; Avdd-supply = <&mt6358_vaud28_reg>; + mediatek,dmic-mode = <0>; }; diff --git a/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt b/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt index 92ac86f83822..6787ce8789dd 100644 --- a/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt +++ b/Documentation/devicetree/bindings/sound/mt8183-da7219-max98357.txt @@ -1,15 +1,20 @@ -MT8183 with MT6358, DA7219 and MAX98357 CODECS +MT8183 with MT6358, DA7219, MAX98357, and RT1015 CODECS Required properties: -- compatible : "mediatek,mt8183_da7219_max98357" +- compatible : "mediatek,mt8183_da7219_max98357" for MAX98357A codec + "mediatek,mt8183_da7219_rt1015" for RT1015 codec - mediatek,headset-codec: the phandles of da7219 codecs - mediatek,platform: the phandle of MT8183 ASoC platform +Optional properties: +- mediatek,hdmi-codec: the phandles of HDMI codec + Example: sound { compatible = "mediatek,mt8183_da7219_max98357"; mediatek,headset-codec = <&da7219>; + mediatek,hdmi-codec = <&it6505dptx>; mediatek,platform = <&afe>; }; diff --git a/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt b/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt index decaa013a07e..235eac8aea7b 100644 --- a/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt +++ b/Documentation/devicetree/bindings/sound/mt8183-mt6358-ts3a227-max98357.txt @@ -1,13 +1,16 @@ -MT8183 with MT6358, TS3A227 and MAX98357 CODECS +MT8183 with MT6358, TS3A227, MAX98357, and RT1015 CODECS Required properties: -- compatible : "mediatek,mt8183_mt6358_ts3a227_max98357" +- compatible : "mediatek,mt8183_mt6358_ts3a227_max98357" for MAX98357A codec + "mediatek,mt8183_mt6358_ts3a227_max98357b" for MAX98357B codec + "mediatek,mt8183_mt6358_ts3a227_rt1015" for RT1015 codec - mediatek,platform: the phandle of MT8183 ASoC platform Optional properties: - mediatek,headset-codec: the phandles of ts3a227 codecs - mediatek,ec-codec: the phandle of EC codecs. See google,cros-ec-codec.txt for more details. +- mediatek,hdmi-codec: the phandles of HDMI codec Example: @@ -15,6 +18,7 @@ Example: compatible = "mediatek,mt8183_mt6358_ts3a227_max98357"; mediatek,headset-codec = <&ts3a227>; mediatek,ec-codec = <&ec_codec>; + mediatek,hdmi-codec = <&it6505dptx>; mediatek,platform = <&afe>; }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml new file mode 100644 index 000000000000..e620c77d0728 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra186-dspk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra186 DSPK Controller Device Tree Bindings + +description: | + The Digital Speaker Controller (DSPK) can be viewed as a Pulse + Density Modulation (PDM) transmitter that up-samples the input to + the desired sampling rate by interpolation and then converts the + over sampled Pulse Code Modulation (PCM) input to the desired 1-bit + output via Delta Sigma Modulation (DSM). + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + $nodename: + pattern: "^dspk@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra186-dspk + - items: + - const: nvidia,tegra194-dspk + - const: nvidia,tegra186-dspk + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: dspk + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + sound-name-prefix: + pattern: "^DSPK[1-9]$" + allOf: + - $ref: /schemas/types.yaml#/definitions/string + description: + Used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + The name can be "DSPK1" or "DSPKx", where x depends on the maximum + available instances on a Tegra SoC. + +required: + - compatible + - reg + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - sound-name-prefix + +examples: + - | + #include<dt-bindings/clock/tegra186-clock.h> + + dspk@2905000 { + compatible = "nvidia,tegra186-dspk"; + reg = <0x2905000 0x100>; + clocks = <&bpmp TEGRA186_CLK_DSPK1>; + clock-names = "dspk"; + assigned-clocks = <&bpmp TEGRA186_CLK_DSPK1>; + assigned-clock-parents = <&bpmp TEGRA186_CLK_PLL_A_OUT0>; + assigned-clock-rates = <12288000>; + sound-name-prefix = "DSPK1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml new file mode 100644 index 000000000000..41c77f45d2fd --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-admaif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 ADMAIF Device Tree Bindings + +description: | + ADMAIF is the interface between ADMA and AHUB. Each ADMA channel + that sends/receives data to/from AHUB must interface through an + ADMAIF channel. ADMA channel sending data to AHUB pairs with ADMAIF + Tx channel and ADMA channel receiving data from AHUB pairs with + ADMAIF Rx channel. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + $nodename: + pattern: "^admaif@[0-9a-f]*$" + + compatible: + oneOf: + - enum: + - nvidia,tegra210-admaif + - nvidia,tegra186-admaif + - items: + - const: nvidia,tegra194-admaif + - const: nvidia,tegra186-admaif + + reg: + maxItems: 1 + + dmas: true + + dma-names: true + +if: + properties: + compatible: + contains: + const: nvidia,tegra210-admaif + +then: + properties: + dmas: + description: + DMA channel specifiers, equally divided for Tx and Rx. + minItems: 1 + maxItems: 20 + dma-names: + items: + pattern: "^[rt]x(10|[1-9])$" + description: + Should be "rx1", "rx2" ... "rx10" for DMA Rx channel + Should be "tx1", "tx2" ... "tx10" for DMA Tx channel + minItems: 1 + maxItems: 20 + +else: + properties: + dmas: + description: + DMA channel specifiers, equally divided for Tx and Rx. + minItems: 1 + maxItems: 40 + dma-names: + items: + pattern: "^[rt]x(1[0-9]|[1-9]|20)$" + description: + Should be "rx1", "rx2" ... "rx20" for DMA Rx channel + Should be "tx1", "tx2" ... "tx20" for DMA Tx channel + minItems: 1 + maxItems: 40 + +required: + - compatible + - reg + - dmas + - dma-names + +examples: + - | + admaif@702d0000 { + compatible = "nvidia,tegra210-admaif"; + reg = <0x702d0000 0x800>; + dmas = <&adma 1>, <&adma 1>, + <&adma 2>, <&adma 2>, + <&adma 3>, <&adma 3>, + <&adma 4>, <&adma 4>, + <&adma 5>, <&adma 5>, + <&adma 6>, <&adma 6>, + <&adma 7>, <&adma 7>, + <&adma 8>, <&adma 8>, + <&adma 9>, <&adma 9>, + <&adma 10>, <&adma 10>; + dma-names = "rx1", "tx1", + "rx2", "tx2", + "rx3", "tx3", + "rx4", "tx4", + "rx5", "tx5", + "rx6", "tx6", + "rx7", "tx7", + "rx8", "tx8", + "rx9", "tx9", + "rx10", "tx10"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml new file mode 100644 index 000000000000..44ee9d844ae0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-ahub.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 AHUB Device Tree Bindings + +description: | + The Audio Hub (AHUB) comprises a collection of hardware accelerators + for audio pre-processing, post-processing and a programmable full + crossbar for routing audio data across these accelerators. It has + external interfaces such as I2S, DMIC, DSPK. It interfaces with ADMA + engine through ADMAIF. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + $nodename: + pattern: "^ahub@[0-9a-f]*$" + + compatible: + oneOf: + - enum: + - nvidia,tegra210-ahub + - nvidia,tegra186-ahub + - items: + - const: nvidia,tegra194-ahub + - const: nvidia,tegra186-ahub + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ahub + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +required: + - compatible + - reg + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - "#address-cells" + - "#size-cells" + - ranges + +examples: + - | + #include<dt-bindings/clock/tegra210-car.h> + + ahub@702d0800 { + compatible = "nvidia,tegra210-ahub"; + reg = <0x702d0800 0x800>; + clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; + clock-names = "ahub"; + assigned-clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x702d0000 0x702d0000 0x0000e400>; + + // All AHUB child nodes below + admaif@702d0000 { + compatible = "nvidia,tegra210-admaif"; + reg = <0x702d0000 0x800>; + dmas = <&adma 1>, <&adma 1>, + <&adma 2>, <&adma 2>, + <&adma 3>, <&adma 3>, + <&adma 4>, <&adma 4>, + <&adma 5>, <&adma 5>, + <&adma 6>, <&adma 6>, + <&adma 7>, <&adma 7>, + <&adma 8>, <&adma 8>, + <&adma 9>, <&adma 9>, + <&adma 10>, <&adma 10>; + dma-names = "rx1", "tx1", + "rx2", "tx2", + "rx3", "tx3", + "rx4", "tx4", + "rx5", "tx5", + "rx6", "tx6", + "rx7", "tx7", + "rx8", "tx8", + "rx9", "tx9", + "rx10", "tx10"; + }; + + i2s@702d1000 { + compatible = "nvidia,tegra210-i2s"; + reg = <0x702d1000 0x100>; + clocks = <&tegra_car TEGRA210_CLK_I2S0>; + clock-names = "i2s"; + assigned-clocks = <&tegra_car TEGRA210_CLK_I2S0>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + assigned-clock-rates = <1536000>; + sound-name-prefix = "I2S1"; + }; + + dmic@702d4000 { + compatible = "nvidia,tegra210-dmic"; + reg = <0x702d4000 0x100>; + clocks = <&tegra_car TEGRA210_CLK_DMIC1>; + clock-names = "dmic"; + assigned-clocks = <&tegra_car TEGRA210_CLK_DMIC1>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + assigned-clock-rates = <3072000>; + sound-name-prefix = "DMIC1"; + }; + + // More child nodes to follow + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml new file mode 100644 index 000000000000..1c14e83f67c7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-dmic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 DMIC Controller Device Tree Bindings + +description: | + The Digital MIC (DMIC) Controller is used to interface with Pulse + Density Modulation (PDM) input devices. It converts PDM signals to + Pulse Coded Modulation (PCM) signals. DMIC can be viewed as a PDM + receiver. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + $nodename: + pattern: "^dmic@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-dmic + - items: + - enum: + - nvidia,tegra194-dmic + - nvidia,tegra186-dmic + - const: nvidia,tegra210-dmic + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: dmic + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + assigned-clock-rates: + maxItems: 1 + + sound-name-prefix: + pattern: "^DMIC[1-9]$" + allOf: + - $ref: /schemas/types.yaml#/definitions/string + description: + used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + The name can be "DMIC1" or "DMIC2" ... "DMICx", where x depends + on the maximum available instances on a Tegra SoC. + +required: + - compatible + - reg + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + +examples: + - | + #include<dt-bindings/clock/tegra210-car.h> + + dmic@702d4000 { + compatible = "nvidia,tegra210-dmic"; + reg = <0x702d4000 0x100>; + clocks = <&tegra_car TEGRA210_CLK_DMIC1>; + clock-names = "dmic"; + assigned-clocks = <&tegra_car TEGRA210_CLK_DMIC1>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + assigned-clock-rates = <3072000>; + sound-name-prefix = "DMIC1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml new file mode 100644 index 000000000000..795797001843 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra210-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tegra210 I2S Controller Device Tree Bindings + +description: | + The Inter-IC Sound (I2S) controller implements full-duplex, + bi-directional and single direction point-to-point serial + interfaces. It can interface with I2S compatible devices. + I2S controller can operate both in master and slave mode. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Sameer Pujar <spujar@nvidia.com> + +properties: + $nodename: + pattern: "^i2s@[0-9a-f]*$" + + compatible: + oneOf: + - const: nvidia,tegra210-i2s + - items: + - enum: + - nvidia,tegra194-i2s + - nvidia,tegra186-i2s + - const: nvidia,tegra210-i2s + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + items: + - description: I2S bit clock + - description: + Sync input clock, which can act as clock source to other I/O + modules in AHUB. The Tegra I2S driver sets this clock rate as + per bit clock rate. I/O module which wants to use this clock + as source, can mention this clock as parent in the DT bindings. + This is an optional clock entry, since it is only required when + some other I/O wants to reference from a particular I2Sx + instance. + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: i2s + - const: sync_input + + assigned-clocks: + minItems: 1 + maxItems: 2 + + assigned-clock-parents: + minItems: 1 + maxItems: 2 + + assigned-clock-rates: + minItems: 1 + maxItems: 2 + + sound-name-prefix: + pattern: "^I2S[1-9]$" + allOf: + - $ref: /schemas/types.yaml#/definitions/string + description: + Used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + The name can be "I2S1" or "I2S2" ... "I2Sx", where x depends + on the maximum available instances on a Tegra SoC. + +required: + - compatible + - reg + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + +examples: + - | + #include<dt-bindings/clock/tegra210-car.h> + + i2s@702d1000 { + compatible = "nvidia,tegra210-i2s"; + reg = <0x702d1000 0x100>; + clocks = <&tegra_car TEGRA210_CLK_I2S0>; + clock-names = "i2s"; + assigned-clocks = <&tegra_car TEGRA210_CLK_I2S0>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_A_OUT0>; + assigned-clock-rates = <1536000>; + sound-name-prefix = "I2S1"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt index 6b9a88d0ea3f..8c4883becae9 100644 --- a/Documentation/devicetree/bindings/sound/qcom,q6asm.txt +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm.txt @@ -39,9 +39,9 @@ configuration of each dai. Must contain the following properties. Usage: Required for Compress offload dais Value type: <u32> Definition: Specifies the direction of the dai stream - 0 for both tx and rx - 1 for only tx (Capture/Encode) - 2 for only rx (Playback/Decode) + Q6ASM_DAI_TX_RX (0) for both tx and rx + Q6ASM_DAI_TX (1) for only tx (Capture/Encode) + Q6ASM_DAI_RX (2) for only rx (Playback/Decode) - is-compress-dai: Usage: Required for Compress offload dais @@ -50,6 +50,7 @@ configuration of each dai. Must contain the following properties. = EXAMPLE +#include <dt-bindings/sound/qcom,q6asm.h> apr-service@7 { compatible = "qcom,q6asm"; @@ -62,7 +63,7 @@ apr-service@7 { dai@0 { reg = <0>; - direction = <2>; + direction = <Q6ASM_DAI_RX>; is-compress-dai; }; }; diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml index 8a4406be387a..0dd3f7361399 100644 --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml @@ -43,30 +43,19 @@ properties: '#sound-dai-cells': const: 1 - fsia,spdif-connection: +patternProperties: + "^fsi(a|b),spdif-connection$": $ref: /schemas/types.yaml#/definitions/flag description: FSI is connected by S/PDIF - fsia,stream-mode-support: + "^fsi(a|b),stream-mode-support$": $ref: /schemas/types.yaml#/definitions/flag description: FSI supports 16bit stream mode - fsia,use-internal-clock: + "^fsi(a|b),use-internal-clock$": $ref: /schemas/types.yaml#/definitions/flag description: FSI uses internal clock when master mode - fsib,spdif-connection: - $ref: /schemas/types.yaml#/definitions/flag - description: same as fsia - - fsib,stream-mode-support: - $ref: /schemas/types.yaml#/definitions/flag - description: same as fsia - - fsib,use-internal-clock: - $ref: /schemas/types.yaml#/definitions/flag - description: same as fsia - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 1596f0d1e2fe..b39743d3f7c4 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -271,6 +271,7 @@ Required properties: - "renesas,rcar_sound-r8a774a1" (RZ/G2M) - "renesas,rcar_sound-r8a774b1" (RZ/G2N) - "renesas,rcar_sound-r8a774c0" (RZ/G2E) + - "renesas,rcar_sound-r8a774e1" (RZ/G2H) - "renesas,rcar_sound-r8a7778" (R-Car M1A) - "renesas,rcar_sound-r8a7779" (R-Car H1) - "renesas,rcar_sound-r8a7790" (R-Car H2) diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.txt deleted file mode 100644 index 1ecd75d2032a..000000000000 --- a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Rockchip Rk3328 internal codec - -Required properties: - -- compatible: "rockchip,rk3328-codec" -- reg: physical base address of the controller and length of memory mapped - region. -- rockchip,grf: the phandle of the syscon node for GRF register. -- clocks: a list of phandle + clock-specifer pairs, one for each entry in clock-names. -- clock-names: should be "pclk". -- spk-depop-time-ms: speak depop time msec. - -Optional properties: - -- mute-gpios: GPIO specifier for external line driver control (typically the - dedicated GPIO_MUTE pin) - -Example for rk3328 internal codec: - -codec: codec@ff410000 { - compatible = "rockchip,rk3328-codec"; - reg = <0x0 0xff410000 0x0 0x1000>; - rockchip,grf = <&grf>; - clocks = <&cru PCLK_ACODEC>; - clock-names = "pclk"; - mute-gpios = <&grf_gpio 0 GPIO_ACTIVE_LOW>; - spk-depop-time-ms = 100; -}; diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml new file mode 100644 index 000000000000..5b85ad5e4834 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3328-codec.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rockchip,rk3328-codec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip rk3328 internal codec + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + const: rockchip,rk3328-codec + + reg: + maxItems: 1 + + clocks: + items: + - description: clock for audio codec + - description: clock for I2S master clock + + clock-names: + items: + - const: pclk + - const: mclk + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the syscon node for the GRF register. + + spk-depop-time-ms: + default: 200 + description: + Speaker depop time in msec. + + mute-gpios: + maxItems: 1 + description: + GPIO specifier for external line driver control (typically the + dedicated GPIO_MUTE pin) + + "#sound-dai-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - rockchip,grf + - "#sound-dai-cells" + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/clock/rk3328-cru.h> + codec: codec@ff410000 { + compatible = "rockchip,rk3328-codec"; + reg = <0xff410000 0x1000>; + clocks = <&cru PCLK_ACODECPHY>, <&cru SCLK_I2S1>; + clock-names = "pclk", "mclk"; + rockchip,grf = <&grf>; + mute-gpios = <&grf_gpio 0 GPIO_ACTIVE_LOW>; + spk-depop-time-ms = <100>; + #sound-dai-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/sound/rohm,bd28623.txt b/Documentation/devicetree/bindings/sound/rohm,bd28623.txt deleted file mode 100644 index d84557c2686e..000000000000 --- a/Documentation/devicetree/bindings/sound/rohm,bd28623.txt +++ /dev/null @@ -1,29 +0,0 @@ -ROHM BD28623MUV Class D speaker amplifier for digital input - -This codec does not have any control buses such as I2C, it detect format and -rate of I2S signal automatically. It has two signals that can be connected -to GPIOs: reset and mute. - -Required properties: -- compatible : should be "rohm,bd28623" -- #sound-dai-cells: should be 0. -- VCCA-supply : regulator phandle for the VCCA supply -- VCCP1-supply : regulator phandle for the VCCP1 supply -- VCCP2-supply : regulator phandle for the VCCP2 supply - -Optional properties: -- reset-gpios : GPIO specifier for the active low reset line -- mute-gpios : GPIO specifier for the active low mute line - -Example: - - codec { - compatible = "rohm,bd28623"; - #sound-dai-cells = <0>; - - VCCA-supply = <&vcc_reg>; - VCCP1-supply = <&vcc_reg>; - VCCP2-supply = <&vcc_reg>; - reset-gpios = <&gpio 0 GPIO_ACTIVE_LOW>; - mute-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; - }; diff --git a/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml b/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml new file mode 100644 index 000000000000..859ce64da152 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rohm,bd28623.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/rohm,bd28623.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD28623MUV Class D speaker amplifier for digital input + +description: + This codec does not have any control buses such as I2C, it detect + format and rate of I2S signal automatically. It has two signals + that can be connected to GPIOs reset and mute. + +maintainers: + - Katsuhiro Suzuki <katsuhiro@katsuster.net> + +properties: + compatible: + const: rohm,bd28623 + + "#sound-dai-cells": + const: 0 + + VCCA-supply: + description: + regulator phandle for the VCCA (for analog) power supply + + VCCP1-supply: + description: + regulator phandle for the VCCP1 (for ch1) power supply + + VCCP2-supply: + description: + regulator phandle for the VCCP2 (for ch2) power supply + + reset-gpios: + maxItems: 1 + description: + GPIO specifier for the active low reset line + + mute-gpios: + maxItems: 1 + description: + GPIO specifier for the active low mute line + +required: + - compatible + - VCCA-supply + - VCCP1-supply + - VCCP2-supply + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + codec { + compatible = "rohm,bd28623"; + #sound-dai-cells = <0>; + + VCCA-supply = <&vcc_reg>; + VCCP1-supply = <&vcc_reg>; + VCCP2-supply = <&vcc_reg>; + reset-gpios = <&gpio 0 GPIO_ACTIVE_LOW>; + mute-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + }; diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml new file mode 100644 index 000000000000..902a0b66628e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -0,0 +1,147 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,aries-wm8994.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Aries audio complex with WM8994 codec + +maintainers: + - Jonathan Bakker <xc-racer2@live.ca> + +properties: + compatible: + oneOf: + - const: samsung,aries-wm8994 + description: With FM radio and modem master + + - const: samsung,fascinate4g-wm8994 + description: Without FM radio and modem slave + + model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + cpu: + type: object + properties: + sound-dai: + minItems: 2 + maxItems: 2 + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + phandles to the I2S controller and bluetooth codec, + in that order + + codec: + type: object + properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: phandle to the WM8994 CODEC + + samsung,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + 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; + valid names for sources and sinks are the WM8994's pins (as + documented in its binding), and the jacks on the board - + For samsung,aries-wm8994: HP, SPK, RCV, LINE, Main Mic, Headset Mic, + or FM In + For samsung,fascinate4g-wm8994: HP, SPK, RCV, LINE, Main Mic, + or HeadsetMic + + extcon: + description: Extcon phandle for dock detection + + main-micbias-supply: + description: Supply for the micbias on the main mic + + headset-micbias-supply: + description: Supply for the micbias on the headset mic + + earpath-sel-gpios: + description: GPIO for switching between tv-out and mic paths + + headset-detect-gpios: + description: GPIO for detection of headset insertion + + headset-key-gpios: + description: GPIO for detection of headset key press + + io-channels: + maxItems: 1 + description: IO channel to read micbias voltage for headset detection + + io-channel-names: + const: headset-detect + +required: + - compatible + - model + - cpu + - codec + - samsung,audio-routing + - extcon + - main-micbias-supply + - headset-micbias-supply + - earpath-sel-gpios + - headset-detect-gpios + - headset-key-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + sound { + compatible = "samsung,fascinate4g-wm8994"; + + model = "Fascinate4G"; + + extcon = <&fsa9480>; + + main-micbias-supply = <&main_micbias_reg>; + headset-micbias-supply = <&headset_micbias_reg>; + + earpath-sel-gpios = <&gpj2 6 GPIO_ACTIVE_HIGH>; + + io-channels = <&adc 3>; + io-channel-names = "headset-detect"; + headset-detect-gpios = <&gph0 6 GPIO_ACTIVE_HIGH>; + headset-key-gpios = <&gph3 6 GPIO_ACTIVE_HIGH>; + + samsung,audio-routing = + "HP", "HPOUT1L", + "HP", "HPOUT1R", + + "SPK", "SPKOUTLN", + "SPK", "SPKOUTLP", + + "RCV", "HPOUT2N", + "RCV", "HPOUT2P", + + "LINE", "LINEOUT2N", + "LINE", "LINEOUT2P", + + "IN1LP", "Main Mic", + "IN1LN", "Main Mic", + + "IN1RP", "Headset Mic", + "IN1RN", "Headset Mic"; + + pinctrl-names = "default"; + pinctrl-0 = <&headset_det &earpath_sel>; + + cpu { + sound-dai = <&i2s0>, <&bt_codec>; + }; + + codec { + sound-dai = <&wm8994>; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml new file mode 100644 index 000000000000..1c755de686f7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,midas-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Midas audio complex with WM1811 codec + +maintainers: + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + const: samsung,midas-audio + + model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + cpu: + type: object + properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the I2S controller + required: + - sound-dai + + codec: + type: object + properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the WM1811 CODEC + required: + - sound-dai + + samsung,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + 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; valid names for sources and sinks are + the WM1811's pins (as documented in its binding), and the jacks + on the board: HP, SPK, Main Mic, Sub Mic, Headset Mic. + + mic-bias-supply: + description: Supply for the micbias on the Main microphone + + submic-bias-supply: + description: Supply for the micbias on the Sub microphone + + fm-sel-gpios: + description: GPIO pin for FM selection + + lineout-sel-gpios: + description: GPIO pin for line out selection + +required: + - compatible + - model + - cpu + - codec + - samsung,audio-routing + - mic-bias-supply + - submic-bias-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + sound { + compatible = "samsung,midas-audio"; + model = "Midas"; + + fm-sel-gpios = <&gpaa0 3 GPIO_ACTIVE_HIGH>; + + mic-bias-supply = <&mic_bias_reg>; + submic-bias-supply = <&submic_bias_reg>; + + samsung,audio-routing = + "HP", "HPOUT1L", + "HP", "HPOUT1R", + + "SPK", "SPKOUTLN", + "SPK", "SPKOUTLP", + "SPK", "SPKOUTRN", + "SPK", "SPKOUTRP", + + "RCV", "HPOUT2N", + "RCV", "HPOUT2P", + + "IN1LP", "Main Mic", + "IN1LN", "Main Mic", + "IN1RP", "Sub Mic", + "IN1LP", "Sub Mic"; + + cpu { + sound-dai = <&i2s0>; + }; + + codec { + sound-dai = <&wm1811>; + }; + + }; diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt deleted file mode 100644 index 9d9ff5184939..000000000000 --- a/Documentation/devicetree/bindings/sound/sgtl5000.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Freescale SGTL5000 Stereo Codec - -Required properties: -- compatible : "fsl,sgtl5000". - -- reg : the I2C address of the device - -- #sound-dai-cells: must be equal to 0 - -- clocks : the clock provider of SYS_MCLK - -- VDDA-supply : the regulator provider of VDDA - -- VDDIO-supply: the regulator provider of VDDIO - -Optional properties: - -- VDDD-supply : the regulator provider of VDDD - -- micbias-resistor-k-ohms : the bias resistor to be used in kOhms - The resistor can take values of 2k, 4k or 8k. - If set to 0 it will be off. - If this node is not mentioned or if the value is unknown, then - micbias resistor is set to 4K. - -- micbias-voltage-m-volts : the bias voltage to be used in mVolts - The voltage can take values from 1.25V to 3V by 250mV steps - If this node is not mentioned or the value is unknown, then - the value is set to 1.25V. - -- lrclk-strength: the LRCLK pad strength. Possible values are: -0, 1, 2 and 3 as per the table below: - -VDDIO 1.8V 2.5V 3.3V -0 = Disable -1 = 1.66 mA 2.87 mA 4.02 mA -2 = 3.33 mA 5.74 mA 8.03 mA -3 = 4.99 mA 8.61 mA 12.05 mA - -- sclk-strength: the SCLK pad strength. Possible values are: -0, 1, 2 and 3 as per the table below: - -VDDIO 1.8V 2.5V 3.3V -0 = Disable -1 = 1.66 mA 2.87 mA 4.02 mA -2 = 3.33 mA 5.74 mA 8.03 mA -3 = 4.99 mA 8.61 mA 12.05 mA - -Example: - -sgtl5000: codec@a { - compatible = "fsl,sgtl5000"; - reg = <0x0a>; - #sound-dai-cells = <0>; - clocks = <&clks 150>; - micbias-resistor-k-ohms = <2>; - micbias-voltage-m-volts = <2250>; - VDDA-supply = <®_3p3v>; - VDDIO-supply = <®_3p3v>; -}; diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml new file mode 100644 index 000000000000..4f29b63c54d3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/sgtl5000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale SGTL5000 Stereo Codec + +maintainers: + - Fabio Estevam <festevam@gmail.com> + +properties: + compatible: + const: fsl,sgtl5000 + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + clocks: + items: + - description: the clock provider of SYS_MCLK + + VDDA-supply: + description: the regulator provider of VDDA + + VDDIO-supply: + description: the regulator provider of VDDIO + + VDDD-supply: + description: the regulator provider of VDDD + + micbias-resistor-k-ohms: + description: The bias resistor to be used in kOhms. The resistor can take + values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not + mentioned or if the value is unknown, then micbias resistor is set to + 4k. + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [ 0, 2, 4, 8 ] + + micbias-voltage-m-volts: + description: The bias voltage to be used in mVolts. The voltage can take + values from 1.25V to 3V by 250mV steps. If this node is not mentioned + or the value is unknown, then the value is set to 1.25V. + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ] + + lrclk-strength: + description: | + The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the + table below: + + VDDIO 1.8V 2.5V 3.3V + 0 = Disable + 1 = 1.66 mA 2.87 mA 4.02 mA + 2 = 3.33 mA 5.74 mA 8.03 mA + 3 = 4.99 mA 8.61 mA 12.05 mA + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [ 0, 1, 2, 3 ] + + sclk-strength: + description: | + The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the + table below: + + VDDIO 1.8V 2.5V 3.3V + 0 = Disable + 1 = 1.66 mA 2.87 mA 4.02 mA + 2 = 3.33 mA 5.74 mA 8.03 mA + 3 = 4.99 mA 8.61 mA 12.05 mA + $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [ 0, 1, 2, 3 ] + +required: + - compatible + - reg + - "#sound-dai-cells" + - clocks + - VDDA-supply + - VDDIO-supply + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@a { + compatible = "fsl,sgtl5000"; + reg = <0x0a>; + #sound-dai-cells = <0>; + clocks = <&clks 150>; + micbias-resistor-k-ohms = <2>; + micbias-voltage-m-volts = <2250>; + VDDA-supply = <®_3p3v>; + VDDIO-supply = <®_3p3v>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml new file mode 100644 index 000000000000..4987eb91f2ab --- /dev/null +++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/socionext,uniphier-aio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UniPhier AIO audio system + +maintainers: + - <alsa-devel@alsa-project.org> + +properties: + compatible: + enum: + - socionext,uniphier-ld11-aio + - socionext,uniphier-ld20-aio + - socionext,uniphier-pxs2-aio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + const: aio + + clocks: + maxItems: 1 + + reset-names: + const: aio + + resets: + maxItems: 1 + + socionext,syscon: + description: | + Specifies a phandle to soc-glue, which is used for changing mode of S/PDIF + signal pin to output from Hi-Z. This property is optional if you use I2S + signal pins only. + $ref: "/schemas/types.yaml#/definitions/phandle" + + "#sound-dai-cells": + const: 1 + +patternProperties: + "^port@[0-9]$": + type: object + properties: + endpoint: true + required: + - endpoint + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + - reset-names + - resets + - "#sound-dai-cells" + +examples: + - | + audio@56000000 { + compatible = "socionext,uniphier-ld20-aio"; + reg = <0x56000000 0x80000>; + interrupts = <0 144 4>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_aout>; + clock-names = "aio"; + clocks = <&sys_clk 40>; + reset-names = "aio"; + resets = <&sys_rst 40>; + #sound-dai-cells = <1>; + socionext,syscon = <&soc_glue>; + }; diff --git a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml new file mode 100644 index 000000000000..228168f685cf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/socionext,uniphier-evea.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UniPhier EVEA SoC-internal sound codec + +maintainers: + - <alsa-devel@alsa-project.org> + +properties: + compatible: + const: socionext,uniphier-evea + + reg: + maxItems: 1 + + clock-names: + items: + - const: evea + - const: exiv + + clocks: + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: evea + - const: exiv + - const: adamv + + resets: + minItems: 3 + maxItems: 3 + + "#sound-dai-cells": + const: 1 + +patternProperties: + "^port@[0-9]$": + type: object + properties: + endpoint: true + required: + - endpoint + +additionalProperties: false + +required: + - compatible + - reg + - clock-names + - clocks + - reset-names + - resets + - "#sound-dai-cells" + +examples: + - | + codec@57900000 { + compatible = "socionext,uniphier-evea"; + reg = <0x57900000 0x1000>; + clock-names = "evea", "exiv"; + clocks = <&sys_clk 41>, <&sys_clk 42>; + reset-names = "evea", "exiv", "adamv"; + resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>; + #sound-dai-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt b/Documentation/devicetree/bindings/sound/tas2552.txt index 2d71eb05c1d3..a7eecad83db1 100644 --- a/Documentation/devicetree/bindings/sound/tas2552.txt +++ b/Documentation/devicetree/bindings/sound/tas2552.txt @@ -33,4 +33,4 @@ tas2552: tas2552@41 { }; For more product information please see the link below: -http://www.ti.com/product/TAS2552 +https://www.ti.com/product/TAS2552 diff --git a/Documentation/devicetree/bindings/sound/tas2562.txt b/Documentation/devicetree/bindings/sound/tas2562.txt index 94796b547184..dc6d7362ded7 100644 --- a/Documentation/devicetree/bindings/sound/tas2562.txt +++ b/Documentation/devicetree/bindings/sound/tas2562.txt @@ -11,12 +11,14 @@ Required properties: - compatible: - Should contain "ti,tas2562", "ti,tas2563". - reg: - The i2c address. Should be 0x4c, 0x4d, 0x4e or 0x4f. - ti,imon-slot-no:- TDM TX current sense time slot. + - ti,vmon-slot-no:- TDM TX voltage sense time slot. This slot must always be + greater then ti,imon-slot-no. Optional properties: - interrupt-parent: phandle to the interrupt controller which provides the interrupt. - interrupts: (GPIO) interrupt to which the chip is connected. -- shut-down: GPIO used to control the state of the device. +- shut-down-gpio: GPIO used to control the state of the device. Examples: tas2562@4c { @@ -28,7 +30,8 @@ tas2562@4c { interrupt-parent = <&gpio1>; interrupts = <14>; - shut-down = <&gpio1 15 0>; + shut-down-gpio = <&gpio1 15 0>; ti,imon-slot-no = <0>; + ti,vmon-slot-no = <1>; }; diff --git a/Documentation/devicetree/bindings/sound/tas2562.yaml b/Documentation/devicetree/bindings/sound/tas2562.yaml new file mode 100644 index 000000000000..8d75a798740b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2562.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2562.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2562 Smart PA + +maintainers: + - Dan Murphy <dmurphy@ti.com> + +description: | + The TAS2562 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2562 + - ti,tas2563 + + reg: + maxItems: 1 + description: | + I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f + + shut-down-gpios: + description: GPIO used to control the state of the device. + deprecated: true + + shutdown-gpios: + description: GPIO used to control the state of the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@4c { + compatible = "ti,tas2562"; + reg = <0x4c>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + shutdown-gpios = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/tas2770.txt b/Documentation/devicetree/bindings/sound/tas2770.txt deleted file mode 100644 index ede6bb3d9637..000000000000 --- a/Documentation/devicetree/bindings/sound/tas2770.txt +++ /dev/null @@ -1,37 +0,0 @@ -Texas Instruments TAS2770 Smart PA - -The TAS2770 is a mono, digital input Class-D audio amplifier optimized for -efficiently driving high peak power into small loudspeakers. -Integrated speaker voltage and current sense provides for -real time monitoring of loudspeaker behavior. - -Required properties: - - - compatible: - Should contain "ti,tas2770". - - reg: - The i2c address. Should contain <0x4c>, <0x4d>,<0x4e>, or <0x4f>. - - #address-cells - Should be <1>. - - #size-cells - Should be <0>. - - ti,asi-format: - Sets TDM RX capture edge. 0->Rising; 1->Falling. - - ti,imon-slot-no:- TDM TX current sense time slot. - - ti,vmon-slot-no:- TDM TX voltage sense time slot. - -Optional properties: - -- interrupt-parent: the phandle to the interrupt controller which provides - the interrupt. -- interrupts: interrupt specification for data-ready. - -Examples: - - tas2770@4c { - compatible = "ti,tas2770"; - reg = <0x4c>; - #address-cells = <1>; - #size-cells = <0>; - interrupt-parent = <&msm_gpio>; - interrupts = <97 0>; - ti,asi-format = <0>; - ti,imon-slot-no = <0>; - ti,vmon-slot-no = <2>; - }; - diff --git a/Documentation/devicetree/bindings/sound/tas2770.yaml b/Documentation/devicetree/bindings/sound/tas2770.yaml new file mode 100644 index 000000000000..8192450d72dc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2770.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2019-20 Texas Instruments Incorporated +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/tas2770.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Texas Instruments TAS2770 Smart PA + +maintainers: + - Shi Fu <shifu0704@thundersoft.com> + +description: | + The TAS2770 is a mono, digital input Class-D audio amplifier optimized for + efficiently driving high peak power into small loudspeakers. + Integrated speaker voltage and current sense provides for + real time monitoring of loudspeaker behavior. + +properties: + compatible: + enum: + - ti,tas2770 + + reg: + maxItems: 1 + description: | + I2C address of the device can be one of these 0x4c, 0x4d, 0x4e or 0x4f + + reset-gpio: + description: GPIO used to reset the device. + + interrupts: + maxItems: 1 + + ti,imon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX current sense time slot. + + ti,vmon-slot-no: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TDM TX voltage sense time slot. + + ti,asi-format: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Sets TDM RX capture edge. + enum: + - 0 # Rising edge + - 1 # Falling edge + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + codec: codec@4c { + compatible = "ti,tas2770"; + reg = <0x4c>; + #sound-dai-cells = <1>; + interrupt-parent = <&gpio1>; + interrupts = <14>; + reset-gpio = <&gpio1 15 0>; + ti,imon-slot-no = <0>; + ti,vmon-slot-no = <2>; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/tas5720.txt b/Documentation/devicetree/bindings/sound/tas5720.txt index 7481653fe8e3..df99ca9451b0 100644 --- a/Documentation/devicetree/bindings/sound/tas5720.txt +++ b/Documentation/devicetree/bindings/sound/tas5720.txt @@ -4,9 +4,9 @@ The TAS5720 serial control bus communicates through the I2C protocol only. The serial bus is also used for periodic codec fault checking/reporting during audio playback. For more product information please see the links below: -http://www.ti.com/product/TAS5720L -http://www.ti.com/product/TAS5720M -http://www.ti.com/product/TAS5722L +https://www.ti.com/product/TAS5720L +https://www.ti.com/product/TAS5720M +https://www.ti.com/product/TAS5722L Required properties: diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml new file mode 100644 index 000000000000..6f2be6503401 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments J721e Common Processor Board Audio Support + +maintainers: + - Peter Ujfalusi <peter.ujfalusi@ti.com> + +description: | + The audio support on the board is using pcm3168a codec connected to McASP10 + serializers in parallel setup. + The pcm3168a SCKI clock is sourced from j721e AUDIO_REFCLK2 pin. + In order to support 48KHz and 44.1KHz family of sampling rates the parent + clock for AUDIO_REFCLK2 needs to be changed between PLL4 (for 48KHz) and + PLL15 (for 44.1KHz). The same PLLs are used for McASP10's AUXCLK clock via + different HSDIVIDER. + + Clocking setup for 48KHz family: + PLL4 ---> PLL4_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk + |-> PLL4_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI + + Clocking setup for 44.1KHz family: + PLL15 ---> PLL15_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk + |-> PLL15_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI + +properties: + compatible: + items: + - const: ti,j721e-cpb-audio + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + ti,cpb-mcasp: + description: phandle to McASP used on CPB + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + ti,cpb-codec: + description: phandle to the pcm3168a codec used on the CPB + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + clocks: + items: + - description: AUXCLK clock for McASP used by CPB audio + - description: Parent for CPB_McASP auxclk (for 48KHz) + - description: Parent for CPB_McASP auxclk (for 44.1KHz) + - description: SCKI clock for the pcm3168a codec on CPB + - description: Parent for CPB_SCKI clock (for 48KHz) + - description: Parent for CPB_SCKI clock (for 44.1KHz) + + clock-names: + items: + - const: cpb-mcasp-auxclk + - const: cpb-mcasp-auxclk-48000 + - const: cpb-mcasp-auxclk-44100 + - const: cpb-codec-scki + - const: cpb-codec-scki-48000 + - const: cpb-codec-scki-44100 + +required: + - compatible + - model + - ti,cpb-mcasp + - ti,cpb-codec + - clocks + - clock-names + +additionalProperties: false + +examples: + - |+ + sound { + compatible = "ti,j721e-cpb-audio"; + model = "j721e-cpb"; + + status = "okay"; + + ti,cpb-mcasp = <&mcasp10>; + ti,cpb-codec = <&pcm3168a_1>; + + clocks = <&k3_clks 184 1>, + <&k3_clks 184 2>, <&k3_clks 184 4>, + <&k3_clks 157 371>, + <&k3_clks 157 400>, <&k3_clks 157 401>; + clock-names = "cpb-mcasp-auxclk", + "cpb-mcasp-auxclk-48000", "cpb-mcasp-auxclk-44100", + "cpb-codec-scki", + "cpb-codec-scki-48000", "cpb-codec-scki-44100"; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml new file mode 100644 index 000000000000..e0b88470a502 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-ivi-audio.yaml @@ -0,0 +1,150 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,j721e-cpb-ivi-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments J721e Common Processor Board Audio Support + +maintainers: + - Peter Ujfalusi <peter.ujfalusi@ti.com> + +description: | + The Infotainment board plugs into the Common Processor Board, the support of the + extension board is extending the CPB audio support, decribed in: + sound/ti,j721e-cpb-audio.txt + + The audio support on the Infotainment Expansion Board consists of McASP0 + connected to two pcm3168a codecs with dedicated set of serializers to each. + The SCKI for pcm3168a is sourced from j721e AUDIO_REFCLK0 pin. + + In order to support 48KHz and 44.1KHz family of sampling rates the parent clock + for AUDIO_REFCLK0 needs to be changed between PLL4 (for 48KHz) and PLL15 (for + 44.1KHz). The same PLLs are used for McASP0's AUXCLK clock via different + HSDIVIDER. + + Note: the same PLL4 and PLL15 is used by the audio support on the CPB! + + Clocking setup for 48KHz family: + PLL4 ---> PLL4_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk + | |-> MCASP0_AUXCLK ---> McASP0.auxclk + | + |-> PLL4_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI + |-> AUDIO_REFCLK0 ---> pcm3168a_a/b.SCKI + + Clocking setup for 44.1KHz family: + PLL15 ---> PLL15_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk + | |-> MCASP0_AUXCLK ---> McASP0.auxclk + | + |-> PLL15_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI + |-> AUDIO_REFCLK0 ---> pcm3168a_a/b.SCKI + +properties: + compatible: + items: + - const: ti,j721e-cpb-ivi-audio + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + ti,cpb-mcasp: + description: phandle to McASP used on CPB + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + ti,cpb-codec: + description: phandle to the pcm3168a codec used on the CPB + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + ti,ivi-mcasp: + description: phandle to McASP used on IVI + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + ti,ivi-codec-a: + description: phandle to the pcm3168a-A codec on the expansion board + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + ti,ivi-codec-b: + description: phandle to the pcm3168a-B codec on the expansion board + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + + clocks: + items: + - description: AUXCLK clock for McASP used by CPB audio + - description: Parent for CPB_McASP auxclk (for 48KHz) + - description: Parent for CPB_McASP auxclk (for 44.1KHz) + - description: SCKI clock for the pcm3168a codec on CPB + - description: Parent for CPB_SCKI clock (for 48KHz) + - description: Parent for CPB_SCKI clock (for 44.1KHz) + - description: AUXCLK clock for McASP used by IVI audio + - description: Parent for IVI_McASP auxclk (for 48KHz) + - description: Parent for IVI_McASP auxclk (for 44.1KHz) + - description: SCKI clock for the pcm3168a codec on IVI + - description: Parent for IVI_SCKI clock (for 48KHz) + - description: Parent for IVI_SCKI clock (for 44.1KHz) + + clock-names: + items: + - const: cpb-mcasp-auxclk + - const: cpb-mcasp-auxclk-48000 + - const: cpb-mcasp-auxclk-44100 + - const: cpb-codec-scki + - const: cpb-codec-scki-48000 + - const: cpb-codec-scki-44100 + - const: ivi-mcasp-auxclk + - const: ivi-mcasp-auxclk-48000 + - const: ivi-mcasp-auxclk-44100 + - const: ivi-codec-scki + - const: ivi-codec-scki-48000 + - const: ivi-codec-scki-44100 + +required: + - compatible + - model + - ti,cpb-mcasp + - ti,cpb-codec + - ti,ivi-mcasp + - ti,ivi-codec-a + - ti,ivi-codec-b + - clocks + - clock-names + +additionalProperties: false + +examples: + - |+ + sound { + compatible = "ti,j721e-cpb-ivi-audio"; + model = "j721e-cpb-ivi"; + + status = "okay"; + + ti,cpb-mcasp = <&mcasp10>; + ti,cpb-codec = <&pcm3168a_1>; + + ti,ivi-mcasp = <&mcasp0>; + ti,ivi-codec-a = <&pcm3168a_a>; + ti,ivi-codec-b = <&pcm3168a_b>; + + clocks = <&k3_clks 184 1>, + <&k3_clks 184 2>, <&k3_clks 184 4>, + <&k3_clks 157 371>, + <&k3_clks 157 400>, <&k3_clks 157 401>, + <&k3_clks 174 1>, + <&k3_clks 174 2>, <&k3_clks 174 4>, + <&k3_clks 157 301>, + <&k3_clks 157 330>, <&k3_clks 157 331>; + clock-names = "cpb-mcasp-auxclk", + "cpb-mcasp-auxclk-48000", "cpb-mcasp-auxclk-44100", + "cpb-codec-scki", + "cpb-codec-scki-48000", "cpb-codec-scki-44100", + "ivi-mcasp-auxclk", + "ivi-mcasp-auxclk-48000", "ivi-mcasp-auxclk-44100", + "ivi-codec-scki", + "ivi-codec-scki-48000", "ivi-codec-scki-44100"; + }; diff --git a/Documentation/devicetree/bindings/sound/ti,tas6424.txt b/Documentation/devicetree/bindings/sound/ti,tas6424.txt index eacb54f34188..00940c489299 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas6424.txt +++ b/Documentation/devicetree/bindings/sound/ti,tas6424.txt @@ -19,4 +19,4 @@ tas6424: tas6424@6a { }; For more product information please see the link below: -http://www.ti.com/product/TAS6424-Q1 +https://www.ti.com/product/TAS6424-Q1 diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index 2e6ac5d2ee96..e84d4a20c633 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -18,9 +18,9 @@ description: | microphone bias or supply voltage generation. Specifications can be found at: - http://www.ti.com/lit/ds/symlink/tlv320adc3140.pdf - http://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf - http://www.ti.com/lit/ds/symlink/tlv320adc6140.pdf + https://www.ti.com/lit/ds/symlink/tlv320adc3140.pdf + https://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf + https://www.ti.com/lit/ds/symlink/tlv320adc6140.pdf properties: compatible: @@ -108,6 +108,32 @@ properties: maximum: 7 default: [0, 0, 0, 0] +patternProperties: + '^ti,gpo-config-[1-4]$': + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Defines the configuration and output driver for the general purpose + output pins (GPO). These values are pairs, the first value is for the + configuration type and the second value is for the output drive type. + The array is defined as <GPO_CFG GPO_DRV> + + GPO output configuration can be one of the following: + + 0 - (default) disabled + 1 - GPOX is configured as a general-purpose output (GPO) + 2 - GPOX is configured as a device interrupt output (IRQ) + 3 - GPOX is configured as a secondary ASI output (SDOUT2) + 4 - GPOX is configured as a PDM clock output (PDMCLK) + + GPO output drive configuration for the GPO pins can be one of the following: + + 0d - (default) Hi-Z output + 1d - Drive active low and active high + 2d - Drive active low and weak high + 3d - Drive active low and Hi-Z + 4d - Drive weak low and active high + 5d - Drive Hi-Z and active high + required: - compatible - reg @@ -124,6 +150,8 @@ examples: ti,mic-bias-source = <6>; ti,pdm-edge-select = <0 1 0 1>; ti,gpi-config = <4 5 6 7>; + ti,gpo-config-1 = <0 0>; + ti,gpo-config-2 = <0 0>; reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; }; }; diff --git a/Documentation/devicetree/bindings/sound/uniphier,aio.txt b/Documentation/devicetree/bindings/sound/uniphier,aio.txt deleted file mode 100644 index 4ce68ed6f2f2..000000000000 --- a/Documentation/devicetree/bindings/sound/uniphier,aio.txt +++ /dev/null @@ -1,45 +0,0 @@ -Socionext UniPhier SoC audio driver - -The Socionext UniPhier audio subsystem consists of I2S and S/PDIF blocks in -the same register space. - -Required properties: -- compatible : should be one of the following: - "socionext,uniphier-ld11-aio" - "socionext,uniphier-ld20-aio" - "socionext,uniphier-pxs2-aio" -- reg : offset and length of the register set for the device. -- interrupts : should contain I2S or S/PDIF interrupt. -- pinctrl-names : should be "default". -- pinctrl-0 : defined I2S signal pins for an external codec chip. -- clock-names : should include following entries: - "aio" -- clocks : a list of phandle, should contain an entry for each - entry in clock-names. -- reset-names : should include following entries: - "aio" -- resets : a list of phandle, should contain an entry for each - entry in reset-names. -- #sound-dai-cells: should be 1. - -Optional properties: -- socionext,syscon: a phandle, should contain soc-glue. - The soc-glue is used for changing mode of S/PDIF signal pin - to Output from Hi-Z. This property is optional if you use - I2S signal pins only. - -Example: - audio { - compatible = "socionext,uniphier-ld20-aio"; - reg = <0x56000000 0x80000>; - interrupts = <0 144 4>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_aout>; - clock-names = "aio"; - clocks = <&sys_clk 40>; - reset-names = "aio"; - resets = <&sys_rst 40>; - #sound-dai-cells = <1>; - - socionext,syscon = <&sg>; - }; diff --git a/Documentation/devicetree/bindings/sound/uniphier,evea.txt b/Documentation/devicetree/bindings/sound/uniphier,evea.txt deleted file mode 100644 index 3f31b235f18b..000000000000 --- a/Documentation/devicetree/bindings/sound/uniphier,evea.txt +++ /dev/null @@ -1,26 +0,0 @@ -Socionext EVEA - UniPhier SoC internal codec driver - -Required properties: -- compatible : should be "socionext,uniphier-evea". -- reg : offset and length of the register set for the device. -- clock-names : should include following entries: - "evea", "exiv" -- clocks : a list of phandle, should contain an entry for each - entries in clock-names. -- reset-names : should include following entries: - "evea", "exiv", "adamv" -- resets : a list of phandle, should contain reset entries of - reset-names. -- #sound-dai-cells: should be 1. - -Example: - - codec { - compatible = "socionext,uniphier-evea"; - reg = <0x57900000 0x1000>; - clock-names = "evea", "exiv"; - clocks = <&sys_clk 41>, <&sys_clk 42>; - reset-names = "evea", "exiv", "adamv"; - resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>; - #sound-dai-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/sound/wm8960.txt b/Documentation/devicetree/bindings/sound/wm8960.txt index 6d29ac3750ee..85d3b287108c 100644 --- a/Documentation/devicetree/bindings/sound/wm8960.txt +++ b/Documentation/devicetree/bindings/sound/wm8960.txt @@ -21,6 +21,17 @@ Optional properties: enabled and disabled together with HP_L and HP_R pins in response to jack detect events. + - wlf,hp-cfg: A list of headphone jack detect configuration register values. + The list must be 3 entries long. + hp-cfg[0]: HPSEL[1:0] of R48 (Additional Control 4). + hp-cfg[1]: {HPSWEN:HPSWPOL} of R24 (Additional Control 2). + hp-cfg[2]: {TOCLKSEL:TOEN} of R23 (Additional Control 1). + + - wlf,gpio-cfg: A list of GPIO configuration register values. + The list must be 2 entries long. + gpio-cfg[0]: ALRCGPIO of R9 (Audio interface) + gpio-cfg[1]: {GPIOPOL:GPIOSEL[2:0]} of R48 (Additional Control 4). + Example: wm8960: codec@1a { diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt index 367b58ce1bb9..8fa947509c10 100644 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ b/Documentation/devicetree/bindings/sound/wm8994.txt @@ -68,6 +68,29 @@ Optional properties: - wlf,csnaddr-pd : If present enable the internal pull-down resistor on the CS/ADDR pin. +Pins on the device (for linking into audio routes): + + * IN1LN + * IN1LP + * IN2LN + * IN2LP:VXRN + * IN1RN + * IN1RP + * IN2RN + * IN2RP:VXRP + * SPKOUTLP + * SPKOUTLN + * SPKOUTRP + * SPKOUTRN + * HPOUT1L + * HPOUT1R + * HPOUT2P + * HPOUT2N + * LINEOUT1P + * LINEOUT1N + * LINEOUT2P + * LINEOUT2N + Example: wm8994: codec@1a { diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index 87369264feb9..44ba6765697d 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -50,7 +50,7 @@ properties: nvmem-cell-names: const: calibration - # See ./thermal.txt for details + # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details "#thermal-sensor-cells": enum: - 0 diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt index 703979dbd577..12fc4ef04837 100644 --- a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt @@ -6,7 +6,7 @@ transaction. Required properties: - compatible: "amazon,al-thermal". - reg: The physical base address and length of the sensor's registers. -- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells: Must be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example: thermal: thermal { diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml index f3e68ed03abf..1ab5070c751d 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-ro-thermal.yaml @@ -23,7 +23,7 @@ properties: compatible: const: brcm,bcm2711-thermal - # See ./thermal.txt for details + # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details "#thermal-sensor-cells": const: 0 diff --git a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt index da8c5b73ad10..a3e9ec5dc7ac 100644 --- a/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/brcm,bcm2835-thermal.txt @@ -7,7 +7,7 @@ compatible: should be one of: "brcm,bcm2835-thermal", "brcm,bcm2836-thermal" or "brcm,bcm2837-thermal" reg: Address range of the thermal registers. clocks: Phandle of the clock used by the thermal sensor. -#thermal-sensor-cells: should be 0 (see thermal.txt) +#thermal-sensor-cells: should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml) Example: diff --git a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt index cef716a236f1..4b19d80e6558 100644 --- a/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/hisilicon-thermal.txt @@ -9,7 +9,7 @@ by /SOCTHERM/tsensor. - clock-names: Input clock name, should be 'thermal_clk'. - clocks: phandles for clock specified in "clock-names" property. -- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Example : diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt index 323a3b3822aa..82ed5d487966 100644 --- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt @@ -8,12 +8,12 @@ below threshold level. Required properties: ------------------- -#thermal-sensor-cells: Please refer <devicetree/bindings/thermal/thermal.txt> - for more details. +#thermal-sensor-cells: For more details, please refer to + <devicetree/bindings/thermal/thermal-sensor.yaml> The value must be 0. For more details, please refer generic thermal DT binding document -<devicetree/bindings/thermal/thermal.txt>. +<devicetree/bindings/thermal/thermal*.yaml>. Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding document for the MAX77620. diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index f8d7831f3974..1e249c42fae0 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -23,7 +23,7 @@ Required properties: - resets: Reference to the reset controller controlling the thermal controller. - mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses - mediatek,apmixedsys: A phandle to the APMIXEDSYS controller. -- #thermal-sensor-cells : Should be 0. See ./thermal.txt for a description. +- #thermal-sensor-cells : Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - nvmem-cells: A phandle to the calibration data provided by a nvmem device. If diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt index f02f38527a6b..db880e7ed713 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt @@ -28,9 +28,10 @@ Required properties : See ../reset/reset.txt for details. - reset-names : Must include the following entries: - soctherm -- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description - of this property. See <dt-bindings/thermal/tegra124-soctherm.h> for a - list of valid values when referring to thermal sensors. +- #thermal-sensor-cells : Should be 1. For a description of this property, see + Documentation/devicetree/bindings/thermal/thermal-sensor.yaml. + See <dt-bindings/thermal/tegra124-soctherm.h> for a list of valid values + when referring to thermal sensors. - throttle-cfgs: A sub-node which is a container of configuration for each hardware throttle events. These events can be set as cooling devices. * throttle events: Sub-nodes must be named as "light" or "heavy". @@ -62,7 +63,8 @@ Required properties : TEGRA_SOCTHERM_THROT_LEVEL_MED (75%), TEGRA_SOCTHERM_THROT_LEVEL_HIGH (85%). - #cooling-cells: Should be 1. This cooling device only support on/off state. - See ./thermal.txt for a description of this property. + For a description of this property see: + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml Optional properties: The following properties are T210 specific and valid only for OCx throttle events. diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt index e17c07be270b..fc87f6aa1b8f 100644 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt @@ -8,7 +8,7 @@ exposed by BPMP. The BPMP thermal node must be located directly inside the main BPMP node. See ../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding. -This node represents a thermal sensor. See thermal.txt for details of the +This node represents a thermal sensor. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details of the core thermal binding. Required properties: diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt index 0273a92a2a84..2d5b2ad03314 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt @@ -8,7 +8,7 @@ Required properties: - compatible: Should contain "qcom,spmi-temp-alarm". - reg: Specifies the SPMI address. - interrupts: PMIC temperature alarm interrupt. -- #thermal-sensor-cells: Should be 0. See thermal.txt for a description. +- #thermal-sensor-cells: Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - io-channels: Should contain IIO channel specifier for the ADC channel, diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index adac01c9d9cd..95462e071ab4 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - qcom,msm8916-tsens + - qcom,msm8939-tsens - qcom,msm8974-tsens - const: qcom,tsens-v0_1 diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index c6aac9bcacf1..7f94669e9ebe 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -24,7 +24,7 @@ Required properties: - pinctrl-1 : The "default" pinctrl state, it will be set after reset the TSADC controller. - pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend. -- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. +- #thermal-sensor-cells : Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. diff --git a/Documentation/devicetree/bindings/thermal/tango-thermal.txt b/Documentation/devicetree/bindings/thermal/tango-thermal.txt index 212198d4b937..2c918d742867 100644 --- a/Documentation/devicetree/bindings/thermal/tango-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/tango-thermal.txt @@ -4,7 +4,7 @@ The SMP8758 SoC includes 3 instances of this temperature sensor (in the CPU, video decoder, and PCIe controller). Required properties: -- #thermal-sensor-cells: Should be 0 (see thermal.txt) +- #thermal-sensor-cells: Should be 0 (see Documentation/devicetree/bindings/thermal/thermal-sensor.yaml) - compatible: "sigma,smp8758-thermal" - reg: Address range of the thermal registers diff --git a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt index 691a09db2fef..e136946a2f4f 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt +++ b/Documentation/devicetree/bindings/thermal/thermal-generic-adc.txt @@ -8,7 +8,7 @@ temperature using voltage-temperature lookup table. Required properties: =================== - compatible: Must be "generic-adc-thermal". -- #thermal-sensor-cells: Should be 1. See ./thermal.txt for a description +- #thermal-sensor-cells: Should be 1. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description of this property. Optional properties: =================== diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt deleted file mode 100644 index f78bec19ca35..000000000000 --- a/Documentation/devicetree/bindings/thermal/thermal.txt +++ /dev/null @@ -1,586 +0,0 @@ -* Thermal Framework Device Tree descriptor - -This file describes a generic binding to provide a way of -defining hardware thermal structure using device tree. -A thermal structure includes thermal zones and their components, -such as trip points, polling intervals, sensors and cooling devices -binding descriptors. - -The target of device tree thermal descriptors is to describe only -the hardware thermal aspects. The thermal device tree bindings are -not about how the system must control or which algorithm or policy -must be taken in place. - -There are five types of nodes involved to describe thermal bindings: -- thermal sensors: devices which may be used to take temperature - measurements. -- cooling devices: devices which may be used to dissipate heat. -- trip points: describe key temperatures at which cooling is recommended. The - set of points should be chosen based on hardware limits. -- cooling maps: used to describe links between trip points and cooling devices; -- thermal zones: used to describe thermal data within the hardware; - -The following is a description of each of these node types. - -* Thermal sensor devices - -Thermal sensor devices are nodes providing temperature sensing capabilities on -thermal zones. Typical devices are I2C ADC converters and bandgaps. These are -nodes providing temperature data to thermal zones. Thermal sensor devices may -control one or more internal sensors. - -Required property: -- #thermal-sensor-cells: Used to provide sensor device specific information - Type: unsigned while referring to it. Typically 0 on thermal sensor - Size: one cell nodes with only one sensor, and at least 1 on nodes - with several internal sensors, in order - to identify uniquely the sensor instances within - the IC. See thermal zone binding for more details - on how consumers refer to sensor devices. - -* Cooling device nodes - -Cooling devices are nodes providing control on power dissipation. There -are essentially two ways to provide control on power dissipation. First -is by means of regulating device performance, which is known as passive -cooling. A typical passive cooling is a CPU that has dynamic voltage and -frequency scaling (DVFS), and uses lower frequencies as cooling states. -Second is by means of activating devices in order to remove -the dissipated heat, which is known as active cooling, e.g. regulating -fan speeds. In both cases, cooling devices shall have a way to determine -the state of cooling in which the device is. - -Any cooling device has a range of cooling states (i.e. different levels -of heat dissipation). For example a fan's cooling states correspond to -the different fan speeds possible. Cooling states are referred to by -single unsigned integers, where larger numbers mean greater heat -dissipation. The precise set of cooling states associated with a device -should be defined in a particular device's binding. -For more examples of cooling devices, refer to the example sections below. - -Required properties: -- #cooling-cells: Used to provide cooling device specific information - Type: unsigned while referring to it. Must be at least 2, in order - Size: one cell to specify minimum and maximum cooling state used - in the reference. The first cell is the minimum - cooling state requested and the second cell is - the maximum cooling state requested in the reference. - See Cooling device maps section below for more details - on how consumers refer to cooling devices. - -* Trip points - -The trip node is a node to describe a point in the temperature domain -in which the system takes an action. This node describes just the point, -not the action. - -Required properties: -- temperature: An integer indicating the trip temperature level, - Type: signed in millicelsius. - Size: one cell - -- hysteresis: A low hysteresis value on temperature property (above). - Type: unsigned This is a relative value, in millicelsius. - Size: one cell - -- type: a string containing the trip type. Expected values are: - "active": A trip point to enable active cooling - "passive": A trip point to enable passive cooling - "hot": A trip point to notify emergency - "critical": Hardware not reliable. - Type: string - -* Cooling device maps - -The cooling device maps node is a node to describe how cooling devices -get assigned to trip points of the zone. The cooling devices are expected -to be loaded in the target system. - -Required properties: -- cooling-device: A list of phandles of cooling devices with their specifiers, - Type: phandle + referring to which cooling devices are used in this - cooling specifier binding. In the cooling specifier, the first cell - is the minimum cooling state and the second cell - is the maximum cooling state used in this map. -- trip: A phandle of a trip point node within the same thermal - Type: phandle of zone. - trip point node - -Optional property: -- contribution: The cooling contribution to the thermal zone of the - Type: unsigned referred cooling device at the referred trip point. - Size: one cell The contribution is a ratio of the sum - of all cooling contributions within a thermal zone. - -Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle -limit specifier means: -(i) - minimum state allowed for minimum cooling state used in the reference. -(ii) - maximum state allowed for maximum cooling state used in the reference. -Refer to include/dt-bindings/thermal/thermal.h for definition of this constant. - -* Thermal zone nodes - -The thermal zone node is the node containing all the required info -for describing a thermal zone, including its cooling device bindings. The -thermal zone node must contain, apart from its own properties, one sub-node -containing trip nodes and one sub-node containing all the zone cooling maps. - -Required properties: -- polling-delay: The maximum number of milliseconds to wait between polls - Type: unsigned when checking this thermal zone. - Size: one cell - -- polling-delay-passive: The maximum number of milliseconds to wait - Type: unsigned between polls when performing passive cooling. - Size: one cell - -- thermal-sensors: A list of thermal sensor phandles and sensor specifier - Type: list of used while monitoring the thermal zone. - phandles + sensor - specifier - -- trips: A sub-node which is a container of only trip point nodes - Type: sub-node required to describe the thermal zone. - -Optional property: -- cooling-maps: A sub-node which is a container of only cooling device - Type: sub-node map nodes, used to describe the relation between trips - and cooling devices. - -- coefficients: An array of integers (one signed cell) containing - Type: array coefficients to compose a linear relation between - Elem size: one cell the sensors listed in the thermal-sensors property. - Elem type: signed Coefficients defaults to 1, in case this property - is not specified. A simple linear polynomial is used: - Z = c0 * x0 + c1 * x1 + ... + c(n-1) * x(n-1) + cn. - - The coefficients are ordered and they match with sensors - by means of sensor ID. Additional coefficients are - interpreted as constant offset. - -- sustainable-power: An estimate of the sustainable power (in mW) that the - Type: unsigned thermal zone can dissipate at the desired - Size: one cell control temperature. For reference, the - sustainable power of a 4'' phone is typically - 2000mW, while on a 10'' tablet is around - 4500mW. - -Note: The delay properties are bound to the maximum dT/dt (temperature -derivative over time) in two situations for a thermal zone: -(i) - when passive cooling is activated (polling-delay-passive); and -(ii) - when the zone just needs to be monitored (polling-delay) or -when active cooling is activated. - -The maximum dT/dt is highly bound to hardware power consumption and dissipation -capability. The delays should be chosen to account for said max dT/dt, -such that a device does not cross several trip boundaries unexpectedly -between polls. Choosing the right polling delays shall avoid having the -device in temperature ranges that may damage the silicon structures and -reduce silicon lifetime. - -* The thermal-zones node - -The "thermal-zones" node is a container for all thermal zone nodes. It shall -contain only sub-nodes describing thermal zones as in the section -"Thermal zone nodes". The "thermal-zones" node appears under "/". - -* Examples - -Below are several examples on how to use thermal data descriptors -using device tree bindings: - -(a) - CPU thermal zone - -The CPU thermal zone example below describes how to setup one thermal zone -using one single sensor as temperature source and many cooling devices and -power dissipation control sources. - -#include <dt-bindings/thermal/thermal.h> - -cpus { - /* - * Here is an example of describing a cooling device for a DVFS - * capable CPU. The CPU node describes its four OPPs. - * The cooling states possible are 0..3, and they are - * used as OPP indexes. The minimum cooling state is 0, which means - * all four OPPs can be available to the system. The maximum - * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V) - * can be available in the system. - */ - cpu0: cpu@0 { - ... - operating-points = < - /* kHz uV */ - 970000 1200000 - 792000 1100000 - 396000 950000 - 198000 850000 - >; - #cooling-cells = <2>; /* min followed by max */ - }; - ... -}; - -&i2c1 { - ... - /* - * A simple fan controller which supports 10 speeds of operation - * (represented as 0-9). - */ - fan0: fan@48 { - ... - #cooling-cells = <2>; /* min followed by max */ - }; -}; - -ocp { - ... - /* - * A simple IC with a single bandgap temperature sensor. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - thermal-sensors = <&bandgap0>; - - trips { - cpu_alert0: cpu-alert0 { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "active"; - }; - cpu_alert1: cpu-alert1 { - temperature = <100000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - cpu_crit: cpu-crit { - temperature = <125000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_alert0>; - cooling-device = <&fan0 THERMAL_NO_LIMIT 4>; - }; - map1 { - trip = <&cpu_alert1>; - cooling-device = <&fan0 5 THERMAL_NO_LIMIT>, <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; - }; - }; - }; -}; - -In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is -used to monitor the zone 'cpu-thermal' using its sole sensor. A fan -device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten -different cooling states 0-9. It is used to remove the heat out of -the thermal zone 'cpu-thermal' using its cooling states -from its minimum to 4, when it reaches trip point 'cpu_alert0' -at 90C, as an example of active cooling. The same cooling device is used at -'cpu_alert1', but from 5 to its maximum state. The cpu@0 device is also -linked to the same thermal zone, 'cpu-thermal', as a passive cooling device, -using all its cooling states at trip point 'cpu_alert1', -which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the -temperature of 125C, represented by the trip point 'cpu_crit', the silicon -is not reliable anymore. - -(b) - IC with several internal sensors - -The example below describes how to deploy several thermal zones based off a -single sensor IC, assuming it has several internal sensors. This is a common -case on SoC designs with several internal IPs that may need different thermal -requirements, and thus may have their own sensor to monitor or detect internal -hotspots in their silicon. - -#include <dt-bindings/thermal/thermal.h> - -ocp { - ... - /* - * A simple IC with several bandgap temperature sensors. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <1>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 0>; - - trips { - /* each zone within the SoC may have its own trips */ - cpu_alert: cpu-alert { - temperature = <100000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - cpu_crit: cpu-crit { - temperature = <125000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; - - gpu_thermal: gpu-thermal { - polling-delay-passive = <120>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 1>; - - trips { - /* each zone within the SoC may have its own trips */ - gpu_alert: gpu-alert { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - gpu_crit: gpu-crit { - temperature = <105000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; - - dsp_thermal: dsp-thermal { - polling-delay-passive = <50>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&bandgap0 2>; - - trips { - /* each zone within the SoC may have its own trips */ - dsp_alert: dsp-alert { - temperature = <90000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - dsp_crit: gpu-crit { - temperature = <135000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - /* each zone within the SoC may have its own cooling */ - ... - }; - }; -}; - -In the example above, there is one bandgap IC which has the capability to -monitor three sensors. The hardware has been designed so that sensors are -placed on different places in the DIE to monitor different temperature -hotspots: one for CPU thermal zone, one for GPU thermal zone and the -other to monitor a DSP thermal zone. - -Thus, there is a need to assign each sensor provided by the bandgap IC -to different thermal zones. This is achieved by means of using the -#thermal-sensor-cells property and using the first cell of the sensor -specifier as sensor ID. In the example, then, <bandgap 0> is used to -monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal -zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone -may be uncorrelated, having its own dT/dt requirements, trips -and cooling maps. - - -(c) - Several sensors within one single thermal zone - -The example below illustrates how to use more than one sensor within -one thermal zone. - -#include <dt-bindings/thermal/thermal.h> - -&i2c1 { - ... - /* - * A simple IC with a single temperature sensor. - */ - adc: sensor@49 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -ocp { - ... - /* - * A simple IC with a single bandgap temperature sensor. - */ - bandgap0: bandgap@0000ed00 { - ... - #thermal-sensor-cells = <0>; - }; -}; - -thermal-zones { - cpu_thermal: cpu-thermal { - polling-delay-passive = <250>; /* milliseconds */ - polling-delay = <1000>; /* milliseconds */ - - thermal-sensors = <&bandgap0>, /* cpu */ - <&adc>; /* pcb north */ - - /* hotspot = 100 * bandgap - 120 * adc + 484 */ - coefficients = <100 -120 484>; - - trips { - ... - }; - - cooling-maps { - ... - }; - }; -}; - -In some cases, there is a need to use more than one sensor to extrapolate -a thermal hotspot in the silicon. The above example illustrates this situation. -For instance, it may be the case that a sensor external to CPU IP may be placed -close to CPU hotspot and together with internal CPU sensor, it is used -to determine the hotspot. Assuming this is the case for the above example, -the hypothetical extrapolation rule would be: - hotspot = 100 * bandgap - 120 * adc + 484 - -In other context, the same idea can be used to add fixed offset. For instance, -consider the hotspot extrapolation rule below: - hotspot = 1 * adc + 6000 - -In the above equation, the hotspot is always 6C higher than what is read -from the ADC sensor. The binding would be then: - thermal-sensors = <&adc>; - - /* hotspot = 1 * adc + 6000 */ - coefficients = <1 6000>; - -(d) - Board thermal - -The board thermal example below illustrates how to setup one thermal zone -with many sensors and many cooling devices. - -#include <dt-bindings/thermal/thermal.h> - -&i2c1 { - ... - /* - * An IC with several temperature sensor. - */ - adc_dummy: sensor@50 { - ... - #thermal-sensor-cells = <1>; /* sensor internal ID */ - }; -}; - -thermal-zones { - batt-thermal { - polling-delay-passive = <500>; /* milliseconds */ - polling-delay = <2500>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&adc_dummy 4>; - - trips { - ... - }; - - cooling-maps { - ... - }; - }; - - board_thermal: board-thermal { - polling-delay-passive = <1000>; /* milliseconds */ - polling-delay = <2500>; /* milliseconds */ - - /* sensor ID */ - thermal-sensors = <&adc_dummy 0>, /* pcb top edge */ - <&adc_dummy 1>, /* lcd */ - <&adc_dummy 2>; /* back cover */ - /* - * An array of coefficients describing the sensor - * linear relation. E.g.: - * z = c1*x1 + c2*x2 + c3*x3 - */ - coefficients = <1200 -345 890>; - - sustainable-power = <2500>; - - trips { - /* Trips are based on resulting linear equation */ - cpu_trip: cpu-trip { - temperature = <60000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - gpu_trip: gpu-trip { - temperature = <55000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - } - lcd_trip: lcp-trip { - temperature = <53000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "passive"; - }; - crit_trip: crit-trip { - temperature = <68000>; /* millicelsius */ - hysteresis = <2000>; /* millicelsius */ - type = "critical"; - }; - }; - - cooling-maps { - map0 { - trip = <&cpu_trip>; - cooling-device = <&cpu0 0 2>; - contribution = <55>; - }; - map1 { - trip = <&gpu_trip>; - cooling-device = <&gpu0 0 2>; - contribution = <20>; - }; - map2 { - trip = <&lcd_trip>; - cooling-device = <&lcd0 5 10>; - contribution = <15>; - }; - }; - }; -}; - -The above example is a mix of previous examples, a sensor IP with several internal -sensors used to monitor different zones, one of them is composed by several sensors and -with different cooling devices. diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 4165352a590a..b7e94fe8643f 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -80,8 +80,6 @@ properties: - fsl,mpl3115 # MPR121: Proximity Capacitive Touch Sensor Controller - fsl,mpr121 - # SGTL5000: Ultra Low-Power Audio Codec - - fsl,sgtl5000 # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface - gmt,g751 # Infineon IR38064 Voltage Regulator diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 936dad22b47e..f3d847832fdc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -20,7 +20,7 @@ patternProperties: "^(keypad|m25p|max8952|max8997|max8998|mpmc),.*": true "^(pinctrl-single|#pinctrl-single|PowerPC),.*": true "^(pl022|pxa-mmc|rcar_sound|rotary-encoder|s5m8767|sdhci),.*": true - "^(simple-audio-card|simple-graph-card|st-plgpio|st-spics|ts),.*": true + "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true # Keep list in alphabetical order. "^70mai,.*": @@ -473,6 +473,8 @@ patternProperties: description: ILI Technology Corporation (ILITEK) "^img,.*": description: Imagination Technologies Ltd. + "^imi,.*": + description: Integrated Micro-Electronics Inc. "^incircuit,.*": description: In-Circuit GmbH "^inet-tek,.*": diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt index e60b9a13bdcb..aa10b8ec36e2 100644 --- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt @@ -11,8 +11,8 @@ Optional properties: See clock-bindings.txt Documentation: -Davinci DM646x - http://www.ti.com/lit/ug/spruer5b/spruer5b.pdf -Keystone - http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf +Davinci DM646x - https://www.ti.com/lit/ug/spruer5b/spruer5b.pdf +Keystone - https://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf Examples: diff --git a/Documentation/devicetree/bindings/watchdog/dw_wdt.txt b/Documentation/devicetree/bindings/watchdog/dw_wdt.txt deleted file mode 100644 index eb0914420c7c..000000000000 --- a/Documentation/devicetree/bindings/watchdog/dw_wdt.txt +++ /dev/null @@ -1,24 +0,0 @@ -Synopsys Designware Watchdog Timer - -Required Properties: - -- compatible : Should contain "snps,dw-wdt" -- reg : Base address and size of the watchdog timer registers. -- clocks : phandle + clock-specifier for the clock that drives the - watchdog timer. - -Optional Properties: - -- interrupts : The interrupt used for the watchdog timeout warning. -- resets : phandle pointing to the system reset controller with - line index for the watchdog. - -Example: - - watchdog0: wd@ffd02000 { - compatible = "snps,dw-wdt"; - reg = <0xffd02000 0x1000>; - interrupts = <0 171 4>; - clocks = <&per_base_clk>; - resets = <&rst WDT0_RESET>; - }; diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt b/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt deleted file mode 100644 index 41aeaa2ff0f8..000000000000 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt +++ /dev/null @@ -1,28 +0,0 @@ -Qualcomm Krait Processor Sub-system (KPSS) Watchdog ---------------------------------------------------- - -Required properties : -- compatible : shall contain only one of the following: - - "qcom,kpss-wdt-msm8960" - "qcom,kpss-wdt-apq8064" - "qcom,kpss-wdt-ipq8064" - "qcom,kpss-wdt-ipq4019" - "qcom,kpss-timer" - "qcom,scss-timer" - "qcom,kpss-wdt" - -- reg : shall contain base register location and length -- clocks : shall contain the input clock - -Optional properties : -- timeout-sec : shall contain the default watchdog timeout in seconds, - if unset, the default timeout is 30 seconds - -Example: - watchdog@208a038 { - compatible = "qcom,kpss-wdt-ipq8064"; - reg = <0x0208a038 0x40>; - clocks = <&sleep_clk>; - timeout-sec = <10>; - }; diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml new file mode 100644 index 000000000000..0709ddf0b6a5 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/qcom-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Krait Processor Sub-system (KPSS) Watchdog timer + +maintainers: + - Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - qcom,apss-wdt-qcs404 + - qcom,apss-wdt-sc7180 + - qcom,apss-wdt-sdm845 + - qcom,apss-wdt-sm8150 + - qcom,kpss-timer + - qcom,kpss-wdt + - qcom,kpss-wdt-apq8064 + - qcom,kpss-wdt-ipq4019 + - qcom,kpss-wdt-ipq8064 + - qcom,kpss-wdt-msm8960 + - qcom,scss-timer + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +examples: + - | + watchdog@208a038 { + compatible = "qcom,kpss-wdt-ipq8064"; + reg = <0x0208a038 0x40>; + clocks = <&sleep_clk>; + timeout-sec = <10>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 572f4c912fef..6933005b52bd 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -41,6 +41,7 @@ properties: - renesas,r8a774a1-wdt # RZ/G2M - renesas,r8a774b1-wdt # RZ/G2N - renesas,r8a774c0-wdt # RZ/G2E + - renesas,r8a774e1-wdt # RZ/G2H - renesas,r8a7795-wdt # R-Car H3 - renesas,r8a7796-wdt # R-Car M3-W - renesas,r8a77961-wdt # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml new file mode 100644 index 000000000000..d9fc7bb851b1 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/snps,dw-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys Designware Watchdog Timer + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Jamie Iles <jamie@jamieiles.com> + +properties: + compatible: + const: snps,dw-wdt + + reg: + maxItems: 1 + + interrupts: + description: DW Watchdog pre-timeout interrupt + maxItems: 1 + + clocks: + minItems: 1 + items: + - description: Watchdog timer reference clock + - description: APB3 interface clock + + clock-names: + minItems: 1 + items: + - const: tclk + - const: pclk + + resets: + description: Phandle to the DW Watchdog reset lane + maxItems: 1 + + snps,watchdog-tops: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + DW APB Watchdog custom timer intervals - Timeout Period ranges (TOPs). + Each TOP is a number loaded into the watchdog counter at the moment of + the timer restart. The counter decrementing happens each tick of the + reference clock. Therefore the TOPs array is equivalent to an array of + the timer expiration intervals supported by the DW APB Watchdog. Note + DW APB Watchdog IP-core might be synthesized with fixed TOP values, + in which case this property is unnecessary with default TOPs utilized. + default: [0x0001000 0x0002000 0x0004000 0x0008000 + 0x0010000 0x0020000 0x0040000 0x0080000 + 0x0100000 0x0200000 0x0400000 0x0800000 + 0x1000000 0x2000000 0x4000000 0x8000000] + minItems: 16 + maxItems: 16 + +unevaluatedProperties: false + +required: + - compatible + - reg + - clocks + +examples: + - | + watchdog@ffd02000 { + compatible = "snps,dw-wdt"; + reg = <0xffd02000 0x1000>; + interrupts = <0 171 4>; + clocks = <&per_base_clk>; + resets = <&wdt_rst>; + }; + + - | + watchdog@ffd02000 { + compatible = "snps,dw-wdt"; + reg = <0xffd02000 0x1000>; + interrupts = <0 171 4>; + clocks = <&per_base_clk>; + clock-names = "tclk"; + snps,watchdog-tops = <0x000000FF 0x000001FF 0x000003FF + 0x000007FF 0x0000FFFF 0x0001FFFF + 0x0003FFFF 0x0007FFFF 0x000FFFFF + 0x001FFFFF 0x003FFFFF 0x007FFFFF + 0x00FFFFFF 0x01FFFFFF 0x03FFFFFF + 0x07FFFFFF>; + }; +... diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index ab82c8f21d31..ddb0a81a796c 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -239,6 +239,22 @@ Currently, the types available are: want to transfer a portion of uncompressed data directly to the display to print it +- DMA_COMPLETION_NO_ORDER + + - The device does not support in order completion. + + - The driver should return DMA_OUT_OF_ORDER for device_tx_status if + the device is setting this capability. + + - All cookie tracking and checking API should be treated as invalid if + the device exports this capability. + + - At this point, this is incompatible with polling option for dmatest. + + - If this cap is set, the user is recommended to provide an unique + identifier for each descriptor sent to the DMA device in order to + properly track the completion. + - DMA_REPEAT - The device supports repeated transfers. A repeated transfer, indicated by @@ -420,6 +436,9 @@ supported. - In the case of a cyclic transfer, it should only take into account the current period. + - Should return DMA_OUT_OF_ORDER if the device does not support in order + completion and is completing the operation out of order. + - This function can be called in an interrupt context. - device_config @@ -509,7 +528,7 @@ dma_cookie_t DMA_CTRL_ACK - If clear, the descriptor cannot be reused by provider until the - client acknowledges receipt, i.e. has has a chance to establish any + client acknowledges receipt, i.e. has a chance to establish any dependency chains - This can be acked by invoking async_tx_ack() diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index e622f8f6e56a..b02c52cd69d6 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -262,7 +262,7 @@ the system. Counter Counts may be allocated via counter_count structures, and respective Counter Signal associations (Synapses) made via counter_synapse structures. Associated counter_synapse structures are -stored as an array and set to the the synapses array member of the +stored as an array and set to the synapses array member of the respective counter_count structure. These counter_count structures are set to the counts array member of an allocated counter_device structure before the Counter is registered to the system. diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst index e9036ef9f8f4..dd64c9c5fb1e 100644 --- a/Documentation/driver-api/iio/buffers.rst +++ b/Documentation/driver-api/iio/buffers.rst @@ -88,7 +88,7 @@ fields in iio_chan_spec definition:: The driver implementing the accelerometer described above will have the following channel definition:: - struct struct iio_chan_spec accel_channels[] = { + struct iio_chan_spec accel_channels[] = { { .type = IIO_ACCEL, .modified = 1, diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst index 292f587fccdd..bc281f10ce4b 100644 --- a/Documentation/driver-api/ipmi.rst +++ b/Documentation/driver-api/ipmi.rst @@ -516,6 +516,7 @@ at module load time (for a module) with:: slave_addrs=<addr1>,<addr2>,... tryacpi=[0|1] trydmi=[0|1] [dbg_probe=1] + alerts_broken The addresses are normal I2C addresses. The adapter is the string name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name. @@ -537,6 +538,9 @@ The slave_addrs specifies the IPMI address of the local BMC. This is usually 0x20 and the driver defaults to that, but in case it's not, it can be specified when the driver starts up. +alerts_broken does not enable SMBus alert for SSIF. Otherwise SMBus +alert will be enabled on supported hardware. + Discovering the IPMI compliant BMC on the SMBus can cause devices on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI message as a block write to the I2C bus and waits for a response. diff --git a/Documentation/driver-api/media/drivers/pvrusb2.rst b/Documentation/driver-api/media/drivers/pvrusb2.rst index 83bfaa531ea8..cbd9359c247a 100644 --- a/Documentation/driver-api/media/drivers/pvrusb2.rst +++ b/Documentation/driver-api/media/drivers/pvrusb2.rst @@ -20,7 +20,7 @@ last known snapshot and evolved the driver to the state it is in here. More information on this driver can be found at: -http://www.isely.net/pvrusb2.html +https://www.isely.net/pvrusb2.html This driver has a strong separation of layers. They are very diff --git a/Documentation/driver-api/media/drivers/tuners.rst b/Documentation/driver-api/media/drivers/tuners.rst index 7509be888909..d7924141c544 100644 --- a/Documentation/driver-api/media/drivers/tuners.rst +++ b/Documentation/driver-api/media/drivers/tuners.rst @@ -18,7 +18,7 @@ These differ mainly by the bandswitch byte. Tuner Manufacturers ------------------- -- SAMSUNG Tuner identification: (e.g. TCPM9091PD27) +- Samsung Tuner identification: (e.g. TCPM9091PD27) .. code-block:: none diff --git a/Documentation/driver-api/nvdimm/firmware-activate.rst b/Documentation/driver-api/nvdimm/firmware-activate.rst new file mode 100644 index 000000000000..7ee7decbbdc3 --- /dev/null +++ b/Documentation/driver-api/nvdimm/firmware-activate.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +NVDIMM Runtime Firmware Activation +================================== + +Some persistent memory devices run a firmware locally on the device / +"DIMM" to perform tasks like media management, capacity provisioning, +and health monitoring. The process of updating that firmware typically +involves a reboot because it has implications for in-flight memory +transactions. However, reboots are disruptive and at least the Intel +persistent memory platform implementation, described by the Intel ACPI +DSM specification [1], has added support for activating firmware at +runtime. + +A native sysfs interface is implemented in libnvdimm to allow platform +to advertise and control their local runtime firmware activation +capability. + +The libnvdimm bus object, ndbusX, implements an ndbusX/firmware/activate +attribute that shows the state of the firmware activation as one of 'idle', +'armed', 'overflow', and 'busy'. + +- idle: + No devices are set / armed to activate firmware + +- armed: + At least one device is armed + +- busy: + In the busy state armed devices are in the process of transitioning + back to idle and completing an activation cycle. + +- overflow: + If the platform has a concept of incremental work needed to perform + the activation it could be the case that too many DIMMs are armed for + activation. In that scenario the potential for firmware activation to + timeout is indicated by the 'overflow' state. + +The 'ndbusX/firmware/activate' property can be written with a value of +either 'live', or 'quiesce'. A value of 'quiesce' triggers the kernel to +run firmware activation from within the equivalent of the hibernation +'freeze' state where drivers and applications are notified to stop their +modifications of system memory. A value of 'live' attempts +firmware activation without this hibernation cycle. The +'ndbusX/firmware/activate' property will be elided completely if no +firmware activation capability is detected. + +Another property 'ndbusX/firmware/capability' indicates a value of +'live' or 'quiesce', where 'live' indicates that the firmware +does not require or inflict any quiesce period on the system to update +firmware. A capability value of 'quiesce' indicates that firmware does +expect and injects a quiet period for the memory controller, but 'live' +may still be written to 'ndbusX/firmware/activate' as an override to +assume the risk of racing firmware update with in-flight device and +application activity. The 'ndbusX/firmware/capability' property will be +elided completely if no firmware activation capability is detected. + +The libnvdimm memory-device / DIMM object, nmemX, implements +'nmemX/firmware/activate' and 'nmemX/firmware/result' attributes to +communicate the per-device firmware activation state. Similar to the +'ndbusX/firmware/activate' attribute, the 'nmemX/firmware/activate' +attribute indicates 'idle', 'armed', or 'busy'. The state transitions +from 'armed' to 'idle' when the system is prepared to activate firmware, +firmware staged + state set to armed, and 'ndbusX/firmware/activate' is +triggered. After that activation event the nmemX/firmware/result +attribute reflects the state of the last activation as one of: + +- none: + No runtime activation triggered since the last time the device was reset + +- success: + The last runtime activation completed successfully. + +- fail: + The last runtime activation failed for device-specific reasons. + +- not_staged: + The last runtime activation failed due to a sequencing error of the + firmware image not being staged. + +- need_reset: + Runtime firmware activation failed, but the firmware can still be + activated via the legacy method of power-cycling the system. + +[1]: https://docs.pmem.io/persistent-memory/ diff --git a/Documentation/driver-api/serial/n_gsm.rst b/Documentation/driver-api/serial/n_gsm.rst index 286e7ff4d2d9..87dfcd54a96b 100644 --- a/Documentation/driver-api/serial/n_gsm.rst +++ b/Documentation/driver-api/serial/n_gsm.rst @@ -5,7 +5,7 @@ GSM 0710 tty multiplexor HOWTO This line discipline implements the GSM 07.10 multiplexing protocol detailed in the following 3GPP document: - http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip + https://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip This document give some hints on how to use this driver with GPRS and 3G modems connected to a physical serial port. diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index f8ec5c13cde4..894d9693b380 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | ok | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | ok | diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index ca6bacb1e99e..53da483c8326 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | TODO | | sparc: | TODO | diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt index b7e4f3608838..2db76807ec6f 100644 --- a/Documentation/features/debug/kmemleak/arch-support.txt +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | ok | | sparc: | ok | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index 3db4763aa3f5..3329559c8207 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | TODO | | sh: | ok | | sparc: | TODO | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index 4f844ecd0680..940b0bd02957 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | ok | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | ok | | sh: | ok | | sparc: | ok | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 68658a6f8c5b..47e6903f47a5 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -5,7 +5,7 @@ # # Architecture requirements # -# * arm/arm64 +# * arm/arm64/powerpc # # Rely on implicit context synchronization as a result of exception return # when returning from IPI handler, and when returning to user-space. @@ -45,7 +45,7 @@ | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | - | powerpc: | TODO | + | powerpc: | ok | | riscv: | TODO | | s390: | TODO | | sh: | TODO | diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index a71f3a945285..266c81e8a721 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -23,7 +23,7 @@ | openrisc: | TODO | | parisc: | TODO | | powerpc: | ok | - | riscv: | TODO | + | riscv: | ok | | s390: | TODO | | sh: | TODO | | sparc: | ok | diff --git a/Documentation/filesystems/dlmfs.rst b/Documentation/filesystems/dlmfs.rst index 68daaa7facf9..28dd41a63be2 100644 --- a/Documentation/filesystems/dlmfs.rst +++ b/Documentation/filesystems/dlmfs.rst @@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its infrastructure. :Project web page: http://ocfs2.wiki.kernel.org :Tools web page: https://github.com/markfasheh/ocfs2-tools -:OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/ +:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/ All code copyright 2005 Oracle except when otherwise noted. diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index a11d329542f9..ec8d99703ecb 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -258,6 +258,8 @@ compress_extension=%s Support adding specified extension, so that f2fs can enab on compression extension list and enable compression on these file by default rather than to enable it via ioctl. For other files, we can still enable compression via ioctl. + Note that, there is one reserved special extension '*', it + can be set to enable compression for all files. inlinecrypt When possible, encrypt/decrypt the contents of encrypted files using the blk-crypto framework rather than filesystem-layer encryption. This allows the use of @@ -743,8 +745,8 @@ Compression implementation - In order to eliminate write amplification during overwrite, F2FS only support compression on write-once file, data can be compressed only when - all logical blocks in file are valid and cluster compress ratio is lower - than specified threshold. + all logical blocks in cluster contain valid data and compress ratio of + cluster data is lower than specified threshold. - To enable compression on regular inode, there are three ways: diff --git a/Documentation/filesystems/journalling.rst b/Documentation/filesystems/journalling.rst index 58ce6b395206..7e2be2faf653 100644 --- a/Documentation/filesystems/journalling.rst +++ b/Documentation/filesystems/journalling.rst @@ -10,27 +10,27 @@ Details The journalling layer is easy to use. You need to first of all create a journal_t data structure. There are two calls to do this dependent on how you decide to allocate the physical media on which the journal -resides. The :c:func:`jbd2_journal_init_inode` call is for journals stored in -filesystem inodes, or the :c:func:`jbd2_journal_init_dev` call can be used +resides. The jbd2_journal_init_inode() call is for journals stored in +filesystem inodes, or the jbd2_journal_init_dev() call can be used for journal stored on a raw device (in a continuous range of blocks). A journal_t is a typedef for a struct pointer, so when you are finally -finished make sure you call :c:func:`jbd2_journal_destroy` on it to free up +finished make sure you call jbd2_journal_destroy() on it to free up any used kernel memory. Once you have got your journal_t object you need to 'mount' or load the journal file. The journalling layer expects the space for the journal was already allocated and initialized properly by the userspace tools. -When loading the journal you must call :c:func:`jbd2_journal_load` to process +When loading the journal you must call jbd2_journal_load() to process journal contents. If the client file system detects the journal contents does not need to be processed (or even need not have valid contents), it -may call :c:func:`jbd2_journal_wipe` to clear the journal contents before -calling :c:func:`jbd2_journal_load`. +may call jbd2_journal_wipe() to clear the journal contents before +calling jbd2_journal_load(). Note that jbd2_journal_wipe(..,0) calls -:c:func:`jbd2_journal_skip_recovery` for you if it detects any outstanding -transactions in the journal and similarly :c:func:`jbd2_journal_load` will -call :c:func:`jbd2_journal_recover` if necessary. I would advise reading -:c:func:`ext4_load_journal` in fs/ext4/super.c for examples on this stage. +jbd2_journal_skip_recovery() for you if it detects any outstanding +transactions in the journal and similarly jbd2_journal_load() will +call jbd2_journal_recover() if necessary. I would advise reading +ext4_load_journal() in fs/ext4/super.c for examples on this stage. Now you can go ahead and start modifying the underlying filesystem. Almost. @@ -39,57 +39,57 @@ You still need to actually journal your filesystem changes, this is done by wrapping them into transactions. Additionally you also need to wrap the modification of each of the buffers with calls to the journal layer, so it knows what the modifications you are actually making are. To do -this use :c:func:`jbd2_journal_start` which returns a transaction handle. +this use jbd2_journal_start() which returns a transaction handle. -:c:func:`jbd2_journal_start` and its counterpart :c:func:`jbd2_journal_stop`, +jbd2_journal_start() and its counterpart jbd2_journal_stop(), which indicates the end of a transaction are nestable calls, so you can reenter a transaction if necessary, but remember you must call -:c:func:`jbd2_journal_stop` the same number of times as -:c:func:`jbd2_journal_start` before the transaction is completed (or more +jbd2_journal_stop() the same number of times as +jbd2_journal_start() before the transaction is completed (or more accurately leaves the update phase). Ext4/VFS makes use of this feature to simplify handling of inode dirtying, quota support, etc. Inside each transaction you need to wrap the modifications to the individual buffers (blocks). Before you start to modify a buffer you -need to call :c:func:`jbd2_journal_get_create_access()` / -:c:func:`jbd2_journal_get_write_access()` / -:c:func:`jbd2_journal_get_undo_access()` as appropriate, this allows the +need to call jbd2_journal_get_create_access() / +jbd2_journal_get_write_access() / +jbd2_journal_get_undo_access() as appropriate, this allows the journalling layer to copy the unmodified data if it needs to. After all the buffer may be part of a previously uncommitted transaction. At this point you are at last ready to modify a buffer, and once you are have done so you need to call -:c:func:`jbd2_journal_dirty_metadata`. Or if you've asked for access to a +jbd2_journal_dirty_metadata(). Or if you've asked for access to a buffer you now know is now longer required to be pushed back on the -device you can call :c:func:`jbd2_journal_forget` in much the same way as you -might have used :c:func:`bforget` in the past. +device you can call jbd2_journal_forget() in much the same way as you +might have used bforget() in the past. -A :c:func:`jbd2_journal_flush` may be called at any time to commit and +A jbd2_journal_flush() may be called at any time to commit and checkpoint all your transactions. -Then at umount time , in your :c:func:`put_super` you can then call -:c:func:`jbd2_journal_destroy` to clean up your in-core journal object. +Then at umount time , in your put_super() you can then call +jbd2_journal_destroy() to clean up your in-core journal object. Unfortunately there a couple of ways the journal layer can cause a deadlock. The first thing to note is that each task can only have a single outstanding transaction at any one time, remember nothing commits -until the outermost :c:func:`jbd2_journal_stop`. This means you must complete +until the outermost jbd2_journal_stop(). This means you must complete the transaction at the end of each file/inode/address etc. operation you perform, so that the journalling system isn't re-entered on another journal. Since transactions can't be nested/batched across differing journals, and another filesystem other than yours (say ext4) may be modified in a later syscall. -The second case to bear in mind is that :c:func:`jbd2_journal_start` can block +The second case to bear in mind is that jbd2_journal_start() can block if there isn't enough space in the journal for your transaction (based on the passed nblocks param) - when it blocks it merely(!) needs to wait for transactions to complete and be committed from other tasks, so -essentially we are waiting for :c:func:`jbd2_journal_stop`. So to avoid -deadlocks you must treat :c:func:`jbd2_journal_start` / -:c:func:`jbd2_journal_stop` as if they were semaphores and include them in +essentially we are waiting for jbd2_journal_stop(). So to avoid +deadlocks you must treat jbd2_journal_start() / +jbd2_journal_stop() as if they were semaphores and include them in your semaphore ordering rules to prevent -deadlocks. Note that :c:func:`jbd2_journal_extend` has similar blocking -behaviour to :c:func:`jbd2_journal_start` so you can deadlock here just as -easily as on :c:func:`jbd2_journal_start`. +deadlocks. Note that jbd2_journal_extend() has similar blocking +behaviour to jbd2_journal_start() so you can deadlock here just as +easily as on jbd2_journal_start(). Try to reserve the right number of blocks the first time. ;-). This will be the maximum number of blocks you are going to touch in this @@ -116,8 +116,8 @@ called after each transaction commit. You can also use that need processing when the transaction commits. JBD2 also provides a way to block all transaction updates via -:c:func:`jbd2_journal_lock_updates()` / -:c:func:`jbd2_journal_unlock_updates()`. Ext4 uses this when it wants a +jbd2_journal_lock_updates() / +jbd2_journal_unlock_updates(). Ext4 uses this when it wants a window with a clean and stable fs for a moment. E.g. :: diff --git a/Documentation/filesystems/ocfs2.rst b/Documentation/filesystems/ocfs2.rst index 412386bc6506..42ca9a3d4c6e 100644 --- a/Documentation/filesystems/ocfs2.rst +++ b/Documentation/filesystems/ocfs2.rst @@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl". Project web page: http://ocfs2.wiki.kernel.org Tools git tree: https://github.com/markfasheh/ocfs2-tools -OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/ +OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/ All code copyright 2005 Oracle except when otherwise noted. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index e024a9efffd8..533c79e8d2cd 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1633,9 +1633,6 @@ may allocate from based on an estimation of its current memory and swap use. For example, if a task is using all allowed memory, its badness score will be 1000. If it is using half of its allowed memory, its score will be 500. -There is an additional factor included in the badness score: the current memory -and swap usage is discounted by 3% for root processes. - The amount of "allowed" memory depends on the context in which the oom killer was called. If it is due to the memory assigned to the allocating task's cpuset being exhausted, the allowed memory represents the set of mems assigned to that @@ -1671,11 +1668,6 @@ The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last value set by a CAP_SYS_RESOURCE process. To reduce the value any lower requires CAP_SYS_RESOURCE. -Caveat: when a parent task is selected, the oom killer will sacrifice any first -generation children with separate address spaces instead, if possible. This -avoids servers and important system daemons from being killed and loses the -minimal amount of work. - 3.2 /proc/<pid>/oom_score - Display current oom-killer score ------------------------------------------------------------- @@ -1684,6 +1676,9 @@ This file can be used to check the current score used by the oom-killer for any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which process should be killed in an out-of-memory situation. +Please note that the exported value includes oom_score_adj so it is +effectively in range [0,2000]. + 3.3 /proc/<pid>/io - Display the IO accounting fields ------------------------------------------------------- diff --git a/Documentation/filesystems/quota.rst b/Documentation/filesystems/quota.rst index a30cdd47c652..abd4303c546e 100644 --- a/Documentation/filesystems/quota.rst +++ b/Documentation/filesystems/quota.rst @@ -18,7 +18,7 @@ Quota limits (and amount of grace time) are set independently for each filesystem. For more details about quota design, see the documentation in quota-tools package -(http://sourceforge.net/projects/linuxquota). +(https://sourceforge.net/projects/linuxquota). Quota netlink interface ======================= @@ -31,11 +31,11 @@ the above events to userspace. There they can be captured by an application and processed accordingly. The interface uses generic netlink framework (see -http://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for more -details about this layer). The name of the quota generic netlink interface -is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. -Since the quota netlink protocol is not namespace aware, quota netlink messages -are sent only in initial network namespace. +https://lwn.net/Articles/208755/ and http://www.infradead.org/~tgr/libnl/ for +more details about this layer). The name of the quota generic netlink interface +is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. Since +the quota netlink protocol is not namespace aware, quota netlink messages are +sent only in initial network namespace. Currently, the interface supports only one message type QUOTA_NL_C_WARNING. This command is used to send a notification about any of the above mentioned diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst index 4e95929301a5..c44f8b1d3cab 100644 --- a/Documentation/filesystems/tmpfs.rst +++ b/Documentation/filesystems/tmpfs.rst @@ -150,6 +150,22 @@ These options do not have any effect on remount. You can change these parameters with chmod(1), chown(1) and chgrp(1) on a mounted filesystem. +tmpfs has a mount option to select whether it will wrap at 32- or 64-bit inode +numbers: + +======= ======================== +inode64 Use 64-bit inode numbers +inode32 Use 32-bit inode numbers +======= ======================== + +On a 32-bit kernel, inode32 is implicit, and inode64 is refused at mount time. +On a 64-bit kernel, CONFIG_TMPFS_INODE64 sets the default. inode64 avoids the +possibility of multiple files with the same inode number on a single device; +but risks glibc failing with EOVERFLOW once 33-bit inode numbers are reached - +if a long-lived tmpfs is accessed by 32-bit applications so ancient that +opening a file larger than 2GiB fails with EINVAL. + + So 'mount -t tmpfs -o size=10G,nr_inodes=10k,mode=700 tmpfs /mytmpfs' will give you tmpfs instance on /mytmpfs which can allocate 10GB RAM/SWAP in 10240 inodes and it is only accessible by root. @@ -161,3 +177,5 @@ RAM/SWAP in 10240 inodes and it is only accessible by root. Hugh Dickins, 4 June 2007 :Updated: KOSAKI Motohiro, 16 Mar 2010 +:Updated: + Chris Down, 13 July 2020 diff --git a/Documentation/filesystems/udf.rst b/Documentation/filesystems/udf.rst index d9badbf285b2..f9489ddbb767 100644 --- a/Documentation/filesystems/udf.rst +++ b/Documentation/filesystems/udf.rst @@ -72,4 +72,4 @@ For the latest version and toolset see: Documentation on UDF and ECMA 167 is available FREE from: - http://www.osta.org/ - - http://www.ecma-international.org/ + - https://www.ecma-international.org/ diff --git a/Documentation/filesystems/zonefs.rst b/Documentation/filesystems/zonefs.rst index 71d845c6a700..6c18bc8ce332 100644 --- a/Documentation/filesystems/zonefs.rst +++ b/Documentation/filesystems/zonefs.rst @@ -110,14 +110,14 @@ contain files named "0", "1", "2", ... The file numbers also represent increasing zone start sector on the device. All read and write operations to zone files are not allowed beyond the file -maximum size, that is, beyond the zone size. Any access exceeding the zone -size is failed with the -EFBIG error. +maximum size, that is, beyond the zone capacity. Any access exceeding the zone +capacity is failed with the -EFBIG error. Creating, deleting, renaming or modifying any attribute of files and sub-directories is not allowed. The number of blocks of a file as reported by stat() and fstat() indicates the -size of the file zone, or in other words, the maximum file size. +capacity of the zone file, or in other words, the maximum file size. Conventional zone files ----------------------- @@ -156,8 +156,8 @@ all accepted. Truncating sequential zone files is allowed only down to 0, in which case, the zone is reset to rewind the file zone write pointer position to the start of -the zone, or up to the zone size, in which case the file's zone is transitioned -to the FULL state (finish zone operation). +the zone, or up to the zone capacity, in which case the file's zone is +transitioned to the FULL state (finish zone operation). Format options -------------- @@ -324,7 +324,7 @@ file size set to 0. This is necessary as the write pointer of read-only zones is defined as invalib by the ZBC and ZAC standards, making it impossible to discover the amount of data that has been written to the zone. In the case of a read-only zone discovered at run-time, as indicated in the previous section. -the size of the zone file is left unchanged from its last updated value. +The size of the zone file is left unchanged from its last updated value. Zonefs User Space Tools ======================= @@ -401,8 +401,9 @@ append-writes to the file:: # ls -l /mnt/seq/0 -rw-r----- 1 root root 0 Nov 25 13:49 /mnt/seq/0 -Since files are statically mapped to zones on the disk, the number of blocks of -a file as reported by stat() and fstat() indicates the size of the file zone:: +Since files are statically mapped to zones on the disk, the number of blocks +of a file as reported by stat() and fstat() indicates the capacity of the file +zone:: # stat /mnt/seq/0 File: /mnt/seq/0 @@ -416,5 +417,6 @@ a file as reported by stat() and fstat() indicates the size of the file zone:: The number of blocks of the file ("Blocks") in units of 512B blocks gives the maximum file size of 524288 * 512 B = 256 MB, corresponding to the device zone -size in this example. Of note is that the "IO block" field always indicates the -minimum I/O size for writes and corresponds to the device physical sector size. +capacity in this example. Of note is that the "IO block" field always +indicates the minimum I/O size for writes and corresponds to the device +physical sector size. diff --git a/Documentation/gpu/backlight.rst b/Documentation/gpu/backlight.rst new file mode 100644 index 000000000000..9ebfc9d0aced --- /dev/null +++ b/Documentation/gpu/backlight.rst @@ -0,0 +1,12 @@ +================= +Backlight support +================= + +.. kernel-doc:: drivers/video/backlight/backlight.c + :doc: overview + +.. kernel-doc:: include/linux/backlight.h + :internal: + +.. kernel-doc:: drivers/video/backlight/backlight.c + :export: diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 1fcf8e851e15..c9a51e3bfb5a 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide drm-uapi drm-client drivers + backlight vga-switcheroo vgaarbiter todo diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index b83da0e94184..faf32330c335 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -43,6 +43,7 @@ Supported adapters: * Intel Elkhart Lake (PCH) * Intel Tiger Lake (PCH) * Intel Jasper Lake (SOC) + * Intel Emmitsburg (PCH) Datasheets: Publicly available at the Intel website diff --git a/Documentation/i2c/dev-interface.rst b/Documentation/i2c/dev-interface.rst index bdb247f2f11a..73ad34849f99 100644 --- a/Documentation/i2c/dev-interface.rst +++ b/Documentation/i2c/dev-interface.rst @@ -159,6 +159,8 @@ for details) through the following functions:: __s32 i2c_smbus_read_word_data(int file, __u8 command); __s32 i2c_smbus_write_word_data(int file, __u8 command, __u16 value); __s32 i2c_smbus_process_call(int file, __u8 command, __u16 value); + __s32 i2c_smbus_block_process_call(int file, __u8 command, __u8 length, + __u8 *values); __s32 i2c_smbus_read_block_data(int file, __u8 command, __u8 *values); __s32 i2c_smbus_write_block_data(int file, __u8 command, __u8 length, __u8 *values); diff --git a/Documentation/i2c/index.rst b/Documentation/i2c/index.rst index fee4744475df..8a2ad3845191 100644 --- a/Documentation/i2c/index.rst +++ b/Documentation/i2c/index.rst @@ -62,7 +62,6 @@ Legacy documentation .. toctree:: :maxdepth: 1 - upgrading-clients old-module-parameters .. only:: subproject and html diff --git a/Documentation/i2c/upgrading-clients.rst b/Documentation/i2c/upgrading-clients.rst deleted file mode 100644 index 1708090d7b8f..000000000000 --- a/Documentation/i2c/upgrading-clients.rst +++ /dev/null @@ -1,285 +0,0 @@ -================================================= -Upgrading I2C Drivers to the new 2.6 Driver Model -================================================= - -Ben Dooks <ben-linux@fluff.org> - -Introduction ------------- - -This guide outlines how to alter existing Linux 2.6 client drivers from -the old to the new binding methods. - - -Example old-style driver ------------------------- - -:: - - struct example_state { - struct i2c_client client; - .... - }; - - static struct i2c_driver example_driver; - - static unsigned short ignore[] = { I2C_CLIENT_END }; - static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; - - I2C_CLIENT_INSMOD; - - static int example_attach(struct i2c_adapter *adap, int addr, int kind) - { - struct example_state *state; - struct device *dev = &adap->dev; /* to use for dev_ reports */ - int ret; - - state = kzalloc(sizeof(struct example_state), GFP_KERNEL); - if (state == NULL) { - dev_err(dev, "failed to create our state\n"); - return -ENOMEM; - } - - example->client.addr = addr; - example->client.flags = 0; - example->client.adapter = adap; - - i2c_set_clientdata(&state->i2c_client, state); - strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name)); - - ret = i2c_attach_client(&state->i2c_client); - if (ret < 0) { - dev_err(dev, "failed to attach client\n"); - kfree(state); - return ret; - } - - dev = &state->i2c_client.dev; - - /* rest of the initialisation goes here. */ - - dev_info(dev, "example client created\n"); - - return 0; - } - - static int example_detach(struct i2c_client *client) - { - struct example_state *state = i2c_get_clientdata(client); - - i2c_detach_client(client); - kfree(state); - return 0; - } - - static int example_attach_adapter(struct i2c_adapter *adap) - { - return i2c_probe(adap, &addr_data, example_attach); - } - - static struct i2c_driver example_driver = { - .driver = { - .owner = THIS_MODULE, - .name = "example", - .pm = &example_pm_ops, - }, - .attach_adapter = example_attach_adapter, - .detach_client = example_detach, - }; - - -Updating the client -------------------- - -The new style binding model will check against a list of supported -devices and their associated address supplied by the code registering -the busses. This means that the driver .attach_adapter and -.detach_client methods can be removed, along with the addr_data, -as follows:: - - - static struct i2c_driver example_driver; - - - static unsigned short ignore[] = { I2C_CLIENT_END }; - - static unsigned short normal_addr[] = { OUR_ADDR, I2C_CLIENT_END }; - - - I2C_CLIENT_INSMOD; - - - static int example_attach_adapter(struct i2c_adapter *adap) - - { - - return i2c_probe(adap, &addr_data, example_attach); - - } - - static struct i2c_driver example_driver = { - - .attach_adapter = example_attach_adapter, - - .detach_client = example_detach, - } - -Add the probe and remove methods to the i2c_driver, as so:: - - static struct i2c_driver example_driver = { - + .probe = example_probe, - + .remove = example_remove, - } - -Change the example_attach method to accept the new parameters -which include the i2c_client that it will be working with:: - - - static int example_attach(struct i2c_adapter *adap, int addr, int kind) - + static int example_probe(struct i2c_client *client, - + const struct i2c_device_id *id) - -Change the name of example_attach to example_probe to align it with the -i2c_driver entry names. The rest of the probe routine will now need to be -changed as the i2c_client has already been setup for use. - -The necessary client fields have already been setup before -the probe function is called, so the following client setup -can be removed:: - - - example->client.addr = addr; - - example->client.flags = 0; - - example->client.adapter = adap; - - - - strscpy(client->i2c_client.name, "example", sizeof(client->i2c_client.name)); - -The i2c_set_clientdata is now:: - - - i2c_set_clientdata(&state->client, state); - + i2c_set_clientdata(client, state); - -The call to i2c_attach_client is no longer needed, if the probe -routine exits successfully, then the driver will be automatically -attached by the core. Change the probe routine as so:: - - - ret = i2c_attach_client(&state->i2c_client); - - if (ret < 0) { - - dev_err(dev, "failed to attach client\n"); - - kfree(state); - - return ret; - - } - - -Remove the storage of 'struct i2c_client' from the 'struct example_state' -as we are provided with the i2c_client in our example_probe. Instead we -store a pointer to it for when it is needed. - -:: - - struct example_state { - - struct i2c_client client; - + struct i2c_client *client; - -the new i2c client as so:: - - - struct device *dev = &adap->dev; /* to use for dev_ reports */ - + struct device *dev = &i2c_client->dev; /* to use for dev_ reports */ - -And remove the change after our client is attached, as the driver no -longer needs to register a new client structure with the core:: - - - dev = &state->i2c_client.dev; - -In the probe routine, ensure that the new state has the client stored -in it:: - - static int example_probe(struct i2c_client *i2c_client, - const struct i2c_device_id *id) - { - struct example_state *state; - struct device *dev = &i2c_client->dev; - int ret; - - state = kzalloc(sizeof(struct example_state), GFP_KERNEL); - if (state == NULL) { - dev_err(dev, "failed to create our state\n"); - return -ENOMEM; - } - - + state->client = i2c_client; - -Update the detach method, by changing the name to _remove and -to delete the i2c_detach_client call. It is possible that you -can also remove the ret variable as it is not needed for any -of the core functions. - -:: - - - static int example_detach(struct i2c_client *client) - + static int example_remove(struct i2c_client *client) - { - struct example_state *state = i2c_get_clientdata(client); - - - i2c_detach_client(client); - -And finally ensure that we have the correct ID table for the i2c-core -and other utilities:: - - + struct i2c_device_id example_idtable[] = { - + { "example", 0 }, - + { } - +}; - + - +MODULE_DEVICE_TABLE(i2c, example_idtable); - - static struct i2c_driver example_driver = { - .driver = { - .owner = THIS_MODULE, - .name = "example", - }, - + .id_table = example_ids, - - -Our driver should now look like this:: - - struct example_state { - struct i2c_client *client; - .... - }; - - static int example_probe(struct i2c_client *client, - const struct i2c_device_id *id) - { - struct example_state *state; - struct device *dev = &client->dev; - - state = kzalloc(sizeof(struct example_state), GFP_KERNEL); - if (state == NULL) { - dev_err(dev, "failed to create our state\n"); - return -ENOMEM; - } - - state->client = client; - i2c_set_clientdata(client, state); - - /* rest of the initialisation goes here. */ - - dev_info(dev, "example client created\n"); - - return 0; - } - - static int example_remove(struct i2c_client *client) - { - struct example_state *state = i2c_get_clientdata(client); - - kfree(state); - return 0; - } - - static struct i2c_device_id example_idtable[] = { - { "example", 0 }, - { } - }; - - MODULE_DEVICE_TABLE(i2c, example_idtable); - - static struct i2c_driver example_driver = { - .driver = { - .owner = THIS_MODULE, - .name = "example", - .pm = &example_pm_ops, - }, - .id_table = example_idtable, - .probe = example_probe, - .remove = example_remove, - }; diff --git a/Documentation/input/uinput.rst b/Documentation/input/uinput.rst index b8e90b6a126c..10c62e62a0a6 100644 --- a/Documentation/input/uinput.rst +++ b/Documentation/input/uinput.rst @@ -99,7 +99,7 @@ the sake of simplicity. /* * Give userspace some time to read the events before we destroy the - * device with UI_DEV_DESTOY. + * device with UI_DEV_DESTROY. */ sleep(1); @@ -164,7 +164,7 @@ mouse. /* * Give userspace some time to read the events before we destroy the - * device with UI_DEV_DESTOY. + * device with UI_DEV_DESTROY. */ sleep(1); @@ -233,7 +233,7 @@ but interact with uinput via ioctl calls, or use libevdev. /* * Give userspace some time to read the events before we destroy the - * device with UI_DEV_DESTOY. + * device with UI_DEV_DESTROY. */ sleep(1); diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 b/Documentation/kbuild/Kconfig.recursion-issue-02 index b9fd56c4b57e..df245fd7670d 100644 --- a/Documentation/kbuild/Kconfig.recursion-issue-02 +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 @@ -42,7 +42,7 @@ # "select FW_LOADER" [0], in the end the simple alternative solution to this # problem consisted on matching semantics with newly introduced features. # -# [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com +# [0] https://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com mainmenu "Simple example to demo cumulative kconfig recursive dependency implication" diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 39881b719782..1cf1aebdd6cd 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -540,8 +540,8 @@ followed by a test macro:: If you need to expose a compiler capability to makefiles and/or C source files, `CC_HAS_` is the recommended prefix for the config option:: - config CC_HAS_STACKPROTECTOR_NONE - def_bool $(cc-option,-fno-stack-protector) + config CC_HAS_ASM_GOTO + def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC)) Build as module only ~~~~~~~~~~~~~~~~~~~~ @@ -688,10 +688,10 @@ and real world requirements were not well understood. As it stands though only reverse engineering techniques have been used to deduce semantics from variability modeling languages such as Kconfig [3]_. -.. [0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf -.. [1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf -.. [2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf -.. [3] http://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf +.. [0] https://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf +.. [1] https://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +.. [2] https://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf +.. [3] https://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf Full SAT solver for Kconfig ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -710,10 +710,10 @@ such efforts somehow on Kconfig. There is enough interest from mentors of existing projects to not only help advise how to integrate this work upstream but also help maintain it long term. Interested developers should visit: -http://kernelnewbies.org/KernelProjects/kconfig-sat +https://kernelnewbies.org/KernelProjects/kconfig-sat -.. [4] http://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf -.. [5] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +.. [4] https://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf +.. [5] https://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf .. [6] https://cados.cs.fau.de .. [7] https://vamos.cs.fau.de .. [8] https://undertaker.cs.fau.de diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index c776b6eee969..2aac50b97921 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -76,7 +76,7 @@ Getting Help Getting LLVM ------------- -- http://releases.llvm.org/download.html +- https://releases.llvm.org/download.html - https://github.com/llvm/llvm-project - https://llvm.org/docs/GettingStarted.html - https://llvm.org/docs/CMake.html diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index 6515ebc12b6f..b81b8913a5a3 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -368,6 +368,14 @@ more details, with real examples. subdir-ccflags-y := -Werror + ccflags-remove-y, asflags-remove-y + These flags are used to remove particular flags for the compiler, + assembler invocations. + + Example:: + + ccflags-remove-$(CONFIG_MCOUNT) += -pg + CFLAGS_$@, AFLAGS_$@ CFLAGS_$@ and AFLAGS_$@ only apply to commands in current kbuild makefile. @@ -375,6 +383,9 @@ more details, with real examples. $(CFLAGS_$@) specifies per-file options for $(CC). The $@ part has a literal value which specifies the file that it is for. + CFLAGS_$@ has the higher priority than ccflags-remove-y; CFLAGS_$@ + can re-add compiler flags that were removed by ccflags-remove-y. + Example:: # drivers/scsi/Makefile @@ -387,6 +398,9 @@ more details, with real examples. $(AFLAGS_$@) is a similar feature for source files in assembly languages. + AFLAGS_$@ has the higher priority than asflags-remove-y; AFLAGS_$@ + can re-add assembler flags that were removed by asflags-remove-y. + Example:: # arch/arm/kernel/Makefile @@ -735,6 +749,10 @@ Both possibilities are described in the following. hostprogs := lxdialog always-y := $(hostprogs) + Kbuild provides the following shorthand for this: + + hostprogs-always-y := lxdialog + This will tell kbuild to build lxdialog even if not referenced in any rule. @@ -817,7 +835,32 @@ The syntax is quite similar. The difference is to use "userprogs" instead of 5.4 When userspace programs are actually built ---------------------------------------------- - Same as "When host programs are actually built". + Kbuild builds userspace programs only when told to do so. + There are two ways to do this. + + (1) Add it as the prerequisite of another file + + Example:: + + #net/bpfilter/Makefile + userprogs := bpfilter_umh + $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh + + $(obj)/bpfilter_umh is built before $(obj)/bpfilter_umh_blob.o + + (2) Use always-y + + Example:: + + userprogs := binderfs_example + always-y := $(userprogs) + + Kbuild provides the following shorthand for this: + + userprogs-always-y := binderfs_example + + This will tell Kbuild to build binderfs_example when it visits this + Makefile. 6 Kbuild clean infrastructure ============================= diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index 1b577a8bf982..4cefed8048ca 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -10,7 +10,7 @@ Introduction ============ The kernel provides a variety of locking primitives which can be divided -into two categories: +into three categories: - Sleeping locks - CPU local locks diff --git a/Documentation/locking/seqlock.rst b/Documentation/locking/seqlock.rst index 366dd368d90a..62c5ad98c11c 100644 --- a/Documentation/locking/seqlock.rst +++ b/Documentation/locking/seqlock.rst @@ -87,6 +87,58 @@ Read path:: } while (read_seqcount_retry(&foo_seqcount, seq)); +.. _seqcount_locktype_t: + +Sequence counters with associated locks (``seqcount_LOCKTYPE_t``) +----------------------------------------------------------------- + +As discussed at :ref:`seqcount_t`, sequence count write side critical +sections must be serialized and non-preemptible. This variant of +sequence counters associate the lock used for writer serialization at +initialization time, which enables lockdep to validate that the write +side critical sections are properly serialized. + +This lock association is a NOOP if lockdep is disabled and has neither +storage nor runtime overhead. If lockdep is enabled, the lock pointer is +stored in struct seqcount and lockdep's "lock is held" assertions are +injected at the beginning of the write side critical section to validate +that it is properly protected. + +For lock types which do not implicitly disable preemption, preemption +protection is enforced in the write side function. + +The following sequence counters with associated locks are defined: + + - ``seqcount_spinlock_t`` + - ``seqcount_raw_spinlock_t`` + - ``seqcount_rwlock_t`` + - ``seqcount_mutex_t`` + - ``seqcount_ww_mutex_t`` + +The plain seqcount read and write APIs branch out to the specific +seqcount_LOCKTYPE_t implementation at compile-time. This avoids kernel +API explosion per each new seqcount LOCKTYPE. + +Initialization (replace "LOCKTYPE" with one of the supported locks):: + + /* dynamic */ + seqcount_LOCKTYPE_t foo_seqcount; + seqcount_LOCKTYPE_init(&foo_seqcount, &lock); + + /* static */ + static seqcount_LOCKTYPE_t foo_seqcount = + SEQCNT_LOCKTYPE_ZERO(foo_seqcount, &lock); + + /* C99 struct init */ + struct { + .seq = SEQCNT_LOCKTYPE_ZERO(foo.seq, &lock), + } foo; + +Write path: same as in :ref:`seqcount_t`, while running from a context +with the associated LOCKTYPE lock acquired. + +Read path: same as in :ref:`seqcount_t`. + .. _seqlock_t: Sequential locks (``seqlock_t``) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 4e55aba3eb4a..96186332e5f4 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1935,6 +1935,20 @@ There are some more advanced barrier functions: relaxed I/O accessors and the Documentation/DMA-API.txt file for more information on consistent memory. + (*) pmem_wmb(); + + This is for use with persistent memory to ensure that stores for which + modifications are written to persistent storage reached a platform + durability domain. + + For example, after a non-temporal write to pmem region, we use pmem_wmb() + to ensure that stores have reached a platform durability domain. This ensures + that stores have updated persistent storage before any data access or + data transfer caused by subsequent instructions is initiated. This is + in addition to the ordering done by wmb(). + + For load from persistent memory, existing read memory barriers are sufficient + to ensure read ordering. =============================== IMPLICIT KERNEL MEMORY BARRIERS diff --git a/Documentation/powerpc/cpu_families.rst b/Documentation/powerpc/cpu_families.rst index 1e063c5440c3..9b84e045e713 100644 --- a/Documentation/powerpc/cpu_families.rst +++ b/Documentation/powerpc/cpu_families.rst @@ -9,7 +9,9 @@ and are supported by arch/powerpc. Book3S (aka sPAPR) ------------------ -- Hash MMU +- Hash MMU (except 603 and e300) +- Software loaded TLB (603 and e300) +- Selectable Software loaded TLB in addition to hash MMU (755, 7450, e600) - Mix of 32 & 64 bit:: +--------------+ +----------------+ @@ -24,9 +26,9 @@ Book3S (aka sPAPR) | | | | v v - +--------------+ +----------------+ +-------+ - | 604 | | 750 (G3) | ---> | 750CX | - +--------------+ +----------------+ +-------+ + +--------------+ +-----+ +----------------+ +-------+ + | 604 | | 755 | <--- | 750 (G3) | ---> | 750CX | + +--------------+ +-----+ +----------------+ +-------+ | | | | | | v v v diff --git a/Documentation/powerpc/mpc52xx.rst b/Documentation/powerpc/mpc52xx.rst index 8676ac63e077..30260707c3fe 100644 --- a/Documentation/powerpc/mpc52xx.rst +++ b/Documentation/powerpc/mpc52xx.rst @@ -2,7 +2,7 @@ Linux 2.6.x on MPC52xx family ============================= -For the latest info, go to http://www.246tNt.com/mpc52xx/ +For the latest info, go to https://www.246tNt.com/mpc52xx/ To compile/use : diff --git a/Documentation/powerpc/syscall64-abi.rst b/Documentation/powerpc/syscall64-abi.rst index e49f69f941b9..46caaadbb029 100644 --- a/Documentation/powerpc/syscall64-abi.rst +++ b/Documentation/powerpc/syscall64-abi.rst @@ -5,6 +5,15 @@ Power Architecture 64-bit Linux system call ABI syscall ======= +Invocation +---------- +The syscall is made with the sc instruction, and returns with execution +continuing at the instruction following the sc instruction. + +If PPC_FEATURE2_SCV appears in the AT_HWCAP2 ELF auxiliary vector, the +scv 0 instruction is an alternative that may provide better performance, +with some differences to calling sequence. + syscall calling sequence\ [1]_ matches the Power Architecture 64-bit ELF ABI specification C function calling sequence, including register preservation rules, with the following differences. @@ -12,16 +21,23 @@ rules, with the following differences. .. [1] Some syscalls (typically low-level management functions) may have different calling sequences (e.g., rt_sigreturn). -Parameters and return value ---------------------------- +Parameters +---------- The system call number is specified in r0. There is a maximum of 6 integer parameters to a syscall, passed in r3-r8. -Both a return value and a return error code are returned. cr0.SO is the return -error code, and r3 is the return value or error code. When cr0.SO is clear, -the syscall succeeded and r3 is the return value. When cr0.SO is set, the -syscall failed and r3 is the error code that generally corresponds to errno. +Return value +------------ +- For the sc instruction, both a value and an error condition are returned. + cr0.SO is the error condition, and r3 is the return value. When cr0.SO is + clear, the syscall succeeded and r3 is the return value. When cr0.SO is set, + the syscall failed and r3 is the error value (that normally corresponds to + errno). + +- For the scv 0 instruction, the return value indicates failure if it is + -4095..-1 (i.e., it is >= -MAX_ERRNO (-4095) as an unsigned comparison), + in which case the error value is the negated return value. Stack ----- @@ -34,22 +50,23 @@ Register preservation rules match the ELF ABI calling sequence with the following differences: =========== ============= ======================================== +--- For the sc instruction, differences with the ELF ABI --- r0 Volatile (System call number.) r3 Volatile (Parameter 1, and return value.) r4-r8 Volatile (Parameters 2-6.) -cr0 Volatile (cr0.SO is the return error condition) +cr0 Volatile (cr0.SO is the return error condition.) cr1, cr5-7 Nonvolatile lr Nonvolatile + +--- For the scv 0 instruction, differences with the ELF ABI --- +r0 Volatile (System call number.) +r3 Volatile (Parameter 1, and return value.) +r4-r8 Volatile (Parameters 2-6.) =========== ============= ======================================== All floating point and vector data registers as well as control and status registers are nonvolatile. -Invocation ----------- -The syscall is performed with the sc instruction, and returns with execution -continuing at the instruction following the sc instruction. - Transactional Memory -------------------- Syscall behavior can change if the processor is in transactional or suspended @@ -75,6 +92,7 @@ auxiliary vector. returning to the caller. This case is not well defined or supported, so this behavior should not be relied upon. +scv 0 syscalls will always behave as PPC_FEATURE2_HTM_NOSC. vsyscall ======== diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst index df136c8f91fa..ba6b1bf1cc44 100644 --- a/Documentation/powerpc/ultravisor.rst +++ b/Documentation/powerpc/ultravisor.rst @@ -895,6 +895,7 @@ Return values One of the following values: * H_SUCCESS on success. + * H_STATE if the VM is not in a position to switch to secure. Description ~~~~~~~~~~~ @@ -933,6 +934,8 @@ Return values * H_UNSUPPORTED if called from the wrong context (e.g. from an SVM or before an H_SVM_INIT_START hypercall). + * H_STATE if the hypervisor could not successfully + transition the VM to Secure VM. Description ~~~~~~~~~~~ diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index 3588f48841eb..4ae1e0f600c1 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -113,7 +113,7 @@ than one development cycle past their initial release. So, for example, the 5.2 kernel's history looked like this (all dates in 2019): ============== =============================== - September 15 5.2 stable release + July 7 5.2 stable release July 14 5.2.1 July 21 5.2.2 July 26 5.2.3 diff --git a/Documentation/scsi/advansys.rst b/Documentation/scsi/advansys.rst index e0367e179696..7ea12b100ff4 100644 --- a/Documentation/scsi/advansys.rst +++ b/Documentation/scsi/advansys.rst @@ -125,7 +125,7 @@ The following constants can be defined in the source file. c. klogd is started with the appropriate -c parameter (e.g. klogd -c 8) - This will cause printk() messages to be be displayed on the + This will cause printk() messages to be displayed on the current console. Refer to the klogd(8) and syslogd(8) man pages for details. diff --git a/Documentation/scsi/scsi-parameters.rst b/Documentation/scsi/scsi-parameters.rst index 9aba897c97ac..e5f68b431f5c 100644 --- a/Documentation/scsi/scsi-parameters.rst +++ b/Documentation/scsi/scsi-parameters.rst @@ -94,7 +94,7 @@ parameters may be changed at runtime by the command (/proc/sys/dev/scsi/logging_level). There is also a nice 'scsi_logging_level' script in the S390-tools package, available for download at - http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html + https://github.com/ibm-s390-tools/s390-tools/blob/master/scripts/scsi_logging_level scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are discovered. async scans them in kernel threads, diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst index 72f97d4b01a7..c755b1c5e16f 100644 --- a/Documentation/sound/alsa-configuration.rst +++ b/Documentation/sound/alsa-configuration.rst @@ -309,7 +309,7 @@ pcifix This module supports all ADB PCM channels, ac97 mixer, SPDIF, hardware EQ, mpu401, gameport. A3D and wavetable support are still in development. Development and reverse engineering work is being coordinated at -http://savannah.nongnu.org/projects/openvortex/ +https://savannah.nongnu.org/projects/openvortex/ SPDIF output has a copy of the AC97 codec output, unless you use the ``spdif`` pcm device, which allows raw data passthru. The hardware EQ hardware and SPDIF is only present in the Vortex2 and @@ -1575,7 +1575,7 @@ See Documentation/sound/cards/multisound.sh for important information about this driver. Note that it has been discontinued, but the Voyetra Turtle Beach knowledge base entry for it is still available at -http://www.turtlebeach.com +https://www.turtlebeach.com Module snd-msnd-pinnacle ------------------------ @@ -2703,4 +2703,4 @@ Kernel Bugzilla ALSA Developers ML mailto:alsa-devel@alsa-project.org alsa-info.sh script - http://www.alsa-project.org/alsa-info.sh + https://www.alsa-project.org/alsa-info.sh diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst index 86213234435f..998f76e19cdd 100644 --- a/Documentation/sound/cards/audigy-mixer.rst +++ b/Documentation/sound/cards/audigy-mixer.rst @@ -331,7 +331,7 @@ WO 9901953 (A1) Execution and Audio Data Sequencing (Jan. 14, 1999) -US Patents (http://www.uspto.gov/) +US Patents (https://www.uspto.gov/) ---------------------------------- US 5925841 diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst index bcb62fc99bbb..eccb0f0ffd0f 100644 --- a/Documentation/sound/cards/sb-live-mixer.rst +++ b/Documentation/sound/cards/sb-live-mixer.rst @@ -336,7 +336,7 @@ WO 9901953 (A1) Execution and Audio Data Sequencing (Jan. 14, 1999) -US Patents (http://www.uspto.gov/) +US Patents (https://www.uspto.gov/) ---------------------------------- US 5925841 diff --git a/Documentation/sound/designs/compress-offload.rst b/Documentation/sound/designs/compress-offload.rst index ad4bfbdacc83..935f325dbc77 100644 --- a/Documentation/sound/designs/compress-offload.rst +++ b/Documentation/sound/designs/compress-offload.rst @@ -151,6 +151,57 @@ Modifications include: - Addition of encoding options when required (derived from OpenMAX IL) - Addition of rateControlSupported (missing in OpenMAX AL) +State Machine +============= + +The compressed audio stream state machine is described below :: + + +----------+ + | | + | OPEN | + | | + +----------+ + | + | + | compr_set_params() + | + v + compr_free() +----------+ + +------------------------------------| | + | | SETUP | + | +-------------------------| |<-------------------------+ + | | compr_write() +----------+ | + | | ^ | + | | | compr_drain_notify() | + | | | or | + | | | compr_stop() | + | | | | + | | +----------+ | + | | | | | + | | | DRAIN | | + | | | | | + | | +----------+ | + | | ^ | + | | | | + | | | compr_drain() | + | | | | + | v | | + | +----------+ +----------+ | + | | | compr_start() | | compr_stop() | + | | PREPARE |------------------->| RUNNING |--------------------------+ + | | | | | | + | +----------+ +----------+ | + | | | ^ | + | |compr_free() | | | + | | compr_pause() | | compr_resume() | + | | | | | + | v v | | + | +----------+ +----------+ | + | | | | | compr_stop() | + +--->| FREE | | PAUSE |---------------------------+ + | | | | + +----------+ +----------+ + Gapless Playback ================ @@ -199,6 +250,38 @@ Sequence flow for gapless would be: (note: order for partial_drain and write for next track can be reversed as well) +Gapless Playback SM +=================== + +For Gapless, we move from running state to partial drain and back, along +with setting of meta_data and signalling for next track :: + + + +----------+ + compr_drain_notify() | | + +------------------------>| RUNNING | + | | | + | +----------+ + | | + | | + | | compr_next_track() + | | + | V + | +----------+ + | | | + | |NEXT_TRACK| + | | | + | +----------+ + | | + | | + | | compr_partial_drain() + | | + | V + | +----------+ + | | | + +------------------------ | PARTIAL_ | + | DRAIN | + +----------+ Not supported ============= diff --git a/Documentation/sound/designs/procfile.rst b/Documentation/sound/designs/procfile.rst index 29a466851fd2..e9f7e0cbdc5f 100644 --- a/Documentation/sound/designs/procfile.rst +++ b/Documentation/sound/designs/procfile.rst @@ -91,7 +91,7 @@ PCM Proc Files ``card*/pcm*/xrun_debug`` This file appears when ``CONFIG_SND_DEBUG=y`` and - ``CONFIG_PCM_XRUN_DEBUG=y``. + ``CONFIG_SND_PCM_XRUN_DEBUG=y``. This shows the status of xrun (= buffer overrun/xrun) and invalid PCM position debug/check of ALSA PCM middle layer. It takes an integer value, can be changed by writing to this diff --git a/Documentation/sound/hd-audio/notes.rst b/Documentation/sound/hd-audio/notes.rst index 0f3109d9abc8..cf4d7158af78 100644 --- a/Documentation/sound/hd-audio/notes.rst +++ b/Documentation/sound/hd-audio/notes.rst @@ -42,7 +42,7 @@ If you are interested in the deep debugging of HD-audio, read the HD-audio specification at first. The specification is found on Intel's web page, for example: -* http://www.intel.com/standards/hdaudio/ +* https://www.intel.com/standards/hdaudio/ HD-Audio Controller @@ -728,7 +728,7 @@ version can be found on git repository: The script can be fetched directly from the following URL, too: -* http://www.alsa-project.org/alsa-info.sh +* https://www.alsa-project.org/alsa-info.sh Run this script as root, and it will gather the important information such as the module lists, module parameters, proc file contents @@ -818,7 +818,7 @@ proc-compatible output. The hda-analyzer: -* http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer +* https://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer is a part of alsa.git repository in alsa-project.org: diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index 14cd138989e3..c8cc651eccf7 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -99,7 +99,7 @@ ASoC Core API .. kernel-doc:: include/sound/soc.h .. kernel-doc:: sound/soc/soc-core.c .. kernel-doc:: sound/soc/soc-devres.c -.. kernel-doc:: sound/soc/soc-io.c +.. kernel-doc:: sound/soc/soc-component.c .. kernel-doc:: sound/soc/soc-pcm.c .. kernel-doc:: sound/soc/soc-ops.c .. kernel-doc:: sound/soc/soc-compress.c diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index fa4968817696..aa9d5ab183d2 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3579,7 +3579,7 @@ dependent on the bus. For normal devices, pass the device pointer ``SNDRV_DMA_TYPE_DEV`` type. For the continuous buffer unrelated to the bus can be pre-allocated with ``SNDRV_DMA_TYPE_CONTINUOUS`` type. You can pass NULL to the device pointer in that case, which is the -default mode implying to allocate with ``GFP_KRENEL`` flag. +default mode implying to allocate with ``GFP_KERNEL`` flag. If you need a different GFP flag, you can pass it by encoding the flag into the device pointer via a special macro :c:func:`snd_dma_continuous_data()`. diff --git a/Documentation/sound/soc/dai.rst b/Documentation/sound/soc/dai.rst index 2e99183a7a47..009b07e5a0f3 100644 --- a/Documentation/sound/soc/dai.rst +++ b/Documentation/sound/soc/dai.rst @@ -17,7 +17,7 @@ frame (FRAME) (usually 48kHz) is always driven by the controller. Each AC97 frame is 21uS long and is divided into 13 time slots. The AC97 specification can be found at : -http://www.intel.com/p/en_US/business/design +https://www.intel.com/p/en_US/business/design I2S diff --git a/Documentation/staging/rpmsg.rst b/Documentation/staging/rpmsg.rst index 24b7a9e1a5f9..1ce353cb232a 100644 --- a/Documentation/staging/rpmsg.rst +++ b/Documentation/staging/rpmsg.rst @@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on failure. :: - struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev, - void (*cb)(struct rpmsg_channel *, void *, int, void *, u32), - void *priv, u32 addr); + struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, + rpmsg_rx_cb_t cb, void *priv, + struct rpmsg_channel_info chinfo); every rpmsg address in the system is bound to an rx callback (so when inbound messages arrive, they are dispatched by the rpmsg bus using the diff --git a/Documentation/trace/intel_th.rst b/Documentation/trace/intel_th.rst index 70b7126eaeeb..b31818d5f6c5 100644 --- a/Documentation/trace/intel_th.rst +++ b/Documentation/trace/intel_th.rst @@ -58,7 +58,7 @@ Bus and Subdevices For each Intel TH device in the system a bus of its own is created and assigned an id number that reflects the order in which TH -devices were emumerated. All TH subdevices (devices on intel_th bus) +devices were enumerated. All TH subdevices (devices on intel_th bus) begin with this id: 0-gth, 0-msc0, 0-msc1, 0-pti, 0-sth, which is followed by device's name and an optional index. diff --git a/Documentation/translations/zh_CN/admin-guide/cpu-load.rst b/Documentation/translations/zh_CN/admin-guide/cpu-load.rst index 0116d0477799..c972731c0e57 100644 --- a/Documentation/translations/zh_CN/admin-guide/cpu-load.rst +++ b/Documentation/translations/zh_CN/admin-guide/cpu-load.rst @@ -1,6 +1,6 @@ -======= +======== CPU 负载 -======= +======== Linux通过``/proc/stat``和``/proc/uptime``导出各种信息，用户空间工具 如top(1)使用这些信息计算系统花费在某个特定状态的平均时间。 diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 7d502fa5da64..ed5ab7e37f38 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :ref:`Documentation/admin-guide/index.rst` +:Original: :doc:`../../../admin-guide/index` :Translator: Alex Shi <alex.shi@linux.alibaba.com> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 59472cd6a11d..2a198838fca9 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -339,6 +339,7 @@ Code Seq# Include File Comments 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org> 0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org> 0xB6 all linux/fpga-dfl.h +0xB7 all uapi/linux/remoteproc_cdev.h <mailto:linux-remoteproc@vger.kernel.org> 0xC0 00-0F linux/usb/iowarrior.h 0xCA 00-0F uapi/misc/cxl.h 0xCA 10-2F uapi/misc/ocxl.h diff --git a/Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst b/Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst index 94e46a11d68d..436a882dfa31 100644 --- a/Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst +++ b/Documentation/userspace-api/media/cec/cec-ioc-adap-g-caps.rst @@ -58,6 +58,9 @@ returns the information to the application. The ioctl never fails. - The name of this CEC adapter. The combination ``driver`` and ``name`` must be unique. * - __u32 + - ``available_log_addrs`` + - The maximum number of logical addresses that can be configured. + * - __u32 - ``capabilities`` - The capabilities of the CEC adapter, see :ref:`cec-capabilities`. diff --git a/Documentation/userspace-api/media/dvb/fe-get-info.rst b/Documentation/userspace-api/media/dvb/fe-get-info.rst index 80d9f8195ac4..6b3ffd301142 100644 --- a/Documentation/userspace-api/media/dvb/fe-get-info.rst +++ b/Documentation/userspace-api/media/dvb/fe-get-info.rst @@ -34,8 +34,7 @@ Arguments File descriptor returned by :ref:`open() <frontend_f_open>`. ``argp`` - pointer to struct struct - :c:type:`dvb_frontend_info` + pointer to struct :c:type:`dvb_frontend_info` Description diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst index 951ae1ed485f..57e752aaf414 100644 --- a/Documentation/userspace-api/media/v4l/buffer.rst +++ b/Documentation/userspace-api/media/v4l/buffer.rst @@ -23,8 +23,8 @@ argument to the :ref:`VIDIOC_QUERYBUF`, :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API, some plane-specific members of struct :c:type:`v4l2_buffer`, -such as pointers and sizes for each plane, are stored in struct -struct :c:type:`v4l2_plane` instead. In that case, struct +such as pointers and sizes for each plane, are stored in +struct :c:type:`v4l2_plane` instead. In that case, struct :c:type:`v4l2_buffer` contains an array of plane structures. Dequeued video buffers come with timestamps. The driver decides at which @@ -577,7 +577,10 @@ Buffer Flags applications shall use this flag if the data captured in the buffer is not going to be touched by the CPU, instead the buffer will, probably, be passed on to a DMA-capable hardware unit for - further processing or output. + further processing or output. This flag is ignored unless the + queue is used for :ref:`memory mapping <mmap>` streaming I/O and + reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS + <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. * .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`: - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` @@ -585,7 +588,10 @@ Buffer Flags - Caches do not have to be cleaned for this buffer. Typically applications shall use this flag for output buffers if the data in this buffer has not been created by the CPU but by some - DMA-capable unit, in which case caches have not been used. + DMA-capable unit, in which case caches have not been used. This flag + is ignored unless the queue is used for :ref:`memory mapping <mmap>` + streaming I/O and reports :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS + <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. * .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`: - ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` @@ -681,6 +687,36 @@ Buffer Flags \normalsize +.. _memory-flags: + +Memory Consistency Flags +======================== + +.. tabularcolumns:: |p{7.0cm}|p{2.2cm}|p{8.3cm}| + +.. cssclass:: longtable + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 3 1 4 + + * .. _`V4L2-FLAG-MEMORY-NON-CONSISTENT`: + + - ``V4L2_FLAG_MEMORY_NON_CONSISTENT`` + - 0x00000001 + - A buffer is allocated either in consistent (it will be automatically + coherent between the CPU and the bus) or non-consistent memory. The + latter can provide performance gains, for instance the CPU cache + sync/flush operations can be avoided if the buffer is accessed by the + corresponding device only and the CPU does not read/write to/from that + buffer. However, this requires extra care from the driver -- it must + guarantee memory consistency by issuing a cache flush/sync when + consistency is needed. If this flag is set V4L2 will attempt to + allocate the buffer in non-consistent memory. The flag takes effect + only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the + queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS + <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. .. c:type:: v4l2_memory diff --git a/Documentation/userspace-api/media/v4l/colorspaces-details.rst b/Documentation/userspace-api/media/v4l/colorspaces-details.rst index 79ed6f4f76eb..300c5d2e7d0f 100644 --- a/Documentation/userspace-api/media/v4l/colorspaces-details.rst +++ b/Documentation/userspace-api/media/v4l/colorspaces-details.rst @@ -767,8 +767,8 @@ scaled to [-128…128] and then clipped to [-128…127]. information. So if something other than sRGB is used, then the driver will have to set that information explicitly. Effectively ``V4L2_COLORSPACE_JPEG`` can be considered to be an abbreviation for - ``V4L2_COLORSPACE_SRGB``, ``V4L2_YCBCR_ENC_601`` and - ``V4L2_QUANTIZATION_FULL_RANGE``. + ``V4L2_COLORSPACE_SRGB``, ``V4L2_XFER_FUNC_SRGB``, ``V4L2_YCBCR_ENC_601`` + and ``V4L2_QUANTIZATION_FULL_RANGE``. *************************************** Detailed Transfer Function Descriptions diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst index 606b54947e10..3d4138a4ba69 100644 --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst @@ -247,7 +247,7 @@ Querying Capabilities Initialization ============== -1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT` +1. Set the coded format on ``OUTPUT`` via :c:func:`VIDIOC_S_FMT`. * **Required fields:** @@ -803,7 +803,7 @@ it may be affected as per normal decoder operation. * The decoder will drop all the pending ``OUTPUT`` buffers and they must be treated as returned to the client (following standard semantics). -2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON` +2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON`. * **Required fields:** @@ -906,7 +906,9 @@ reflected by corresponding queries): * visible resolution (selection rectangles), -* the minimum number of buffers needed for decoding. +* the minimum number of buffers needed for decoding, + +* bit-depth of the bitstream has been changed. Whenever that happens, the decoder must proceed as follows: @@ -1059,7 +1061,7 @@ sequence was started. ``V4L2_DEC_CMD_STOP`` again while the drain sequence is in progress and they will fail with -EBUSY error code if attempted. - Although mandatory, the availability of decoder commands may be queried + Although not mandatory, the availability of decoder commands may be queried using :c:func:`VIDIOC_TRY_DECODER_CMD`. End of Stream diff --git a/Documentation/userspace-api/media/v4l/dev-encoder.rst b/Documentation/userspace-api/media/v4l/dev-encoder.rst new file mode 100644 index 000000000000..fb44f20924de --- /dev/null +++ b/Documentation/userspace-api/media/v4l/dev-encoder.rst @@ -0,0 +1,753 @@ +.. This file is dual-licensed: you can use it either under the terms +.. of the GPL 2.0 or the GFDL 1.1+ license, at your option. Note that this +.. dual licensing only applies to this file, and not this project as a +.. whole. +.. +.. a) This file is free software; you can redistribute it and/or +.. modify it under the terms of the GNU General Public License as +.. published by the Free Software Foundation version 2 of +.. the License. +.. +.. This file is distributed in the hope that it will be useful, +.. but WITHOUT ANY WARRANTY; without even the implied warranty of +.. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +.. GNU General Public License for more details. +.. +.. Or, alternatively, +.. +.. b) Permission is granted to copy, distribute and/or modify this +.. document under the terms of the GNU Free Documentation License, +.. Version 1.1 or any later version published by the Free Software +.. Foundation, with no Invariant Sections, no Front-Cover Texts +.. and no Back-Cover Texts. A copy of the license is included at +.. Documentation/userspace-api/media/fdl-appendix.rst. +.. +.. TODO: replace it to GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections + +.. _encoder: + +************************************************* +Memory-to-Memory Stateful Video Encoder Interface +************************************************* + +A stateful video encoder takes raw video frames in display order and encodes +them into a bytestream. It generates complete chunks of the bytestream, including +all metadata, headers, etc. The resulting bytestream does not require any +further post-processing by the client. + +Performing software stream processing, header generation etc. in the driver +in order to support this interface is strongly discouraged. In case such +operations are needed, use of the Stateless Video Encoder Interface (in +development) is strongly advised. + +Conventions and Notations Used in This Document +=============================================== + +1. The general V4L2 API rules apply if not specified in this document + otherwise. + +2. The meaning of words "must", "may", "should", etc. is as per `RFC + 2119 <https://tools.ietf.org/html/rfc2119>`_. + +3. All steps not marked "optional" are required. + +4. :c:func:`VIDIOC_G_EXT_CTRLS` and :c:func:`VIDIOC_S_EXT_CTRLS` may be used + interchangeably with :c:func:`VIDIOC_G_CTRL` and :c:func:`VIDIOC_S_CTRL`, + unless specified otherwise. + +5. Single-planar API (see :ref:`planar-apis`) and applicable structures may be + used interchangeably with multi-planar API, unless specified otherwise, + depending on encoder capabilities and following the general V4L2 guidelines. + +6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i = + [0..2]: i = 0, 1, 2. + +7. Given an ``OUTPUT`` buffer A, then A' represents a buffer on the ``CAPTURE`` + queue containing data that resulted from processing buffer A. + +Glossary +======== + +Refer to :ref:`decoder-glossary`. + +State Machine +============= + +.. kernel-render:: DOT + :alt: DOT digraph of encoder state machine + :caption: Encoder State Machine + + digraph encoder_state_machine { + node [shape = doublecircle, label="Encoding"] Encoding; + + node [shape = circle, label="Initialization"] Initialization; + node [shape = circle, label="Stopped"] Stopped; + node [shape = circle, label="Drain"] Drain; + node [shape = circle, label="Reset"] Reset; + + node [shape = point]; qi + qi -> Initialization [ label = "open()" ]; + + Initialization -> Encoding [ label = "Both queues streaming" ]; + + Encoding -> Drain [ label = "V4L2_ENC_CMD_STOP" ]; + Encoding -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ]; + Encoding -> Stopped [ label = "VIDIOC_STREAMOFF(OUTPUT)" ]; + Encoding -> Encoding; + + Drain -> Stopped [ label = "All CAPTURE\nbuffers dequeued\nor\nVIDIOC_STREAMOFF(OUTPUT)" ]; + Drain -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ]; + + Reset -> Encoding [ label = "VIDIOC_STREAMON(CAPTURE)" ]; + Reset -> Initialization [ label = "VIDIOC_REQBUFS(OUTPUT, 0)" ]; + + Stopped -> Encoding [ label = "V4L2_ENC_CMD_START\nor\nVIDIOC_STREAMON(OUTPUT)" ]; + Stopped -> Reset [ label = "VIDIOC_STREAMOFF(CAPTURE)" ]; + } + +Querying Capabilities +===================== + +1. To enumerate the set of coded formats supported by the encoder, the + client may call :c:func:`VIDIOC_ENUM_FMT` on ``CAPTURE``. + + * The full set of supported formats will be returned, regardless of the + format set on ``OUTPUT``. + +2. To enumerate the set of supported raw formats, the client may call + :c:func:`VIDIOC_ENUM_FMT` on ``OUTPUT``. + + * Only the formats supported for the format currently active on ``CAPTURE`` + will be returned. + + * In order to enumerate raw formats supported by a given coded format, + the client must first set that coded format on ``CAPTURE`` and then + enumerate the formats on ``OUTPUT``. + +3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported + resolutions for a given format, passing the desired pixel format in + :c:type:`v4l2_frmsizeenum` ``pixel_format``. + + * Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a coded pixel + format will include all possible coded resolutions supported by the + encoder for the given coded pixel format. + + * Values returned by :c:func:`VIDIOC_ENUM_FRAMESIZES` for a raw pixel format + will include all possible frame buffer resolutions supported by the + encoder for the given raw pixel format and coded format currently set on + ``CAPTURE``. + +4. The client may use :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` to detect supported + frame intervals for a given format and resolution, passing the desired pixel + format in :c:type:`v4l2_frmsizeenum` ``pixel_format`` and the resolution + in :c:type:`v4l2_frmsizeenum` ``width`` and :c:type:`v4l2_frmsizeenum` + ``height``. + + * Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a coded pixel + format and coded resolution will include all possible frame intervals + supported by the encoder for the given coded pixel format and resolution. + + * Values returned by :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` for a raw pixel + format and resolution will include all possible frame intervals supported + by the encoder for the given raw pixel format and resolution and for the + coded format, coded resolution and coded frame interval currently set on + ``CAPTURE``. + + * Support for :c:func:`VIDIOC_ENUM_FRAMEINTERVALS` is optional. If it is + not implemented, then there are no special restrictions other than the + limits of the codec itself. + +5. Supported profiles and levels for the coded format currently set on + ``CAPTURE``, if applicable, may be queried using their respective controls + via :c:func:`VIDIOC_QUERYCTRL`. + +6. Any additional encoder capabilities may be discovered by querying + their respective controls. + +Initialization +============== + +1. Set the coded format on the ``CAPTURE`` queue via :c:func:`VIDIOC_S_FMT`. + + * **Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``. + + ``pixelformat`` + the coded format to be produced. + + ``sizeimage`` + desired size of ``CAPTURE`` buffers; the encoder may adjust it to + match hardware requirements. + + ``width``, ``height`` + ignored (read-only). + + other fields + follow standard semantics. + + * **Return fields:** + + ``sizeimage`` + adjusted size of ``CAPTURE`` buffers. + + ``width``, ``height`` + the coded size selected by the encoder based on current state, e.g. + ``OUTPUT`` format, selection rectangles, etc. (read-only). + + .. important:: + + Changing the ``CAPTURE`` format may change the currently set ``OUTPUT`` + format. How the new ``OUTPUT`` format is determined is up to the encoder + and the client must ensure it matches its needs afterwards. + +2. **Optional.** Enumerate supported ``OUTPUT`` formats (raw formats for + source) for the selected coded format via :c:func:`VIDIOC_ENUM_FMT`. + + * **Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. + + other fields + follow standard semantics. + + * **Return fields:** + + ``pixelformat`` + raw format supported for the coded format currently selected on + the ``CAPTURE`` queue. + + other fields + follow standard semantics. + +3. Set the raw source format on the ``OUTPUT`` queue via + :c:func:`VIDIOC_S_FMT`. + + * **Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. + + ``pixelformat`` + raw format of the source. + + ``width``, ``height`` + source resolution. + + other fields + follow standard semantics. + + * **Return fields:** + + ``width``, ``height`` + may be adjusted to match encoder minimums, maximums and alignment + requirements, as required by the currently selected formats, as + reported by :c:func:`VIDIOC_ENUM_FRAMESIZES`. + + other fields + follow standard semantics. + + * Setting the ``OUTPUT`` format will reset the selection rectangles to their + default values, based on the new resolution, as described in the next + step. + +4. Set the raw frame interval on the ``OUTPUT`` queue via + :c:func:`VIDIOC_S_PARM`. This also sets the coded frame interval on the + ``CAPTURE`` queue to the same value. + + * ** Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. + + ``parm.output`` + set all fields except ``parm.output.timeperframe`` to 0. + + ``parm.output.timeperframe`` + the desired frame interval; the encoder may adjust it to + match hardware requirements. + + * **Return fields:** + + ``parm.output.timeperframe`` + the adjusted frame interval. + + .. important:: + + Changing the ``OUTPUT`` frame interval *also* sets the framerate that + the encoder uses to encode the video. So setting the frame interval + to 1/24 (or 24 frames per second) will produce a coded video stream + that can be played back at that speed. The frame interval for the + ``OUTPUT`` queue is just a hint, the application may provide raw + frames at a different rate. It can be used by the driver to help + schedule multiple encoders running in parallel. + + In the next step the ``CAPTURE`` frame interval can optionally be + changed to a different value. This is useful for off-line encoding + were the coded frame interval can be different from the rate at + which raw frames are supplied. + + .. important:: + + ``timeperframe`` deals with *frames*, not fields. So for interlaced + formats this is the time per two fields, since a frame consists of + a top and a bottom field. + + .. note:: + + It is due to historical reasons that changing the ``OUTPUT`` frame + interval also changes the coded frame interval on the ``CAPTURE`` + queue. Ideally these would be independent settings, but that would + break the existing API. + +5. **Optional** Set the coded frame interval on the ``CAPTURE`` queue via + :c:func:`VIDIOC_S_PARM`. This is only necessary if the coded frame + interval is different from the raw frame interval, which is typically + the case for off-line encoding. Support for this feature is signalled + by the :ref:`V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL <fmtdesc-flags>` format flag. + + * ** Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE``. + + ``parm.capture`` + set all fields except ``parm.capture.timeperframe`` to 0. + + ``parm.capture.timeperframe`` + the desired coded frame interval; the encoder may adjust it to + match hardware requirements. + + * **Return fields:** + + ``parm.capture.timeperframe`` + the adjusted frame interval. + + .. important:: + + Changing the ``CAPTURE`` frame interval sets the framerate for the + coded video. It does *not* set the rate at which buffers arrive on the + ``CAPTURE`` queue, that depends on how fast the encoder is and how + fast raw frames are queued on the ``OUTPUT`` queue. + + .. important:: + + ``timeperframe`` deals with *frames*, not fields. So for interlaced + formats this is the time per two fields, since a frame consists of + a top and a bottom field. + + .. note:: + + Not all drivers support this functionality, in that case just set + the desired coded frame interval for the ``OUTPUT`` queue. + + However, drivers that can schedule multiple encoders based on the + ``OUTPUT`` frame interval must support this optional feature. + +6. **Optional.** Set the visible resolution for the stream metadata via + :c:func:`VIDIOC_S_SELECTION` on the ``OUTPUT`` queue if it is desired + to be different than the full OUTPUT resolution. + + * **Required fields:** + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. + + ``target`` + set to ``V4L2_SEL_TGT_CROP``. + + ``r.left``, ``r.top``, ``r.width``, ``r.height`` + visible rectangle; this must fit within the `V4L2_SEL_TGT_CROP_BOUNDS` + rectangle and may be subject to adjustment to match codec and + hardware constraints. + + * **Return fields:** + + ``r.left``, ``r.top``, ``r.width``, ``r.height`` + visible rectangle adjusted by the encoder. + + * The following selection targets are supported on ``OUTPUT``: + + ``V4L2_SEL_TGT_CROP_BOUNDS`` + equal to the full source frame, matching the active ``OUTPUT`` + format. + + ``V4L2_SEL_TGT_CROP_DEFAULT`` + equal to ``V4L2_SEL_TGT_CROP_BOUNDS``. + + ``V4L2_SEL_TGT_CROP`` + rectangle within the source buffer to be encoded into the + ``CAPTURE`` stream; defaults to ``V4L2_SEL_TGT_CROP_DEFAULT``. + + .. note:: + + A common use case for this selection target is encoding a source + video with a resolution that is not a multiple of a macroblock, + e.g. the common 1920x1080 resolution may require the source + buffers to be aligned to 1920x1088 for codecs with 16x16 macroblock + size. To avoid encoding the padding, the client needs to explicitly + configure this selection target to 1920x1080. + + .. warning:: + + The encoder may adjust the crop/compose rectangles to the nearest + supported ones to meet codec and hardware requirements. The client needs + to check the adjusted rectangle returned by :c:func:`VIDIOC_S_SELECTION`. + +7. Allocate buffers for both ``OUTPUT`` and ``CAPTURE`` via + :c:func:`VIDIOC_REQBUFS`. This may be performed in any order. + + * **Required fields:** + + ``count`` + requested number of buffers to allocate; greater than zero. + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` or + ``CAPTURE``. + + other fields + follow standard semantics. + + * **Return fields:** + + ``count`` + actual number of buffers allocated. + + .. warning:: + + The actual number of allocated buffers may differ from the ``count`` + given. The client must check the updated value of ``count`` after the + call returns. + + .. note:: + + To allocate more than the minimum number of OUTPUT buffers (for pipeline + depth), the client may query the ``V4L2_CID_MIN_BUFFERS_FOR_OUTPUT`` + control to get the minimum number of buffers required, and pass the + obtained value plus the number of additional buffers needed in the + ``count`` field to :c:func:`VIDIOC_REQBUFS`. + + Alternatively, :c:func:`VIDIOC_CREATE_BUFS` can be used to have more + control over buffer allocation. + + * **Required fields:** + + ``count`` + requested number of buffers to allocate; greater than zero. + + ``type`` + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT``. + + other fields + follow standard semantics. + + * **Return fields:** + + ``count`` + adjusted to the number of allocated buffers. + +8. Begin streaming on both ``OUTPUT`` and ``CAPTURE`` queues via + :c:func:`VIDIOC_STREAMON`. This may be performed in any order. The actual + encoding process starts when both queues start streaming. + +.. note:: + + If the client stops the ``CAPTURE`` queue during the encode process and then + restarts it again, the encoder will begin generating a stream independent + from the stream generated before the stop. The exact constraints depend + on the coded format, but may include the following implications: + + * encoded frames produced after the restart must not reference any + frames produced before the stop, e.g. no long term references for + H.264/HEVC, + + * any headers that must be included in a standalone stream must be + produced again, e.g. SPS and PPS for H.264/HEVC. + +Encoding +======== + +This state is reached after the `Initialization` sequence finishes +successfully. In this state, the client queues and dequeues buffers to both +queues via :c:func:`VIDIOC_QBUF` and :c:func:`VIDIOC_DQBUF`, following the +standard semantics. + +The content of encoded ``CAPTURE`` buffers depends on the active coded pixel +format and may be affected by codec-specific extended controls, as stated +in the documentation of each format. + +Both queues operate independently, following standard behavior of V4L2 buffer +queues and memory-to-memory devices. In addition, the order of encoded frames +dequeued from the ``CAPTURE`` queue may differ from the order of queuing raw +frames to the ``OUTPUT`` queue, due to properties of the selected coded format, +e.g. frame reordering. + +The client must not assume any direct relationship between ``CAPTURE`` and +``OUTPUT`` buffers and any specific timing of buffers becoming +available to dequeue. Specifically: + +* a buffer queued to ``OUTPUT`` may result in more than one buffer produced on + ``CAPTURE`` (for example, if returning an encoded frame allowed the encoder + to return a frame that preceded it in display, but succeeded it in the decode + order; however, there may be other reasons for this as well), + +* a buffer queued to ``OUTPUT`` may result in a buffer being produced on + ``CAPTURE`` later into encode process, and/or after processing further + ``OUTPUT`` buffers, or be returned out of order, e.g. if display + reordering is used, + +* buffers may become available on the ``CAPTURE`` queue without additional + buffers queued to ``OUTPUT`` (e.g. during drain or ``EOS``), because of the + ``OUTPUT`` buffers queued in the past whose encoding results are only + available at later time, due to specifics of the encoding process, + +* buffers queued to ``OUTPUT`` may not become available to dequeue instantly + after being encoded into a corresponding ``CAPTURE`` buffer, e.g. if the + encoder needs to use the frame as a reference for encoding further frames. + +.. note:: + + To allow matching encoded ``CAPTURE`` buffers with ``OUTPUT`` buffers they + originated from, the client can set the ``timestamp`` field of the + :c:type:`v4l2_buffer` struct when queuing an ``OUTPUT`` buffer. The + ``CAPTURE`` buffer(s), which resulted from encoding that ``OUTPUT`` buffer + will have their ``timestamp`` field set to the same value when dequeued. + + In addition to the straightforward case of one ``OUTPUT`` buffer producing + one ``CAPTURE`` buffer, the following cases are defined: + + * one ``OUTPUT`` buffer generates multiple ``CAPTURE`` buffers: the same + ``OUTPUT`` timestamp will be copied to multiple ``CAPTURE`` buffers, + + * the encoding order differs from the presentation order (i.e. the + ``CAPTURE`` buffers are out-of-order compared to the ``OUTPUT`` buffers): + ``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` timestamps. + +.. note:: + + To let the client distinguish between frame types (keyframes, intermediate + frames; the exact list of types depends on the coded format), the + ``CAPTURE`` buffers will have corresponding flag bits set in their + :c:type:`v4l2_buffer` struct when dequeued. See the documentation of + :c:type:`v4l2_buffer` and each coded pixel format for exact list of flags + and their meanings. + +Should an encoding error occur, it will be reported to the client with the level +of details depending on the encoder capabilities. Specifically: + +* the ``CAPTURE`` buffer (if any) that contains the results of the failed encode + operation will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag set, + +* if the encoder is able to precisely report the ``OUTPUT`` buffer(s) that triggered + the error, such buffer(s) will be returned with the ``V4L2_BUF_FLAG_ERROR`` flag + set. + +.. note:: + + If a ``CAPTURE`` buffer is too small then it is just returned with the + ``V4L2_BUF_FLAG_ERROR`` flag set. More work is needed to detect that this + error occurred because the buffer was too small, and to provide support to + free existing buffers that were too small. + +In case of a fatal failure that does not allow the encoding to continue, any +further operations on corresponding encoder file handle will return the -EIO +error code. The client may close the file handle and open a new one, or +alternatively reinitialize the instance by stopping streaming on both queues, +releasing all buffers and performing the Initialization sequence again. + +Encoding Parameter Changes +========================== + +The client is allowed to use :c:func:`VIDIOC_S_CTRL` to change encoder +parameters at any time. The availability of parameters is encoder-specific +and the client must query the encoder to find the set of available controls. + +The ability to change each parameter during encoding is encoder-specific, as +per the standard semantics of the V4L2 control interface. The client may +attempt to set a control during encoding and if the operation fails with the +-EBUSY error code, the ``CAPTURE`` queue needs to be stopped for the +configuration change to be allowed. To do this, it may follow the `Drain` +sequence to avoid losing the already queued/encoded frames. + +The timing of parameter updates is encoder-specific, as per the standard +semantics of the V4L2 control interface. If the client needs to apply the +parameters exactly at specific frame, using the Request API +(:ref:`media-request-api`) should be considered, if supported by the encoder. + +Drain +===== + +To ensure that all the queued ``OUTPUT`` buffers have been processed and the +related ``CAPTURE`` buffers are given to the client, the client must follow the +drain sequence described below. After the drain sequence ends, the client has +received all encoded frames for all ``OUTPUT`` buffers queued before the +sequence was started. + +1. Begin the drain sequence by issuing :c:func:`VIDIOC_ENCODER_CMD`. + + * **Required fields:** + + ``cmd`` + set to ``V4L2_ENC_CMD_STOP``. + + ``flags`` + set to 0. + + ``pts`` + set to 0. + + .. warning:: + + The sequence can be only initiated if both ``OUTPUT`` and ``CAPTURE`` + queues are streaming. For compatibility reasons, the call to + :c:func:`VIDIOC_ENCODER_CMD` will not fail even if any of the queues is + not streaming, but at the same time it will not initiate the `Drain` + sequence and so the steps described below would not be applicable. + +2. Any ``OUTPUT`` buffers queued by the client before the + :c:func:`VIDIOC_ENCODER_CMD` was issued will be processed and encoded as + normal. The client must continue to handle both queues independently, + similarly to normal encode operation. This includes: + + * queuing and dequeuing ``CAPTURE`` buffers, until a buffer marked with the + ``V4L2_BUF_FLAG_LAST`` flag is dequeued, + + .. warning:: + + The last buffer may be empty (with :c:type:`v4l2_buffer` + ``bytesused`` = 0) and in that case it must be ignored by the client, + as it does not contain an encoded frame. + + .. note:: + + Any attempt to dequeue more ``CAPTURE`` buffers beyond the buffer + marked with ``V4L2_BUF_FLAG_LAST`` will result in a -EPIPE error from + :c:func:`VIDIOC_DQBUF`. + + * dequeuing processed ``OUTPUT`` buffers, until all the buffers queued + before the ``V4L2_ENC_CMD_STOP`` command are dequeued, + + * dequeuing the ``V4L2_EVENT_EOS`` event, if the client subscribes to it. + + .. note:: + + For backwards compatibility, the encoder will signal a ``V4L2_EVENT_EOS`` + event when the last frame has been encoded and all frames are ready to be + dequeued. It is deprecated behavior and the client must not rely on it. + The ``V4L2_BUF_FLAG_LAST`` buffer flag should be used instead. + +3. Once all ``OUTPUT`` buffers queued before the ``V4L2_ENC_CMD_STOP`` call are + dequeued and the last ``CAPTURE`` buffer is dequeued, the encoder is stopped + and it will accept, but not process any newly queued ``OUTPUT`` buffers + until the client issues any of the following operations: + + * ``V4L2_ENC_CMD_START`` - the encoder will not be reset and will resume + operation normally, with all the state from before the drain, + + * a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the + ``CAPTURE`` queue - the encoder will be reset (see the `Reset` sequence) + and then resume encoding, + + * a pair of :c:func:`VIDIOC_STREAMOFF` and :c:func:`VIDIOC_STREAMON` on the + ``OUTPUT`` queue - the encoder will resume operation normally, however any + source frames queued to the ``OUTPUT`` queue between ``V4L2_ENC_CMD_STOP`` + and :c:func:`VIDIOC_STREAMOFF` will be discarded. + +.. note:: + + Once the drain sequence is initiated, the client needs to drive it to + completion, as described by the steps above, unless it aborts the process by + issuing :c:func:`VIDIOC_STREAMOFF` on any of the ``OUTPUT`` or ``CAPTURE`` + queues. The client is not allowed to issue ``V4L2_ENC_CMD_START`` or + ``V4L2_ENC_CMD_STOP`` again while the drain sequence is in progress and they + will fail with -EBUSY error code if attempted. + + For reference, handling of various corner cases is described below: + + * In case of no buffer in the ``OUTPUT`` queue at the time the + ``V4L2_ENC_CMD_STOP`` command was issued, the drain sequence completes + immediately and the encoder returns an empty ``CAPTURE`` buffer with the + ``V4L2_BUF_FLAG_LAST`` flag set. + + * In case of no buffer in the ``CAPTURE`` queue at the time the drain + sequence completes, the next time the client queues a ``CAPTURE`` buffer + it is returned at once as an empty buffer with the ``V4L2_BUF_FLAG_LAST`` + flag set. + + * If :c:func:`VIDIOC_STREAMOFF` is called on the ``CAPTURE`` queue in the + middle of the drain sequence, the drain sequence is canceled and all + ``CAPTURE`` buffers are implicitly returned to the client. + + * If :c:func:`VIDIOC_STREAMOFF` is called on the ``OUTPUT`` queue in the + middle of the drain sequence, the drain sequence completes immediately and + next ``CAPTURE`` buffer will be returned empty with the + ``V4L2_BUF_FLAG_LAST`` flag set. + + Although not mandatory, the availability of encoder commands may be queried + using :c:func:`VIDIOC_TRY_ENCODER_CMD`. + +Reset +===== + +The client may want to request the encoder to reinitialize the encoding, so +that the following stream data becomes independent from the stream data +generated before. Depending on the coded format, that may imply that: + +* encoded frames produced after the restart must not reference any frames + produced before the stop, e.g. no long term references for H.264/HEVC, + +* any headers that must be included in a standalone stream must be produced + again, e.g. SPS and PPS for H.264/HEVC. + +This can be achieved by performing the reset sequence. + +1. Perform the `Drain` sequence to ensure all the in-flight encoding finishes + and respective buffers are dequeued. + +2. Stop streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMOFF`. This + will return all currently queued ``CAPTURE`` buffers to the client, without + valid frame data. + +3. Start streaming on the ``CAPTURE`` queue via :c:func:`VIDIOC_STREAMON` and + continue with regular encoding sequence. The encoded frames produced into + ``CAPTURE`` buffers from now on will contain a standalone stream that can be + decoded without the need for frames encoded before the reset sequence, + starting at the first ``OUTPUT`` buffer queued after issuing the + `V4L2_ENC_CMD_STOP` of the `Drain` sequence. + +This sequence may be also used to change encoding parameters for encoders +without the ability to change the parameters on the fly. + +Commit Points +============= + +Setting formats and allocating buffers triggers changes in the behavior of the +encoder. + +1. Setting the format on the ``CAPTURE`` queue may change the set of formats + supported/advertised on the ``OUTPUT`` queue. In particular, it also means + that the ``OUTPUT`` format may be reset and the client must not rely on the + previously set format being preserved. + +2. Enumerating formats on the ``OUTPUT`` queue always returns only formats + supported for the current ``CAPTURE`` format. + +3. Setting the format on the ``OUTPUT`` queue does not change the list of + formats available on the ``CAPTURE`` queue. An attempt to set the ``OUTPUT`` + format that is not supported for the currently selected ``CAPTURE`` format + will result in the encoder adjusting the requested ``OUTPUT`` format to a + supported one. + +4. Enumerating formats on the ``CAPTURE`` queue always returns the full set of + supported coded formats, irrespective of the current ``OUTPUT`` format. + +5. While buffers are allocated on any of the ``OUTPUT`` or ``CAPTURE`` queues, + the client must not change the format on the ``CAPTURE`` queue. Drivers will + return the -EBUSY error code for any such format change attempt. + +To summarize, setting formats and allocation must always start with the +``CAPTURE`` queue and the ``CAPTURE`` queue is the master that governs the +set of supported formats for the ``OUTPUT`` queue. diff --git a/Documentation/userspace-api/media/v4l/dev-mem2mem.rst b/Documentation/userspace-api/media/v4l/dev-mem2mem.rst index 9279d87c08a1..40aff9c95267 100644 --- a/Documentation/userspace-api/media/v4l/dev-mem2mem.rst +++ b/Documentation/userspace-api/media/v4l/dev-mem2mem.rst @@ -46,4 +46,5 @@ devices are given in the following sections. :maxdepth: 1 dev-decoder + dev-encoder dev-stateless-decoder diff --git a/Documentation/userspace-api/media/v4l/dev-osd.rst b/Documentation/userspace-api/media/v4l/dev-osd.rst index 67dc46373a91..ad0c156c7898 100644 --- a/Documentation/userspace-api/media/v4l/dev-osd.rst +++ b/Documentation/userspace-api/media/v4l/dev-osd.rst @@ -51,7 +51,7 @@ other information, the physical address of the framebuffer in the ``base`` field of struct :c:type:`v4l2_framebuffer`. The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same address in the ``smem_start`` field of struct -struct :c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO`` +:c:type:`fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO`` ioctl and struct :c:type:`fb_fix_screeninfo` are defined in the ``linux/fb.h`` header file. diff --git a/Documentation/userspace-api/media/v4l/dev-sdr.rst b/Documentation/userspace-api/media/v4l/dev-sdr.rst index c9563bca444e..4a80319a53c6 100644 --- a/Documentation/userspace-api/media/v4l/dev-sdr.rst +++ b/Documentation/userspace-api/media/v4l/dev-sdr.rst @@ -78,7 +78,7 @@ field of a struct :c:type:`v4l2_format` to ``V4L2_BUF_TYPE_SDR_CAPTURE`` or ``V4L2_BUF_TYPE_SDR_OUTPUT`` and use the struct :c:type:`v4l2_sdr_format` ``sdr`` member of the ``fmt`` union as needed per the desired operation. Currently -there is two fields, ``pixelformat`` and ``buffersize``, of struct +there are two fields, ``pixelformat`` and ``buffersize``, of struct :c:type:`v4l2_sdr_format` which are used. Content of the ``pixelformat`` is V4L2 FourCC code of the data format. The ``buffersize`` field is maximum buffer size in bytes required for diff --git a/Documentation/userspace-api/media/v4l/hist-v4l2.rst b/Documentation/userspace-api/media/v4l/hist-v4l2.rst index 7913d017cd33..6dcfe6046e33 100644 --- a/Documentation/userspace-api/media/v4l/hist-v4l2.rst +++ b/Documentation/userspace-api/media/v4l/hist-v4l2.rst @@ -43,7 +43,7 @@ transmission arguments. 1998-09-28: Revamped video standard. Made video controls individually enumerable. -1998-10-02: The ``id`` field was removed from struct +1998-10-02: The ``id`` field was removed from struct ``video_standard`` and the color subcarrier fields were renamed. The :ref:`VIDIOC_QUERYSTD` ioctl was renamed to :ref:`VIDIOC_ENUMSTD`, @@ -260,7 +260,7 @@ multiple tuners into account.) 2000-09-18: ``V4L2_BUF_TYPE_VBI`` was added. This may *break compatibility* as the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and -:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the struct +:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls may fail now if the struct ``v4l2_fmt`` ``type`` field does not contain ``V4L2_BUF_TYPE_VBI``. In the documentation of the struct :c:type:`v4l2_vbi_format` ``offset`` field the diff --git a/Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst b/Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst index ec1239ada316..e2f5a2b36092 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-srggb14p.rst @@ -69,37 +69,37 @@ Each cell is one byte. B\ :sub:`00low bits 5--0`\ (bits 5--0) - - R\ :sub:`02low bits 3--0`\ (bits 7--4) + - B\ :sub:`02low bits 3--0`\ (bits 7--4) G\ :sub:`01low bits 5--2`\ (bits 3--0) - G\ :sub:`03low bits 5--0`\ (bits 7--2) - R\ :sub:`02low bits 5--4`\ (bits 1--0) + B\ :sub:`02low bits 5--4`\ (bits 1--0) - .. row 2 - start + 7 - - G\ :sub:`00high` + - G\ :sub:`10high` - - R\ :sub:`01high` + - R\ :sub:`11high` - - G\ :sub:`02high` + - G\ :sub:`12high` - - R\ :sub:`03high` + - R\ :sub:`13high` - - R\ :sub:`01low bits 1--0`\ (bits 7--6) + - R\ :sub:`11low bits 1--0`\ (bits 7--6) - G\ :sub:`00low bits 5--0`\ (bits 5--0) + G\ :sub:`10low bits 5--0`\ (bits 5--0) - - G\ :sub:`02low bits 3--0`\ (bits 7--4) + - G\ :sub:`12low bits 3--0`\ (bits 7--4) - R\ :sub:`01low bits 5--2`\ (bits 3--0) + R\ :sub:`11low bits 5--2`\ (bits 3--0) - - R\ :sub:`03low bits 5--0`\ (bits 7--2) + - R\ :sub:`13low bits 5--0`\ (bits 7--2) - G\ :sub:`02low bits 5--4`\ (bits 1--0) + G\ :sub:`12low bits 5--4`\ (bits 1--0) - .. row 3 @@ -117,13 +117,13 @@ Each cell is one byte. B\ :sub:`20low bits 5--0`\ (bits 5--0) - - R\ :sub:`22low bits 3--0`\ (bits 7--4) + - B\ :sub:`22low bits 3--0`\ (bits 7--4) G\ :sub:`21low bits 5--2`\ (bits 3--0) - G\ :sub:`23low bits 5--0`\ (bits 7--2) - R\ :sub:`22low bits 5--4`\ (bits 1--0) + B\ :sub:`22low bits 5--4`\ (bits 1--0) - .. row 4 diff --git a/Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst b/Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst index 759420a872d6..e0ee2823ab1f 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-v4l2.rst @@ -44,6 +44,11 @@ Single-planar format structure inside the stream, when fed to a stateful mem2mem decoder, the fields may be zero to rely on the decoder to detect the right values. For more details see :ref:`decoder` and format descriptions. + + For compressed formats on the CAPTURE side of a stateful mem2mem + encoder, the fields must be zero, since the coded size is expected to + be calculated internally by the encoder itself, based on the OUTPUT + side. For more details see :ref:`encoder` and format descriptions. * - __u32 - ``pixelformat`` - The pixel format or type of compression, set by the application. diff --git a/Documentation/userspace-api/media/v4l/v4l2.rst b/Documentation/userspace-api/media/v4l/v4l2.rst index ab7c97c39b97..35796c4fbe52 100644 --- a/Documentation/userspace-api/media/v4l/v4l2.rst +++ b/Documentation/userspace-api/media/v4l/v4l2.rst @@ -63,6 +63,7 @@ Authors, in alphabetical order: - Figa, Tomasz <tfiga@chromium.org> - Documented the memory-to-memory decoder interface. + - Documented the memory-to-memory encoder interface. - H Schimek, Michael <mschimek@gmx.at> @@ -75,6 +76,7 @@ Authors, in alphabetical order: - Osciak, Pawel <posciak@chromium.org> - Documented the memory-to-memory decoder interface. + - Documented the memory-to-memory encoder interface. - Osciak, Pawel <pawel@osciak.com> diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst index e1afc5b504c2..f2a702870fad 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst @@ -121,7 +121,12 @@ than the number requested. other changes, then set ``count`` to 0, ``memory`` to ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type. * - __u32 - - ``reserved``\ [7] + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. + + * - __u32 + - ``reserved``\ [6] - A place holder for future extensions. Drivers and applications must set the array to zero. diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst index a9a176d5256d..9412be0c3747 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst @@ -260,7 +260,7 @@ call. :ref:`v4l2_queryctrl <v4l2-queryctrl>`. * - __s32 - ``default_value`` - - The default value value of the control. See struct + - The default value of the control. See struct :ref:`v4l2_queryctrl <v4l2-queryctrl>`. diff --git a/Documentation/userspace-api/media/v4l/vidioc-encoder-cmd.rst b/Documentation/userspace-api/media/v4l/vidioc-encoder-cmd.rst index 16269b3b1715..d0eacce5485e 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-encoder-cmd.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-encoder-cmd.rst @@ -51,25 +51,26 @@ To send a command applications must initialize all fields of a struct ``VIDIOC_ENCODER_CMD`` or ``VIDIOC_TRY_ENCODER_CMD`` with a pointer to this structure. -The ``cmd`` field must contain the command code. The ``flags`` field is -currently only used by the STOP command and contains one bit: If the -``V4L2_ENC_CMD_STOP_AT_GOP_END`` flag is set, encoding will continue -until the end of the current *Group Of Pictures*, otherwise it will stop -immediately. +The ``cmd`` field must contain the command code. Some commands use the +``flags`` field for additional information. -A :ref:`read() <func-read>` or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` -call sends an implicit START command to the encoder if it has not been -started yet. After a STOP command, :ref:`read() <func-read>` calls will read +After a STOP command, :ref:`read() <func-read>` calls will read the remaining data buffered by the driver. When the buffer is empty, :ref:`read() <func-read>` will return zero and the next :ref:`read() <func-read>` call will restart the encoder. +A :ref:`read() <func-read>` or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` +call sends an implicit START command to the encoder if it has not been +started yet. Applies to both queues of mem2mem encoders. + A :ref:`close() <func-close>` or :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` call of a streaming file descriptor sends an implicit immediate STOP to -the encoder, and all buffered data is discarded. +the encoder, and all buffered data is discarded. Applies to both queues of +mem2mem encoders. These ioctls are optional, not all drivers may support them. They were -introduced in Linux 2.6.21. +introduced in Linux 2.6.21. They are, however, mandatory for stateful mem2mem +encoders (as further documented in :ref:`encoder`). .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}| @@ -109,21 +110,24 @@ introduced in Linux 2.6.21. - 0 - Start the encoder. When the encoder is already running or paused, this command does nothing. No flags are defined for this command. + + For a device implementing the :ref:`encoder`, once the drain sequence + is initiated with the ``V4L2_ENC_CMD_STOP`` command, it must be driven + to completion before this command can be invoked. Any attempt to + invoke the command while the drain sequence is in progress will trigger + an ``EBUSY`` error code. See :ref:`encoder` for more details. * - ``V4L2_ENC_CMD_STOP`` - 1 - Stop the encoder. When the ``V4L2_ENC_CMD_STOP_AT_GOP_END`` flag is set, encoding will continue until the end of the current *Group Of Pictures*, otherwise encoding will stop immediately. When the - encoder is already stopped, this command does nothing. mem2mem - encoders will send a ``V4L2_EVENT_EOS`` event when the last frame - has been encoded and all frames are ready to be dequeued and will - set the ``V4L2_BUF_FLAG_LAST`` buffer flag on the last buffer of - the capture queue to indicate there will be no new buffers - produced to dequeue. This buffer may be empty, indicated by the - driver setting the ``bytesused`` field to 0. Once the - ``V4L2_BUF_FLAG_LAST`` flag was set, the - :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore, - but return an ``EPIPE`` error code. + encoder is already stopped, this command does nothing. + + For a device implementing the :ref:`encoder`, the command will initiate + the drain sequence as documented in :ref:`encoder`. No flags or other + arguments are accepted in this case. Any attempt to invoke the command + again before the sequence completes will trigger an ``EBUSY`` error + code. * - ``V4L2_ENC_CMD_PAUSE`` - 2 - Pause the encoder. When the encoder has not been started yet, the @@ -152,6 +156,8 @@ introduced in Linux 2.6.21. - Stop encoding at the end of the current *Group Of Pictures*, rather than immediately. + Does not apply to :ref:`encoder`. + Return Value ============ @@ -160,6 +166,11 @@ On success 0 is returned, on error -1 and the ``errno`` variable is set appropriately. The generic error codes are described at the :ref:`Generic Error Codes <gen-errors>` chapter. +EBUSY + A drain sequence of a device implementing the :ref:`encoder` is still in + progress. It is not allowed to issue another encoder command until it + completes. + EINVAL The ``cmd`` field is invalid. diff --git a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst index a53dd3d7f7e2..05835e04c20b 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst @@ -167,17 +167,37 @@ the ``mbus_code`` field is handled differently: - The hardware decoder for this compressed bytestream format (aka coded format) is capable of parsing a continuous bytestream. Applications do not need to parse the bytestream themselves to find the boundaries - between frames/fields. This flag can only be used in combination with - the ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to compressed + between frames/fields. + + This flag can only be used in combination with the + ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to compressed formats only. This flag is valid for stateful decoders only. * - ``V4L2_FMT_FLAG_DYN_RESOLUTION`` - 0x0008 - Dynamic resolution switching is supported by the device for this compressed bytestream format (aka coded format). It will notify the user via the event ``V4L2_EVENT_SOURCE_CHANGE`` when changes in the video - parameters are detected. This flag can only be used in combination - with the ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to - compressed formats only. It is also only applies to stateful codecs. + parameters are detected. + + This flag can only be used in combination with the + ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to + compressed formats only. This flag is valid for stateful codecs only. + * - ``V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL`` + - 0x0010 + - The hardware encoder supports setting the ``CAPTURE`` coded frame + interval separately from the ``OUTPUT`` raw frame interval. + Setting the ``OUTPUT`` raw frame interval with :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` + also sets the ``CAPTURE`` coded frame interval to the same value. + If this flag is set, then the ``CAPTURE`` coded frame interval can be + set to a different value afterwards. This is typically used for + offline encoding where the ``OUTPUT`` raw frame interval is used as + a hint for reserving hardware encoder resources and the ``CAPTURE`` coded + frame interval is the actual frame rate embedded in the encoded video + stream. + + This flag can only be used in combination with the + ``V4L2_FMT_FLAG_COMPRESSED`` flag, since this applies to + compressed formats only. This flag is valid for stateful encoders only. Return Value diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-parm.rst b/Documentation/userspace-api/media/v4l/vidioc-g-parm.rst index 42e9f6ee7a59..59e02aca164c 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-parm.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-parm.rst @@ -42,12 +42,13 @@ Arguments Description =========== -The current video standard determines a nominal number of frames per -second. If less than this number of frames is to be captured or output, -applications can request frame skipping or duplicating on the driver -side. This is especially useful when using the :ref:`read() <func-read>` or -:ref:`write() <func-write>`, which are not augmented by timestamps or sequence -counters, and to avoid unnecessary data copying. +Applications can request a different frame interval. The capture or +output device will be reconfigured to support the requested frame +interval if possible. Optionally drivers may choose to skip or +repeat frames to achieve the requested frame interval. + +For stateful encoders (see :ref:`encoder`) this represents the +frame interval that is typically embedded in the encoded video stream. Changing the frame interval shall never change the format. Changing the format, on the other hand, may change the frame interval. @@ -57,7 +58,8 @@ internally by a driver in read/write mode. For implications see the section discussing the :ref:`read() <func-read>` function. To get and set the streaming parameters applications call the -:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take a +:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and +:ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take a pointer to a struct :c:type:`v4l2_streamparm` which contains a union holding separate parameters for input and output devices. @@ -113,14 +115,21 @@ union holding separate parameters for input and output devices. * - struct :c:type:`v4l2_fract` - ``timeperframe`` - This is the desired period between successive frames captured by - the driver, in seconds. The field is intended to skip frames on - the driver side, saving I/O bandwidth. + the driver, in seconds. + * - :cspan:`2` + + This will configure the speed at which the video source (e.g. a sensor) + generates video frames. If the speed is fixed, then the driver may + choose to skip or repeat frames in order to achieve the requested + frame rate. + + For stateful encoders (see :ref:`encoder`) this represents the + frame interval that is typically embedded in the encoded video stream. Applications store here the desired frame period, drivers return - the actual frame period, which must be greater or equal to the - nominal frame period determined by the current video standard - (struct :c:type:`v4l2_standard` ``frameperiod`` - field). Changing the video standard (also implicitly by switching + the actual frame period. + + Changing the video standard (also implicitly by switching the video input) may reset this parameter to the nominal frame period. To reset manually applications can just set this field to zero. @@ -173,11 +182,15 @@ union holding separate parameters for input and output devices. :ref:`write() <func-write>` mode (in streaming mode timestamps can be used to throttle the output), saving I/O bandwidth. + For stateful encoders (see :ref:`encoder`) this represents the + frame interval that is typically embedded in the encoded video stream + and it provides a hint to the encoder of the speed at which raw + frames are queued up to the encoder. + Applications store here the desired frame period, drivers return - the actual frame period, which must be greater or equal to the - nominal frame period determined by the current video standard - (struct :c:type:`v4l2_standard` ``frameperiod`` - field). Changing the video standard (also implicitly by switching + the actual frame period. + + Changing the video standard (also implicitly by switching the video output) may reset this parameter to the nominal frame period. To reset manually applications can just set this field to zero. @@ -216,8 +229,8 @@ union holding separate parameters for input and output devices. * - ``V4L2_CAP_TIMEPERFRAME`` - 0x1000 - - The frame skipping/repeating controlled by the ``timeperframe`` - field is supported. + - The frame period can be modified by setting the ``timeperframe`` + field. diff --git a/Documentation/userspace-api/media/v4l/vidioc-querycap.rst b/Documentation/userspace-api/media/v4l/vidioc-querycap.rst index 666ac4d42051..90347367ef06 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-querycap.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-querycap.rst @@ -168,11 +168,11 @@ specification the ioctl returns an ``EINVAL`` error code. - The device supports the :ref:`multi-planar API <planar-apis>` through the :ref:`Video Output <output>` interface. * - ``V4L2_CAP_VIDEO_M2M`` - - 0x00004000 + - 0x00008000 - The device supports the single-planar API through the Video Memory-To-Memory interface. * - ``V4L2_CAP_VIDEO_M2M_MPLANE`` - - 0x00008000 + - 0x00004000 - The device supports the :ref:`multi-planar API <planar-apis>` through the Video Memory-To-Memory interface. * - ``V4L2_CAP_VIDEO_OVERLAY`` diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst index b6d52083707b..75d894d9c36c 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst @@ -112,10 +112,17 @@ aborting or finishing any DMA in progress, an implicit ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will free any previously allocated buffers, so this is typically something that will be done at the start of the application. + * - union { + - (anonymous) + * - __u32 + - ``flags`` + - Specifies additional buffer management attributes. + See :ref:`memory-flags`. * - __u32 - ``reserved``\ [1] - - A place holder for future extensions. Drivers and applications - must set the array to zero. + - Kept for backwards compatibility. Use ``flags`` instead. + * - } + - .. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}| @@ -126,6 +133,7 @@ aborting or finishing any DMA in progress, an implicit .. _V4L2-BUF-CAP-SUPPORTS-REQUESTS: .. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS: .. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF: +.. _V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS: .. cssclass:: longtable @@ -156,6 +164,15 @@ aborting or finishing any DMA in progress, an implicit - Only valid for stateless decoders. If set, then userspace can set the ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning the capture buffer until the OUTPUT timestamp changes. + * - ``V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS`` + - 0x00000040 + - This capability is set by the driver to indicate that the queue supports + cache and memory management hints. However, it's only valid when the + queue is used for :ref:`memory mapping <mmap>` streaming I/O. See + :ref:`V4L2_FLAG_MEMORY_NON_CONSISTENT <V4L2-FLAG-MEMORY-NON-CONSISTENT>`, + :ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE <V4L2-BUF-FLAG-NO-CACHE-INVALIDATE>` and + :ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN <V4L2-BUF-FLAG-NO-CACHE-CLEAN>`. + Return Value ============ diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index a625fb90e3a9..ca05e4e126b2 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -187,6 +187,7 @@ replace define V4L2_FMT_FLAG_COMPRESSED fmtdesc-flags replace define V4L2_FMT_FLAG_EMULATED fmtdesc-flags replace define V4L2_FMT_FLAG_CONTINUOUS_BYTESTREAM fmtdesc-flags replace define V4L2_FMT_FLAG_DYN_RESOLUTION fmtdesc-flags +replace define V4L2_FMT_FLAG_ENC_CAP_FRAME_INTERVAL fmtdesc-flags # V4L2 timecode types replace define V4L2_TC_TYPE_24FPS timecode-type diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index fe05201e17be..eb3a1316f03e 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -669,6 +669,10 @@ MSRs that have been set successfully. Defines the vcpu responses to the cpuid instruction. Applications should use the KVM_SET_CPUID2 ioctl if available. +Note, when this IOCTL fails, KVM gives no guarantees that previous valid CPUID +configuration (if there is) is not corrupted. Userspace can get a copy of the +resulting CPUID configuration through KVM_GET_CPUID2 in case. + :: struct kvm_cpuid_entry { @@ -2156,9 +2160,12 @@ registers, find a list below: PPC KVM_REG_PPC_MMCRA 64 PPC KVM_REG_PPC_MMCR2 64 PPC KVM_REG_PPC_MMCRS 64 + PPC KVM_REG_PPC_MMCR3 64 PPC KVM_REG_PPC_SIAR 64 PPC KVM_REG_PPC_SDAR 64 PPC KVM_REG_PPC_SIER 64 + PPC KVM_REG_PPC_SIER2 64 + PPC KVM_REG_PPC_SIER3 64 PPC KVM_REG_PPC_PMC1 32 PPC KVM_REG_PPC_PMC2 32 PPC KVM_REG_PPC_PMC3 32 @@ -4795,6 +4802,7 @@ hardware_exit_reason. /* KVM_EXIT_FAIL_ENTRY */ struct { __u64 hardware_entry_failure_reason; + __u32 cpu; /* if KVM_LAST_CPU */ } fail_entry; If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/vm/arch_pgtable_helpers.rst new file mode 100644 index 000000000000..f3591ee3aaa8 --- /dev/null +++ b/Documentation/vm/arch_pgtable_helpers.rst @@ -0,0 +1,258 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _arch_page_table_helpers: + +=============================== +Architecture Page Table Helpers +=============================== + +Generic MM expects architectures (with MMU) to provide helpers to create, access +and modify page table entries at various level for different memory functions. +These page table helpers need to conform to a common semantics across platforms. +Following tables describe the expected semantics which can also be tested during +boot via CONFIG_DEBUG_VM_PGTABLE option. All future changes in here or the debug +test need to be in sync. + +====================== +PTE Page Table Helpers +====================== + ++---------------------------+--------------------------------------------------+ +| pte_same | Tests whether both PTE entries are the same | ++---------------------------+--------------------------------------------------+ +| pte_bad | Tests a non-table mapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_present | Tests a valid mapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_young | Tests a young PTE | ++---------------------------+--------------------------------------------------+ +| pte_dirty | Tests a dirty PTE | ++---------------------------+--------------------------------------------------+ +| pte_write | Tests a writable PTE | ++---------------------------+--------------------------------------------------+ +| pte_special | Tests a special PTE | ++---------------------------+--------------------------------------------------+ +| pte_protnone | Tests a PROT_NONE PTE | ++---------------------------+--------------------------------------------------+ +| pte_devmap | Tests a ZONE_DEVICE mapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_soft_dirty | Tests a soft dirty PTE | ++---------------------------+--------------------------------------------------+ +| pte_swp_soft_dirty | Tests a soft dirty swapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkyoung | Creates a young PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkold | Creates an old PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkdirty | Creates a dirty PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkclean | Creates a clean PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkwrite | Creates a writable PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkwrprotect | Creates a write protected PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkspecial | Creates a special PTE | ++---------------------------+--------------------------------------------------+ +| pte_mkdevmap | Creates a ZONE_DEVICE mapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_mksoft_dirty | Creates a soft dirty PTE | ++---------------------------+--------------------------------------------------+ +| pte_clear_soft_dirty | Clears a soft dirty PTE | ++---------------------------+--------------------------------------------------+ +| pte_swp_mksoft_dirty | Creates a soft dirty swapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_swp_clear_soft_dirty | Clears a soft dirty swapped PTE | ++---------------------------+--------------------------------------------------+ +| pte_mknotpresent | Invalidates a mapped PTE | ++---------------------------+--------------------------------------------------+ +| ptep_get_and_clear | Clears a PTE | ++---------------------------+--------------------------------------------------+ +| ptep_get_and_clear_full | Clears a PTE | ++---------------------------+--------------------------------------------------+ +| ptep_test_and_clear_young | Clears young from a PTE | ++---------------------------+--------------------------------------------------+ +| ptep_set_wrprotect | Converts into a write protected PTE | ++---------------------------+--------------------------------------------------+ +| ptep_set_access_flags | Converts into a more permissive PTE | ++---------------------------+--------------------------------------------------+ + +====================== +PMD Page Table Helpers +====================== + ++---------------------------+--------------------------------------------------+ +| pmd_same | Tests whether both PMD entries are the same | ++---------------------------+--------------------------------------------------+ +| pmd_bad | Tests a non-table mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_leaf | Tests a leaf mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_huge | Tests a HugeTLB mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_trans_huge | Tests a Transparent Huge Page (THP) at PMD | ++---------------------------+--------------------------------------------------+ +| pmd_present | Tests a valid mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_young | Tests a young PMD | ++---------------------------+--------------------------------------------------+ +| pmd_dirty | Tests a dirty PMD | ++---------------------------+--------------------------------------------------+ +| pmd_write | Tests a writable PMD | ++---------------------------+--------------------------------------------------+ +| pmd_special | Tests a special PMD | ++---------------------------+--------------------------------------------------+ +| pmd_protnone | Tests a PROT_NONE PMD | ++---------------------------+--------------------------------------------------+ +| pmd_devmap | Tests a ZONE_DEVICE mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_soft_dirty | Tests a soft dirty PMD | ++---------------------------+--------------------------------------------------+ +| pmd_swp_soft_dirty | Tests a soft dirty swapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkyoung | Creates a young PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkold | Creates an old PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkdirty | Creates a dirty PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkclean | Creates a clean PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkwrite | Creates a writable PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkwrprotect | Creates a write protected PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkspecial | Creates a special PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkdevmap | Creates a ZONE_DEVICE mapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mksoft_dirty | Creates a soft dirty PMD | ++---------------------------+--------------------------------------------------+ +| pmd_clear_soft_dirty | Clears a soft dirty PMD | ++---------------------------+--------------------------------------------------+ +| pmd_swp_mksoft_dirty | Creates a soft dirty swapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_swp_clear_soft_dirty | Clears a soft dirty swapped PMD | ++---------------------------+--------------------------------------------------+ +| pmd_mkinvalid | Invalidates a mapped PMD [1] | ++---------------------------+--------------------------------------------------+ +| pmd_set_huge | Creates a PMD huge mapping | ++---------------------------+--------------------------------------------------+ +| pmd_clear_huge | Clears a PMD huge mapping | ++---------------------------+--------------------------------------------------+ +| pmdp_get_and_clear | Clears a PMD | ++---------------------------+--------------------------------------------------+ +| pmdp_get_and_clear_full | Clears a PMD | ++---------------------------+--------------------------------------------------+ +| pmdp_test_and_clear_young | Clears young from a PMD | ++---------------------------+--------------------------------------------------+ +| pmdp_set_wrprotect | Converts into a write protected PMD | ++---------------------------+--------------------------------------------------+ +| pmdp_set_access_flags | Converts into a more permissive PMD | ++---------------------------+--------------------------------------------------+ + +====================== +PUD Page Table Helpers +====================== + ++---------------------------+--------------------------------------------------+ +| pud_same | Tests whether both PUD entries are the same | ++---------------------------+--------------------------------------------------+ +| pud_bad | Tests a non-table mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_leaf | Tests a leaf mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_huge | Tests a HugeTLB mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_trans_huge | Tests a Transparent Huge Page (THP) at PUD | ++---------------------------+--------------------------------------------------+ +| pud_present | Tests a valid mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_young | Tests a young PUD | ++---------------------------+--------------------------------------------------+ +| pud_dirty | Tests a dirty PUD | ++---------------------------+--------------------------------------------------+ +| pud_write | Tests a writable PUD | ++---------------------------+--------------------------------------------------+ +| pud_devmap | Tests a ZONE_DEVICE mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkyoung | Creates a young PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkold | Creates an old PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkdirty | Creates a dirty PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkclean | Creates a clean PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkwrite | Creates a writable PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkwrprotect | Creates a write protected PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD | ++---------------------------+--------------------------------------------------+ +| pud_mkinvalid | Invalidates a mapped PUD [1] | ++---------------------------+--------------------------------------------------+ +| pud_set_huge | Creates a PUD huge mapping | ++---------------------------+--------------------------------------------------+ +| pud_clear_huge | Clears a PUD huge mapping | ++---------------------------+--------------------------------------------------+ +| pudp_get_and_clear | Clears a PUD | ++---------------------------+--------------------------------------------------+ +| pudp_get_and_clear_full | Clears a PUD | ++---------------------------+--------------------------------------------------+ +| pudp_test_and_clear_young | Clears young from a PUD | ++---------------------------+--------------------------------------------------+ +| pudp_set_wrprotect | Converts into a write protected PUD | ++---------------------------+--------------------------------------------------+ +| pudp_set_access_flags | Converts into a more permissive PUD | ++---------------------------+--------------------------------------------------+ + +========================== +HugeTLB Page Table Helpers +========================== + ++---------------------------+--------------------------------------------------+ +| pte_huge | Tests a HugeTLB | ++---------------------------+--------------------------------------------------+ +| pte_mkhuge | Creates a HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_pte_dirty | Tests a dirty HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_pte_write | Tests a writable HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_pte_mkdirty | Creates a dirty HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_pte_mkwrite | Creates a writable HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_pte_mkwrprotect | Creates a write protected HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_ptep_get_and_clear | Clears a HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_ptep_set_wrprotect | Converts into a write protected HugeTLB | ++---------------------------+--------------------------------------------------+ +| huge_ptep_set_access_flags | Converts into a more permissive HugeTLB | ++---------------------------+--------------------------------------------------+ + +======================== +SWAP Page Table Helpers +======================== + ++---------------------------+--------------------------------------------------+ +| __pte_to_swp_entry | Creates a swapped entry (arch) from a mapped PTE | ++---------------------------+--------------------------------------------------+ +| __swp_to_pte_entry | Creates a mapped PTE from a swapped entry (arch) | ++---------------------------+--------------------------------------------------+ +| __pmd_to_swp_entry | Creates a swapped entry (arch) from a mapped PMD | ++---------------------------+--------------------------------------------------+ +| __swp_to_pmd_entry | Creates a mapped PMD from a swapped entry (arch) | ++---------------------------+--------------------------------------------------+ +| is_migration_entry | Tests a migration (read or write) swapped entry | ++---------------------------+--------------------------------------------------+ +| is_write_migration_entry | Tests a write migration swapped entry | ++---------------------------+--------------------------------------------------+ +| make_migration_entry_read | Converts into read migration swapped entry | ++---------------------------+--------------------------------------------------+ +| make_migration_entry | Creates a migration swapped entry (read or write)| ++---------------------------+--------------------------------------------------+ + +[1] https://lore.kernel.org/linux-mm/20181017020930.GN30832@redhat.com/ diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index cc65bc85d260..769449734573 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -141,11 +141,8 @@ sections: `mem_section` objects and the number of rows is calculated to fit all the memory sections. -The architecture setup code should call :c:func:`memory_present` for -each active memory range or use :c:func:`memblocks_present` or -:c:func:`sparse_memory_present_with_active_regions` wrappers to -initialize the memory sections. Next, the actual memory maps should be -set up using :c:func:`sparse_init`. +The architecture setup code should call sparse_init() to +initialize the memory sections and the memory maps. With SPARSEMEM there are two possible ways to convert a PFN to the corresponding `struct page` - a "classic sparse" and "sparse @@ -178,7 +175,7 @@ for persistent memory devices in pre-allocated storage on those devices. This storage is represented with :c:type:`struct vmem_altmap` that is eventually passed to vmemmap_populate() through a long chain of function calls. The vmemmap_populate() implementation may use the -`vmem_altmap` along with :c:func:`altmap_alloc_block_buf` helper to +`vmem_altmap` along with :c:func:`vmemmap_alloc_block_buf` helper to allocate memory map on the persistent memory device. ZONE_DEVICE diff --git a/Documentation/vm/page_migration.rst b/Documentation/vm/page_migration.rst index 1d6cd7db4e43..68883ac485fa 100644 --- a/Documentation/vm/page_migration.rst +++ b/Documentation/vm/page_migration.rst @@ -253,5 +253,32 @@ which are function pointers of struct address_space_operations. PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag for own purpose. +Monitoring Migration +===================== + +The following events (counters) can be used to monitor page migration. + +1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means that a + page was migrated. If the page was a non-THP page, then this counter is + increased by one. If the page was a THP, then this counter is increased by + the number of THP subpages. For example, migration of a single 2MB THP that + has 4KB-size base pages (subpages) will cause this counter to increase by + 512. + +2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules as for + _SUCCESS, above: this will be increased by the number of subpages, if it was + a THP. + +3. THP_MIGRATION_SUCCESS: A THP was migrated without being split. + +4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split. + +5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had + to be split. After splitting, a migration retry was used for it's sub-pages. + +THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or +PGMIGRATE_FAIL events. For example, a THP migration failure will cause both +THP_MIGRATION_FAIL and PGMIGRATE_FAIL to increase. + Christoph Lameter, May 8, 2006. Minchan Kim, Mar 28, 2016. diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst index 4eee598555c9..289d231cee97 100644 --- a/Documentation/vm/slub.rst +++ b/Documentation/vm/slub.rst @@ -41,6 +41,11 @@ slub_debug=<Debug-Options>,<slab name1>,<slab name2>,... Enable options only for select slabs (no spaces after a comma) +Multiple blocks of options for all slabs or selected slabs can be given, with +blocks of options delimited by ';'. The last of "all slabs" blocks is applied +to all slabs except those that match one of the "select slabs" block. Options +of the first "select slabs" blocks that matches the slab's name are applied. + Possible debug options are:: F Sanity checks on (enables SLAB_DEBUG_CONSISTENCY_CHECKS @@ -83,17 +88,33 @@ switch off debugging for such caches by default, use:: slub_debug=O -In case you forgot to enable debugging on the kernel command line: It is -possible to enable debugging manually when the kernel is up. Look at the -contents of:: +You can apply different options to different list of slab names, using blocks +of options. This will enable red zoning for dentry and user tracking for +kmalloc. All other slabs will not get any debugging enabled:: + + slub_debug=Z,dentry;U,kmalloc-* + +You can also enable options (e.g. sanity checks and poisoning) for all caches +except some that are deemed too performance critical and don't need to be +debugged by specifying global debug options followed by a list of slab names +with "-" as options:: + + slub_debug=FZ;-,zs_handle,zspage + +The state of each debug option for a slab can be found in the respective files +under:: /sys/kernel/slab/<slab name>/ -Look at the writable files. Writing 1 to them will enable the -corresponding debug option. All options can be set on a slab that does -not contain objects. If the slab already contains objects then sanity checks -and tracing may only be enabled. The other options may cause the realignment -of objects. +If the file contains 1, the option is enabled, 0 means disabled. The debug +options from the ``slub_debug`` parameter translate to the following files:: + + F sanity_checks + Z red_zone + P poison + U store_user + T trace + A failslab Careful with tracing: It may spew out lots of information and never stop if used on the wrong slab. diff --git a/Documentation/watchdog/mlx-wdt.rst b/Documentation/watchdog/mlx-wdt.rst index bf5bafac47f0..35e690dea9db 100644 --- a/Documentation/watchdog/mlx-wdt.rst +++ b/Documentation/watchdog/mlx-wdt.rst @@ -24,10 +24,19 @@ Type 2: Maximum timeout is 255 sec. Get time-left is supported. +Type 3: + Same as Type 2 with extended maximum timeout period. + Maximum timeout is 65535 sec. + Type 1 HW watchdog implementation exist in old systems and all new systems have type 2 HW watchdog. Two types of HW implementation have also different register map. +Type 3 HW watchdog implementation can exist on all Mellanox systems +with new programmer logic device. +It's differentiated by WD capability bit. +Old systems still have only one main watchdog. + Mellanox system can have 2 watchdogs: main and auxiliary. Main and auxiliary watchdog devices can be enabled together on the same system. @@ -54,3 +63,4 @@ The driver checks during initialization if the previous system reset was done by the watchdog. If yes, it makes a notification about this event. Access to HW registers is performed through a generic regmap interface. +Programmable logic device registers have little-endian order. diff --git a/Documentation/watchdog/watchdog-api.rst b/Documentation/watchdog/watchdog-api.rst index c6c1e9fa9f73..800dcd7586f2 100644 --- a/Documentation/watchdog/watchdog-api.rst +++ b/Documentation/watchdog/watchdog-api.rst @@ -168,7 +168,7 @@ the fields returned in the ident struct are: the options field can have the following bits set, and describes what kind of information that the GET_STATUS and GET_BOOT_STATUS ioctls can -return. [FIXME -- Is this correct?] +return. ================ ========================= WDIOF_OVERHEAT Reset due to CPU overheat diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst index 068a55ee0d4a..baf44e986b07 100644 --- a/Documentation/watchdog/watchdog-kernel-api.rst +++ b/Documentation/watchdog/watchdog-kernel-api.rst @@ -336,3 +336,15 @@ an action is taken by a preconfigured pretimeout governor preassigned to the watchdog device. If watchdog pretimeout governor framework is not enabled, watchdog_notify_pretimeout() prints a notification message to the kernel log buffer. + +To set the last known HW keepalive time for a watchdog, the following function +should be used:: + + int watchdog_set_last_hw_keepalive(struct watchdog_device *wdd, + unsigned int last_ping_ms) + +This function must be called immediately after watchdog registration. It +sets the last known hardware heartbeat to have happened last_ping_ms before +current time. Calling this is only needed if the watchdog is already running +when probe is called, and the watchdog can only be pinged after the +min_hw_heartbeat_ms time has passed from the last ping. |