diff options
Diffstat (limited to 'Documentation')
691 files changed, 20444 insertions, 6460 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-block b/Documentation/ABI/testing/sysfs-block index ed8c14f161ee..2322eb748b38 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -273,6 +273,24 @@ Description: device ("host-aware" or "host-managed" zone model). For regular block devices, the value is always 0. +What: /sys/block/<disk>/queue/max_active_zones +Date: July 2020 +Contact: Niklas Cassel <niklas.cassel@wdc.com> +Description: + For zoned block devices (zoned attribute indicating + "host-managed" or "host-aware"), the sum of zones belonging to + any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED, + is limited by this value. If this value is 0, there is no limit. + +What: /sys/block/<disk>/queue/max_open_zones +Date: July 2020 +Contact: Niklas Cassel <niklas.cassel@wdc.com> +Description: + For zoned block devices (zoned attribute indicating + "host-managed" or "host-aware"), the sum of zones belonging to + any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, + is limited by this value. If this value is 0, there is no limit. + What: /sys/block/<disk>/queue/chunk_sectors Date: September 2016 Contact: Hannes Reinecke <hare@suse.com> 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-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform index 5172a6124b27..194ca700e962 100644 --- a/Documentation/ABI/testing/sysfs-bus-platform +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -18,3 +18,13 @@ Description: devices to opt-out of driver binding using a driver_override name such as "none". Only a single driver may be specified in the override, there is no support for parsing delimiters. + +What: /sys/bus/platform/devices/.../numa_node +Date: June 2020 +Contact: Barry Song <song.bao.hua@hisilicon.com> +Description: + This file contains the NUMA node to which the platform device + is attached. It won't be visible if the node is unknown. The + value comes from an ACPI _PXM method or a similar firmware + source. Initial users for this file would be devices like + arm smmu which are populated by arm64 acpi_iort. diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 82e80de78dd0..dd565c378b40 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -178,11 +178,18 @@ KernelVersion: 4.13 Contact: thunderbolt-software@lists.01.org Description: When new NVM image is written to the non-active NVM area (through non_activeX NVMem device), the - authentication procedure is started by writing 1 to - this file. If everything goes well, the device is + authentication procedure is started by writing to + this file. + If everything goes well, the device is restarted with the new NVM firmware. If the image verification fails an error code is returned instead. + This file will accept writing values "1" or "2" + - Writing "1" will flush the image to the storage + area and authenticate the image in one action. + - Writing "2" will run some basic validation on the image + and flush it to the storage area. + When read holds status of the last authentication operation if an error occurred during the process. This is directly the status value from the DMA configuration @@ -236,3 +243,49 @@ KernelVersion: 4.15 Contact: thunderbolt-software@lists.01.org Description: This contains XDomain service specific settings as bitmask. Format: %x + +What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/device +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: Retimer device identifier read from the hardware. + +What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/nvm_authenticate +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: When new NVM image is written to the non-active NVM + area (through non_activeX NVMem device), the + authentication procedure is started by writing 1 to + this file. If everything goes well, the device is + restarted with the new NVM firmware. If the image + verification fails an error code is returned instead. + + When read holds status of the last authentication + operation if an error occurred during the process. + Format: %x. + +What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/nvm_version +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: Holds retimer NVM version number. Format: %x.%x, major.minor. + +What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/vendor +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mika Westerberg <mika.westerberg@linux.intel.com> +Description: Retimer vendor identifier read from the hardware. + +What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect +Date: Oct 2020 +KernelVersion: v5.9 +Contact: Mario Limonciello <mario.limonciello@dell.com> +Description: For supported devices, automatically authenticate the new Thunderbolt + image when the device is disconnected from the host system. + + This file will accept writing values "1" or "2" + - Writing "1" will flush the image to the storage + area and prepare the device for authentication on disconnect. + - Writing "2" will run some basic validation on the image + and flush it to the storage area. diff --git a/Documentation/ABI/testing/sysfs-class-devlink b/Documentation/ABI/testing/sysfs-class-devlink new file mode 100644 index 000000000000..64791b65c9a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-devlink @@ -0,0 +1,126 @@ +What: /sys/class/devlink/.../ +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + Provide a place in sysfs for the device link objects in the + kernel at any given time. The name of a device link directory, + denoted as ... above, is of the form <supplier>--<consumer> + where <supplier> is the supplier device name and <consumer> is + the consumer device name. + +What: /sys/class/devlink/.../auto_remove_on +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file indicates if the device link will ever be + automatically removed by the driver core when the consumer and + supplier devices themselves are still present. + + This will be one of the following strings: + + 'consumer unbind' + 'supplier unbind' + 'never' + + 'consumer unbind' means the device link will be removed when + the consumer's driver is unbound from the consumer device. + + 'supplier unbind' means the device link will be removed when + the supplier's driver is unbound from the supplier device. + + 'never' means the device link will not be automatically removed + when as long as the supplier and consumer devices themselves + are still present. + +What: /sys/class/devlink/.../consumer +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file is a symlink to the consumer device's sysfs directory. + +What: /sys/class/devlink/.../runtime_pm +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file indicates if the device link has any impact on the + runtime power management behavior of the consumer and supplier + devices. For example: Making sure the supplier doesn't enter + runtime suspend while the consumer is active. + + This will be one of the following strings: + + '0' - Does not affect runtime power management + '1' - Affects runtime power management + +What: /sys/class/devlink/.../status +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file indicates the status of the device link. The status + of a device link is affected by whether the supplier and + consumer devices have been bound to their corresponding + drivers. The status of a device link also affects the binding + and unbinding of the supplier and consumer devices with their + drivers and also affects whether the software state of the + supplier device is synced with the hardware state of the + supplier device after boot up. + See also: sysfs-devices-state_synced. + + This will be one of the following strings: + + 'not tracked' + 'dormant' + 'available' + 'consumer probing' + 'active' + 'supplier unbinding' + 'unknown' + + 'not tracked' means this device link does not track the status + and has no impact on the binding, unbinding and syncing the + hardware and software device state. + + 'dormant' means the supplier and the consumer devices have not + bound to their driver. + + 'available' means the supplier has bound to its driver and is + available to supply resources to the consumer device. + + 'consumer probing' means the consumer device is currently + trying to bind to its driver. + + 'active' means the supplier and consumer devices have both + bound successfully to their drivers. + + 'supplier unbinding' means the supplier devices is currently in + the process of unbinding from its driver. + + 'unknown' means the state of the device link is not any of the + above. If this is ever the value, there's a bug in the kernel. + +What: /sys/class/devlink/.../supplier +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file is a symlink to the supplier device's sysfs directory. + +What: /sys/class/devlink/.../sync_state_only +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + This file indicates if the device link is limited to only + affecting the syncing of the hardware and software state of the + supplier device. + + This will be one of the following strings: + + '0' + '1' - Affects runtime power management + + '0' means the device link can affect other device behaviors + like binding/unbinding, suspend/resume, runtime power + management, etc. + + '1' means the device link will only affect the syncing of + hardware and software state of the supplier device after boot + up and doesn't not affect other behaviors of the devices. diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia new file mode 100644 index 000000000000..795a5de12fc1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia @@ -0,0 +1,14 @@ +What: /sys/class/leds/<led>/device/brightness +Date: July 2020 +KernelVersion: 5.9 +Contact: Marek Behún <marek.behun@nic.cz> +Description: (RW) On the front panel of the Turris Omnia router there is also + a button which can be used to control the intensity of all the + LEDs at once, so that if they are too bright, user can dim them. + + The microcontroller cycles between 8 levels of this global + brightness (from 100% to 0%), but this setting can have any + integer value between 0 and 100. It is therefore convenient to be + able to change this setting from software. + + Format: %i diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor new file mode 100644 index 000000000000..eeeddcbdbbe3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-multicolor @@ -0,0 +1,35 @@ +What: /sys/class/leds/<led>/brightness +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy <dmurphy@ti.com> +Description: read/write + Writing to this file will update all LEDs within the group to a + calculated percentage of what each color LED intensity is set + to. The percentage is calculated for each grouped LED via the + equation below: + + led_brightness = brightness * multi_intensity/max_brightness + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + + The value of the LED is from 0 to + /sys/class/leds/<led>/max_brightness. + +What: /sys/class/leds/<led>/multi_index +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy <dmurphy@ti.com> +Description: read + The multi_index array, when read, will output the LED colors + as an array of strings as they are indexed in the + multi_intensity file. + +What: /sys/class/leds/<led>/multi_intensity +Date: March 2020 +KernelVersion: 5.9 +Contact: Dan Murphy <dmurphy@ti.com> +Description: read/write + This file contains array of integers. Order of components is + described by the multi_index array. The maximum intensity should + not exceed /sys/class/leds/<led>/max_brightness. diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei index e9dc110650ae..5c52372b43cb 100644 --- a/Documentation/ABI/testing/sysfs-class-mei +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -90,3 +90,16 @@ Description: Display trc status register content The ME FW writes Glitch Detection HW (TRC) status information into trc status register for BIOS and OS to monitor fw health. + +What: /sys/class/mei/meiN/kind +Date: Jul 2020 +KernelVersion: 5.8 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: Display kind of the device + + Generic devices are marked as "mei" + while special purpose have their own + names. + Available options: + - mei: generic mei device. + - itouch: itouch (ipts) mei device. 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-devices-consumer b/Documentation/ABI/testing/sysfs-devices-consumer new file mode 100644 index 000000000000..1f06d74d1c3c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-consumer @@ -0,0 +1,8 @@ +What: /sys/devices/.../consumer:<consumer> +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + The /sys/devices/.../consumer:<consumer> are symlinks to device + links where this device is the supplier. <consumer> denotes the + name of the consumer in that device link. There can be zero or + more of these symlinks for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu index ae9af984471a..a8daceb4a956 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu +++ b/Documentation/ABI/testing/sysfs-devices-platform-stratix10-rsu @@ -126,3 +126,39 @@ Description: 1 no action 0 firmware record the notify code defined in b[15:0]. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf0 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong <richard.gong@linux.intel.com> +Description: + (RO) Decision firmware copy 0 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf1 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong <richard.gong@linux.intel.com> +Description: + (RO) Decision firmware copy 1 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf2 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong <richard.gong@linux.intel.com> +Description: + (RO) Decision firmware copy 2 version information. + +What: /sys/devices/platform/stratix10-rsu.0/dcmf3 +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong <richard.gong@linux.intel.com> +Description: + (RO) Decision firmware copy 3 version information. + +What: /sys/devices/platform/stratix10-rsu.0/max_retry +Date: June 2020 +KernelVersion: 5.8 +Contact: Richard Gong <richard.gong@linux.intel.com> +Description: + (RO) max retry parameter is stored in the firmware + decision IO section, as a byte located at offset 0x18c. diff --git a/Documentation/ABI/testing/sysfs-devices-state_synced b/Documentation/ABI/testing/sysfs-devices-state_synced new file mode 100644 index 000000000000..0c922d7d02fc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-state_synced @@ -0,0 +1,24 @@ +What: /sys/devices/.../state_synced +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + The /sys/devices/.../state_synced attribute is only present for + devices whose bus types or driver provides the .sync_state() + callback. The number read from it (0 or 1) reflects the value + of the device's 'state_synced' field. A value of 0 means the + .sync_state() callback hasn't been called yet. A value of 1 + means the .sync_state() callback has been called. + + Generally, if a device has sync_state() support and has some of + the resources it provides enabled at the time the kernel starts + (Eg: enabled by hardware reset or bootloader or anything that + run before the kernel starts), then it'll keep those resources + enabled and in a state that's compatible with the state they + were in at the start of the kernel. The device will stop doing + this only when the sync_state() callback has been called -- + which happens only when all its consumer devices are registered + and have probed successfully. Resources that were left disabled + at the time the kernel starts are not affected or limited in + any way by sync_state() callbacks. + + diff --git a/Documentation/ABI/testing/sysfs-devices-supplier b/Documentation/ABI/testing/sysfs-devices-supplier new file mode 100644 index 000000000000..a919e0db5e90 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-supplier @@ -0,0 +1,8 @@ +What: /sys/devices/.../supplier:<supplier> +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + The /sys/devices/.../supplier:<supplier> are symlinks to device + links where this device is the consumer. <supplier> denotes the + name of the supplier in that device link. There can be zero or + more of these symlinks for a given device. diff --git a/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier b/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier new file mode 100644 index 000000000000..59d073d20db6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-waiting_for_supplier @@ -0,0 +1,17 @@ +What: /sys/devices/.../waiting_for_supplier +Date: May 2020 +Contact: Saravana Kannan <saravanak@google.com> +Description: + The /sys/devices/.../waiting_for_supplier attribute is only + present when fw_devlink kernel command line option is enabled + and is set to something stricter than "permissive". It is + removed once a device probes successfully (because the + information is no longer relevant). The number read from it (0 + or 1) reflects whether the device is waiting for one or more + suppliers to be added and then linked to using device links + before the device can probe. + + A value of 0 means the device is not waiting for any suppliers + to be added before it can probe. A value of 1 means the device + is waiting for one or more suppliers to be added before it can + probe. 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/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 1012bd9305e9..e5a8def45f3f 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -70,10 +70,10 @@ statements via:: nullarbor:~ # cat <debugfs>/dynamic_debug/control # filename:lineno [module]function flags format - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" + net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" + net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" + net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" + net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" ... @@ -93,7 +93,7 @@ the debug statement callsites with any non-default flags:: nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control # filename:lineno [module]function flags format - /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" + net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" Command Language Reference ========================== @@ -156,6 +156,7 @@ against. Possible keywords are::: ``line-range`` cannot contain space, e.g. "1-30" is valid range but "1 - 30" is not. + ``module=foo`` combined keyword=value form is interchangably accepted The meanings of each keyword are: @@ -164,15 +165,18 @@ func of each callsite. Example:: func svc_tcp_accept + func *recv* # in rfcomm, bluetooth, ping, tcp file - The given string is compared against either the full pathname, the - src-root relative pathname, or the basename of the source file of - each callsite. Examples:: + The given string is compared against either the src-root relative + pathname, or the basename of the source file of each callsite. + Examples:: file svcsock.c - file kernel/freezer.c - file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c + file kernel/freezer.c # ie column 1 of control file + file drivers/usb/* # all callsites under it + file inode.c:start_* # parse :tail as a func (above) + file inode.c:1-100 # parse :tail as a line-range (above) module The given string is compared against the module name @@ -182,6 +186,7 @@ module module sunrpc module nfsd + module drm* # both drm, drm_kms_helper format The given string is searched for in the dynamic debug format @@ -251,8 +256,8 @@ the syntax described above, but must not exceed 1023 characters. Your bootloader may impose lower limits. These ``dyndbg`` params are processed just after the ddebug tables are -processed, as part of the arch_initcall. Thus you can enable debug -messages in all code run after this arch_initcall via this boot +processed, as part of the early_initcall. Thus you can enable debug +messages in all code run after this early_initcall via this boot parameter. On an x86 system for example ACPI enablement is a subsys_initcall and:: diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index ff5018b39ed0..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 @@ -832,6 +832,21 @@ useful to also enable the page_owner functionality. on: enable the feature + debugfs= [KNL] This parameter enables what is exposed to userspace + and debugfs internal clients. + Format: { on, no-mount, off } + on: All functions are enabled. + no-mount: + Filesystem is not registered but kernel clients can + access APIs and a crashkernel can be used to read + its content. There is nothing to mount. + off: Filesystem is not registered and clients + get a -EPERM as result when trying to register files + or directories within debugfs. + This is equivalent of the runtime functionality if + debugfs was not enabled in the kernel at all. + Default value is set in build-time with a kernel configuration. + debugpat [X86] Enable PAT debugging decnet.addr= [HW,NET] @@ -901,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. @@ -1408,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 @@ -1795,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. @@ -1803,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" } @@ -1821,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 @@ -1906,7 +1925,7 @@ strict regions from userspace. relaxed - iommu= [x86] + iommu= [X86] off force noforce @@ -1916,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. @@ -2060,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 @@ -2351,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. @@ -3169,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. @@ -3936,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. @@ -3948,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= @@ -4674,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 @@ -5789,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 @@ -5816,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/md.rst b/Documentation/admin-guide/md.rst index d973d469ffc4..cc8781b96b4d 100644 --- a/Documentation/admin-guide/md.rst +++ b/Documentation/admin-guide/md.rst @@ -426,6 +426,10 @@ All md devices contain: The accepted values when writing to this file are ``ppl`` and ``resync``, used to enable and disable PPL. + uuid + This indicates the UUID of the array in the following format: + xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + As component devices are added to an md array, they appear in the ``md`` directory as new directories named:: 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/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index 10c4f0ce2ad0..613cb24c76c7 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -173,8 +173,8 @@ following ``udev`` rule:: ACTION=="add", SUBSYSTEM=="thunderbolt", ATTRS{iommu_dma_protection}=="1", ATTR{authorized}=="0", ATTR{authorized}="1" -Upgrading NVM on Thunderbolt device or host -------------------------------------------- +Upgrading NVM on Thunderbolt device, host or retimer +---------------------------------------------------- Since most of the functionality is handled in firmware running on a host controller or a device, it is important that the firmware can be upgraded to the latest where possible bugs in it have been fixed. @@ -185,9 +185,10 @@ for some machines: `Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_ -Before you upgrade firmware on a device or host, please make sure it is a -suitable upgrade. Failing to do that may render the device (or host) in a -state where it cannot be used properly anymore without special tools! +Before you upgrade firmware on a device, host or retimer, please make +sure it is a suitable upgrade. Failing to do that may render the device +in a state where it cannot be used properly anymore without special +tools! Host NVM upgrade on Apple Macs is not supported. diff --git a/Documentation/arm/arm.rst b/Documentation/arm/arm.rst index 2edc509df92a..99d660fdf73f 100644 --- a/Documentation/arm/arm.rst +++ b/Documentation/arm/arm.rst @@ -184,10 +184,8 @@ Kernel entry (head.S) We group machine (or platform) support code into machine classes. A class typically based around one or more system on a chip devices, and acts as a natural container around the actual implementations. These - classes are given directories - arch/arm/mach-<class> and - arch/arm/mach-<class> - which contain the source files to/include/mach - support the machine class. This directories also contain any machine - specific supporting code. + classes are given directories - arch/arm/mach-<class> - which contain + the source files and include/mach/ to support the machine class. For example, the SA1100 class is based upon the SA1100 and SA1110 SoC devices, and contains the code to support the way the on-board and off- 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/block/queue-sysfs.rst b/Documentation/block/queue-sysfs.rst index 6a8513af9201..f261a5c84170 100644 --- a/Documentation/block/queue-sysfs.rst +++ b/Documentation/block/queue-sysfs.rst @@ -117,6 +117,20 @@ Maximum number of elements in a DMA scatter/gather list with integrity data that will be submitted by the block layer core to the associated block driver. +max_active_zones (RO) +--------------------- +For zoned block devices (zoned attribute indicating "host-managed" or +"host-aware"), the sum of zones belonging to any of the zone states: +EXPLICIT OPEN, IMPLICIT OPEN or CLOSED, is limited by this value. +If this value is 0, there is no limit. + +max_open_zones (RO) +------------------- +For zoned block devices (zoned attribute indicating "host-managed" or +"host-aware"), the sum of zones belonging to any of the zone states: +EXPLICIT OPEN or IMPLICIT OPEN, is limited by this value. +If this value is 0, there is no limit. + max_sectors_kb (RW) ------------------- This is the maximum number of kilobytes that the block layer will allow diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst index 12a246fcf6cb..2df7b067ab93 100644 --- a/Documentation/bpf/bpf_design_QA.rst +++ b/Documentation/bpf/bpf_design_QA.rst @@ -246,17 +246,6 @@ program is loaded the kernel will print warning message, so this helper is only useful for experiments and prototypes. Tracing BPF programs are root only. -Q: bpf_trace_printk() helper warning ------------------------------------- -Q: When bpf_trace_printk() helper is used the kernel prints nasty -warning message. Why is that? - -A: This is done to nudge program authors into better interfaces when -programs need to pass data to user space. Like bpf_perf_event_output() -can be used to efficiently stream data via perf ring buffer. -BPF maps can be used for asynchronous data sharing between kernel -and user space. bpf_trace_printk() should only be used for debugging. - Q: New functionality via kernel modules? ---------------------------------------- Q: Can BPF functionality such as new program or map types, new diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 4d565d202ce3..b5361b8621c9 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -691,6 +691,42 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the beginning of section (``btf_ext_info_sec->sec_name_off``). +4.2 .BTF_ids section +==================== + +The .BTF_ids section encodes BTF ID values that are used within the kernel. + +This section is created during the kernel compilation with the help of +macros defined in ``include/linux/btf_ids.h`` header file. Kernel code can +use them to create lists and sets (sorted lists) of BTF ID values. + +The ``BTF_ID_LIST`` and ``BTF_ID`` macros define unsorted list of BTF ID values, +with following syntax:: + + BTF_ID_LIST(list) + BTF_ID(type1, name1) + BTF_ID(type2, name2) + +resulting in following layout in .BTF_ids section:: + + __BTF_ID__type1__name1__1: + .zero 4 + __BTF_ID__type2__name2__2: + .zero 4 + +The ``u32 list[];`` variable is defined to access the list. + +The ``BTF_ID_UNUSED`` macro defines 4 zero bytes. It's used when we +want to define unused entry in BTF_ID_LIST, like:: + + BTF_ID_LIST(bpf_skb_output_btf_ids) + BTF_ID(struct, sk_buff) + BTF_ID_UNUSED + BTF_ID(struct, task_struct) + +All the BTF ID lists and sets are compiled in the .BTF_ids section and +resolved during the linking phase of kernel build by ``resolve_btfids`` tool. + 5. Using BTF ************ diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 0f60b95e83c4..d46429be334e 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -5,10 +5,10 @@ BPF Documentation This directory contains documentation for the BPF (Berkeley Packet Filter) facility, with a focus on the extended BPF version (eBPF). -This kernel side documentation is still work in progress. The main +This kernel side documentation is still work in progress. The main textual documentation is (for historical reasons) described in -`Documentation/networking/filter.rst`_, which describe both classical -and extended BPF instruction-set. +:ref:`networking-filter`, which describe both classical and extended +BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. @@ -48,6 +48,15 @@ Program types bpf_lsm +Map types +========= + +.. toctree:: + :maxdepth: 1 + + map_cgroup_storage + + Testing and debugging BPF ========================= @@ -67,7 +76,7 @@ Other ringbuf .. Links: -.. _Documentation/networking/filter.rst: ../networking/filter.txt +.. _networking-filter: ../networking/filter.rst .. _man-pages: https://www.kernel.org/doc/man-pages/ -.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html -.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/ +.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html +.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/ diff --git a/Documentation/bpf/map_cgroup_storage.rst b/Documentation/bpf/map_cgroup_storage.rst new file mode 100644 index 000000000000..cab9543017bf --- /dev/null +++ b/Documentation/bpf/map_cgroup_storage.rst @@ -0,0 +1,169 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. Copyright (C) 2020 Google LLC. + +=========================== +BPF_MAP_TYPE_CGROUP_STORAGE +=========================== + +The ``BPF_MAP_TYPE_CGROUP_STORAGE`` map type represents a local fix-sized +storage. It is only available with ``CONFIG_CGROUP_BPF``, and to programs that +attach to cgroups; the programs are made available by the same Kconfig. The +storage is identified by the cgroup the program is attached to. + +The map provide a local storage at the cgroup that the BPF program is attached +to. It provides a faster and simpler access than the general purpose hash +table, which performs a hash table lookups, and requires user to track live +cgroups on their own. + +This document describes the usage and semantics of the +``BPF_MAP_TYPE_CGROUP_STORAGE`` map type. Some of its behaviors was changed in +Linux 5.9 and this document will describe the differences. + +Usage +===== + +The map uses key of type of either ``__u64 cgroup_inode_id`` or +``struct bpf_cgroup_storage_key``, declared in ``linux/bpf.h``:: + + struct bpf_cgroup_storage_key { + __u64 cgroup_inode_id; + __u32 attach_type; + }; + +``cgroup_inode_id`` is the inode id of the cgroup directory. +``attach_type`` is the the program's attach type. + +Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key type. +When this key type is used, then all attach types of the particular cgroup and +map will share the same storage. Otherwise, if the type is +``struct bpf_cgroup_storage_key``, then programs of different attach types +be isolated and see different storages. + +To access the storage in a program, use ``bpf_get_local_storage``:: + + void *bpf_get_local_storage(void *map, u64 flags) + +``flags`` is reserved for future use and must be 0. + +There is no implicit synchronization. Storages of ``BPF_MAP_TYPE_CGROUP_STORAGE`` +can be accessed by multiple programs across different CPUs, and user should +take care of synchronization by themselves. The bpf infrastructure provides +``struct bpf_spin_lock`` to synchronize the storage. See +``tools/testing/selftests/bpf/progs/test_spin_lock.c``. + +Examples +======== + +Usage with key type as ``struct bpf_cgroup_storage_key``:: + + #include <bpf/bpf.h> + + struct { + __uint(type, BPF_MAP_TYPE_CGROUP_STORAGE); + __type(key, struct bpf_cgroup_storage_key); + __type(value, __u32); + } cgroup_storage SEC(".maps"); + + int program(struct __sk_buff *skb) + { + __u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0); + __sync_fetch_and_add(ptr, 1); + + return 0; + } + +Userspace accessing map declared above:: + + #include <linux/bpf.h> + #include <linux/libbpf.h> + + __u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type) + { + struct bpf_cgroup_storage_key = { + .cgroup_inode_id = cgrp, + .attach_type = type, + }; + __u32 value; + bpf_map_lookup_elem(bpf_map__fd(map), &key, &value); + // error checking omitted + return value; + } + +Alternatively, using just ``__u64 cgroup_inode_id`` as key type:: + + #include <bpf/bpf.h> + + struct { + __uint(type, BPF_MAP_TYPE_CGROUP_STORAGE); + __type(key, __u64); + __type(value, __u32); + } cgroup_storage SEC(".maps"); + + int program(struct __sk_buff *skb) + { + __u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0); + __sync_fetch_and_add(ptr, 1); + + return 0; + } + +And userspace:: + + #include <linux/bpf.h> + #include <linux/libbpf.h> + + __u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type) + { + __u32 value; + bpf_map_lookup_elem(bpf_map__fd(map), &cgrp, &value); + // error checking omitted + return value; + } + +Semantics +========= + +``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE`` is a variant of this map type. This +per-CPU variant will have different memory regions for each CPU for each +storage. The non-per-CPU will have the same memory region for each storage. + +Prior to Linux 5.9, the lifetime of a storage is precisely per-attachment, and +for a single ``CGROUP_STORAGE`` map, there can be at most one program loaded +that uses the map. A program may be attached to multiple cgroups or have +multiple attach types, and each attach creates a fresh zeroed storage. The +storage is freed upon detach. + +There is a one-to-one association between the map of each type (per-CPU and +non-per-CPU) and the BPF program during load verification time. As a result, +each map can only be used by one BPF program and each BPF program can only use +one storage map of each type. Because of map can only be used by one BPF +program, sharing of this cgroup's storage with other BPF programs were +impossible. + +Since Linux 5.9, storage can be shared by multiple programs. When a program is +attached to a cgroup, the kernel would create a new storage only if the map +does not already contain an entry for the cgroup and attach type pair, or else +the old storage is reused for the new attachment. If the map is attach type +shared, then attach type is simply ignored during comparison. Storage is freed +only when either the map or the cgroup attached to is being freed. Detaching +will not directly free the storage, but it may cause the reference to the map +to reach zero and indirectly freeing all storage in the map. + +The map is not associated with any BPF program, thus making sharing possible. +However, the BPF program can still only associate with one map of each type +(per-CPU and non-per-CPU). A BPF program cannot use more than one +``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one +``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``. + +In all versions, userspace may use the the attach parameters of cgroup and +attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the BPF map +APIs to read or update the storage for a given attachment. For Linux 5.9 +attach type shared storages, only the first value in the struct, cgroup inode +id, is used during comparison, so userspace may just specify a ``__u64`` +directly. + +The storage is bound at attach time. Even if the program is attached to parent +and triggers in child, the storage still belongs to the parent. + +Userspace cannot create a new entry in the map or delete an existing entry. +Program test runs always use a temporary storage. 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/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 949af2da81e5..29ae2fee8123 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -19,13 +19,13 @@ compiles the kernel as a standalone Linux executable that can be run like any other program directly inside of a host operating system. To be clear, it does not require any virtualization support: it is just a regular program. -What is a kunitconfig? -====================== +What is a .kunitconfig? +======================= It's just a defconfig that kunit_tool looks for in the base directory. kunit_tool uses it to generate a .config as you might expect. In addition, it verifies that the generated .config contains the CONFIG options in the -kunitconfig; the reason it does this is so that it is easy to be sure that a +.kunitconfig; the reason it does this is so that it is easy to be sure that a CONFIG that enables a test actually ends up in the .config. How do I use kunit_tool? @@ -46,16 +46,9 @@ However, you most likely want to use it with the following options: - ``--timeout`` sets a maximum amount of time to allow tests to run. - ``--jobs`` sets the number of threads to use to build the kernel. -If you just want to use the defconfig that ships with the kernel, you can -append the ``--defconfig`` flag as well: - -.. code-block:: bash - - ./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all` --defconfig - .. note:: - This command is particularly helpful for getting started because it - just works. No kunitconfig needs to be present. + This command will work even without a .kunitconfig file: if no + .kunitconfig is present, a default one will be used instead. For a list of all the flags supported by kunit_tool, you can run: diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index bb112cf70624..d23385e3e159 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -18,7 +18,7 @@ The wrapper can be run with: .. code-block:: bash - ./tools/testing/kunit/kunit.py run --defconfig + ./tools/testing/kunit/kunit.py run For more information on this wrapper (also called kunit_tool) check out the :doc:`kunit-tool` page. 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/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt index 846f6daae71b..d711676b4a51 100644 --- a/Documentation/devicetree/bindings/arm/coresight.txt +++ b/Documentation/devicetree/bindings/arm/coresight.txt @@ -108,6 +108,13 @@ its hardware characteristcs. * arm,cp14: must be present if the system accesses ETM/PTM management registers via co-processor 14. + * qcom,skip-power-up: boolean. Indicates that an implementation can + skip powering up the trace unit. TRCPDCR.PU does not have to be set + on Qualcomm Technologies Inc. systems since ETMs are in the same power + domain as their CPU cores. This property is required to identify such + systems with hardware errata where the CPU watchdog counter is stopped + when TRCPDCR.PU is set. + * Optional property for TMC: * arm,buffer-size: size of contiguous buffer space for TMC ETR @@ -121,6 +128,12 @@ its hardware characteristcs. * interrupts : Exactly one SPI may be listed for reporting the address error +* Optional property for configurable replicators: + + * qcom,replicator-loses-context: boolean. Indicates that the replicator + will lose register context when AMBA clock is removed which is observed + in some replicator designs. + Graph bindings for Coresight ------------------------------- 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/bus/mti,mips-cdmm.yaml b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml new file mode 100644 index 000000000000..9cc2d5f1beef --- /dev/null +++ b/Documentation/devicetree/bindings/bus/mti,mips-cdmm.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/mti,mips-cdmm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPS Common Device Memory Map + +description: | + Defines a location of the MIPS Common Device Memory Map registers. + +maintainers: + - James Hogan <jhogan@kernel.org> + +properties: + compatible: + const: mti,mips-cdmm + + reg: + description: | + Base address and size of an unoccupied memory region, which will be + used to map the MIPS CDMM registers block. + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + cdmm@1bde8000 { + compatible = "mti,mips-cdmm"; + reg = <0x1bde8000 0x8000>; + }; +... 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/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml index bd871da6fc7c..3e20ccaf8131 100644 --- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml @@ -130,7 +130,7 @@ examples: #clock-cells = <1>; }; - esdhc@53fb4000 { + mmc@53fb4000 { compatible = "fsl,imx35-esdhc"; reg = <0x53fb4000 0x4000>; interrupts = <7>; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt deleted file mode 100644 index 93d89adb7afe..000000000000 --- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt +++ /dev/null @@ -1,103 +0,0 @@ -* Clock bindings for Freescale i.MX7ULP - -i.MX7ULP Clock functions are under joint control of the System -Clock Generation (SCG) modules, Peripheral Clock Control (PCC) -modules, and Core Mode Controller (CMC)1 blocks - -The clocking scheme provides clear separation between M4 domain -and A7 domain. Except for a few clock sources shared between two -domains, such as the System Oscillator clock, the Slow IRC (SIRC), -and and the Fast IRC clock (FIRCLK), clock sources and clock -management are separated and contained within each domain. - -M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. -A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. - -Note: this binding doc is only for A7 clock domain. - -System Clock Generation (SCG) modules: ---------------------------------------------------------------------- -The System Clock Generation (SCG) is responsible for clock generation -and distribution across this device. Functions performed by the SCG -include: clock reference selection, generation of clock used to derive -processor, system, peripheral bus and external memory interface clocks, -source selection for peripheral clocks and control of power saving -clock gating mode. - -Required properties: - -- compatible: Should be "fsl,imx7ulp-scg1". -- reg : Should contain registers location and length. -- #clock-cells: Should be <1>. -- clocks: Should contain the fixed input clocks. -- clock-names: Should contain the following clock names: - "rosc", "sosc", "sirc", "firc", "upll", "mpll". - -Peripheral Clock Control (PCC) modules: ---------------------------------------------------------------------- -The Peripheral Clock Control (PCC) is responsible for clock selection, -optional division and clock gating mode for peripherals in their -respected power domain - -Required properties: -- compatible: Should be one of: - "fsl,imx7ulp-pcc2", - "fsl,imx7ulp-pcc3". -- reg : Should contain registers location and length. -- #clock-cells: Should be <1>. -- clocks: Should contain the fixed input clocks. -- clock-names: Should contain the following clock names: - "nic1_bus_clk", "nic1_clk", "ddr_clk", "apll_pfd2", - "apll_pfd1", "apll_pfd0", "upll", "sosc_bus_clk", - "mpll", "firc_bus_clk", "rosc", "spll_bus_clk"; - -The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. -See include/dt-bindings/clock/imx7ulp-clock.h -for the full list of i.MX7ULP clock IDs of each module. - -Examples: - -#include <dt-bindings/clock/imx7ulp-clock.h> - -scg1: scg1@403e0000 { - compatible = "fsl,imx7ulp-scg1; - reg = <0x403e0000 0x10000>; - clocks = <&rosc>, <&sosc>, <&sirc>, - <&firc>, <&upll>, <&mpll>; - clock-names = "rosc", "sosc", "sirc", - "firc", "upll", "mpll"; - #clock-cells = <1>; -}; - -pcc2: pcc2@403f0000 { - compatible = "fsl,imx7ulp-pcc2"; - reg = <0x403f0000 0x10000>; - #clock-cells = <1>; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&scg1 IMX7ULP_CLK_DDR_DIV>, - <&scg1 IMX7ULP_CLK_APLL_PFD2>, - <&scg1 IMX7ULP_CLK_APLL_PFD1>, - <&scg1 IMX7ULP_CLK_APLL_PFD0>, - <&scg1 IMX7ULP_CLK_UPLL>, - <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>, - <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>, - <&scg1 IMX7ULP_CLK_ROSC>, - <&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>; - clock-names = "nic1_bus_clk", "nic1_clk", "ddr_clk", - "apll_pfd2", "apll_pfd1", "apll_pfd0", - "upll", "sosc_bus_clk", "mpll", - "firc_bus_clk", "rosc", "spll_bus_clk"; -}; - -usdhc1: usdhc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; -}; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml new file mode 100644 index 000000000000..7caf5cee9199 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx7ulp-pcc-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX7ULP Peripheral Clock Control (PCC) modules + +maintainers: + - A.s. Dong <aisheng.dong@nxp.com> + +description: | + i.MX7ULP Clock functions are under joint control of the System + Clock Generation (SCG) modules, Peripheral Clock Control (PCC) + modules, and Core Mode Controller (CMC)1 blocks + + The clocking scheme provides clear separation between M4 domain + and A7 domain. Except for a few clock sources shared between two + domains, such as the System Oscillator clock, the Slow IRC (SIRC), + and and the Fast IRC clock (FIRCLK), clock sources and clock + management are separated and contained within each domain. + + M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. + A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. + + Note: this binding doc is only for A7 clock domain. + + The Peripheral Clock Control (PCC) is responsible for clock selection, + optional division and clock gating mode for peripherals in their + respected power domain. + + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/imx7ulp-clock.h for the full list of + i.MX7ULP clock IDs of each module. + +properties: + compatible: + enum: + - fsl,imx7ulp-pcc2 + - fsl,imx7ulp-pcc3 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: nic1 bus clock + - description: nic1 clock + - description: ddr clock + - description: apll pfd2 + - description: apll pfd1 + - description: apll pfd0 + - description: usb pll + - description: system osc bus clock + - description: fast internal reference clock bus + - description: rtc osc + - description: system pll bus clock + + clock-names: + items: + - const: nic1_bus_clk + - const: nic1_clk + - const: ddr_clk + - const: apll_pfd2 + - const: apll_pfd1 + - const: apll_pfd0 + - const: upll + - const: sosc_bus_clk + - const: firc_bus_clk + - const: rosc + - const: spll_bus_clk + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx7ulp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@403f0000 { + compatible = "fsl,imx7ulp-pcc2"; + reg = <0x403f0000 0x10000>; + #clock-cells = <1>; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&scg1 IMX7ULP_CLK_DDR_DIV>, + <&scg1 IMX7ULP_CLK_APLL_PFD2>, + <&scg1 IMX7ULP_CLK_APLL_PFD1>, + <&scg1 IMX7ULP_CLK_APLL_PFD0>, + <&scg1 IMX7ULP_CLK_UPLL>, + <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>, + <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>, + <&scg1 IMX7ULP_CLK_ROSC>, + <&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>; + clock-names = "nic1_bus_clk", "nic1_clk", "ddr_clk", + "apll_pfd2", "apll_pfd1", "apll_pfd0", + "upll", "sosc_bus_clk", "firc_bus_clk", + "rosc", "spll_bus_clk"; + }; + + mmc@40380000 { + compatible = "fsl,imx7ulp-usdhc"; + reg = <0x40380000 0x10000>; + interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&pcc2 IMX7ULP_CLK_USDHC1>; + clock-names ="ipg", "ahb", "per"; + bus-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml new file mode 100644 index 000000000000..ee8efb4ed599 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/imx7ulp-scg-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MX7ULP System Clock Generation (SCG) modules + +maintainers: + - A.s. Dong <aisheng.dong@nxp.com> + +description: | + i.MX7ULP Clock functions are under joint control of the System + Clock Generation (SCG) modules, Peripheral Clock Control (PCC) + modules, and Core Mode Controller (CMC)1 blocks + + The clocking scheme provides clear separation between M4 domain + and A7 domain. Except for a few clock sources shared between two + domains, such as the System Oscillator clock, the Slow IRC (SIRC), + and and the Fast IRC clock (FIRCLK), clock sources and clock + management are separated and contained within each domain. + + M4 clock management consists of SCG0, PCC0, PCC1, and CMC0 modules. + A7 clock management consists of SCG1, PCC2, PCC3, and CMC1 modules. + + Note: this binding doc is only for A7 clock domain. + + The System Clock Generation (SCG) is responsible for clock generation + and distribution across this device. Functions performed by the SCG + include: clock reference selection, generation of clock used to derive + processor, system, peripheral bus and external memory interface clocks, + source selection for peripheral clocks and control of power saving + clock gating mode. + + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/imx7ulp-clock.h for the full list of + i.MX7ULP clock IDs of each module. + +properties: + compatible: + const: fsl,imx7ulp-scg1 + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: rtc osc + - description: system osc + - description: slow internal reference clock + - description: fast internal reference clock + - description: usb PLL + + clock-names: + items: + - const: rosc + - const: sosc + - const: sirc + - const: firc + - const: upll + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx7ulp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + clock-controller@403e0000 { + compatible = "fsl,imx7ulp-scg1"; + reg = <0x403e0000 0x10000>; + clocks = <&rosc>, <&sosc>, <&sirc>, + <&firc>, <&upll>; + clock-names = "rosc", "sosc", "sirc", + "firc", "upll"; + #clock-cells = <1>; + }; + + mmc@40380000 { + compatible = "fsl,imx7ulp-usdhc"; + reg = <0x40380000 0x10000>; + interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, + <&scg1 IMX7ULP_CLK_NIC1_DIV>, + <&pcc2 IMX7ULP_CLK_USDHC1>; + clock-names ="ipg", "ahb", "per"; + bus-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 33f3010f48c3..1d5e9bcce4c8 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -62,7 +62,7 @@ examples: }; mmc@5b010000 { - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; + compatible = "fsl,imx8qxp-usdhc"; interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>; reg = <0x5b010000 0x10000>; clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, 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/display/allwinner,sun8i-a83t-de2-mixer.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml index 1dee641e3ea1..c040eef56518 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-de2-mixer.yaml @@ -36,6 +36,9 @@ properties: - const: bus - const: mod + iommus: + maxItems: 1 + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt deleted file mode 100644 index 26649b4c4dd8..000000000000 --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt +++ /dev/null @@ -1,174 +0,0 @@ -Broadcom VC4 (VideoCore4) GPU - -The VC4 device present on the Raspberry Pi includes a display system -with HDMI output and the HVS (Hardware Video Scaler) for compositing -display planes. - -Required properties for VC4: -- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4" - -Required properties for Pixel Valve: -- compatible: Should be one of "brcm,bcm2835-pixelvalve0", - "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2" -- reg: Physical base address and length of the PV's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for HVS: -- compatible: Should be "brcm,bcm2835-hvs" -- reg: Physical base address and length of the HVS's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for HDMI -- compatible: Should be "brcm,bcm2835-hdmi" -- reg: Physical base address and length of the two register ranges - ("HDMI" and "HD", in that order) -- interrupts: The interrupt numbers - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- ddc: phandle of the I2C controller used for DDC EDID probing -- clocks: a) hdmi: The HDMI state machine clock - b) pixel: The pixel clock. - -Optional properties for HDMI: -- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear - as an interrupt/status bit in the HDMI controller - itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt -- dmas: Should contain one entry pointing to the DMA channel used to - transfer audio data -- dma-names: Should contain "audio-rx" - -Required properties for DPI: -- compatible: Should be "brcm,bcm2835-dpi" -- reg: Physical base address and length of the registers -- clocks: a) core: The core clock the unit runs on - b) pixel: The pixel clock that feeds the pixelvalve -- port: Port node with a single endpoint connecting to the panel - device, as defined in [1] - -Required properties for VEC: -- compatible: Should be "brcm,bcm2835-vec" -- reg: Physical base address and length of the registers -- clocks: The core clock the unit runs on -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Required properties for V3D: -- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d" -- reg: Physical base address and length of the V3D's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Optional properties for V3D: -- clocks: The clock the unit runs on - -Required properties for DSI: -- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" -- reg: Physical base address and length of the DSI block's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt -- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY - b) escape: The DSI ESC clock from CPRMAN - c) pixel: The DSI pixel clock from CPRMAN -- clock-output-names: - The 3 clocks output from the DSI analog PHY: dsi[01]_byte, - dsi[01]_ddr2, and dsi[01]_ddr - -Required properties for the TXP (writeback) block: -- compatible: Should be "brcm,bcm2835-txp" -- reg: Physical base address and length of the TXP block's registers -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -[1] Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: -pixelvalve@7e807000 { - compatible = "brcm,bcm2835-pixelvalve2"; - reg = <0x7e807000 0x100>; - interrupts = <2 10>; /* pixelvalve */ -}; - -hvs@7e400000 { - compatible = "brcm,bcm2835-hvs"; - reg = <0x7e400000 0x6000>; - interrupts = <2 1>; -}; - -hdmi: hdmi@7e902000 { - compatible = "brcm,bcm2835-hdmi"; - reg = <0x7e902000 0x600>, - <0x7e808000 0x100>; - interrupts = <2 8>, <2 9>; - ddc = <&i2c2>; - hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; - clocks = <&clocks BCM2835_PLLH_PIX>, - <&clocks BCM2835_CLOCK_HSM>; - clock-names = "pixel", "hdmi"; -}; - -dpi: dpi@7e208000 { - compatible = "brcm,bcm2835-dpi"; - reg = <0x7e208000 0x8c>; - clocks = <&clocks BCM2835_CLOCK_VPU>, - <&clocks BCM2835_CLOCK_DPI>; - clock-names = "core", "pixel"; - #address-cells = <1>; - #size-cells = <0>; - - port { - dpi_out: endpoint@0 { - remote-endpoint = <&panel_in>; - }; - }; -}; - -dsi1: dsi@7e700000 { - compatible = "brcm,bcm2835-dsi1"; - reg = <0x7e700000 0x8c>; - interrupts = <2 12>; - #address-cells = <1>; - #size-cells = <0>; - #clock-cells = <1>; - - clocks = <&clocks BCM2835_PLLD_DSI1>, - <&clocks BCM2835_CLOCK_DSI1E>, - <&clocks BCM2835_CLOCK_DSI1P>; - clock-names = "phy", "escape", "pixel"; - - clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; - - pitouchscreen: panel@0 { - compatible = "raspberrypi,touchscreen"; - reg = <0>; - - <...> - }; -}; - -vec: vec@7e806000 { - compatible = "brcm,bcm2835-vec"; - reg = <0x7e806000 0x1000>; - clocks = <&clocks BCM2835_CLOCK_VEC>; - interrupts = <2 27>; -}; - -v3d: v3d@7ec00000 { - compatible = "brcm,bcm2835-v3d"; - reg = <0x7ec00000 0x1000>; - interrupts = <1 10>; -}; - -vc4: gpu { - compatible = "brcm,bcm2835-vc4"; -}; - -panel: panel { - compatible = "ontat,yx700wv03", "simple-panel"; - - port { - panel_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml new file mode 100644 index 000000000000..5c1024bbc1b3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-dpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) DPI Controller + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + const: brcm,bcm2835-dpi + + reg: + maxItems: 1 + + clocks: + items: + - description: The core clock the unit runs on + - description: The pixel clock that feeds the pixelvalve + + clock-names: + items: + - const: core + - const: pixel + + port: + type: object + description: > + Port node with a single endpoint connecting to the panel, as + defined in Documentation/devicetree/bindings/media/video-interfaces.txt. + +required: + - compatible + - reg + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + dpi: dpi@7e208000 { + compatible = "brcm,bcm2835-dpi"; + reg = <0x7e208000 0x8c>; + clocks = <&clocks BCM2835_CLOCK_VPU>, + <&clocks BCM2835_CLOCK_DPI>; + clock-names = "core", "pixel"; + + port { + dpi_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml new file mode 100644 index 000000000000..3c643b227a70 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-dsi0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) DSI Controller + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + "#clock-cells": + const: 1 + + compatible: + enum: + - brcm,bcm2835-dsi0 + - brcm,bcm2835-dsi1 + + reg: + maxItems: 1 + + clocks: + items: + - description: The DSI PLL clock feeding the DSI analog PHY + - description: The DSI ESC clock + - description: The DSI pixel clock + + clock-names: + items: + - const: phy + - const: escape + - const: pixel + + clock-output-names: true + # FIXME: The meta-schemas don't seem to allow it for now + # items: + # - description: The DSI byte clock for the PHY + # - description: The DSI DDR2 clock + # - description: The DSI DDR clock + + interrupts: + maxItems: 1 + +required: + - "#clock-cells" + - compatible + - reg + - clocks + - clock-names + - clock-output-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + dsi1: dsi@7e700000 { + compatible = "brcm,bcm2835-dsi1"; + reg = <0x7e700000 0x8c>; + interrupts = <2 12>; + #address-cells = <1>; + #size-cells = <0>; + #clock-cells = <1>; + + clocks = <&clocks BCM2835_PLLD_DSI1>, + <&clocks BCM2835_CLOCK_DSI1E>, + <&clocks BCM2835_CLOCK_DSI1P>; + clock-names = "phy", "escape", "pixel"; + + clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; + + pitouchscreen: panel@0 { + compatible = "raspberrypi,touchscreen"; + reg = <0>; + + /* ... */ + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml new file mode 100644 index 000000000000..52b3cdac0bdf --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) HDMI Controller + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + const: brcm,bcm2835-hdmi + + reg: + items: + - description: HDMI register range + - description: HD register range + + interrupts: + minItems: 2 + + clocks: + items: + - description: The pixel clock + - description: The HDMI state machine clock + + clock-names: + items: + - const: pixel + - const: hdmi + + ddc: + allOf: + - $ref: /schemas/types.yaml#/definitions/phandle + description: > + Phandle of the I2C controller used for DDC EDID probing + + hpd-gpios: + description: > + The GPIO pin for the HDMI hotplug detect (if it doesn't appear + as an interrupt/status bit in the HDMI controller itself) + + dmas: + maxItems: 1 + description: > + Should contain one entry pointing to the DMA channel used to + transfer audio data. + + dma-names: + const: audio-rx + +required: + - compatible + - reg + - interrupts + - clocks + - ddc + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + #include <dt-bindings/gpio/gpio.h> + + hdmi: hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600>, + <0x7e808000 0x100>; + interrupts = <2 8>, <2 9>; + ddc = <&i2c2>; + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + clocks = <&clocks BCM2835_PLLH_PIX>, + <&clocks BCM2835_CLOCK_HSM>; + clock-names = "pixel", "hdmi"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml new file mode 100644 index 000000000000..02410f8d6d49 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-hvs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) Hardware Video Scaler + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + const: brcm,bcm2835-hvs + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + hvs@7e400000 { + compatible = "brcm,bcm2835-hvs"; + reg = <0x7e400000 0x6000>; + interrupts = <2 1>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml new file mode 100644 index 000000000000..e60791db1fa1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-pixelvalve0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) PixelValve + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + enum: + - brcm,bcm2835-pixelvalve0 + - brcm,bcm2835-pixelvalve1 + - brcm,bcm2835-pixelvalve2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <2 10>; /* pixelvalve */ + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml new file mode 100644 index 000000000000..bb186197e471 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-txp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) TXP (writeback) Controller + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + const: brcm,bcm2835-txp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + txp: txp@7e004000 { + compatible = "brcm,bcm2835-txp"; + reg = <0x7e004000 0x20>; + interrupts = <1 11>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml new file mode 100644 index 000000000000..8a73780f573d --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-v3d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) V3D GPU + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + enum: + - brcm,bcm2835-v3d + - brcm,cygnus-v3d + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + v3d: v3d@7ec00000 { + compatible = "brcm,bcm2835-v3d"; + reg = <0x7ec00000 0x1000>; + interrupts = <1 10>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml new file mode 100644 index 000000000000..0dcf0c397375 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml @@ -0,0 +1,34 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-vc4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) GPU + +maintainers: + - Eric Anholt <eric@anholt.net> + +description: > + The VC4 device present on the Raspberry Pi includes a display system + with HDMI output and the HVS (Hardware Video Scaler) for compositing + display planes. + +properties: + compatible: + enum: + - brcm,bcm2835-vc4 + - brcm,cygnus-vc4 + +required: + - compatible + +additionalProperties: false + +examples: + - | + vc4: gpu { + compatible = "brcm,bcm2835-vc4"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml new file mode 100644 index 000000000000..d900cc57b4ec --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/brcm,bcm2835-vec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VC4 (VideoCore4) VEC + +maintainers: + - Eric Anholt <eric@anholt.net> + +properties: + compatible: + const: brcm,bcm2835-vec + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/bcm2835.h> + + vec: vec@7e806000 { + compatible = "brcm,bcm2835-vec"; + reg = <0x7e806000 0x1000>; + clocks = <&clocks BCM2835_CLOCK_VEC>; + interrupts = <2 27>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml index 8aff2d68fc33..2c4c34e3bc29 100644 --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml @@ -165,6 +165,7 @@ examples: - | #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/reset/imx8mq-reset.h> @@ -191,12 +192,12 @@ examples: phy-names = "dphy"; panel@0 { - #address-cells = <1>; - #size-cells = <0>; compatible = "rocktech,jh057n00900"; reg = <0>; - port@0 { - reg = <0>; + vcc-supply = <®_2v8_p>; + iovcc-supply = <®_1v8_p>; + reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; + port { panel_in: endpoint { remote-endpoint = <&mipi_dsi_out>; }; diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt deleted file mode 100644 index c62ce2494ed9..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ /dev/null @@ -1,85 +0,0 @@ -Renesas R-Car LVDS Encoder -========================== - -These DT bindings describe the LVDS encoder embedded in the Renesas R-Car -Gen2, R-Car Gen3 and RZ/G SoCs. - -Required properties: - -- compatible : Shall contain one of - - "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders - - "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders - - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders - - "renesas,r8a774b1-lvds" for R8A774B1 (RZ/G2N) compatible LVDS encoders - - "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders - - "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders - - "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders - - "renesas,r8a7793-lvds" for R8A7793 (R-Car M2-N) compatible LVDS encoders - - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders - - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders - - "renesas,r8a77965-lvds" for R8A77965 (R-Car M3-N) compatible LVDS encoders - - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders - - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders - - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders - - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders - -- reg: Base address and length for the memory-mapped registers -- clocks: A list of phandles + clock-specifier pairs, one for each entry in - the clock-names property. -- clock-names: Name of the clocks. This property is model-dependent. - - The functional clock, which mandatory for all models, shall be listed - first, and shall be named "fck". - - On R8A77990, R8A77995 and R8A774C0, the LVDS encoder can use the EXTAL or - DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be - named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN - numerical index. - - When the clocks property only contains the functional clock, the - clock-names property may be omitted. -- resets: A phandle + reset specifier for the module reset - -Required nodes: - -The LVDS encoder has two video ports. Their connections are modelled using the -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 corresponds to the parallel RGB input -- Video port 1 corresponds to the LVDS output - -Each port shall have a single endpoint. - -Optional properties: - -- renesas,companion : phandle to the companion LVDS encoder. This property is - mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall point to - the second encoder to be used as a companion in dual-link mode. It shall not - be set for any other LVDS encoder. - - -Example: - - lvds0: lvds@feb90000 { - compatible = "renesas,r8a77990-lvds"; - reg = <0 0xfeb90000 0 0x20>; - clocks = <&cpg CPG_MOD 727>; - power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; - resets = <&cpg 727>; - - renesas,companion = <&lvds1>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - lvds0_in: endpoint { - remote-endpoint = <&du_out_lvds0>; - }; - }; - port@1 { - reg = <1>; - lvds0_out: endpoint { - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml new file mode 100644 index 000000000000..98c7330a9485 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/renesas,lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car LVDS Encoder + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: | + These DT bindings describe the LVDS encoder embedded in the Renesas R-Car + Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs. + +properties: + compatible: + enum: + - renesas,r8a7743-lvds # for RZ/G1M compatible LVDS encoders + - renesas,r8a7744-lvds # for RZ/G1N compatible LVDS encoders + - renesas,r8a774a1-lvds # for RZ/G2M compatible LVDS encoders + - renesas,r8a774b1-lvds # for RZ/G2N compatible LVDS encoders + - renesas,r8a774c0-lvds # for RZ/G2E compatible LVDS encoders + - renesas,r8a7790-lvds # for R-Car H2 compatible LVDS encoders + - renesas,r8a7791-lvds # for R-Car M2-W compatible LVDS encoders + - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders + - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders + - renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders + - renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders + - renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders + - renesas,r8a77980-lvds # for R-Car V3H compatible LVDS encoders + - renesas,r8a77990-lvds # for R-Car E3 compatible LVDS encoders + - renesas,r8a77995-lvds # for R-Car D3 compatible LVDS encoders + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + resets: + maxItems: 1 + + ports: + type: object + description: | + This device has two video ports. Their connections are modelled using the + OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. + Each port shall have a single endpoint. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + type: object + description: Parallel RGB input port + + port@1: + type: object + description: LVDS output port + + required: + - port@0 + - port@1 + + additionalProperties: false + + power-domains: + maxItems: 1 + + renesas,companion: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to the companion LVDS encoder. This property is mandatory + for the first LVDS encoder on D3 and E3 SoCs, and shall point to + the second encoder to be used as a companion in dual-link mode. It + shall not be set for any other LVDS encoder. + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - ports + +if: + properties: + compatible: + enum: + - renesas,r8a774c0-lvds + - renesas,r8a77990-lvds + - renesas,r8a77995-lvds +then: + properties: + clocks: + minItems: 1 + maxItems: 4 + items: + - description: Functional clock + - description: EXTAL input clock + - description: DU_DOTCLKIN0 input clock + - description: DU_DOTCLKIN1 input clock + + clock-names: + minItems: 1 + maxItems: 4 + items: + - const: fck + # The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks. + # These clocks are optional. + - enum: + - extal + - dclkin.0 + - dclkin.1 + - enum: + - extal + - dclkin.0 + - dclkin.1 + - enum: + - extal + - dclkin.0 + - dclkin.1 + + required: + - clock-names + +else: + properties: + clocks: + maxItems: 1 + items: + - description: Functional clock + + clock-names: + maxItems: 1 + items: + - const: fck + + renesas,companion: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + lvds@feb90000 { + compatible = "renesas,r8a7795-lvds"; + reg = <0xfeb90000 0x14>; + clocks = <&cpg CPG_MOD 727>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 727>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds_in: endpoint { + remote-endpoint = <&du_out_lvds0>; + }; + }; + port@1 { + reg = <1>; + lvds_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + + - | + #include <dt-bindings/clock/renesas-cpg-mssr.h> + #include <dt-bindings/power/r8a77990-sysc.h> + + lvds0: lvds@feb90000 { + compatible = "renesas,r8a77990-lvds"; + reg = <0xfeb90000 0x20>; + clocks = <&cpg CPG_MOD 727>, + <&x13_clk>, + <&extal_clk>; + clock-names = "fck", "dclkin.0", "extal"; + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; + resets = <&cpg 727>; + + renesas,companion = <&lvds1>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds0_in: endpoint { + remote-endpoint = <&du_out_lvds0>; + }; + }; + port@1 { + reg = <1>; + lvds0_out: endpoint { + remote-endpoint = <&panel_in1>; + }; + }; + }; + }; + + lvds1: lvds@feb90100 { + compatible = "renesas,r8a77990-lvds"; + reg = <0xfeb90100 0x20>; + clocks = <&cpg CPG_MOD 727>, + <&x13_clk>, + <&extal_clk>; + clock-names = "fck", "dclkin.0", "extal"; + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>; + resets = <&cpg 726>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + lvds1_in: endpoint { + remote-endpoint = <&du_out_lvds1>; + }; + }; + port@1 { + reg = <1>; + lvds1_out: endpoint { + remote-endpoint = <&panel_in2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt deleted file mode 100644 index 8ec4a7f2623a..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt +++ /dev/null @@ -1,87 +0,0 @@ -SN65DSI86 DSI to eDP bridge chip --------------------------------- - -This is the binding for Texas Instruments SN65DSI86 bridge. -http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf - -Required properties: -- compatible: Must be "ti,sn65dsi86" -- reg: i2c address of the chip, 0x2d as per datasheet -- enable-gpios: gpio specification for bridge_en pin (active high) - -- vccio-supply: A 1.8V supply that powers up the digital IOs. -- vpll-supply: A 1.8V supply that powers up the displayport PLL. -- vcca-supply: A 1.2V supply that powers up the analog circuits. -- vcc-supply: A 1.2V supply that powers up the digital core. - -Optional properties: -- interrupts-extended: Specifier for the SN65DSI86 interrupt line. - -- gpio-controller: Marks the device has a GPIO controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. - See ../../gpio/gpio.txt for more information. -- #pwm-cells : Should be one. See ../../pwm/pwm.yaml for description of - the cell formats. - -- clock-names: should be "refclk" -- clocks: Specification for input reference clock. The reference - clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. - -- data-lanes: See ../../media/video-interface.txt -- lane-polarities: See ../../media/video-interface.txt - -- suspend-gpios: specification for GPIO1 pin on bridge (active low) - -Required nodes: -This device has two video ports. Their connections are modelled using the -OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for DSI input -- Video port 1 for eDP output - -Example -------- - -edp-bridge@2d { - compatible = "ti,sn65dsi86"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x2d>; - - enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>; - suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>; - - interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>; - - vccio-supply = <&pm8916_l17>; - vcca-supply = <&pm8916_l6>; - vpll-supply = <&pm8916_l17>; - vcc-supply = <&pm8916_l6>; - - clock-names = "refclk"; - clocks = <&input_refclk>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - edp_bridge_in: endpoint { - remote-endpoint = <&dsi_out>; - }; - }; - - port@1 { - reg = <1>; - - edp_bridge_out: endpoint { - data-lanes = <2 1 3 0>; - lane-polarities = <0 1 0 1>; - remote-endpoint = <&edp_panel_in>; - }; - }; - }; -} diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml new file mode 100644 index 000000000000..f8622bd0f61e --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -0,0 +1,293 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi86.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI86 DSI to eDP bridge chip + +maintainers: + - Sandeep Panda <spanda@codeaurora.org> + +description: | + The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP. + https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf + +properties: + compatible: + const: ti,sn65dsi86 + + reg: + const: 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + suspend-gpios: + maxItems: 1 + description: GPIO specifier for GPIO1 pin on bridge (active low). + + no-hpd: + type: boolean + description: + Set if the HPD line on the bridge isn't hooked up to anything or is + otherwise unusable. + + vccio-supply: + description: A 1.8V supply that powers the digital IOs. + + vpll-supply: + description: A 1.8V supply that powers the DisplayPort PLL. + + vcca-supply: + description: A 1.2V supply that powers the analog circuits. + + vcc-supply: + description: A 1.2V supply that powers the digital core. + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + Clock specifier for input reference clock. The reference clock rate must + be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. + + clock-names: + const: refclk + + gpio-controller: true + '#gpio-cells': + const: 2 + description: + First cell is pin number, second cell is flags. GPIO pin numbers are + 1-based to match the datasheet. See ../../gpio/gpio.txt for more + information. + + '#pwm-cells': + const: 1 + description: See ../../pwm/pwm.yaml for description of the cell formats. + + ports: + type: object + additionalProperties: false + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + additionalProperties: false + + description: + Video port for MIPI DSI input + + properties: + reg: + const: 0 + + endpoint: + type: object + additionalProperties: false + properties: + remote-endpoint: true + + required: + - reg + + port@1: + type: object + additionalProperties: false + + description: + Video port for eDP output (panel or connector). + + properties: + reg: + const: 1 + + endpoint: + type: object + additionalProperties: false + + properties: + remote-endpoint: true + + data-lanes: + oneOf: + - minItems: 1 + maxItems: 1 + uniqueItems: true + items: + enum: + - 0 + - 1 + description: + If you have 1 logical lane the bridge supports routing + to either port 0 or port 1. Port 0 is suggested. + See ../../media/video-interface.txt for details. + + - minItems: 2 + maxItems: 2 + uniqueItems: true + items: + enum: + - 0 + - 1 + description: + If you have 2 logical lanes the bridge supports + reordering but only on physical ports 0 and 1. + See ../../media/video-interface.txt for details. + + - minItems: 4 + maxItems: 4 + uniqueItems: true + items: + enum: + - 0 + - 1 + - 2 + - 3 + description: + If you have 4 logical lanes the bridge supports + reordering in any way. + See ../../media/video-interface.txt for details. + + lane-polarities: + minItems: 1 + maxItems: 4 + items: + enum: + - 0 + - 1 + description: See ../../media/video-interface.txt + + dependencies: + lane-polarities: [data-lanes] + + required: + - reg + + required: + - "#address-cells" + - "#size-cells" + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - vccio-supply + - vpll-supply + - vcca-supply + - vcc-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + }; + }; + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>; + suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>; + + interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>; + + vccio-supply = <&pm8916_l17>; + vcca-supply = <&pm8916_l6>; + vpll-supply = <&pm8916_l17>; + vcc-supply = <&pm8916_l6>; + + clock-names = "refclk"; + clocks = <&input_refclk>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + edp_bridge_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + + port@1 { + reg = <1>; + + edp_bridge_out: endpoint { + data-lanes = <2 1 3 0>; + lane-polarities = <0 1 0 1>; + remote-endpoint = <&edp_panel_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt deleted file mode 100644 index 5ff4f64ef8e8..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt +++ /dev/null @@ -1,66 +0,0 @@ -TFP410 DPI to DVI encoder -========================= - -Required properties: -- compatible: "ti,tfp410" - -Optional properties: -- powerdown-gpios: power-down gpio -- reg: I2C address. If and only if present the device node should be placed - into the I2C controller node where the TFP410 I2C is connected to. -- ti,deskew: data de-skew in 350ps increments, from -4 to +3, as configured - through th DK[3:1] pins. This property shall be present only if the TFP410 - is not connected through I2C. - -Required nodes: - -This device has two video ports. Their connections are modeled using the OF -graph bindings specified in [1]. Each port node shall have a single endpoint. - -- Port 0 is the DPI input port. Its endpoint subnode shall contain a - pclk-sample and bus-width property and a remote-endpoint property as specified - in [1]. - - If pclk-sample is not defined, pclk-sample = 0 should be assumed for - backward compatibility. - - If bus-width is not defined then bus-width = 24 should be assumed for - backward compatibility. - bus-width = 24: 24 data lines are connected and single-edge mode - bus-width = 12: 12 data lines are connected and dual-edge mode - -- Port 1 is the DVI output port. Its endpoint subnode shall contain a - remote-endpoint property is specified in [1]. - -[1] Documentation/devicetree/bindings/media/video-interfaces.txt - - -Example -------- - -tfp410: encoder@0 { - compatible = "ti,tfp410"; - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; - ti,deskew = <4>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tfp410_in: endpoint@0 { - pclk-sample = <1>; - bus-width = <24>; - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - tfp410_out: endpoint@0 { - remote-endpoint = <&dvi_connector_in>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml new file mode 100644 index 000000000000..605831c1e836 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,tfp410.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TFP410 DPI to DVI encoder + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ti.com> + - Jyri Sarha <jsarha@ti.com> + +properties: + compatible: + const: ti,tfp410 + + reg: + description: I2C address of the device. + maxItems: 1 + + powerdown-gpios: + maxItems: 1 + + ti,deskew: + description: + Data de-skew value in 350ps increments, from 0 to 7, as configured + through the DK[3:1] pins. The de-skew multiplier is computed as + (DK[3:1] - 4), so it ranges from -4 to 3. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + + ports: + description: + A node containing input and output port nodes with endpoint + definitions as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + type: object + + properties: + port@0: + description: DPI input port. + type: object + + properties: + reg: + const: 0 + + endpoint: + type: object + + properties: + pclk-sample: + description: + Endpoint sampling edge. + enum: + - 0 # Falling edge + - 1 # Rising edge + default: 0 + + bus-width: + description: + Endpoint bus width. + enum: + - 12 # 12 data lines connected and dual-edge mode + - 24 # 24 data lines connected and single-edge mode + default: 24 + + port@1: + description: DVI output port. + type: object + + properties: + reg: + const: 1 + + endpoint: + type: object + + required: + - port@0 + - port@1 + +required: + - compatible + - ports + +if: + required: + - reg +then: + properties: + ti,deskew: false +else: + required: + - ti,deskew + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + tfp410: encoder { + compatible = "ti,tfp410"; + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; + ti,deskew = <3>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + tfp410_in: endpoint { + pclk-sample = <1>; + bus-width = <24>; + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + tfp410_out: endpoint { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt deleted file mode 100644 index 883bcb2604c7..000000000000 --- a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt +++ /dev/null @@ -1,31 +0,0 @@ -Analog TV Connector -=================== - -Required properties: -- compatible: "composite-video-connector" or "svideo-connector" - -Optional properties: -- label: a symbolic name for the connector -- sdtv-standards: limit the supported TV standards on a connector to the given - ones. If not specified all TV standards are allowed. - Possible TV standards are defined in - include/dt-bindings/display/sdtv-standards.h. - -Required nodes: -- Video port for TV input - -Example -------- -#include <dt-bindings/display/sdtv-standards.h> - -tv: connector { - compatible = "composite-video-connector"; - label = "tv"; - sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>; - - port { - tv_connector_in: endpoint { - remote-endpoint = <&venc_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml new file mode 100644 index 000000000000..eebe88fed999 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/analog-tv-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog TV Connector + +maintainers: + - Laurent Pinchart <Laurent.pinchart@ideasonboard.com> + +properties: + compatible: + enum: + - composite-video-connector + - svideo-connector + + label: true + + sdtv-standards: + description: + Limit the supported TV standards on a connector to the given ones. If + not specified all TV standards are allowed. Possible TV standards are + defined in include/dt-bindings/display/sdtv-standards.h. + $ref: /schemas/types.yaml#/definitions/uint32 + + port: + description: Connection to controller providing analog TV signals + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/display/sdtv-standards.h> + + connector { + compatible = "composite-video-connector"; + label = "tv"; + sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>; + + port { + tv_connector_in: endpoint { + remote-endpoint = <&venc_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt deleted file mode 100644 index 207e42e9eba0..000000000000 --- a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt +++ /dev/null @@ -1,36 +0,0 @@ -DVI Connector -============== - -Required properties: -- compatible: "dvi-connector" - -Optional properties: -- label: a symbolic name for the connector -- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC -- analog: the connector has DVI analog pins -- digital: the connector has DVI digital pins -- dual-link: the connector has pins for DVI dual-link -- hpd-gpios: HPD GPIO number - -Required nodes: -- Video port for DVI input - -Note: One (or both) of 'analog' or 'digital' must be set. - -Example -------- - -dvi0: connector@0 { - compatible = "dvi-connector"; - label = "dvi"; - - digital; - - ddc-i2c-bus = <&i2c3>; - - port { - dvi_connector_in: endpoint { - remote-endpoint = <&tfp410_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml b/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml new file mode 100644 index 000000000000..71cb9220fa59 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/dvi-connector.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/dvi-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DVI Connector + +maintainers: + - Laurent Pinchart <Laurent.pinchart@ideasonboard.com> + +properties: + compatible: + const: dvi-connector + + label: true + + hpd-gpios: + description: A GPIO line connected to HPD + maxItems: 1 + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + analog: + type: boolean + description: the connector has DVI analog pins + + digital: + type: boolean + description: the connector has DVI digital pins + + dual-link: + type: boolean + description: the connector has pins for DVI dual-link + + port: + description: Connection to controller providing DVI signals + +required: + - compatible + - port + +anyOf: + - required: + - analog + - required: + - digital + +additionalProperties: false + +examples: + - | + connector { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt deleted file mode 100644 index aeb07c4bd703..000000000000 --- a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt +++ /dev/null @@ -1,31 +0,0 @@ -HDMI Connector -============== - -Required properties: -- compatible: "hdmi-connector" -- type: the HDMI connector type: "a", "b", "c", "d" or "e" - -Optional properties: -- label: a symbolic name for the connector -- hpd-gpios: HPD GPIO number -- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing -- ddc-en-gpios: signal to enable DDC bus - -Required nodes: -- Video port for HDMI input - -Example -------- - -hdmi0: connector@1 { - compatible = "hdmi-connector"; - label = "hdmi"; - - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&tpd12s015_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml new file mode 100644 index 000000000000..14d7128af592 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/hdmi-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HDMI Connector + +maintainers: + - Laurent Pinchart <Laurent.pinchart@ideasonboard.com> + +properties: + compatible: + const: hdmi-connector + + type: + description: The HDMI connector type + enum: + - a # Standard full size + - b # Never deployed? + - c # Mini + - d # Micro + - e # automotive + + label: true + + hpd-gpios: + description: A GPIO line connected to HPD + maxItems: 1 + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + ddc-en-gpios: + description: GPIO signal to enable DDC bus + maxItems: 1 + + port: + description: Connection to controller providing HDMI signals + +required: + - compatible + - port + - type + +additionalProperties: false + +examples: + - | + connector { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/connector/vga-connector.txt b/Documentation/devicetree/bindings/display/connector/vga-connector.txt deleted file mode 100644 index c727f298e7ad..000000000000 --- a/Documentation/devicetree/bindings/display/connector/vga-connector.txt +++ /dev/null @@ -1,36 +0,0 @@ -VGA Connector -============= - -Required properties: - -- compatible: "vga-connector" - -Optional properties: - -- label: a symbolic name for the connector corresponding to a hardware label -- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC - -Required nodes: - -The VGA connector internal connections are modeled using the OF graph bindings -specified in Documentation/devicetree/bindings/graph.txt. - -The VGA connector has a single port that must be connected to a video source -port. - - -Example -------- - -vga0: connector@0 { - compatible = "vga-connector"; - label = "vga"; - - ddc-i2c-bus = <&i2c3>; - - port { - vga_connector_in: endpoint { - remote-endpoint = <&adv7123_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/connector/vga-connector.yaml b/Documentation/devicetree/bindings/display/connector/vga-connector.yaml new file mode 100644 index 000000000000..5782c4bb3252 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/vga-connector.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/vga-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: VGA Connector + +maintainers: + - Laurent Pinchart <Laurent.pinchart@ideasonboard.com> + +properties: + compatible: + const: vga-connector + + label: true + + ddc-i2c-bus: + description: phandle link to the I2C controller used for DDC EDID probing + $ref: /schemas/types.yaml#/definitions/phandle + + port: + description: Connection to controller providing VGA signals + +required: + - compatible + - port + +additionalProperties: false + +examples: + - | + connector { + compatible = "vga-connector"; + label = "vga"; + + ddc-i2c-bus = <&i2c3>; + + port { + vga_connector_in: endpoint { + remote-endpoint = <&adv7123_out>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/ingenic,ipu.yaml b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml new file mode 100644 index 000000000000..5bfc33eb32c9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ingenic,ipu.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/ingenic,ipu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs Image Processing Unit (IPU) devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + compatible: + oneOf: + - enum: + - ingenic,jz4725b-ipu + - ingenic,jz4760-ipu + - items: + - const: ingenic,jz4770-ipu + - const: ingenic,jz4760-ipu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipu + +patternProperties: + "^ports?$": + description: OF graph bindings (specified in bindings/graph.txt). + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4770-cgu.h> + ipu@13080000 { + compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu"; + reg = <0x13080000 0x800>; + + interrupt-parent = <&intc>; + interrupts = <29>; + + clocks = <&cgu JZ4770_CLK_IPU>; + clock-names = "ipu"; + + port { + ipu_ep: endpoint { + remote-endpoint = <&lcdc_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt b/Documentation/devicetree/bindings/display/ingenic,lcd.txt deleted file mode 100644 index 01e3261defb6..000000000000 --- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt +++ /dev/null @@ -1,45 +0,0 @@ -Ingenic JZ47xx LCD driver - -Required properties: -- compatible: one of: - * ingenic,jz4740-lcd - * ingenic,jz4725b-lcd - * ingenic,jz4770-lcd -- reg: LCD registers location and length -- clocks: LCD pixclock and device clock specifiers. - The device clock is only required on the JZ4740. -- clock-names: "lcd_pclk" and "lcd" -- interrupts: Specifies the interrupt line the LCD controller is connected to. - -Example: - -panel { - compatible = "sharp,ls020b1dd01d"; - - backlight = <&backlight>; - power-supply = <&vcc>; - - port { - panel_input: endpoint { - remote-endpoint = <&panel_output>; - }; - }; -}; - - -lcd: lcd-controller@13050000 { - compatible = "ingenic,jz4725b-lcd"; - reg = <0x13050000 0x1000>; - - interrupt-parent = <&intc>; - interrupts = <31>; - - clocks = <&cgu JZ4725B_CLK_LCD>; - clock-names = "lcd"; - - port { - panel_output: endpoint { - remote-endpoint = <&panel_input>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml new file mode 100644 index 000000000000..d56db1802fad --- /dev/null +++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ingenic SoCs LCD controller devicetree bindings + +maintainers: + - Paul Cercueil <paul@crapouillou.net> + +properties: + $nodename: + pattern: "^lcd-controller@[0-9a-f]+$" + + compatible: + enum: + - ingenic,jz4740-lcd + - ingenic,jz4725b-lcd + - ingenic,jz4770-lcd + - ingenic,jz4780-lcd + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel clock + - description: Module clock + minItems: 1 + + clock-names: + items: + - const: lcd_pclk + - const: lcd + minItems: 1 + + port: + description: OF graph bindings (specified in bindings/graph.txt). + + ports: + description: OF graph bindings (specified in bindings/graph.txt). + type: object + properties: + port@0: + type: object + description: DPI output, to interface with TFT panels. + + port@8: + type: object + description: Link to the Image Processing Unit (IPU). + (See ingenic,ipu.yaml). + + required: + - port@0 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +if: + properties: + compatible: + contains: + enum: + - ingenic,jz4740-lcd + - ingenic,jz4780-lcd +then: + properties: + clocks: + minItems: 2 + clock-names: + minItems: 2 +else: + properties: + clocks: + maxItems: 1 + clock-names: + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/jz4740-cgu.h> + lcd-controller@13050000 { + compatible = "ingenic,jz4740-lcd"; + reg = <0x13050000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <30>; + + clocks = <&cgu JZ4740_CLK_LCD_PCLK>, <&cgu JZ4740_CLK_LCD>; + clock-names = "lcd_pclk", "lcd"; + + port { + endpoint { + remote-endpoint = <&panel_input>; + }; + }; + }; + + - | + #include <dt-bindings/clock/jz4725b-cgu.h> + lcd-controller@13050000 { + compatible = "ingenic,jz4725b-lcd"; + reg = <0x13050000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <31>; + + clocks = <&cgu JZ4725B_CLK_LCD>; + clock-names = "lcd_pclk"; + + port { + endpoint { + remote-endpoint = <&panel_input>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index af95586c898f..7884fd7a85c1 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -87,6 +87,7 @@ Required properties: * "qcom,dsi-phy-20nm" * "qcom,dsi-phy-28nm-8960" * "qcom,dsi-phy-14nm" + * "qcom,dsi-phy-14nm-660" * "qcom,dsi-phy-10nm" * "qcom,dsi-phy-10nm-8998" - reg: Physical base address and length of the registers of PLL, PHY. Some diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index fd779cd6994d..1af0ff102b50 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -112,6 +112,34 @@ Example a6xx (with GMU): interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; interconnect-names = "gfx-mem"; + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-430000000 { + opp-hz = /bits/ 64 <430000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; + opp-peak-kBps = <5412000>; + }; + + opp-355000000 { + opp-hz = /bits/ 64 <355000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-180000000 { + opp-hz = /bits/ 64 <180000000>; + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; + opp-peak-kBps = <1804000>; + }; + }; + qcom,gmu = <&gmu>; zap-shader { diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt deleted file mode 100644 index 3ab8c7412cf6..000000000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt +++ /dev/null @@ -1,22 +0,0 @@ -Innolux P079ZCA 7.85" 768x1024 TFT LCD panel - -Required properties: -- compatible: should be "innolux,p079zca" -- reg: DSI virtual channel of the peripheral -- power-supply: phandle of the regulator that provides the supply voltage -- enable-gpios: panel enable gpio - -Optional properties: -- backlight: phandle of the backlight device attached to the panel - -Example: - - &mipi_dsi { - panel@0 { - compatible = "innolux,p079zca"; - reg = <0>; - power-supply = <...>; - backlight = <&backlight>; - enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt deleted file mode 100644 index dce48eb9db57..000000000000 --- a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt +++ /dev/null @@ -1,29 +0,0 @@ -Generic MIPI DSI Command Mode Panel -=================================== - -Required properties: -- compatible: "panel-dsi-cm" - -Optional properties: -- label: a symbolic name for the panel -- reset-gpios: panel reset gpio -- te-gpios: panel TE gpio - -Required nodes: -- Video port for DSI input - -Example -------- - -lcd0: display { - compatible = "tpo,taal", "panel-dsi-cm"; - label = "lcd0"; - - reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; - - port { - lcd0_in: endpoint { - remote-endpoint = <&dsi1_out_ep>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml new file mode 100644 index 000000000000..d766c949c622 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-dsi-cm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DSI command mode panels + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ti.com> + - Sebastian Reichel <sre@kernel.org> + +description: | + This binding file is a collection of the DSI panels that + are usually driven in command mode. If no backlight is + referenced via the optional backlight property, the DSI + panel is assumed to have native backlight support. + The panel may use an OF graph binding for the association + to the display, or it may be a direct child node of the + display. + +allOf: + - $ref: panel-common.yaml# + +properties: + + compatible: + items: + - enum: + - motorola,droid4-panel # Panel from Motorola Droid4 phone + - nokia,himalaya # Panel from Nokia N950 phone + - tpo,taal # Panel from OMAP4 SDP board + - const: panel-dsi-cm # Generic DSI command mode panel compatible fallback + + reg: + maxItems: 1 + description: DSI virtual channel + + vddi-supply: + description: + Display panels require power to be supplied. While several panels need + more than one power supply with panel-specific constraints governing the + order and timings of the power supplies, in many cases a single power + supply is sufficient, either because the panel has a single power rail, or + because all its power rails can be driven by the same supply. In that case + the vddi-supply property specifies the supply powering the panel as a + phandle to a regulator. + + vpnl-supply: + description: + When the display panel needs a second power supply, this property can be + used in addition to vddi-supply. Both supplies will be enabled at the + same time before the panel is being accessed. + + width-mm: true + height-mm: true + label: true + rotation: true + panel-timing: true + port: true + reset-gpios: true + te-gpios: true + backlight: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi-controller { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "tpo,taal", "panel-dsi-cm"; + reg = <0>; + reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 16778ce782fc..c0dd9fa29f1d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -33,6 +33,8 @@ properties: - auo,b080uan01 # Boe Corporation 8.0" WUXGA TFT LCD panel - boe,tv080wum-nl0 + # Innolux P079ZCA 7.85" 768x1024 TFT LCD panel + - innolux,p079zca # Kingdisplay KD097D04 9.7" 1536x2048 TFT LCD panel - kingdisplay,kd097d04 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca1479633..6deeeed59e59 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -81,6 +81,10 @@ properties: - boe,nv140fhmn49 # CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel - cdtech,s043wq26h-ct7 + # CDTech(H.K.) Electronics Limited 7" WSVGA (1024x600) TFT LCD Panel + - cdtech,s070pws19hp-fc21 + # CDTech(H.K.) Electronics Limited 7" WVGA (800x480) TFT LCD Panel + - cdtech,s070swv29hg-dc44 # CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel - cdtech,s070wv95-ct16 # Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel @@ -157,6 +161,8 @@ properties: - innolux,zj070na-01p # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel - koe,tx14d24vm1bpa + # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel + - koe,tx26d202vm0bwa # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel - koe,tx31d200vm0baa # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel @@ -245,6 +251,8 @@ properties: - starry,kr122ea0sra # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 + # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel + - tianma,tm070jvhg33 # Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel - tianma,tm070rvhg71 # Toshiba 8.9" WXGA (1280x768) TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt deleted file mode 100644 index a372c5d84695..000000000000 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt +++ /dev/null @@ -1,23 +0,0 @@ -Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel - -Required properties: -- compatible: should be "rocktech,jh057n00900" -- reg: DSI virtual channel of the peripheral -- reset-gpios: panel reset gpio -- backlight: phandle of the backlight device attached to the panel -- vcc-supply: phandle of the regulator that provides the vcc supply voltage. -- iovcc-supply: phandle of the regulator that provides the iovcc supply - voltage. - -Example: - - &mipi_dsi { - panel@0 { - compatible = "rocktech,jh057n00900"; - reg = <0>; - backlight = <&backlight>; - reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; - vcc-supply = <®_2v8_p>; - iovcc-supply = <®_1v8_p>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml new file mode 100644 index 000000000000..d5733ef30954 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel + +maintainers: + - Ondrej Jirman <megi@xff.cz> + +description: | + Rocktech JH057N00900 is a 720x1440 TFT LCD panel + connected using a MIPI-DSI video interface. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel + - rocktech,jh057n00900 + # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel + - xingbangda,xbd599 + + port: true + reg: + maxItems: 1 + description: DSI virtual channel + + vcc-supply: + description: Panel power supply + + iovcc-supply: + description: I/O voltage supply + + reset-gpios: + description: GPIO used for the reset pin + maxItems: 1 + + backlight: + description: Backlight used by the panel + $ref: "/schemas/types.yaml#/definitions/phandle" + +required: + - compatible + - reg + - vcc-supply + - iovcc-supply + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "rocktech,jh057n00900"; + reg = <0>; + vcc-supply = <®_2v8_p>; + iovcc-supply = <®_1v8_p>; + reset-gpios = <&gpio3 13 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt deleted file mode 100644 index 9e766c5f86da..000000000000 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt +++ /dev/null @@ -1,56 +0,0 @@ -Samsung S6E8AA0 AMOLED LCD 5.3 inch panel - -Required properties: - - compatible: "samsung,s6e8aa0" - - reg: the virtual channel number of a DSI peripheral - - vdd3-supply: core voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin - - display-timings: timings for the connected panel as described by [1] - -Optional properties: - - power-on-delay: delay after turning regulators on [ms] - - reset-delay: delay after reset sequence [ms] - - init-delay: delay after initialization sequence [ms] - - panel-width-mm: physical panel width [mm] - - panel-height-mm: physical panel height [mm] - - flip-horizontal: boolean to flip image horizontally - - flip-vertical: boolean to flip image vertically - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - panel { - compatible = "samsung,s6e8aa0"; - reg = <0>; - vdd3-supply = <&vcclcd_reg>; - vci-supply = <&vlcd_reg>; - reset-gpios = <&gpy4 5 0>; - power-on-delay= <50>; - reset-delay = <100>; - init-delay = <100>; - panel-width-mm = <58>; - panel-height-mm = <103>; - flip-horizontal; - flip-vertical; - - display-timings { - timing0: timing-0 { - clock-frequency = <57153600>; - hactive = <720>; - vactive = <1280>; - hfront-porch = <5>; - hback-porch = <5>; - hsync-len = <5>; - vfront-porch = <13>; - vback-porch = <1>; - vsync-len = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml new file mode 100644 index 000000000000..ca959451557e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6e8aa0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6E8AA0 AMOLED LCD 5.3 inch panel + +maintainers: + - Andrzej Hajda <a.hajda@samsung.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,s6e8aa0 + + reg: true + reset-gpios: true + display-timings: true + + vdd3-supply: + description: core voltage supply + + vci-supply: + description: voltage supply for analog circuits + + power-on-delay: + description: delay after turning regulators on [ms] + $ref: /schemas/types.yaml#/definitions/uint32 + + reset-delay: + description: delay after reset sequence [ms] + $ref: /schemas/types.yaml#/definitions/uint32 + + init-delay: + description: delay after initialization sequence [ms] + + panel-width-mm: + description: physical panel width [mm] + + panel-height-mm: + description: physical panel height [mm] + + flip-horizontal: + description: boolean to flip image horizontally + type: boolean + + flip-vertical: + description: boolean to flip image vertically + type: boolean + +required: + - compatible + - reg + - vdd3-supply + - vci-supply + - reset-gpios + - display-timings + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6e8aa0"; + reg = <0>; + vdd3-supply = <&vcclcd_reg>; + vci-supply = <&vlcd_reg>; + reset-gpios = <&gpy4 5 0>; + power-on-delay= <50>; + reset-delay = <100>; + init-delay = <100>; + panel-width-mm = <58>; + panel-height-mm = <103>; + flip-horizontal; + flip-vertical; + + display-timings { + timing0: timing-0 { + clock-frequency = <57153600>; + hactive = <720>; + vactive = <1280>; + hfront-porch = <5>; + hback-porch = <5>; + hsync-len = <5>; + vfront-porch = <13>; + vback-porch = <1>; + vsync-len = <2>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt deleted file mode 100644 index f522bb8e47e1..000000000000 --- a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt +++ /dev/null @@ -1,49 +0,0 @@ -Sharp Microelectronics 10.1" WQXGA TFT LCD panel - -This panel requires a dual-channel DSI host to operate. It supports two modes: -- left-right: each channel drives the left or right half of the screen -- even-odd: each channel drives the even or odd lines of the screen - -Each of the DSI channels controls a separate DSI peripheral. The peripheral -driven by the first link (DSI-LINK1), left or even, is considered the primary -peripheral and controls the device. The 'link2' property contains a phandle -to the peripheral driven by the second link (DSI-LINK2, right or odd). - -Note that in video mode the DSI-LINK1 interface always provides the left/even -pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it -is possible to program either link to drive the left/even or right/odd pixels -but for the sake of consistency this binding assumes that the same assignment -is chosen as for video mode. - -Required properties: -- compatible: should be "sharp,lq101r1sx01" -- reg: DSI virtual channel of the peripheral - -Required properties (for DSI-LINK1 only): -- link2: phandle to the DSI peripheral on the secondary link. Note that the - presence of this property marks the containing node as DSI-LINK1. -- power-supply: phandle of the regulator that provides the supply voltage - -Optional properties (for DSI-LINK1 only): -- backlight: phandle of the backlight device attached to the panel - -Example: - - dsi@54300000 { - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - }; - }; - - dsi@54400000 { - secondary: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - }; - }; diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml new file mode 100644 index 000000000000..a679d3647dbd --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,lq101r1sx01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp Microelectronics 10.1" WQXGA TFT LCD panel + +maintainers: + - Thierry Reding <treding@nvidia.com> + +description: | + This panel requires a dual-channel DSI host to operate. It supports two modes: + - left-right: each channel drives the left or right half of the screen + - even-odd: each channel drives the even or odd lines of the screen + + Each of the DSI channels controls a separate DSI peripheral. The peripheral + driven by the first link (DSI-LINK1), left or even, is considered the primary + peripheral and controls the device. The 'link2' property contains a phandle + to the peripheral driven by the second link (DSI-LINK2, right or odd). + + Note that in video mode the DSI-LINK1 interface always provides the left/even + pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it + is possible to program either link to drive the left/even or right/odd pixels + but for the sake of consistency this binding assumes that the same assignment + is chosen as for video mode. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sharp,lq101r1sx01 + + reg: true + power-supply: true + backlight: true + + link2: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + phandle to the DSI peripheral on the secondary link. Note that the + presence of this property marks the containing node as DSI-LINK1 + +required: + - compatible + - reg + +if: + required: + - link2 +then: + required: + - power-supply + +additionalProperties: false + +examples: + - | + dsi0: dsi@fd922800 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfd922800 0x200>; + + panel: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + + link2 = <&secondary>; + + power-supply = <&power>; + backlight = <&backlight>; + }; + }; + + dsi1: dsi@fd922a00 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0xfd922a00 0x200>; + + secondary: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 1db608c9eef5..eaf8c54fcf50 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -152,28 +152,28 @@ additionalProperties: false examples: - | - aliases { - display0 = &lcdc0; + / { + compatible = "foo"; + model = "foo"; + #address-cells = <1>; + #size-cells = <1>; + + chosen { + #address-cells = <1>; + #size-cells = <1>; + framebuffer0: framebuffer@1d385000 { + compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; + allwinner,pipeline = "de_be0-lcd0"; + reg = <0x1d385000 3840000>; + width = <1600>; + height = <1200>; + stride = <3200>; + format = "r5g6b5"; + clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; + lcd-supply = <®_dc1sw>; + display = <&lcdc0>; + }; + }; }; - chosen { - #address-cells = <1>; - #size-cells = <1>; - stdout-path = "display0"; - framebuffer0: framebuffer@1d385000 { - compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; - allwinner,pipeline = "de_be0-lcd0"; - reg = <0x1d385000 3840000>; - width = <1600>; - height = <1200>; - stride = <3200>; - format = "r5g6b5"; - clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; - lcd-supply = <®_dc1sw>; - display = <&lcdc0>; - }; - }; - - lcdc0: lcdc { }; - ... diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt index aac617acb64f..8b2a71395647 100644 --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -46,7 +46,7 @@ Optional nodes: crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is for Blue[3-7]. For more details see section 3.1.1 in AM335x Silicon Errata: - http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 + https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360 Example: diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml new file mode 100644 index 000000000000..52a939cade3b --- /dev/null +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/xlnx/xlnx,zynqmp-dpsub.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DisplayPort Subsystem + +description: | + The DisplayPort subsystem of Xilinx ZynqMP (Zynq UltraScale+ MPSoC) + implements the display and audio pipelines based on the DisplayPort v1.2 + standard. The subsystem includes multiple functional blocks as below: + + +------------------------------------------------------------+ + +--------+ | +----------------+ +-----------+ | + | DPDMA | --->| | --> | Video | Video +-------------+ | + | 4x vid | | | | | Rendering | -+--> | | | +------+ + | 2x aud | | | Audio/Video | --> | Pipeline | | | DisplayPort |---> | PHY0 | + +--------+ | | Buffer Manager | +-----------+ | | Source | | +------+ + | | and STC | +-----------+ | | Controller | | +------+ + Live Video --->| | --> | Audio | Audio | |---> | PHY1 | + | | | | Mixer | --+-> | | | +------+ + Live Audio --->| | --> | | || +-------------+ | + | +----------------+ +-----------+ || | + +---------------------------------------||-------------------+ + vv + Blended Video and + Mixed Audio to PL + + The Buffer Manager interacts with external interface such as DMA engines or + live audio/video streams from the programmable logic. The Video Rendering + Pipeline blends the video and graphics layers and performs colorspace + conversion. The Audio Mixer mixes the incoming audio streams. The DisplayPort + Source Controller handles the DisplayPort protocol and connects to external + PHYs. + + The subsystem supports 2 video and 2 audio streams, and various pixel formats + and depths up to 4K@30 resolution. + + Please refer to "Zynq UltraScale+ Device Technical Reference Manual" + (https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf) + for more details. + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +properties: + compatible: + const: xlnx,zynqmp-dpsub-1.7 + + reg: + maxItems: 4 + reg-names: + items: + - const: dp + - const: blend + - const: av_buf + - const: aud + + interrupts: + maxItems: 1 + + clocks: + description: + The APB clock and at least one video clock are mandatory, the audio clock + is optional. + minItems: 2 + maxItems: 4 + items: + - description: dp_apb_clk is the APB clock + - description: dp_aud_clk is the Audio clock + - description: + dp_vtc_pixel_clk_in is the non-live video clock (from Processing + System) + - description: + dp_live_video_in_clk is the live video clock (from Programmable + Logic) + clock-names: + oneOf: + - minItems: 2 + maxItems: 3 + items: + - const: dp_apb_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - minItems: 3 + maxItems: 4 + items: + - const: dp_apb_clk + - const: dp_aud_clk + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + maxItems: 4 + items: + - description: Video layer, plane 0 (RGB or luma) + - description: Video layer, plane 1 (U/V or U) + - description: Video layer, plane 2 (V) + - description: Graphics layer + dma-names: + items: + - const: vid0 + - const: vid1 + - const: vid2 + - const: gfx0 + + phys: + description: PHYs for the DP data lanes + minItems: 1 + maxItems: 2 + phy-names: + minItems: 1 + maxItems: 2 + items: + - const: dp-phy0 + - const: dp-phy1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - power-domains + - resets + - dmas + - dma-names + - phys + - phy-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/phy/phy.h> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h> + + display@fd4a0000 { + compatible = "xlnx,zynqmp-dpsub-1.7"; + reg = <0x0 0xfd4a0000 0x0 0x1000>, + <0x0 0xfd4aa000 0x0 0x1000>, + <0x0 0xfd4ab000 0x0 0x1000>, + <0x0 0xfd4ac000 0x0 0x1000>; + reg-names = "dp", "blend", "av_buf", "aud"; + interrupts = <0 119 4>; + interrupt-parent = <&gic>; + + clock-names = "dp_apb_clk", "dp_aud_clk", "dp_live_video_in_clk"; + clocks = <&dp_aclk>, <&clkc 17>, <&si570_1>; + + power-domains = <&pd_dp>; + resets = <&reset ZYNQMP_RESET_DP>; + + dma-names = "vid0", "vid1", "vid2", "gfx0"; + dmas = <&xlnx_dpdma 0>, + <&xlnx_dpdma 1>, + <&xlnx_dpdma 2>, + <&xlnx_dpdma 3>; + + phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>, + <&psgtr 0 PHY_TYPE_DP 1 3 27000000>; + + phy-names = "dp-phy0", "dp-phy1"; + }; + +... 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/dma/xilinx/xlnx,zynqmp-dpdma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml new file mode 100644 index 000000000000..5de510f8c88c --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dpdma.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dpdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DisplayPort DMA Controller Device Tree Bindings + +description: | + These bindings describe the DMA engine included in the Xilinx ZynqMP + DisplayPort Subsystem. The DMA engine supports up to 6 DMA channels (3 + channels for a video stream, 1 channel for a graphics stream, and 2 channels + for an audio stream). + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +allOf: + - $ref: "../dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + description: | + The cell is the DMA channel ID (see dt-bindings/dma/xlnx-zynqmp-dpdma.h + for a list of channel IDs). + + compatible: + const: xlnx,zynqmp-dpdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: The AXI clock + maxItems: 1 + + clock-names: + const: axi_clk + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dma: dma-controller@fd4c0000 { + compatible = "xlnx,zynqmp-dpdma"; + reg = <0x0 0xfd4c0000 0x0 0x1000>; + interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + clocks = <&dpdma_clk>; + clock-names = "axi_clk"; + #dma-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index 8ab19d1d3f9a..e811cf825019 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -493,4 +493,4 @@ FPGA Bridges that exist on the FPGA fabric prior to the partial reconfiguration. -- [1] www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_partrecon.pdf [2] tspace.library.utoronto.ca/bitstream/1807/67932/1/Byma_Stuart_A_201411_MAS_thesis.pdf -[3] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf +[3] https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/ug702.pdf diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt index cfa4ed42b62f..5ef659c1394d 100644 --- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt +++ b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt @@ -1,11 +1,14 @@ Xilinx Slave Serial SPI FPGA Manager -Xilinx Spartan-6 FPGAs support a method of loading the bitstream over -what is referred to as "slave serial" interface. +Xilinx Spartan-6 and 7 Series FPGAs support a method of loading the +bitstream over what is referred to as "slave serial" interface. The slave serial link is not technically SPI, and might require extra circuits in order to play nicely with other SPI slaves on the same bus. -See https://www.xilinx.com/support/documentation/user_guides/ug380.pdf +See: +- https://www.xilinx.com/support/documentation/user_guides/ug380.pdf +- https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf +- https://www.xilinx.com/support/documentation/application_notes/xapp583-fpga-configuration.pdf Required properties: - compatible: should contain "xlnx,fpga-slave-serial" @@ -13,6 +16,10 @@ Required properties: - prog_b-gpios: config pin (referred to as PROGRAM_B in the manual) - done-gpios: config status pin (referred to as DONE in the manual) +Optional properties: +- init-b-gpios: initialization status and configuration error pin + (referred to as INIT_B in the manual) + Example for full FPGA configuration: fpga-region0 { @@ -37,7 +44,8 @@ Example for full FPGA configuration: spi-max-frequency = <60000000>; spi-cpha; reg = <0>; - done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; prog_b-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>; + init-b-gpios = <&gpio0 28 GPIO_ACTIVE_LOW>; + done-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; }; }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index dab537c20def..3126c3817e2a 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -19,6 +19,7 @@ Required properties: nxp,pca9698 nxp,pcal6416 nxp,pcal6524 + nxp,pcal9535 nxp,pcal9555a maxim,max7310 maxim,max7312 diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml new file mode 100644 index 000000000000..338c5312a106 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-pca9570.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-pca9570.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCA9570 I2C GPO expander + +maintainers: + - Sungbo Eo <mans0n@gorani.run> + +properties: + compatible: + enum: + - nxp,pca9570 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + gpio@24 { + compatible = "nxp,pca9570"; + reg = <0x24>; + gpio-controller; + #gpio-cells = <2>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt index 4fa4eb5507cd..f693e82b4c0f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -6,7 +6,9 @@ Required properties: - First cell is the GPIO line number - Second cell is used to specify optional parameters (unused) -- compatible : Should be "xlnx,zynq-gpio-1.0" or "xlnx,zynqmp-gpio-1.0" +- compatible : Should be "xlnx,zynq-gpio-1.0" or + "xlnx,zynqmp-gpio-1.0" or "xlnx,versal-gpio-1.0 + or "xlnx,pmc-gpio-1.0 - clocks : Clock specifier (see clock bindings for details) - gpio-controller : Marks the device node as a GPIO controller. - interrupts : Interrupt specifier (see interrupt bindings for diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt deleted file mode 100644 index 30fd2201b3d4..000000000000 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ /dev/null @@ -1,48 +0,0 @@ -* Marvell PXA GPIO controller - -Required properties: -- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio", - "intel,pxa27x-gpio", "intel,pxa3xx-gpio", - "marvell,pxa93x-gpio", "marvell,mmp-gpio", - "marvell,mmp2-gpio" or marvell,pxa1928-gpio. -- reg : Address and length of the register set for the device -- interrupts : Should be the port interrupt shared by all gpio pins. - There're three gpio interrupts in arch-pxa, and they're gpio0, - gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp, - gpio_mux. -- interrupt-names : Should be the names of irq resources. Each interrupt - uses its own interrupt name, so there should be as many interrupt names - as referenced interrupts. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. -- gpio-controller : Marks the device node as a gpio controller. -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. See gpio.txt for possible - values. - -Example for a MMP platform: - - gpio: gpio@d4019000 { - compatible = "marvell,mmp-gpio"; - reg = <0xd4019000 0x1000>; - interrupts = <49>; - interrupt-names = "gpio_mux"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <1>; - }; - -Example for a PXA3xx platform: - - gpio: gpio@40e00000 { - compatible = "intel,pxa3xx-gpio"; - reg = <0x40e00000 0x10000>; - interrupt-names = "gpio0", "gpio1", "gpio_mux"; - interrupts = <8 9 10>; - gpio-controller; - #gpio-cells = <0x2>; - interrupt-controller; - #interrupt-cells = <0x2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml new file mode 100644 index 000000000000..4db3b8a3332c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/mrvl-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell PXA GPIO controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Bartosz Golaszewski <bgolaszewski@baylibre.com> + - Rob Herring <robh+dt@kernel.org> + +allOf: + - if: + properties: + compatible: + contains: + enum: + - intel,pxa25x-gpio + - intel,pxa26x-gpio + - intel,pxa27x-gpio + - intel,pxa3xx-gpio + then: + properties: + interrupts: + minItems: 3 + maxItems: 3 + interrupt-names: + items: + - const: gpio0 + - const: gpio1 + - const: gpio_mux + - if: + properties: + compatible: + contains: + enum: + - marvell,mmp-gpio + - marvell,mmp2-gpio + then: + properties: + interrupts: + maxItems: 1 + interrupt-names: + items: + - const: gpio_mux + +properties: + $nodename: + pattern: '^gpio@[0-9a-f]+$' + + compatible: + enum: + - intel,pxa25x-gpio + - intel,pxa26x-gpio + - intel,pxa27x-gpio + - intel,pxa3xx-gpio + - marvell,mmp-gpio + - marvell,mmp2-gpio + - marvell,pxa93x-gpio + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: true + + interrupt-names: true + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +patternProperties: + '^gpio@[0-9a-f]*$': + type: object + properties: + reg: + maxItems: 1 + + required: + - reg + + additionalProperties: false + +required: + - compatible + - '#address-cells' + - '#size-cells' + - reg + - gpio-controller + - '#gpio-cells' + - interrupts + - interrupt-names + - interrupt-controller + - '#interrupt-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/pxa-clock.h> + gpio@40e00000 { + compatible = "intel,pxa3xx-gpio"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x40e00000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <8>, <9>, <10>; + interrupt-names = "gpio0", "gpio1", "gpio_mux"; + clocks = <&clks CLK_GPIO>; + interrupt-controller; + #interrupt-cells = <2>; + }; + - | + #include <dt-bindings/clock/marvell,pxa910.h> + gpio@d4019000 { + compatible = "marvell,mmp-gpio"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xd4019000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <49>; + interrupt-names = "gpio_mux"; + clocks = <&soc_clocks PXA910_CLK_GPIO>; + resets = <&soc_clocks PXA910_CLK_GPIO>; + interrupt-controller; + #interrupt-cells = <2>; + ranges; + + gpio@d4019000 { + reg = <0xd4019000 0x4>; + }; + + gpio@d4019004 { + reg = <0xd4019004 0x4>; + }; + + gpio@d4019008 { + reg = <0xd4019008 0x4>; + }; + + gpio@d4019100 { + reg = <0xd4019100 0x4>; + }; + }; + +... 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/hwmon/microchip,sparx5-temp.yaml b/Documentation/devicetree/bindings/hwmon/microchip,sparx5-temp.yaml new file mode 100644 index 000000000000..76be625d5646 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/microchip,sparx5-temp.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/microchip,sparx5-temp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Temperature Monitor + +maintainers: + - Lars Povlsen <lars.povlsen@microchip.com> + +description: | + Microchip Sparx5 embedded temperature monitor + +properties: + compatible: + enum: + - microchip,sparx5-temp + + reg: + maxItems: 1 + + clocks: + items: + - description: AHB reference clock + + '#thermal-sensor-cells': + const: 0 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + tmon0: tmon@610508110 { + compatible = "microchip,sparx5-temp"; + reg = <0x10508110 0xc>; + #thermal-sensor-cells = <0>; + clocks = <&ahb_clk>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml index 90b2fa3f7752..c17e5d3ee3f1 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml @@ -18,8 +18,8 @@ description: | consumption. Datasheets: - http://www.ti.com/lit/gpn/tmp513 - http://www.ti.com/lit/gpn/tmp512 + https://www.ti.com/lit/gpn/tmp513 + https://www.ti.com/lit/gpn/tmp512 properties: diff --git a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml index da6129090a8e..78ffcab2428c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml @@ -52,15 +52,15 @@ properties: description: sda and scl gpio, alternative for {sda,scl}-gpios i2c-gpio,sda-open-drain: - # Generate a warning if present - not: true + type: boolean + deprecated: true description: this means that something outside of our control has put the GPIO line used for SDA into open drain mode, and that something is not the GPIO chip. It is essentially an inconsistency flag. i2c-gpio,scl-open-drain: - # Generate a warning if present - not: true + type: boolean + deprecated: true description: this means that something outside of our control has put the GPIO line used for SCL into open drain mode, and that something is not the GPIO chip. It is essentially an inconsistency flag. diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt deleted file mode 100644 index f0c072ff9eca..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale Low Power Inter IC (LPI2C) for i.MX - -Required properties: -- compatible : - - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc - - "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on i.MX8QXP soc - - "fsl,imx8qm-lpi2c" for LPI2C compatible with the one integrated on i.MX8QM soc -- reg : address and length of the lpi2c master registers -- interrupts : lpi2c interrupt -- clocks : lpi2c clock specifier - -Examples: - -lpi2c7: lpi2c7@40a50000 { - compatible = "fsl,imx7ulp-lpi2c"; - reg = <0x40A50000 0x10000>; - interrupt-parent = <&intc>; - interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX7ULP_CLK_LPI2C7>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml new file mode 100644 index 000000000000..ac0bc5dd64d6 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-imx-lpi2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Low Power Inter IC (LPI2C) for i.MX + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + enum: + - fsl,imx7ulp-lpi2c + - fsl,imx8qxp-lpi2c + - fsl,imx8qm-lpi2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx7ulp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + lpi2c7@40a50000 { + compatible = "fsl,imx7ulp-lpi2c"; + reg = <0x40A50000 0x10000>; + interrupt-parent = <&intc>; + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX7ULP_CLK_LPI2C7>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt deleted file mode 100644 index b967544590e8..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX - -Required properties: -- compatible : - - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC - - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC - - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC -- reg : Should contain I2C/HS-I2C registers location and length -- interrupts : Should contain I2C/HS-I2C interrupt -- clocks : Should contain the I2C/HS-I2C clock specifier - -Optional properties: -- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. - The absence of the property indicates the default frequency 100 kHz. -- dmas: A list of two dma specifiers, one for each entry in dma-names. -- dma-names: should contain "tx" and "rx". -- scl-gpios: specify the gpio related to SCL pin -- sda-gpios: specify the gpio related to SDA pin -- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c - bus recovery, call it "gpio" state - -Examples: - -i2c@83fc4000 { /* I2C2 on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; - reg = <0x83fc4000 0x4000>; - interrupts = <63>; -}; - -i2c@70038000 { /* HS-I2C on i.MX51 */ - compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; - reg = <0x70038000 0x4000>; - interrupts = <64>; - clock-frequency = <400000>; -}; - -i2c0: i2c@40066000 { /* i2c0 on vf610 */ - compatible = "fsl,vf610-i2c"; - reg = <0x40066000 0x1000>; - interrupts =<0 71 0x04>; - dmas = <&edma0 0 50>, - <&edma0 0 51>; - dma-names = "rx","tx"; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&pinctrl_i2c1>; - pinctrl-1 = <&pinctrl_i2c1_gpio>; - scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; - sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml new file mode 100644 index 000000000000..869f2ae3d5b3 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-imx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX + +maintainers: + - Wolfram Sang <wolfram@the-dreams.de> + +properties: + compatible: + oneOf: + - const: fsl,imx1-i2c + - const: fsl,imx21-i2c + - const: fsl,vf610-i2c + - items: + - const: fsl,imx35-i2c + - const: fsl,imx1-i2c + - items: + - enum: + - fsl,imx25-i2c + - fsl,imx27-i2c + - fsl,imx31-i2c + - fsl,imx50-i2c + - fsl,imx51-i2c + - fsl,imx53-i2c + - fsl,imx6q-i2c + - fsl,imx6sl-i2c + - fsl,imx6sx-i2c + - fsl,imx6sll-i2c + - fsl,imx6ul-i2c + - fsl,imx7s-i2c + - fsl,imx8mq-i2c + - fsl,imx8mm-i2c + - fsl,imx8mn-i2c + - fsl,imx8mp-i2c + - const: fsl,imx21-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: ipg + + clock-frequency: + enum: [ 100000, 400000 ] + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + + sda-gpios: + maxItems: 1 + + scl-gpios: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx5-clock.h> + #include <dt-bindings/clock/vf610-clock.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c@83fc4000 { + compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; + reg = <0x83fc4000 0x4000>; + interrupts = <63>; + clocks = <&clks IMX5_CLK_I2C2_GATE>; + }; + + i2c@40066000 { + compatible = "fsl,vf610-i2c"; + reg = <0x40066000 0x1000>; + interrupts = <71 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_I2C0>; + clock-names = "ipg"; + dmas = <&edma0 0 50>, + <&edma0 0 51>; + dma-names = "rx", "tx"; + }; 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-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt deleted file mode 100644 index 4e1c8ac01eba..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Freescale MXS Inter IC (I2C) Controller - -Required properties: -- compatible: Should be "fsl,<chip>-i2c" -- reg: Should contain registers location and length -- interrupts: Should contain ERROR interrupt number -- clock-frequency: Desired I2C bus clock frequency in Hz. - Only 100000Hz and 400000Hz modes are supported. -- dmas: DMA specifier, consisting of a phandle to DMA controller node - and I2C DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. -- dma-names: Must be "rx-tx". - -Examples: - -i2c0: i2c@80058000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx28-i2c"; - reg = <0x80058000 2000>; - interrupts = <111>; - clock-frequency = <100000>; - dmas = <&dma_apbx 6>; - dma-names = "rx-tx"; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml new file mode 100644 index 000000000000..d3134ed775fa --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mxs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS Inter IC (I2C) Controller + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +properties: + compatible: + enum: + - fsl,imx23-i2c + - fsl,imx28-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + enum: [ 100000, 400000 ] + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + i2c@80058000 { + compatible = "fsl,imx28-i2c"; + reg = <0x80058000 2000>; + interrupts = <111>; + clock-frequency = <100000>; + dmas = <&dma_apbx 6>; + dma-names = "rx-tx"; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt deleted file mode 100644 index c30783c0eca0..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt +++ /dev/null @@ -1,31 +0,0 @@ -* Marvell MMP I2C controller - -Required properties : - - - reg : Offset and length of the register set for the device - - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a - compatible processor, e.g. pxa168, pxa910, mmp2, mmp3. - For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required - as shown in the example below. - For the Armada 3700, the compatible should be "marvell,armada-3700-i2c". - -Recommended properties : - - - interrupts : the interrupt number - - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling - status register of i2c controller instead. - - mrvl,i2c-fast-mode : Enable fast mode of i2c controller. - -Examples: - twsi1: i2c@d4011000 { - compatible = "mrvl,mmp-twsi"; - reg = <0xd4011000 0x1000>; - interrupts = <7>; - mrvl,i2c-fast-mode; - }; - - twsi2: i2c@d4025000 { - compatible = "mrvl,mmp-twsi"; - reg = <0xd4025000 0x1000>; - interrupts = <58>; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml new file mode 100644 index 000000000000..da6e8bdc4037 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-pxa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP I2C controller bindings + +maintainers: + - Rob Herring <robh+dt@kernel.org> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + not: + required: + - mrvl,i2c-polling + then: + required: + - interrupts + +properties: + compatible: + enum: + - mrvl,mmp-twsi + - mrvl,pxa-i2c + - marvell,armada-3700-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + + resets: + minItems: 1 + + mrvl,i2c-polling: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Disable interrupt of i2c controller. Polling status register of i2c + controller instead. + + mrvl,i2c-fast-mode: + $ref: /schemas/types.yaml#/definitions/flag + description: Enable fast mode of i2c controller. + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - '#address-cells' + - '#size-cells' + +examples: + - | + #include <dt-bindings/clock/marvell,mmp2.h> + i2c@d4011000 { + compatible = "mrvl,mmp-twsi"; + reg = <0xd4011000 0x1000>; + interrupts = <7>; + clocks = <&soc_clocks MMP2_CLK_TWSI1>; + mrvl,i2c-fast-mode; + #address-cells = <1>; + #size-cells = <0>; + }; + +... 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/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt index c82794002595..89647d714387 100644 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt @@ -21,7 +21,7 @@ controller state. The mux controller state is described in Example: mux: mux-controller { - compatible = "mux-gpio"; + compatible = "gpio-mux"; #mux-control-cells = <0>; mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, 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/imx-keypad.txt b/Documentation/devicetree/bindings/input/imx-keypad.txt deleted file mode 100644 index 2ebaf7d26843..000000000000 --- a/Documentation/devicetree/bindings/input/imx-keypad.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Freescale i.MX Keypad Port(KPP) device tree bindings - -The KPP is designed to interface with a keypad matrix with 2-point contact -or 3-point contact keys. The KPP is designed to simplify the software task -of scanning a keypad matrix. The KPP is capable of detecting, debouncing, -and decoding one or multiple keys pressed simultaneously on a keypad. - -Required SoC Specific Properties: -- compatible: Should be "fsl,<soc>-kpp". - -- reg: Physical base address of the KPP and length of memory mapped - region. - -- interrupts: The KPP interrupt number to the CPU(s). - -- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy -clock(The clock for the KPP is provided by the SoCs automatically). - -Required Board Specific Properties: -- pinctrl-names: The definition can be found at -pinctrl/pinctrl-bindings.txt. - -- pinctrl-0: The definition can be found at -pinctrl/pinctrl-bindings.txt. - -- linux,keymap: The definition can be found at -bindings/input/matrix-keymap.txt. - -Example: -kpp: kpp@73f94000 { - compatible = "fsl,imx51-kpp", "fsl,imx21-kpp"; - reg = <0x73f94000 0x4000>; - interrupts = <60>; - clocks = <&clks 0>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_kpp_1>; - linux,keymap = <0x00000067 /* KEY_UP */ - 0x0001006c /* KEY_DOWN */ - 0x00020072 /* KEY_VOLUMEDOWN */ - 0x00030066 /* KEY_HOME */ - 0x0100006a /* KEY_RIGHT */ - 0x01010069 /* KEY_LEFT */ - 0x0102001c /* KEY_ENTER */ - 0x01030073 /* KEY_VOLUMEUP */ - 0x02000040 /* KEY_F6 */ - 0x02010042 /* KEY_F8 */ - 0x02020043 /* KEY_F9 */ - 0x02030044 /* KEY_F10 */ - 0x0300003b /* KEY_F1 */ - 0x0301003c /* KEY_F2 */ - 0x0302003d /* KEY_F3 */ - 0x03030074>; /* KEY_POWER */ -}; diff --git a/Documentation/devicetree/bindings/input/imx-keypad.yaml b/Documentation/devicetree/bindings/input/imx-keypad.yaml new file mode 100644 index 000000000000..7432c6e8cf3a --- /dev/null +++ b/Documentation/devicetree/bindings/input/imx-keypad.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/imx-keypad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX Keypad Port(KPP) device tree bindings + +maintainers: + - Liu Ying <gnuiyl@gmail.com> + +allOf: + - $ref: "/schemas/input/matrix-keymap.yaml#" + +description: | + The KPP is designed to interface with a keypad matrix with 2-point contact + or 3-point contact keys. The KPP is designed to simplify the software task + of scanning a keypad matrix. The KPP is capable of detecting, debouncing, + and decoding one or multiple keys pressed simultaneously on a keypad. + +properties: + compatible: + oneOf: + - const: fsl,imx21-kpp + - items: + - enum: + - fsl,imx25-kpp + - fsl,imx27-kpp + - fsl,imx31-kpp + - fsl,imx35-kpp + - fsl,imx51-kpp + - fsl,imx53-kpp + - fsl,imx50-kpp + - fsl,imx6q-kpp + - fsl,imx6sx-kpp + - fsl,imx6sl-kpp + - fsl,imx6sll-kpp + - fsl,imx6ul-kpp + - fsl,imx7d-kpp + - const: fsl,imx21-kpp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - linux,keymap + +unevaluatedProperties: false + +examples: + - | + keypad@73f94000 { + compatible = "fsl,imx51-kpp", "fsl,imx21-kpp"; + reg = <0x73f94000 0x4000>; + interrupts = <60>; + clocks = <&clks 0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_kpp_1>; + linux,keymap = <0x00000067 /* KEY_UP */ + 0x0001006c /* KEY_DOWN */ + 0x00020072 /* KEY_VOLUMEDOWN */ + 0x00030066 /* KEY_HOME */ + 0x0100006a /* KEY_RIGHT */ + 0x01010069 /* KEY_LEFT */ + 0x0102001c /* KEY_ENTER */ + 0x01030073 /* KEY_VOLUMEUP */ + 0x02000040 /* KEY_F6 */ + 0x02010042 /* KEY_F8 */ + 0x02020043 /* KEY_F9 */ + 0x02030044 /* KEY_F10 */ + 0x0300003b /* KEY_F1 */ + 0x0301003c /* KEY_F2 */ + 0x0302003d /* KEY_F3 */ + 0x03030074>; /* KEY_POWER */ + }; diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt index c54919fad17e..79f6d01aecaa 100644 --- a/Documentation/devicetree/bindings/input/matrix-keymap.txt +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -1,27 +1 @@ -A simple common binding for matrix-connected key boards. Currently targeted at -defining the keys in the scope of linux key codes since that is a stable and -standardized interface at this time. - -Required properties: -- linux,keymap: an array of packed 1-cell entries containing the equivalent - of row, column and linux key-code. The 32-bit big endian cell is packed - as: - row << 24 | column << 16 | key-code - -Optional properties: -Properties for the number of rows and columns are optional because some -drivers will use fixed values for these. -- keypad,num-rows: Number of row lines connected to the keypad controller. -- keypad,num-columns: Number of column lines connected to the keypad - controller. - -Some users of this binding might choose to specify secondary keymaps for -cases where there is a modifier key such as a Fn key. Proposed names -for said properties are "linux,fn-keymap" or with another descriptive -word for the modifier other from "Fn". - -Example: - linux,keymap = < 0x00030012 - 0x0102003a >; - keypad,num-rows = <2>; - keypad,num-columns = <8>; +This file has been moved to matrix-keymap.yaml diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.yaml b/Documentation/devicetree/bindings/input/matrix-keymap.yaml new file mode 100644 index 000000000000..c3bf09156783 --- /dev/null +++ b/Documentation/devicetree/bindings/input/matrix-keymap.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/matrix-keymap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common key matrices binding for matrix-connected key boards + +maintainers: + - Olof Johansson <olof@lixom.net> + +description: | + A simple common binding for matrix-connected key boards. Currently targeted at + defining the keys in the scope of linux key codes since that is a stable and + standardized interface at this time. + + Some users of this binding might choose to specify secondary keymaps for + cases where there is a modifier key such as a Fn key. Proposed names + for said properties are "linux,fn-keymap" or with another descriptive + word for the modifier other from "Fn". + +properties: + linux,keymap: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + description: | + An array of packed 1-cell entries containing the equivalent of row, + column and linux key-code. The 32-bit big endian cell is packed as: + row << 24 | column << 16 | key-code + + keypad,num-rows: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of row lines connected to the keypad controller. + + keypad,num-columns: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of column lines connected to the keypad controller. + +examples: + - | + keypad { + /* ... */ + linux,keymap = < 0x00030012 + 0x0102003a >; + keypad,num-rows = <2>; + keypad,num-columns = <8>; + }; 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/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index b1db21ed44e9..03fc4f5b4b39 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -51,8 +51,8 @@ properties: description: | This property points how the children interrupts will be mapped into CPU interrupt lines. Each cell refers to a parent interrupt line from 0 to 3 - and each bit in the cell refers to a children interrupt fron 0 to 31. - If a CPU interrupt line didn't connected with liointc, then keep it's + and each bit in the cell refers to a child interrupt from 0 to 31. + If a CPU interrupt line didn't connect with liointc, then keep its cell with zero. $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 4 diff --git a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt b/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt deleted file mode 100644 index 173595305e26..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt +++ /dev/null @@ -1,67 +0,0 @@ -MIPS Global Interrupt Controller (GIC) - -The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. -It also supports local (per-processor) interrupts and software-generated -interrupts which can be used as IPIs. The GIC also includes a free-running -global timer, per-CPU count/compare timers, and a watchdog. - -Required properties: -- compatible : Should be "mti,gic". -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt specifier. Should be 3. - - The first cell is the type of interrupt, local or shared. - See <include/dt-bindings/interrupt-controller/mips-gic.h>. - - The second cell is the GIC interrupt number. - - The third cell encodes the interrupt flags. - See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid - flags. - -Optional properties: -- reg : Base address and length of the GIC registers. If not present, - the base address reported by the hardware GCR_GIC_BASE will be used. -- mti,reserved-cpu-vectors : Specifies the list of CPU interrupt vectors - to which the GIC may not route interrupts. Valid values are 2 - 7. - This property is ignored if the CPU is started in EIC mode. -- mti,reserved-ipi-vectors : Specifies the range of GIC interrupts that are - reserved for IPIs. - It accepts 2 values, the 1st is the starting interrupt and the 2nd is the size - of the reserved range. - If not specified, the driver will allocate the last 2 * number of VPEs in the - system. - -Required properties for timer sub-node: -- compatible : Should be "mti,gic-timer". -- interrupts : Interrupt for the GIC local timer. - -Optional properties for timer sub-node: -- clocks : GIC timer operating clock. -- clock-frequency : Clock frequency at which the GIC timers operate. - -Note that one of clocks or clock-frequency must be specified. - -Example: - - gic: interrupt-controller@1bdc0000 { - compatible = "mti,gic"; - reg = <0x1bdc0000 0x20000>; - - interrupt-controller; - #interrupt-cells = <3>; - - mti,reserved-cpu-vectors = <7>; - mti,reserved-ipi-vectors = <40 8>; - - timer { - compatible = "mti,gic-timer"; - interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>; - clock-frequency = <50000000>; - }; - }; - - uart@18101400 { - ... - interrupt-parent = <&gic>; - interrupts = <GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>; - ... - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt deleted file mode 100644 index a0ed02725a9d..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt +++ /dev/null @@ -1,64 +0,0 @@ -* Marvell MMP Interrupt controller - -Required properties: -- compatible : Should be - "mrvl,mmp-intc" on Marvel MMP, - "mrvl,mmp2-intc" along with "mrvl,mmp2-mux-intc" on MMP2 or - "marvell,mmp3-intc" with "mrvl,mmp2-mux-intc" on MMP3 -- reg : Address and length of the register set of the interrupt controller. - If the interrupt controller is intc, address and length means the range - of the whole interrupt controller. The "marvell,mmp3-intc" controller - also has a secondary range for the second CPU core. If the interrupt - controller is mux-intc, address and length means one register. Since - address of mux-intc is in the range of intc. mux-intc is secondary - interrupt controller. -- reg-names : Name of the register set of the interrupt controller. It's - only required in mux-intc interrupt controller. -- interrupts : Should be the port interrupt shared by mux interrupts. It's - only required in mux-intc interrupt controller. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. -- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt - controller. -- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge - detection first. - -Example: - intc: interrupt-controller@d4282000 { - compatible = "mrvl,mmp2-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd4282000 0x1000>; - mrvl,intc-nr-irqs = <64>; - }; - - intcmux4@d4282150 { - compatible = "mrvl,mmp2-mux-intc"; - interrupts = <4>; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x150 0x4>, <0x168 0x4>; - reg-names = "mux status", "mux mask"; - mrvl,intc-nr-irqs = <2>; - }; - -* Marvell Orion Interrupt controller - -Required properties -- compatible : Should be "marvell,orion-intc". -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. Supported value is <1>. -- interrupt-controller : Declare this node to be an interrupt controller. -- reg : Interrupt mask address. A list of 4 byte ranges, one per controller. - One entry in the list represents 32 interrupts. - -Example: - - intc: interrupt-controller { - compatible = "marvell,orion-intc", "marvell,intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xfed20204 0x04>, - <0xfed20214 0x04>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml new file mode 100644 index 000000000000..372ccbfae771 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/mrvl,intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP/Orion Interrupt controller bindings + +maintainers: + - Thomas Gleixner <tglx@linutronix.de> + - Jason Cooper <jason@lakedaemon.net> + - Marc Zyngier <maz@kernel.org> + - Rob Herring <robh+dt@kernel.org> + +allOf: + - if: + properties: + compatible: + not: + contains: + const: marvell,orion-intc + then: + required: + - mrvl,intc-nr-irqs + - if: + properties: + compatible: + contains: + enum: + - mrvl,mmp-intc + - mrvl,mmp2-intc + then: + properties: + reg: + maxItems: 1 + - if: + properties: + compatible: + contains: + enum: + - marvell,mmp3-intc + - mrvl,mmp2-mux-intc + then: + properties: + reg: + minItems: 2 + - if: + properties: + compatible: + contains: + const: mrvl,mmp2-mux-intc + then: + properties: + interrupts: + maxItems: 1 + reg-names: + items: + - const: 'mux status' + - const: 'mux mask' + required: + - interrupts + else: + properties: + interrupts: false + +properties: + '#interrupt-cells': + const: 1 + + compatible: + enum: + - mrvl,mmp-intc + - mrvl,mmp2-intc + - marvell,mmp3-intc + - marvell,orion-intc + - mrvl,mmp2-mux-intc + + reg: + minItems: 1 + maxItems: 2 + + reg-names: true + + interrupts: true + + interrupt-controller: true + + mrvl,intc-nr-irqs: + description: | + Specifies the number of interrupts in the interrupt controller. + $ref: /schemas/types.yaml#/definitions/uint32 + + mrvl,clr-mfp-irq: + description: | + Specifies the interrupt that needs to clear MFP edge detection first. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - '#interrupt-cells' + - compatible + - reg + - interrupt-controller + +additionalProperties: false + +examples: + - | + interrupt-controller@d4282000 { + compatible = "mrvl,mmp2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xd4282000 0x1000>; + mrvl,intc-nr-irqs = <64>; + }; + + interrupt-controller@d4282150 { + compatible = "mrvl,mmp2-mux-intc"; + interrupts = <4>; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x150 0x4>, <0x168 0x4>; + reg-names = "mux status", "mux mask"; + mrvl,intc-nr-irqs = <2>; + }; + - | + interrupt-controller@fed20204 { + compatible = "marvell,orion-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xfed20204 0x04>, + <0xfed20214 0x04>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml new file mode 100644 index 000000000000..9f0eb3addac4 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mti,gic.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/mti,gic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPS Global Interrupt Controller + +maintainers: + - Paul Burton <paulburton@kernel.org> + - Thomas Bogendoerfer <tsbogend@alpha.franken.de> + +description: | + The MIPS GIC routes external interrupts to individual VPEs and IRQ pins. + It also supports local (per-processor) interrupts and software-generated + interrupts which can be used as IPIs. The GIC also includes a free-running + global timer, per-CPU count/compare timers, and a watchdog. + +properties: + compatible: + const: mti,gic + + "#interrupt-cells": + const: 3 + description: | + The 1st cell is the type of interrupt: local or shared defined in the + file 'dt-bindings/interrupt-controller/mips-gic.h'. The 2nd cell is the + GIC interrupt number. The 3d cell encodes the interrupt flags setting up + the IRQ trigger modes, which are defined in the file + 'dt-bindings/interrupt-controller/irq.h'. + + reg: + description: | + Base address and length of the GIC registers space. If not present, + the base address reported by the hardware GCR_GIC_BASE will be used. + maxItems: 1 + + interrupt-controller: true + + mti,reserved-cpu-vectors: + description: | + Specifies the list of CPU interrupt vectors to which the GIC may not + route interrupts. This property is ignored if the CPU is started in EIC + mode. + allOf: + - $ref: /schemas/types.yaml#definitions/uint32-array + - minItems: 1 + maxItems: 6 + uniqueItems: true + items: + minimum: 2 + maximum: 7 + + mti,reserved-ipi-vectors: + description: | + Specifies the range of GIC interrupts that are reserved for IPIs. + It accepts two values: the 1st is the starting interrupt and the 2nd is + the size of the reserved range. If not specified, the driver will + allocate the last (2 * number of VPEs in the system). + allOf: + - $ref: /schemas/types.yaml#definitions/uint32-array + - items: + - minimum: 0 + maximum: 254 + - minimum: 2 + maximum: 254 + + timer: + type: object + description: | + MIPS GIC includes a free-running global timer, per-CPU count/compare + timers, and a watchdog. Currently only the GIC Timer is supported. + properties: + compatible: + const: mti,gic-timer + + interrupts: + description: | + Interrupt for the GIC local timer, so normally it's suppose to be of + <GIC_LOCAL X IRQ_TYPE_NONE> format. + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: true + + required: + - compatible + - interrupts + + oneOf: + - required: + - clocks + - required: + - clock-frequency + + additionalProperties: false + +unevaluatedProperties: false + +required: + - compatible + - "#interrupt-cells" + - interrupt-controller + +examples: + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + interrupt-controller@1bdc0000 { + compatible = "mti,gic"; + reg = <0x1bdc0000 0x20000>; + interrupt-controller; + #interrupt-cells = <3>; + mti,reserved-cpu-vectors = <7>; + mti,reserved-ipi-vectors = <40 8>; + + timer { + compatible = "mti,gic-timer"; + interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>; + clock-frequency = <50000000>; + }; + }; + - | + #include <dt-bindings/interrupt-controller/mips-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + interrupt-controller@1bdc0000 { + compatible = "mti,gic"; + reg = <0x1bdc0000 0x20000>; + interrupt-controller; + #interrupt-cells = <3>; + + timer { + compatible = "mti,gic-timer"; + interrupts = <GIC_LOCAL 1 IRQ_TYPE_NONE>; + clocks = <&cpu_pll>; + }; + }; + - | + interrupt-controller { + compatible = "mti,gic"; + interrupt-controller; + #interrupt-cells = <3>; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt deleted file mode 100644 index 727b7e4cd6e0..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.txt +++ /dev/null @@ -1,43 +0,0 @@ -DT bindings for the Renesas RZ/A1 Interrupt Controller - -The RZ/A1 Interrupt Controller is a front-end for the GIC found on Renesas -RZ/A1 and RZ/A2 SoCs: - - IRQ sense select for 8 external interrupts, 1:1-mapped to 8 GIC SPI - interrupts, - - NMI edge select. - -Required properties: - - compatible: Must be "renesas,<soctype>-irqc", and "renesas,rza1-irqc" as - fallback. - Examples with soctypes are: - - "renesas,r7s72100-irqc" (RZ/A1H) - - "renesas,r7s9210-irqc" (RZ/A2M) - - #interrupt-cells: Must be 2 (an interrupt index and flags, as defined - in interrupts.txt in this directory) - - #address-cells: Must be zero - - interrupt-controller: Marks the device as an interrupt controller - - reg: Base address and length of the memory resource used by the interrupt - controller - - interrupt-map: Specifies the mapping from external interrupts to GIC - interrupts - - interrupt-map-mask: Must be <7 0> - -Example: - - irqc: interrupt-controller@fcfef800 { - compatible = "renesas,r7s72100-irqc", "renesas,rza1-irqc"; - #interrupt-cells = <2>; - #address-cells = <0>; - interrupt-controller; - reg = <0xfcfef800 0x6>; - interrupt-map = - <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; - interrupt-map-mask = <7 0>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml new file mode 100644 index 000000000000..755cdfabfcd0 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,rza1-irqc.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/renesas,rza1-irqc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A1 Interrupt Controller + +maintainers: + - Chris Brandt <chris.brandt@renesas.com> + - Geert Uytterhoeven <geert+renesas@glider.be> + +description: | + The RZ/A1 Interrupt Controller is a front-end for the GIC found on Renesas RZ/A1 and + RZ/A2 SoCs: + - IRQ sense select for 8 external interrupts, 1:1-mapped to 8 GIC SPI interrupts, + - NMI edge select. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r7s72100-irqc # RZ/A1H + - renesas,r7s9210-irqc # RZ/A2M + - const: renesas,rza1-irqc + + '#interrupt-cells': + const: 2 + + '#address-cells': + const: 0 + + interrupt-controller: true + + reg: + maxItems: 1 + + interrupt-map: + maxItems: 8 + description: Specifies the mapping from external interrupts to GIC interrupts. + + interrupt-map-mask: + items: + - const: 7 + - const: 0 + +required: + - compatible + - '#interrupt-cells' + - '#address-cells' + - interrupt-controller + - reg + - interrupt-map + - interrupt-map-mask + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + irqc: interrupt-controller@fcfef800 { + compatible = "renesas,r7s72100-irqc", "renesas,rza1-irqc"; + #interrupt-cells = <2>; + #address-cells = <0>; + interrupt-controller; + reg = <0xfcfef800 0x6>; + interrupt-map = + <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map-mask = <7 0>; + }; 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 39675cf4ed71..6bfa090fd73a 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -32,9 +32,11 @@ properties: - enum: - renesas,ipmmu-r8a774a1 # RZ/G2M - renesas,ipmmu-r8a774b1 # RZ/G2N + - renesas,ipmmu-r8a774e1 # RZ/G2H - 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/leds/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt deleted file mode 100644 index 321be6640533..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt +++ /dev/null @@ -1,16 +0,0 @@ -gpio-backlight bindings - -Required properties: - - compatible: "gpio-backlight" - - gpios: describes the gpio that is used for enabling/disabling the backlight. - refer to bindings/gpio/gpio.txt for more details. - -Optional properties: - - default-on: enable the backlight at boot. - -Example: - backlight { - compatible = "gpio-backlight"; - gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; - default-on; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml new file mode 100644 index 000000000000..75cc569b9c55 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/gpio-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: gpio-backlight bindings + +maintainers: + - Lee Jones <lee.jones@linaro.org> + - Daniel Thompson <daniel.thompson@linaro.org> + - Jingoo Han <jingoohan1@gmail.com> + +properties: + compatible: + const: gpio-backlight + + gpios: + description: The gpio that is used for enabling/disabling the backlight. + maxItems: 1 + + default-on: + description: enable the backlight at boot. + type: boolean + +required: + - compatible + - gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + backlight { + compatible = "gpio-backlight"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-on; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt deleted file mode 100644 index 4c7dfbe7f67a..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.txt +++ /dev/null @@ -1,28 +0,0 @@ -led-backlight bindings - -This binding is used to describe a basic backlight device made of LEDs. -It can also be used to describe a backlight device controlled by the output of -a LED driver. - -Required properties: - - compatible: "led-backlight" - - leds: a list of LEDs - -Optional properties: - - brightness-levels: Array of distinct brightness levels. The levels must be - in the range accepted by the underlying LED devices. - This is used to translate a backlight brightness level - into a LED brightness level. If it is not provided, the - identity mapping is used. - - - default-brightness-level: The default brightness level. - -Example: - - backlight { - compatible = "led-backlight"; - - leds = <&led1>, <&led2>; - brightness-levels = <0 4 8 16 32 64 128 255>; - default-brightness-level = <6>; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml new file mode 100644 index 000000000000..625082bf3892 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/led-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: led-backlight bindings + +maintainers: + - Lee Jones <lee.jones@linaro.org> + - Daniel Thompson <daniel.thompson@linaro.org> + - Jingoo Han <jingoohan1@gmail.com> + +description: + This binding is used to describe a basic backlight device made of LEDs. It + can also be used to describe a backlight device controlled by the output of + a LED driver. + +properties: + compatible: + const: led-backlight + + leds: + description: A list of LED nodes + $ref: /schemas/types.yaml#/definitions/phandle-array + + brightness-levels: + description: + Array of distinct brightness levels. The levels must be in the range + accepted by the underlying LED devices. This is used to translate a + backlight brightness level into a LED brightness level. If it is not + provided, the identity mapping is used. + $ref: /schemas/types.yaml#/definitions/uint32-array + + default-brightness-level: + description: + The default brightness level (index into the array defined by the + "brightness-levels" property). + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - leds + +additionalProperties: false + +examples: + - | + backlight { + compatible = "led-backlight"; + + leds = <&led1>, <&led2>; + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt deleted file mode 100644 index 64fa2fbd98c9..000000000000 --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt +++ /dev/null @@ -1,61 +0,0 @@ -pwm-backlight bindings - -Required properties: - - compatible: "pwm-backlight" - - pwms: OF device-tree PWM specification (see PWM binding[0]) - - power-supply: regulator for supply voltage - -Optional properties: - - pwm-names: a list of names for the PWM devices specified in the - "pwms" property (see PWM binding[0]) - - enable-gpios: contains a single GPIO specifier for the GPIO which enables - and disables the backlight (see GPIO binding[1]) - - post-pwm-on-delay-ms: Delay in ms between setting an initial (non-zero) PWM - and enabling the backlight using GPIO. - - pwm-off-delay-ms: Delay in ms between disabling the backlight using GPIO - and setting PWM value to 0. - - brightness-levels: Array of distinct brightness levels. Typically these - are in the range from 0 to 255, but any range starting at - 0 will do. The actual brightness level (PWM duty cycle) - will be interpolated from these values. 0 means a 0% duty - cycle (darkest/off), while the last value in the array - represents a 100% duty cycle (brightest). - - default-brightness-level: The default brightness level (index into the - array defined by the "brightness-levels" property). - - num-interpolated-steps: Number of interpolated steps between each value - of brightness-levels table. This way a high - resolution pwm duty cycle can be used without - having to list out every possible value in the - brightness-level array. - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt -[1]: Documentation/devicetree/bindings/gpio/gpio.txt - -Example: - - backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 5000000>; - - brightness-levels = <0 4 8 16 32 64 128 255>; - default-brightness-level = <6>; - - power-supply = <&vdd_bl_reg>; - enable-gpios = <&gpio 58 0>; - post-pwm-on-delay-ms = <10>; - pwm-off-delay-ms = <10>; - }; - -Example using num-interpolation-steps: - - backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 5000000>; - - brightness-levels = <0 2048 4096 8192 16384 65535>; - num-interpolated-steps = <2048>; - default-brightness-level = <4096>; - - power-supply = <&vdd_bl_reg>; - enable-gpios = <&gpio 58 0>; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml new file mode 100644 index 000000000000..fcb8429f3088 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/pwm-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: pwm-backlight bindings + +maintainers: + - Lee Jones <lee.jones@linaro.org> + - Daniel Thompson <daniel.thompson@linaro.org> + - Jingoo Han <jingoohan1@gmail.com> + +properties: + compatible: + const: pwm-backlight + + pwms: + maxItems: 1 + + pwm-names: true + + power-supply: + description: regulator for supply voltage + + enable-gpios: + description: + Contains a single GPIO specifier for the GPIO which enables and disables + the backlight. + maxItems: 1 + + post-pwm-on-delay-ms: + description: + Delay in ms between setting an initial (non-zero) PWM and enabling the + backlight using GPIO. + + pwm-off-delay-ms: + description: + Delay in ms between disabling the backlight using GPIO and setting PWM + value to 0. + + brightness-levels: + description: + Array of distinct brightness levels. Typically these are in the range + from 0 to 255, but any range starting at 0 will do. The actual brightness + level (PWM duty cycle) will be interpolated from these values. 0 means a + 0% duty cycle (darkest/off), while the last value in the array represents + a 100% duty cycle (brightest). + $ref: /schemas/types.yaml#/definitions/uint32-array + + default-brightness-level: + description: + The default brightness level (index into the array defined by the + "brightness-levels" property). + $ref: /schemas/types.yaml#/definitions/uint32 + + num-interpolated-steps: + description: + Number of interpolated steps between each value of brightness-levels + table. This way a high resolution pwm duty cycle can be used without + having to list out every possible value in the brightness-level array. + $ref: /schemas/types.yaml#/definitions/uint32 + +dependencies: + default-brightness-level: [brightness-levels] + num-interpolated-steps: [brightness-levels] + +required: + - compatible + - pwms + - power-supply + +additionalProperties: false + +examples: + - | + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + + power-supply = <&vdd_bl_reg>; + enable-gpios = <&gpio 58 0>; + post-pwm-on-delay-ms = <10>; + pwm-off-delay-ms = <10>; + }; + + - | + // Example using num-interpolation-steps: + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 2048 4096 8192 16384 65535>; + num-interpolated-steps = <2048>; + default-brightness-level = <4096>; + + power-supply = <&vdd_bl_reg>; + enable-gpios = <&gpio 58 0>; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml new file mode 100644 index 000000000000..24ad1446445e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/cznic,turris-omnia-leds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CZ.NIC's Turris Omnia LEDs driver + +maintainers: + - Marek Behún <marek.behun@nic.cz> + +description: + This module adds support for the RGB LEDs found on the front panel of the + Turris Omnia router. There are 12 RGB LEDs that are controlled by a + microcontroller that communicates via the I2C bus. Each LED is described + as a subnode of this I2C device. + +properties: + compatible: + const: cznic,turris-omnia-leds + + reg: + description: I2C slave address of the microcontroller. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^multi-led[0-9a-f]$": + type: object + allOf: + - $ref: leds-class-multicolor.yaml# + description: + This node represents one of the RGB LED devices on Turris Omnia. + No subnodes need to be added for subchannels since this controller only + supports RGB LEDs. + + properties: + reg: + minimum: 0 + maximum: 11 + description: + This property identifies one of the LEDs on the front panel of the + Turris Omnia router. + + required: + - reg + +additionalProperties: false + +examples: + - | + + #include <dt-bindings/leds/common.h> + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@2b { + compatible = "cznic,turris-omnia-leds"; + reg = <0x2b>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + /* + * No subnodes are needed, this controller only supports RGB + * LEDs. + */ + reg = <0>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_POWER; + linux,default-trigger = "heartbeat"; + }; + + multi-led@a { + reg = <0xa>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <1>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file mode 100644 index 000000000000..b55e1f1308a4 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for the multicolor LED class. + +maintainers: + - Dan Murphy <dmurphy@ti.com> + +description: | + Bindings for multi color LEDs show how to describe current outputs of + either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV + etc.) or standalone LEDs, to achieve logically grouped multi-color LED + modules. This is achieved by adding multi-led nodes layer to the + monochrome LED bindings. + The nodes and properties defined in this document are unique to the multicolor + LED class. Common LED nodes and properties are inherited from the common.txt + within this documentation directory. + +patternProperties: + "^multi-led@([0-9a-f])$": + type: object + description: Represents the LEDs that are to be grouped. + properties: + color: + const: 8 # LED_COLOR_ID_MULTI + description: | + For multicolor LED support this property should be defined as + LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h. + + $ref: "common.yaml#" + + required: + - color +... diff --git a/Documentation/devicetree/bindings/leds/leds-lm3532.txt b/Documentation/devicetree/bindings/leds/leds-lm3532.txt index 53793213dd52..097490a5ff91 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3532.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3532.txt @@ -102,4 +102,4 @@ led-controller@38 { }; For more product information please see the links below: -http://www.ti.com/product/LM3532 +https://www.ti.com/product/LM3532 diff --git a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt index 095dafb6ec7f..17e940025dc2 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3601x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3601x.txt @@ -47,5 +47,5 @@ led-controller@64 { } For more product information please see the links below: -http://www.ti.com/product/LM36010 -http://www.ti.com/product/LM36011 +https://www.ti.com/product/LM36010 +https://www.ti.com/product/LM36011 diff --git a/Documentation/devicetree/bindings/leds/leds-lm36274.txt b/Documentation/devicetree/bindings/leds/leds-lm36274.txt index 39c230d59a4d..de6f4931fb31 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm36274.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm36274.txt @@ -82,4 +82,4 @@ lm36274@11 { }; For more product information please see the link below: -http://www.ti.com/lit/ds/symlink/lm36274.pdf +https://www.ti.com/lit/ds/symlink/lm36274.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt index 501468aa4d38..b1103d961d6c 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3692x.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3692x.txt @@ -62,4 +62,4 @@ led-controller@36 { } For more product information please see the link below: -http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf +https://www.ti.com/lit/ds/snvsa29/snvsa29.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt b/Documentation/devicetree/bindings/leds/leds-lm3697.txt index 63992d732959..221b37b6049b 100644 --- a/Documentation/devicetree/bindings/leds/leds-lm3697.txt +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt @@ -70,4 +70,4 @@ led-controller@36 { } For more product information please see the link below: -http://www.ti.com/lit/ds/symlink/lm3697.pdf +https://www.ti.com/lit/ds/symlink/lm3697.pdf diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt deleted file mode 100644 index 1b66a413fb9d..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ /dev/null @@ -1,228 +0,0 @@ -Binding for TI/National Semiconductor LP55xx Led Drivers - -Required properties: -- compatible: one of - national,lp5521 - national,lp5523 - ti,lp55231 - ti,lp5562 - ti,lp8501 - -- reg: I2C slave address -- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) - -Each child has own specific current settings -- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected) -- max-cur: Maximun current at each led channel. - -Optional properties: -- enable-gpio: GPIO attached to the chip's enable pin -- label: Used for naming LEDs -- pwr-sel: LP8501 specific property. Power selection for output channels. - 0: D1~9 are connected to VDD - 1: D1~6 with VDD, D7~9 with VOUT - 2: D1~6 with VOUT, D7~9 with VDD - 3: D1~9 are connected to VOUT - -Alternatively, each child can have a specific channel name and trigger: -- chan-name (optional): name of channel -- linux,default-trigger (optional): see - Documentation/devicetree/bindings/leds/common.txt - -example 1) LP5521 -3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0', -'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger -on channel 0. - -lp5521@32 { - compatible = "national,lp5521"; - reg = <0x32>; - label = "lp5521_pri"; - clock-mode = /bits/ 8 <2>; - - chan0 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - linux,default-trigger = "heartbeat"; - }; - - chan1 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - }; - - chan2 { - led-cur = /bits/ 8 <0x2f>; - max-cur = /bits/ 8 <0x5f>; - }; -}; - -example 2) LP5523 -9 LED channels with specific name. Internal clock used. -The I2C slave address is configurable with ASEL1 and ASEL0 pins. -Available addresses are 32/33/34/35h. - -ASEL1 ASEL0 Address -------------------------- - GND GND 32h - GND VEN 33h - VEN GND 34h - VEN VEN 35h - -lp5523@32 { - compatible = "national,lp5523"; - reg = <0x32>; - clock-mode = /bits/ 8 <1>; - - chan0 { - chan-name = "d1"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan1 { - chan-name = "d2"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan2 { - chan-name = "d3"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan3 { - chan-name = "d4"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan4 { - chan-name = "d5"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan5 { - chan-name = "d6"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan6 { - chan-name = "d7"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan7 { - chan-name = "d8"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan8 { - chan-name = "d9"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; -}; - -example 3) LP5562 -4 channels are defined. - -lp5562@30 { - compatible = "ti,lp5562"; - reg = <0x30>; - clock-mode = /bits/8 <2>; - - chan0 { - chan-name = "R"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan1 { - chan-name = "G"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan2 { - chan-name = "B"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; - - chan3 { - chan-name = "W"; - led-cur = /bits/ 8 <0x20>; - max-cur = /bits/ 8 <0x60>; - }; -}; - -example 4) LP8501 -9 channels are defined. The 'pwr-sel' is LP8501 specific property. -Others are same as LP5523. - -lp8501@32 { - compatible = "ti,lp8501"; - reg = <0x32>; - clock-mode = /bits/ 8 <2>; - pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ - - chan0 { - chan-name = "d1"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan1 { - chan-name = "d2"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan2 { - chan-name = "d3"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan3 { - chan-name = "d4"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan4 { - chan-name = "d5"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan5 { - chan-name = "d6"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan6 { - chan-name = "d7"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan7 { - chan-name = "d8"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; - - chan8 { - chan-name = "d9"; - led-cur = /bits/ 8 <0x14>; - max-cur = /bits/ 8 <0x20>; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml new file mode 100644 index 000000000000..b1bb3feb0f4d --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml @@ -0,0 +1,220 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI/National Semiconductor LP55xx and LP8501 LED Drivers + +maintainers: + - Jacek Anaszewski <jacek.anaszewski@gmail.com> + - Pavel Machek <pavel@ucw.cz> + +description: | + Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel + LED Drivers. + + For more product information please see the link below: + https://www.ti.com/lit/gpn/lp5521 + https://www.ti.com/lit/gpn/lp5523 + https://www.ti.com/lit/gpn/lp55231 + https://www.ti.com/lit/gpn/lp5562 + https://www.ti.com/lit/gpn/lp8501 + +properties: + compatible: + enum: + - national,lp5521 + - national,lp5523 + - ti,lp55231 + - ti,lp5562 + - ti,lp8501 + + reg: + maxItems: 1 + description: I2C slave address + + clock-mode: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + Input clock mode + enum: + - 0 # automode + - 1 # internal + - 2 # external + + enable-gpio: + maxItems: 1 + description: | + GPIO attached to the chip's enable pin + + pwr-sel: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + LP8501 specific property. Power selection for output channels. + enum: + - 0 # D1~9 are connected to VDD + - 1 # D1~6 with VDD, D7~9 with VOUT + - 2 # D1~6 with VOUT, D7~9 with VDD + - 3 # D1~9 are connected to VOUT + +patternProperties: + "(^led@[0-9a-f]$|led)": + type: object + $ref: common.yaml# + properties: + led-cur: + $ref: /schemas/types.yaml#definitions/uint8 + description: | + Current setting at each LED channel (mA x10, 0 if LED is not connected) + minimum: 0 + maximum: 255 + + max-cur: + $ref: /schemas/types.yaml#definitions/uint8 + description: Maximun current at each LED channel. + + reg: + description: | + Output channel for the LED. This is zero based channel identifier and + the data sheet is a one based channel identifier. + reg value to output to LED output number + enum: + - 0 # LED output D1 + - 1 # LED output D2 + - 2 # LED output D3 + - 3 # LED output D4 + - 4 # LED output D5 + - 5 # LED output D6 + - 6 # LED output D7 + - 7 # LED output D8 + - 8 # LED output D9 + + chan-name: + $ref: /schemas/types.yaml#definitions/string + description: name of channel + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@32 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp8501"; + reg = <0x32>; + clock-mode = /bits/ 8 <2>; + pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */ + + led@0 { + reg = <0>; + chan-name = "d1"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@1 { + reg = <1>; + chan-name = "d2"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@2 { + reg = <2>; + chan-name = "d3"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@3 { + reg = <3>; + chan-name = "d4"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@4 { + reg = <4>; + chan-name = "d5"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@5 { + reg = <5>; + chan-name = "d6"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@6 { + reg = <6>; + chan-name = "d7"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@7 { + reg = <7>; + chan-name = "d8"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + led@8 { + reg = <8>; + chan-name = "d9"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + }; + + led-controller@33 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "national,lp5523"; + reg = <0x33>; + clock-mode = /bits/ 8 <0>; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0x2>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_STANDBY; + linux,default-trigger = "heartbeat"; + + led@0 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x0>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@1 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x1>; + color = <LED_COLOR_ID_BLUE>; + }; + + led@6 { + led-cur = /bits/ 8 <50>; + max-cur = /bits/ 8 <100>; + reg = <0x6>; + color = <LED_COLOR_ID_RED>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt b/Documentation/devicetree/bindings/leds/leds-lp8860.txt index 9863220db4ba..8bb25749a3da 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt @@ -47,4 +47,4 @@ led-controller@2d { } For more product information please see the link below: -http://www.ti.com/product/lp8860-q1 +https://www.ti.com/product/lp8860-q1 diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt index 7984efb767b4..7a5830f8d5ab 100644 --- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt @@ -26,9 +26,9 @@ LED sub-node properties: from 0 to 15 for the pca9552 from 0 to 3 for the pca9553 - type: (optional) either - PCA9532_TYPE_NONE - PCA9532_TYPE_LED - PCA9532_TYPE_GPIO + PCA955X_TYPE_NONE + PCA955X_TYPE_LED + PCA955X_TYPE_GPIO see dt-bindings/leds/leds-pca955x.h (default to LED) - label : (optional) see Documentation/devicetree/bindings/leds/common.txt 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/adv7180.txt b/Documentation/devicetree/bindings/media/i2c/adv7180.txt deleted file mode 100644 index 552b6a82cb1f..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Analog Devices ADV7180 analog video decoder family - -The adv7180 family devices are used to capture analog video to different -digital interfaces like MIPI CSI-2 or parallel video. - -Required Properties : -- compatible : value must be one of - "adi,adv7180" - "adi,adv7180cp" - "adi,adv7180st" - "adi,adv7182" - "adi,adv7280" - "adi,adv7280-m" - "adi,adv7281" - "adi,adv7281-m" - "adi,adv7281-ma" - "adi,adv7282" - "adi,adv7282-m" - -Device nodes of "adi,adv7180cp" and "adi,adv7180st" must contain one -'port' child node per device input and output port, in accordance with the -video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. The port -nodes are numbered as follows. - - Port adv7180cp adv7180st -------------------------------------------------------------------- - Input 0-2 0-5 - Output 3 6 - -The digital output port node must contain at least one endpoint. - -Optional Properties : -- powerdown-gpios: reference to the GPIO connected to the powerdown pin, - if any. - - -Example: - - i2c0@1c22000 { - ... - ... - adv7180@21 { - compatible = "adi,adv7180"; - reg = <0x21>; - }; - ... - }; - diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml new file mode 100644 index 000000000000..e0084b272b25 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/adv7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV7180 analog video decoder family + +maintainers: + - Lars-Peter Clausen <lars@metafoo.de> + +description: + The adv7180 family devices are used to capture analog video to different + digital interfaces like MIPI CSI-2 or parallel video. + +properties: + compatible: + items: + - enum: + - adi,adv7180 + - adi,adv7180cp + - adi,adv7180st + - adi,adv7182 + - adi,adv7280 + - adi,adv7280-m + - adi,adv7281 + - adi,adv7281-m + - adi,adv7281-ma + - adi,adv7282 + - adi,adv7282-m + + reg: + maxItems: 1 + + powerdown-gpios: + maxItems: 1 + + port: + type: object + description: + A node containing a single endpoint as doucmented in + Documentation/devicetree/bindings/media/video-interfaces.txt + + ports: + type: object + description: + A node containing input and output port nodes with endpoint definitions + as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + +additionalProperties: false + +required: + - compatible + - reg + +allOf: + - if: + properties: + compatible: + items: + - enum: + - adi,adv7180 + - adi,adv7182 + - adi,adv7280 + - adi,adv7280-m + - adi,adv7281 + - adi,adv7281-m + - adi,adv7281-ma + - adi,adv7282 + - adi,adv7282-m + then: + required: + - port + + - if: + properties: + compatible: + contains: + const: adi,adv7180cp + then: + properties: + ports: + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + port@3: + type: object + description: Output port + + patternProperties: + "^port@[0-2]$": + type: object + description: Input port + + required: + - port@3 + + additionalProperties: false + + required: + - ports + + - if: + properties: + compatible: + contains: + const: adi,adv7180st + then: + properties: + ports: + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + port@6: + type: object + description: Output port + + patternProperties: + "^port@[0-5]$": + type: object + description: Input port + + required: + - port@6 + + additionalProperties: false + + required: + - ports + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + composite-in@20 { + compatible = "adi,adv7180"; + reg = <0x20>; + + port { + adv7180: endpoint { + bus-width = <8>; + remote-endpoint = <&vin1ep>; + }; + }; + }; + + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + composite-in@20 { + compatible = "adi,adv7180cp"; + reg = <0x20>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7180_in: endpoint { + remote-endpoint = <&composite_con_in>; + }; + }; + + port@3 { + reg = <3>; + adv7180_out: endpoint { + remote-endpoint = <&vin4_in>; + }; + }; + }; + }; + }; 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/imx274.txt b/Documentation/devicetree/bindings/media/i2c/imx274.txt index 80f2e89568e1..0727079d2410 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx274.txt +++ b/Documentation/devicetree/bindings/media/i2c/imx274.txt @@ -13,6 +13,11 @@ Required Properties: Optional Properties: - reset-gpios: Sensor reset GPIO +- clocks: Reference to the input clock. +- clock-names: Should be "inck". +- VANA-supply: Sensor 2.8v analog supply. +- VDIG-supply: Sensor 1.8v digital core supply. +- VDDL-supply: Sensor digital IO 1.2v supply. The imx274 device node should contain one 'port' child node with an 'endpoint' subnode. For further reading on port node refer to 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/video.txt b/Documentation/devicetree/bindings/media/xilinx/video.txt index 68ac210e688e..d0335ca0cd57 100644 --- a/Documentation/devicetree/bindings/media/xilinx/video.txt +++ b/Documentation/devicetree/bindings/media/xilinx/video.txt @@ -32,4 +32,4 @@ The following properties are common to all Xilinx video IP cores. defaults to "mono". -[UG934] http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf +[UG934] https://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf 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/fsl/mmdc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt deleted file mode 100644 index bcc36c5b543c..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.txt +++ /dev/null @@ -1,35 +0,0 @@ -Freescale Multi Mode DDR controller (MMDC) - -Required properties : -- compatible : should be one of following: - for i.MX6Q/i.MX6DL: - - "fsl,imx6q-mmdc"; - for i.MX6QP: - - "fsl,imx6qp-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SL: - - "fsl,imx6sl-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SLL: - - "fsl,imx6sll-mmdc", "fsl,imx6q-mmdc"; - for i.MX6SX: - - "fsl,imx6sx-mmdc", "fsl,imx6q-mmdc"; - for i.MX6UL/i.MX6ULL/i.MX6ULZ: - - "fsl,imx6ul-mmdc", "fsl,imx6q-mmdc"; - for i.MX7ULP: - - "fsl,imx7ulp-mmdc", "fsl,imx6q-mmdc"; -- reg : address and size of MMDC DDR controller registers - -Optional properties : -- clocks : the clock provided by the SoC to access the MMDC registers - -Example : - mmdc0: memory-controller@21b0000 { /* MMDC0 */ - compatible = "fsl,imx6q-mmdc"; - reg = <0x021b0000 0x4000>; - clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>; - }; - - mmdc1: memory-controller@21b4000 { /* MMDC1 */ - compatible = "fsl,imx6q-mmdc"; - reg = <0x021b4000 0x4000>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml new file mode 100644 index 000000000000..dee5131c0361 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/mmdc.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/fsl/mmdc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Multi Mode DDR controller (MMDC) + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + oneOf: + - const: fsl,imx6q-mmdc + - items: + - enum: + - fsl,imx6qp-mmdc + - fsl,imx6sl-mmdc + - fsl,imx6sll-mmdc + - fsl,imx6sx-mmdc + - fsl,imx6ul-mmdc + - fsl,imx7ulp-mmdc + - const: fsl,imx6q-mmdc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + + memory-controller@21b0000 { + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b0000 0x4000>; + clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>; + }; + + memory-controller@21b4000 { + compatible = "fsl,imx6q-mmdc"; + reg = <0x021b4000 0x4000>; + }; 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/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt index 86446074e206..a92acf1dd491 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -37,7 +37,7 @@ syscon as a means to arbitrate access. [0] http://www.intel.com/design/chipsets/industry/25128901.pdf [1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4 -[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf +[2] https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf [3] https://en.wikipedia.org/wiki/Super_I/O Required properties diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt index 857af982c88f..bab0d0e66cb3 100644 --- a/Documentation/devicetree/bindings/mfd/da9062.txt +++ b/Documentation/devicetree/bindings/mfd/da9062.txt @@ -1,8 +1,8 @@ * Dialog DA9062 Power Management Integrated Circuit (PMIC) Product information for the DA9062 and DA9061 devices can be found here: -- http://www.dialog-semiconductor.com/products/da9062 -- http://www.dialog-semiconductor.com/products/da9061 +- https://www.dialog-semiconductor.com/products/da9062 +- https://www.dialog-semiconductor.com/products/da9061 The DA9062 PMIC consists of: diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 614e58bb5d7d..049ec2ffc7f9 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -45,7 +45,8 @@ properties: - contains: const: syscon - additionalItems: true + minItems: 2 + maxItems: 4 # Should be enough reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml index d1175030781a..83c86cbe4716 100644 --- a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml +++ b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml @@ -8,7 +8,8 @@ title: Ingenic XBurst based Platforms Device Tree Bindings maintainers: - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> -description: | + +description: Devices with a Ingenic XBurst CPU shall have the following properties. properties: @@ -22,6 +23,11 @@ properties: - const: qi,lb60 - const: ingenic,jz4740 + - description: YLM RetroMini RS-90 + items: + - const: ylm,rs90 + - const: ingenic,jz4725b + - description: Game Consoles Worldwide GCW Zero items: - const: gcw,zero @@ -32,8 +38,13 @@ properties: - const: img,ci20 - const: ingenic,jz4780 - - description: YSH & ATIL General Board CU Neo + - description: YSH & ATIL General Board, CU1000 Module with Neo Backplane items: - const: yna,cu1000-neo - - const: ingenic,x1000 + - const: ingenic,x1000e + + - description: YSH & ATIL General Board, CU1830 Module with Neo Backplane + items: + - const: yna,cu1830-neo + - const: ingenic,x1830 ... diff --git a/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml new file mode 100644 index 000000000000..16fa03d65ad5 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mips/ingenic/ingenic,cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Ingenic XBurst family CPUs + +maintainers: + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> + +description: + Ingenic XBurst family CPUs shall have the following properties. + +properties: + compatible: + oneOf: + + - description: Ingenic XBurst®1 CPU Cores + enum: + - ingenic,xburst-mxu1.0 + - ingenic,xburst-fpu1.0-mxu1.1 + - ingenic,xburst-fpu2.0-mxu2.0 + + - description: Ingenic XBurst®2 CPU Cores + enum: + - ingenic,xburst2-fpu2.1-mxu2.1-smt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - device_type + - compatible + - reg + - clocks + +examples: + - | + #include <dt-bindings/clock/jz4780-cgu.h> + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "ingenic,xburst-fpu1.0-mxu1.1"; + reg = <0>; + + clocks = <&cgu JZ4780_CLK_CPU>; + clock-names = "cpu"; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "ingenic,xburst-fpu1.0-mxu1.1"; + reg = <1>; + + clocks = <&cgu JZ4780_CLK_CORE1>; + clock-names = "cpu"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mips/loongson/devices.yaml b/Documentation/devicetree/bindings/mips/loongson/devices.yaml index 74ed4e397a78..d25e80aa8b2a 100644 --- a/Documentation/devicetree/bindings/mips/loongson/devices.yaml +++ b/Documentation/devicetree/bindings/mips/loongson/devices.yaml @@ -17,11 +17,23 @@ properties: compatible: oneOf: - - description: Generic Loongson3 Quad Core + RS780E + - description: Classic Loongson64 Quad Core + LS7A items: - - const: loongson,loongson3-4core-rs780e + - const: loongson,loongson64c-4core-ls7a - - description: Generic Loongson3 Octa Core + RS780E + - description: Classic Loongson64 Quad Core + RS780E items: - - const: loongson,loongson3-8core-rs780e + - const: loongson,loongson64c-4core-rs780e + + - description: Classic Loongson64 Octa Core + RS780E + items: + - const: loongson,loongson64c-8core-rs780e + + - description: Generic Loongson64 Quad Core + LS7A + items: + - const: loongson,loongson64g-4core-ls7a + + - description: Virtual Loongson64 Quad Core + VirtIO + items: + - const: loongson,loongson64v-4core-virtio ... diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt index ebd329181c14..7b486d4985dc 100644 --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt @@ -10,7 +10,7 @@ such as network interfaces, crypto accelerator instances, L2 switches, etc. For an overview of the DPAA2 architecture and fsl-mc bus see: -Documentation/networking/device_drivers/freescale/dpaa2/overview.rst +Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst As described in the above overview, all DPAA2 objects in a DPRC share the same hardware "isolation context" and a 10-bit value called an ICID diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt deleted file mode 100644 index 2d7cdf19a0d0..000000000000 --- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt +++ /dev/null @@ -1,23 +0,0 @@ -OLPC XO-1.75 Embedded Controller - -Required properties: -- compatible: Should be "olpc,xo1.75-ec". -- cmd-gpios: gpio specifier of the CMD pin - -The embedded controller requires the SPI controller driver to signal readiness -to receive a transfer (that is, when TX FIFO contains the response data) by -strobing the ACK pin with the ready signal. See the "ready-gpios" property of the -SSP binding as documented in: -<Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml>. - -Example: - &ssp3 { - spi-slave; - ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; - - slave { - compatible = "olpc,xo1.75-ec"; - spi-cpha; - cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml new file mode 100644 index 000000000000..e75d77beec6a --- /dev/null +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright (C) 2019,2020 Lubomir Rintel <lkundrak@v3.sk> +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/olpc,xo1.75-ec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OLPC XO-1.75 Embedded Controller bindings + +description: | + This binding describes the Embedded Controller acting as a SPI bus master + on a OLPC XO-1.75 laptop computer. + + The embedded controller requires the SPI controller driver to signal + readiness to receive a transfer (that is, when TX FIFO contains the + response data) by strobing the ACK pin with the ready signal. See the + "ready-gpios" property of the SSP binding as documented in: + <Documentation/devicetree/bindings/spi/marvell,mmp2-ssp.yaml>. + +maintainers: + - Lubomir Rintel <lkundrak@v3.sk> + +properties: + compatible: + const: olpc,xo1.75-ec + + cmd-gpios: + description: GPIO uspecifier of the CMD pin + maxItems: 1 + +required: + - compatible + - cmd-gpios + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + spi-slave; + ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; + + slave { + compatible = "olpc,xo1.75-ec"; + spi-cpha; + cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt deleted file mode 100644 index f29bf7dd2ece..000000000000 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt +++ /dev/null @@ -1,192 +0,0 @@ -Device Tree Bindings for the Arasan SDHCI Controller - - The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings. - Only deviations are documented here. - - [1] Documentation/devicetree/bindings/mmc/mmc.txt - [2] Documentation/devicetree/bindings/clock/clock-bindings.txt - [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - [4] Documentation/devicetree/bindings/phy/phy-bindings.txt - -Required Properties: - - compatible: Compatibility string. One of: - - "arasan,sdhci-8.9a": generic Arasan SDHCI 8.9a PHY - - "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY - - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY - - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "xlnx,zynqmp-8.9a": ZynqMP SDHCI 8.9a PHY - For this device it is strongly suggested to include clock-output-names and - #clock-cells. - - "xlnx,versal-8.9a": Versal SDHCI 8.9a PHY - For this device it is strongly suggested to include clock-output-names and - #clock-cells. - - "ti,am654-sdhci-5.1", "arasan,sdhci-5.1": TI AM654 MMC PHY - Note: This binding has been deprecated and moved to [5]. - - "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel LGM eMMC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1": Intel LGM SDXC PHY - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1": Intel Keem Bay eMMC - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-sd": Intel Keem Bay SD controller - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - "intel,keembay-sdhci-5.1-sdio": Intel Keem Bay SDIO controller - For this device it is strongly suggested to include arasan,soc-ctl-syscon. - - [5] Documentation/devicetree/bindings/mmc/sdhci-am654.txt - - - reg: From mmc bindings: Register location and length. - - clocks: From clock bindings: Handles to clock inputs. - - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb" - - interrupts: Interrupt specifier - -Required Properties for "arasan,sdhci-5.1": - - phys: From PHY bindings: Phandle for the Generic PHY for arasan. - - phy-names: MUST be "phy_arasan". - -Optional Properties: - - arasan,soc-ctl-syscon: A phandle to a syscon device (see ../mfd/syscon.txt) - used to access core corecfg registers. Offsets of registers in this - syscon are determined based on the main compatible string for the device. - - clock-output-names: If specified, this will be the name of the card clock - which will be exposed by this device. Required if #clock-cells is - specified. - - #clock-cells: If specified this should be the value <0> or <1>. With this - property in place we will export one or two clocks representing the Card - Clock. These clocks are expected to be consumed by our PHY. - - xlnx,fails-without-test-cd: when present, the controller doesn't work when - the CD line is not connected properly, and the line is not connected - properly. Test mode can be used to force the controller to function. - - xlnx,int-clock-stable-broken: when present, the controller always reports - that the internal clock is stable even when it is not. - - - xlnx,mio-bank: When specified, this will indicate the MIO bank number in - which the command and data lines are configured. If not specified, driver - will assume this as 0. - -Example: - sdhci@e0100000 { - compatible = "arasan,sdhci-8.9a"; - reg = <0xe0100000 0x1000>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&clkc 21>, <&clkc 32>; - interrupt-parent = <&gic>; - interrupts = <0 24 4>; - } ; - - sdhci@e2800000 { - compatible = "arasan,sdhci-5.1"; - reg = <0xe2800000 0x1000>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&cru 8>, <&cru 18>; - interrupt-parent = <&gic>; - interrupts = <0 24 4>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - } ; - - sdhci: sdhci@fe330000 { - compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1"; - reg = <0x0 0xfe330000 0x0 0x10000>; - interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>; - clock-names = "clk_xin", "clk_ahb"; - arasan,soc-ctl-syscon = <&grf>; - assigned-clocks = <&cru SCLK_EMMC>; - assigned-clock-rates = <200000000>; - clock-output-names = "emmc_cardclock"; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - #clock-cells = <0>; - }; - - sdhci: mmc@ff160000 { - compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; - interrupt-parent = <&gic>; - interrupts = <0 48 4>; - reg = <0x0 0xff160000 0x0 0x1000>; - clocks = <&clk200>, <&clk200>; - clock-names = "clk_xin", "clk_ahb"; - clock-output-names = "clk_out_sd0", "clk_in_sd0"; - #clock-cells = <1>; - clk-phase-sd-hs = <63>, <72>; - }; - - sdhci: mmc@f1040000 { - compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a"; - interrupt-parent = <&gic>; - interrupts = <0 126 4>; - reg = <0x0 0xf1040000 0x0 0x10000>; - clocks = <&clk200>, <&clk200>; - clock-names = "clk_xin", "clk_ahb"; - clock-output-names = "clk_out_sd0", "clk_in_sd0"; - #clock-cells = <1>; - clk-phase-sd-hs = <132>, <60>; - }; - - emmc: sdhci@ec700000 { - compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; - reg = <0xec700000 0x300>; - interrupt-parent = <&ioapic1>; - interrupts = <44 1>; - clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>, - <&cgu0 LGM_GCLK_EMMC>; - clock-names = "clk_xin", "clk_ahb", "gate"; - clock-output-names = "emmc_cardclock"; - #clock-cells = <0>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - arasan,soc-ctl-syscon = <&sysconf>; - }; - - sdxc: sdhci@ec600000 { - compatible = "arasan,sdhci-5.1", "intel,lgm-sdhci-5.1-sdxc"; - reg = <0xec600000 0x300>; - interrupt-parent = <&ioapic1>; - interrupts = <43 1>; - clocks = <&cgu0 LGM_CLK_SDIO>, <&cgu0 LGM_CLK_NGI>, - <&cgu0 LGM_GCLK_SDXC>; - clock-names = "clk_xin", "clk_ahb", "gate"; - clock-output-names = "sdxc_cardclock"; - #clock-cells = <0>; - phys = <&sdxc_phy>; - phy-names = "phy_arasan"; - arasan,soc-ctl-syscon = <&sysconf>; - }; - - mmc: mmc@33000000 { - compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1"; - interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x0 0x33000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>, - <&scmi_clk KEEM_BAY_PSS_EMMC>; - phys = <&emmc_phy>; - phy-names = "phy_arasan"; - assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>; - assigned-clock-rates = <200000000>; - clock-output-names = "emmc_cardclock"; - #clock-cells = <0>; - arasan,soc-ctl-syscon = <&mmc_phy_syscon>; - }; - - sd0: mmc@31000000 { - compatible = "intel,keembay-sdhci-5.1-sd"; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x0 0x31000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>, - <&scmi_clk KEEM_BAY_PSS_SD0>; - arasan,soc-ctl-syscon = <&sd0_phy_syscon>; - }; - - sd1: mmc@32000000 { - compatible = "intel,keembay-sdhci-5.1-sdio"; - interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x0 0x32000000 0x0 0x300>; - clock-names = "clk_xin", "clk_ahb"; - clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD1>, - <&scmi_clk KEEM_BAY_PSS_SD1>; - arasan,soc-ctl-syscon = <&sd1_phy_syscon>; - }; diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml new file mode 100644 index 000000000000..5887c917d480 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -0,0 +1,299 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mmc/arasan,sdhci.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device Tree Bindings for the Arasan SDHCI Controller + +maintainers: + - Adrian Hunter <adrian.hunter@intel.com> + +allOf: + - $ref: "mmc-controller.yaml#" + - if: + properties: + compatible: + contains: + const: arasan,sdhci-5.1 + then: + required: + - phys + - phy-names + - if: + properties: + compatible: + contains: + enum: + - xlnx,zynqmp-8.9a + - xlnx,versal-8.9a + then: + properties: + clock-output-names: + items: + - const: clk_out_sd0 + - const: clk_in_sd0 + +properties: + compatible: + oneOf: + - const: arasan,sdhci-8.9a # generic Arasan SDHCI 8.9a PHY + - const: arasan,sdhci-4.9a # generic Arasan SDHCI 4.9a PHY + - const: arasan,sdhci-5.1 # generic Arasan SDHCI 5.1 PHY + - items: + - const: rockchip,rk3399-sdhci-5.1 # rk3399 eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: xlnx,zynqmp-8.9a # ZynqMP SDHCI 8.9a PHY + - const: arasan,sdhci-8.9a + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. + - items: + - const: xlnx,versal-8.9a # Versal SDHCI 8.9a PHY + - const: arasan,sdhci-8.9a + description: + For this device it is strongly suggested to include + clock-output-names and '#clock-cells'. + - items: + - const: intel,lgm-sdhci-5.1-emmc # Intel LGM eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: intel,lgm-sdhci-5.1-sdxc # Intel LGM SDXC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - items: + - const: intel,keembay-sdhci-5.1-emmc # Intel Keem Bay eMMC PHY + - const: arasan,sdhci-5.1 + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - const: intel,keembay-sdhci-5.1-sd # Intel Keem Bay SD controller + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + - const: intel,keembay-sdhci-5.1-sdio # Intel Keem Bay SDIO controller + description: + For this device it is strongly suggested to include + arasan,soc-ctl-syscon. + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + items: + - const: clk_xin + - const: clk_ahb + - const: gate + + interrupts: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + const: phy_arasan + + arasan,soc-ctl-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle to a syscon device (see ../mfd/syscon.txt) used to access + core corecfg registers. Offsets of registers in this syscon are + determined based on the main compatible string for the device. + + clock-output-names: + minItems: 1 + maxItems: 2 + description: + Name of the card clock which will be exposed by this device. + + '#clock-cells': + enum: [0, 1] + description: + With this property in place we will export one or two clocks + representing the Card Clock. These clocks are expected to be + consumed by our PHY. + + xlnx,fails-without-test-cd: + $ref: /schemas/types.yaml#/definitions/flag + description: + When present, the controller doesn't work when the CD line is not + connected properly, and the line is not connected properly. + Test mode can be used to force the controller to function. + + xlnx,int-clock-stable-broken: + $ref: /schemas/types.yaml#/definitions/flag + description: + When present, the controller always reports that the internal clock + is stable even when it is not. + + xlnx,mio-bank: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 2] + default: 0 + description: + The MIO bank number in which the command and data lines are configured. + +dependencies: + clock-output-names: [ '#clock-cells' ] + '#clock-cells': [ clock-output-names ] + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + mmc@e0100000 { + compatible = "arasan,sdhci-8.9a"; + reg = <0xe0100000 0x1000>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&clkc 21>, <&clkc 32>; + interrupt-parent = <&gic>; + interrupts = <0 24 4>; + }; + + - | + mmc@e2800000 { + compatible = "arasan,sdhci-5.1"; + reg = <0xe2800000 0x1000>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&cru 8>, <&cru 18>; + interrupt-parent = <&gic>; + interrupts = <0 24 4>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + }; + + - | + #include <dt-bindings/clock/rk3399-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + mmc@fe330000 { + compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1"; + reg = <0xfe330000 0x10000>; + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>; + clock-names = "clk_xin", "clk_ahb"; + arasan,soc-ctl-syscon = <&grf>; + assigned-clocks = <&cru SCLK_EMMC>; + assigned-clock-rates = <200000000>; + clock-output-names = "emmc_cardclock"; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + #clock-cells = <0>; + }; + + - | + mmc@ff160000 { + compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; + interrupt-parent = <&gic>; + interrupts = <0 48 4>; + reg = <0xff160000 0x1000>; + clocks = <&clk200>, <&clk200>; + clock-names = "clk_xin", "clk_ahb"; + clock-output-names = "clk_out_sd0", "clk_in_sd0"; + #clock-cells = <1>; + clk-phase-sd-hs = <63>, <72>; + }; + + - | + mmc@f1040000 { + compatible = "xlnx,versal-8.9a", "arasan,sdhci-8.9a"; + interrupt-parent = <&gic>; + interrupts = <0 126 4>; + reg = <0xf1040000 0x10000>; + clocks = <&clk200>, <&clk200>; + clock-names = "clk_xin", "clk_ahb"; + clock-output-names = "clk_out_sd0", "clk_in_sd0"; + #clock-cells = <1>; + clk-phase-sd-hs = <132>, <60>; + }; + + - | + #define LGM_CLK_EMMC5 + #define LGM_CLK_NGI + #define LGM_GCLK_EMMC + mmc@ec700000 { + compatible = "intel,lgm-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + reg = <0xec700000 0x300>; + interrupt-parent = <&ioapic1>; + interrupts = <44 1>; + clocks = <&cgu0 LGM_CLK_EMMC5>, <&cgu0 LGM_CLK_NGI>, + <&cgu0 LGM_GCLK_EMMC>; + clock-names = "clk_xin", "clk_ahb", "gate"; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + arasan,soc-ctl-syscon = <&sysconf>; + }; + + - | + #define LGM_CLK_SDIO + #define LGM_GCLK_SDXC + mmc@ec600000 { + compatible = "intel,lgm-sdhci-5.1-sdxc", "arasan,sdhci-5.1"; + reg = <0xec600000 0x300>; + interrupt-parent = <&ioapic1>; + interrupts = <43 1>; + clocks = <&cgu0 LGM_CLK_SDIO>, <&cgu0 LGM_CLK_NGI>, + <&cgu0 LGM_GCLK_SDXC>; + clock-names = "clk_xin", "clk_ahb", "gate"; + clock-output-names = "sdxc_cardclock"; + #clock-cells = <0>; + phys = <&sdxc_phy>; + phy-names = "phy_arasan"; + arasan,soc-ctl-syscon = <&sysconf>; + }; + + - | + #define KEEM_BAY_PSS_AUX_EMMC + #define KEEM_BAY_PSS_EMMC + mmc@33000000 { + compatible = "intel,keembay-sdhci-5.1-emmc", "arasan,sdhci-5.1"; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x33000000 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>, + <&scmi_clk KEEM_BAY_PSS_EMMC>; + phys = <&emmc_phy>; + phy-names = "phy_arasan"; + assigned-clocks = <&scmi_clk KEEM_BAY_PSS_AUX_EMMC>; + assigned-clock-rates = <200000000>; + clock-output-names = "emmc_cardclock"; + #clock-cells = <0>; + arasan,soc-ctl-syscon = <&mmc_phy_syscon>; + }; + + - | + #define KEEM_BAY_PSS_AUX_SD0 + #define KEEM_BAY_PSS_SD0 + mmc@31000000 { + compatible = "intel,keembay-sdhci-5.1-sd"; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x31000000 0x300>; + clock-names = "clk_xin", "clk_ahb"; + clocks = <&scmi_clk KEEM_BAY_PSS_AUX_SD0>, + <&scmi_clk KEEM_BAY_PSS_SD0>; + arasan,soc-ctl-syscon = <&sd0_phy_syscon>; + }; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt deleted file mode 100644 index de1b8bd550d3..000000000000 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ /dev/null @@ -1,67 +0,0 @@ -* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX - -The Enhanced Secure Digital Host Controller on Freescale i.MX family -provides an interface for MMC, SD, and SDIO types of memory cards. - -This file documents differences between the core properties described -by mmc.txt and the properties used by the sdhci-esdhc-imx driver. - -Required properties: -- compatible : Should be "fsl,<chip>-esdhc", the supported chips include - "fsl,imx25-esdhc" - "fsl,imx35-esdhc" - "fsl,imx51-esdhc" - "fsl,imx53-esdhc" - "fsl,imx6q-usdhc" - "fsl,imx6sl-usdhc" - "fsl,imx6sx-usdhc" - "fsl,imx6ull-usdhc" - "fsl,imx7d-usdhc" - "fsl,imx7ulp-usdhc" - "fsl,imx8mq-usdhc" - "fsl,imx8mm-usdhc" - "fsl,imx8mn-usdhc" - "fsl,imx8mp-usdhc" - "fsl,imx8qm-usdhc" - "fsl,imx8qxp-usdhc" - -Optional properties: -- fsl,wp-controller : Indicate to use controller internal write protection -- fsl,delay-line : Specify the number of delay cells for override mode. - This is used to set the clock delay for DLL(Delay Line) on override mode - to select a proper data sampling window in case the clock quality is not good - due to signal path is too long on the board. Please refer to eSDHC/uSDHC - chapter, DLL (Delay Line) section in RM for details. -- voltage-ranges : Specify the voltage range in case there are software - transparent level shifters on the outputs of the controller. Two cells are - required, first cell specifies minimum slot voltage (mV), second cell - specifies maximum slot voltage (mV). Several ranges could be specified. -- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19 - in tuning procedure. -- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure. - The uSDHC use one delay cell as default increasing step to do tuning process. - This property allows user to change the tuning step to more than one delay - cells which is useful for some special boards or cards when the default - tuning step can't find the proper delay window within limited tuning retries. -- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay target. - This delay target programming host controller loopback read clock, and this - property allows user to change the delay target for the strobe input read clock. - If not use this property, driver default set the delay target to value 7. - Only eMMC HS400 mode need to take care of this property. - -Examples: - -esdhc@70004000 { - compatible = "fsl,imx51-esdhc"; - reg = <0x70004000 0x4000>; - interrupts = <1>; - fsl,wp-controller; -}; - -esdhc@70008000 { - compatible = "fsl,imx51-esdhc"; - reg = <0x70008000 0x4000>; - interrupts = <2>; - cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */ - wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */ -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml new file mode 100644 index 000000000000..75dc1168d717 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +allOf: + - $ref: "mmc-controller.yaml" + +description: | + The Enhanced Secure Digital Host Controller on Freescale i.MX family + provides an interface for MMC, SD, and SDIO types of memory cards. + + This file documents differences between the core properties described + by mmc.txt and the properties used by the sdhci-esdhc-imx driver. + +properties: + compatible: + enum: + - fsl,imx25-esdhc + - fsl,imx35-esdhc + - fsl,imx51-esdhc + - fsl,imx53-esdhc + - fsl,imx6q-usdhc + - fsl,imx6sl-usdhc + - fsl,imx6sx-usdhc + - fsl,imx6ull-usdhc + - fsl,imx7d-usdhc + - fsl,imx7ulp-usdhc + - fsl,imx8mq-usdhc + - fsl,imx8mm-usdhc + - fsl,imx8mn-usdhc + - fsl,imx8mp-usdhc + - fsl,imx8qm-usdhc + - fsl,imx8qxp-usdhc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,wp-controller: + description: | + boolean, if present, indicate to use controller internal write protection. + type: boolean + + fsl,delay-line: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the number of delay cells for override mode. + This is used to set the clock delay for DLL(Delay Line) on override mode + to select a proper data sampling window in case the clock quality is not good + due to signal path is too long on the board. Please refer to eSDHC/uSDHC + chapter, DLL (Delay Line) section in RM for details. + default: 0 + + voltage-ranges: + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' + description: | + Specify the voltage range in case there are software transparent level + shifters on the outputs of the controller. Two cells are required, first + cell specifies minimum slot voltage (mV), second cell specifies maximum + slot voltage (mV). + items: + items: + - description: value for minimum slot voltage + - description: value for maximum slot voltage + maxItems: 1 + + fsl,tuning-start-tap: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the start delay cell point when send first CMD19 in tuning procedure. + default: 0 + + fsl,tuning-step: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the increasing delay cell steps in tuning procedure. + The uSDHC use one delay cell as default increasing step to do tuning process. + This property allows user to change the tuning step to more than one delay + cells which is useful for some special boards or cards when the default + tuning step can't find the proper delay window within limited tuning retries. + default: 0 + + fsl,strobe-dll-delay-target: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specify the strobe dll control slave delay target. + This delay target programming host controller loopback read clock, and this + property allows user to change the delay target for the strobe input read clock. + If not use this property, driver default set the delay target to value 7. + Only eMMC HS400 mode need to take care of this property. + default: 0 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + mmc@70004000 { + compatible = "fsl,imx51-esdhc"; + reg = <0x70004000 0x4000>; + interrupts = <1>; + fsl,wp-controller; + }; + + mmc@70008000 { + compatible = "fsl,imx51-esdhc"; + reg = <0x70008000 0x4000>; + interrupts = <2>; + cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */ + wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */ + }; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt deleted file mode 100644 index 184ccffe2739..000000000000 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Freescale Secure Digital Host Controller for i.MX2/3 series - -This file documents differences to the properties defined in mmc.txt. - -Required properties: -- compatible : Should be "fsl,<chip>-mmc", chip can be imx21 or imx31 - -Optional properties: -- dmas: One DMA phandle with arguments as defined by the devicetree bindings - of the used DMA controller. -- dma-names: Has to be "rx-tx". - -Example: - -sdhci1: sdhci@10014000 { - compatible = "fsl,imx27-mmc", "fsl,imx21-mmc"; - reg = <0x10014000 0x1000>; - interrupts = <11>; - dmas = <&dma 7>; - dma-names = "rx-tx"; - bus-width = <4>; - cd-gpios = <&gpio3 29>; -}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml new file mode 100644 index 000000000000..ffa162722b8e --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-mmc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/fsl-imx-mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Secure Digital Host Controller for i.MX2/3 series + +maintainers: + - Markus Pargmann <mpa@pengutronix.de> + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + oneOf: + - const: fsl,imx21-mmc + - const: fsl,imx31-mmc + - items: + - const: fsl,imx27-mmc + - const: fsl,imx21-mmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + mmc@10014000 { + compatible = "fsl,imx27-mmc", "fsl,imx21-mmc"; + reg = <0x10014000 0x1000>; + interrupts = <11>; + dmas = <&dma 7>; + dma-names = "rx-tx"; + bus-width = <4>; + cd-gpios = <&gpio3 29>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml index 4931fab34d81..b96da0c7f819 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml @@ -169,6 +169,11 @@ properties: description: Full power cycle of the card is supported. + full-pwr-cycle-in-suspend: + $ref: /schemas/types.yaml#/definitions/flag + description: + Full power cycle of the card in suspend is supported. + mmc-ddr-1_2v: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt deleted file mode 100644 index 3d965d57e00b..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt +++ /dev/null @@ -1,25 +0,0 @@ -* The simple eMMC hardware reset provider - -The purpose of this driver is to perform standard eMMC hw reset -procedure, as described by Jedec 4.4 specification. This procedure is -performed just after MMC core enabled power to the given mmc host (to -fix possible issues if bootloader has left eMMC card in initialized or -unknown state), and before performing complete system reboot (also in -case of emergency reboot call). The latter is needed on boards, which -doesn't have hardware reset logic connected to emmc card and (limited or -broken) ROM bootloaders are unable to read second stage from the emmc -card if the card is left in unknown or already initialized state. - -Required properties: -- compatible : contains "mmc-pwrseq-emmc". -- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted - and then deasserted to perform eMMC card reset. To perform - reset procedure as described in Jedec 4.4 specification, the - gpio line should be defined as GPIO_ACTIVE_LOW. - -Example: - - sdhci0_pwrseq { - compatible = "mmc-pwrseq-emmc"; - reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml new file mode 100644 index 000000000000..77f746f57284 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-emmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple eMMC hardware reset provider binding + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: + The purpose of this driver is to perform standard eMMC hw reset + procedure, as described by Jedec 4.4 specification. This procedure is + performed just after MMC core enabled power to the given mmc host (to + fix possible issues if bootloader has left eMMC card in initialized or + unknown state), and before performing complete system reboot (also in + case of emergency reboot call). The latter is needed on boards, which + doesn't have hardware reset logic connected to emmc card and (limited or + broken) ROM bootloaders are unable to read second stage from the emmc + card if the card is left in unknown or already initialized state. + +properties: + compatible: + const: mmc-pwrseq-emmc + + reset-gpios: + minItems: 1 + description: + contains a GPIO specifier. The reset GPIO is asserted + and then deasserted to perform eMMC card reset. To perform + reset procedure as described in Jedec 4.4 specification, the + gpio line should be defined as GPIO_ACTIVE_LOW. + +required: + - compatible + - reset-gpios + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + sdhci0_pwrseq { + compatible = "mmc-pwrseq-emmc"; + reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt deleted file mode 100644 index 22e9340e4ba2..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt +++ /dev/null @@ -1,16 +0,0 @@ -* Marvell SD8787 power sequence provider - -Required properties: -- compatible: must be "mmc-pwrseq-sd8787". -- powerdown-gpios: contains a power down GPIO specifier with the - default active state -- reset-gpios: contains a reset GPIO specifier with the default - active state - -Example: - - wifi_pwrseq: wifi_pwrseq { - compatible = "mmc-pwrseq-sd8787"; - powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>; - reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml new file mode 100644 index 000000000000..a68820d31d50 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-sd8787.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell SD8787 power sequence provider binding + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +properties: + compatible: + const: mmc-pwrseq-sd8787 + + powerdown-gpios: + minItems: 1 + description: + contains a power down GPIO specifier with the default active state + + reset-gpios: + minItems: 1 + description: + contains a reset GPIO specifier with the default active state + +required: + - compatible + - powerdown-gpios + - reset-gpios + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-sd8787"; + powerdown-gpios = <&twl_gpio 0 GPIO_ACTIVE_LOW>; + reset-gpios = <&twl_gpio 1 GPIO_ACTIVE_LOW>; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt deleted file mode 100644 index 9029b45b8a22..000000000000 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ /dev/null @@ -1,31 +0,0 @@ -* The simple MMC power sequence provider - -The purpose of the simple MMC power sequence provider is to supports a set of -common properties between various SOC designs. It thus enables us to use the -same provider for several SOC designs. - -Required properties: -- compatible : contains "mmc-pwrseq-simple". - -Optional properties: -- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted - at initialization and prior we start the power up procedure of the card. - They will be de-asserted right after the power has been provided to the - card. -- clocks : Must contain an entry for the entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entry: - "ext_clock" (External clock provided to the card). -- post-power-on-delay-ms : Delay in ms after powering the card and - de-asserting the reset-gpios (if any) -- power-off-delay-us : Delay in us after asserting the reset-gpios (if any) - during power off of the card. - -Example: - - sdhci0_pwrseq { - compatible = "mmc-pwrseq-simple"; - reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; - clocks = <&clk_32768_ck>; - clock-names = "ext_clock"; - } diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml new file mode 100644 index 000000000000..449215444723 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-pwrseq-simple.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Simple MMC power sequence provider binding + +maintainers: + - Ulf Hansson <ulf.hansson@linaro.org> + +description: + The purpose of the simple MMC power sequence provider is to supports a set + of common properties between various SOC designs. It thus enables us to use + the same provider for several SOC designs. + +properties: + compatible: + const: mmc-pwrseq-simple + + reset-gpios: + minItems: 1 + description: + contains a list of GPIO specifiers. The reset GPIOs are asserted + at initialization and prior we start the power up procedure of the card. + They will be de-asserted right after the power has been provided to the + card. + + clocks: + minItems: 1 + description: Handle for the entry in clock-names. + + clock-names: + items: + - const: ext_clock + description: External clock provided to the card. + + post-power-on-delay-ms: + description: + Delay in ms after powering the card and de-asserting the + reset-gpios (if any). + $ref: /schemas/types.yaml#/definitions/uint32 + + power-off-delay-us: + description: + Delay in us after asserting the reset-gpios (if any) + during power off of the card. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + sdhci0_pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; + clocks = <&clk_32768_ck>; + clock-names = "ext_clock"; + }; +... diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index 8a532f4453f2..0c9cf6a8808c 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 "mediatek,mt8183-mmc": for mmc host ip compatible with mt8183 "mediatek,mt8516-mmc": for mmc host ip compatible with mt8516 + "mediatek,mt6779-mmc": for mmc host ip compatible with mt6779 "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 "mediatek,mt7622-mmc": for MT7622 SoC diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt deleted file mode 100644 index 515addc20070..000000000000 --- a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Freescale MXS MMC controller - -The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller -to support MMC, SD, and SDIO types of memory cards. - -This file documents differences between the core properties in mmc.txt -and the properties used by the mxsmmc driver. - -Required properties: -- compatible: Should be "fsl,<chip>-mmc". The supported chips include - imx23 and imx28. -- interrupts: Should contain ERROR interrupt number -- dmas: DMA specifier, consisting of a phandle to DMA controller node - and SSP DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. -- dma-names: Must be "rx-tx". - -Examples: - -ssp0: ssp@80010000 { - compatible = "fsl,imx28-mmc"; - reg = <0x80010000 2000>; - interrupts = <96>; - dmas = <&dma_apbh 0>; - dma-names = "rx-tx"; - bus-width = <8>; -}; diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml new file mode 100644 index 000000000000..1cccc0478d49 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mxs-mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MXS MMC controller + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: | + The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller + to support MMC, SD, and SDIO types of memory cards. + + This file documents differences between the core properties in mmc.txt + and the properties used by the mxsmmc driver. + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + enum: + - fsl,imx23-mmc + - fsl,imx28-mmc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + +required: + - compatible + - reg + - interrupts + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + mmc@80010000 { + compatible = "fsl,imx28-mmc"; + reg = <0x80010000 2000>; + interrupts = <96>; + dmas = <&dma_apbh 0>; + dma-names = "rx-tx"; + bus-width = <8>; + }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt b/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt deleted file mode 100644 index 0ca9a622cce0..000000000000 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.txt +++ /dev/null @@ -1,114 +0,0 @@ -* Renesas SDHI SD/MMC controller - -Required properties: -- compatible: should contain one or more of the following: - "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC - "renesas,sdhi-r7s72100" - SDHI IP on R7S72100 SoC - "renesas,sdhi-r7s9210" - SDHI IP on R7S9210 SoC - "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC - "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC - "renesas,sdhi-r8a7742" - SDHI IP on R8A7742 SoC - "renesas,sdhi-r8a7743" - SDHI IP on R8A7743 SoC - "renesas,sdhi-r8a7744" - SDHI IP on R8A7744 SoC - "renesas,sdhi-r8a7745" - SDHI IP on R8A7745 SoC - "renesas,sdhi-r8a774a1" - SDHI IP on R8A774A1 SoC - "renesas,sdhi-r8a774b1" - SDHI IP on R8A774B1 SoC - "renesas,sdhi-r8a774c0" - SDHI IP on R8A774C0 SoC - "renesas,sdhi-r8a77470" - SDHI IP on R8A77470 SoC - "renesas,sdhi-mmc-r8a77470" - SDHI/MMC IP on R8A77470 SoC - "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC - "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC - "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC - "renesas,sdhi-r8a7791" - SDHI IP on R8A7791 SoC - "renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC - "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC - "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC - "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC - "renesas,sdhi-r8a7796" - SDHI IP on R8A77960 SoC - "renesas,sdhi-r8a77961" - SDHI IP on R8A77961 SoC - "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC - "renesas,sdhi-r8a77970" - SDHI IP on R8A77970 SoC - "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC - "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC - "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC - "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller - "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller - "renesas,rcar-gen2-sdhi" - a generic R-Car Gen2 and RZ/G1 SDHI - (not SDHI/MMC) controller - "renesas,rcar-gen3-sdhi" - a generic R-Car Gen3 or RZ/G2 - SDHI controller - - - When compatible with the generic version, nodes must list - the SoC-specific version corresponding to the platform - first followed by the generic version. - -- clocks: Most controllers only have 1 clock source per channel. However, on - some variations of this controller, the internal card detection - logic that exists in this controller is sectioned off to be run by a - separate second clock source to allow the main core clock to be turned - off to save power. - If 2 clocks are specified by the hardware, you must name them as - "core" and "cd". If the controller only has 1 clock, naming is not - required. - Devices which have more than 1 clock are listed below: - 2: R7S72100, R7S9210 - -Optional properties: -- pinctrl-names: should be "default", "state_uhs" -- pinctrl-0: should contain default/high speed pin ctrl -- pinctrl-1: should contain uhs mode pin ctrl - -Example: R8A7790 (R-Car H2) SDHI controller nodes - - sdhi0: sd@ee100000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee100000 0 0x328>; - interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 314>; - dmas = <&dmac0 0xcd>, <&dmac0 0xce>, - <&dmac1 0xcd>, <&dmac1 0xce>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <195000000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 314>; - }; - - sdhi1: sd@ee120000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee120000 0 0x328>; - interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 313>; - dmas = <&dmac0 0xc9>, <&dmac0 0xca>, - <&dmac1 0xc9>, <&dmac1 0xca>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <195000000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 313>; - }; - - sdhi2: sd@ee140000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee140000 0 0x100>; - interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 312>; - dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, - <&dmac1 0xc1>, <&dmac1 0xc2>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <97500000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 312>; - }; - - sdhi3: sd@ee160000 { - compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; - reg = <0 0xee160000 0 0x100>; - interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 311>; - dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, - <&dmac1 0xd3>, <&dmac1 0xd4>; - dma-names = "tx", "rx", "tx", "rx"; - max-frequency = <97500000>; - power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; - resets = <&cpg 311>; - }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml new file mode 100644 index 000000000000..e5dbc20456e5 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mmc/renesas,sdhi.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas SDHI SD/MMC controller + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: "mmc-controller.yaml" + +properties: + compatible: + oneOf: + - items: + - const: renesas,sdhi-sh73a0 # R-Mobile APE6 + - items: + - const: renesas,sdhi-r7s72100 # RZ/A1H + - items: + - const: renesas,sdhi-r7s9210 # SH-Mobile AG5 + - items: + - const: renesas,sdhi-r8a73a4 # R-Mobile APE6 + - items: + - const: renesas,sdhi-r8a7740 # R-Mobile A1 + - items: + - enum: + - renesas,sdhi-r8a7778 # R-Car M1 + - renesas,sdhi-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-sdhi # R-Car Gen1 + - items: + - enum: + - renesas,sdhi-r8a7742 # RZ/G1H + - renesas,sdhi-r8a7743 # RZ/G1M + - renesas,sdhi-r8a7744 # RZ/G1N + - renesas,sdhi-r8a7745 # RZ/G1E + - renesas,sdhi-r8a77470 # RZ/G1C + - renesas,sdhi-r8a7790 # R-Car H2 + - renesas,sdhi-r8a7791 # R-Car M2-W + - renesas,sdhi-r8a7792 # R-Car V2H + - renesas,sdhi-r8a7793 # R-Car M2-N + - renesas,sdhi-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-sdhi # R-Car Gen2 and RZ/G1 + - items: + - const: renesas,sdhi-mmc-r8a77470 # RZ/G1C (SDHI/MMC IP) + - items: + - enum: + - renesas,sdhi-r8a774a1 # RZ/G2M + - renesas,sdhi-r8a774b1 # RZ/G2N + - renesas,sdhi-r8a774c0 # RZ/G2E + - renesas,sdhi-r8a7795 # R-Car H3 + - renesas,sdhi-r8a7796 # R-Car M3-W + - renesas,sdhi-r8a77961 # R-Car M3-W+ + - renesas,sdhi-r8a77965 # R-Car M3-N + - renesas,sdhi-r8a77970 # R-Car V3M + - renesas,sdhi-r8a77980 # R-Car V3H + - renesas,sdhi-r8a77990 # R-Car E3 + - renesas,sdhi-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 3 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: core + - const: cd + + dmas: + minItems: 4 + maxItems: 4 + + dma-names: + minItems: 4 + maxItems: 4 + items: + enum: + - tx + - rx + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + pinctrl-0: + minItems: 1 + maxItems: 2 + + pinctrl-1: + maxItems: 1 + + pinctrl-names: + minItems: 1 + maxItems: 2 + items: + - const: default + - const: state_uhs + + max-frequency: true + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + +if: + properties: + compatible: + items: + enum: + - renesas,sdhi-r7s72100 + - renesas,sdhi-r7s9210 +then: + required: + - clock-names + description: + The internal card detection logic that exists in these controllers is + sectioned off to be run by a separate second clock source to allow + the main core clock to be turned off to save power. + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + sdhi0: mmc@ee100000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee100000 0x328>; + interrupts = <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 314>; + dmas = <&dmac0 0xcd>, <&dmac0 0xce>, <&dmac1 0xcd>, <&dmac1 0xce>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 314>; + }; + + sdhi1: mmc@ee120000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee120000 0x328>; + interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 313>; + dmas = <&dmac0 0xc9>, <&dmac0 0xca>, <&dmac1 0xc9>, <&dmac1 0xca>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <195000000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 313>; + }; + + sdhi2: mmc@ee140000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee140000 0x100>; + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 312>; + dmas = <&dmac0 0xc1>, <&dmac0 0xc2>, <&dmac1 0xc1>, <&dmac1 0xc2>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 312>; + }; + + sdhi3: mmc@ee160000 { + compatible = "renesas,sdhi-r8a7790", "renesas,rcar-gen2-sdhi"; + reg = <0xee160000 0x100>; + interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 311>; + dmas = <&dmac0 0xd3>, <&dmac0 0xd4>, <&dmac1 0xd3>, <&dmac1 0xd4>; + dma-names = "tx", "rx", "tx", "rx"; + max-frequency = <97500000>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 311>; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt index c6ccecb9ae5a..6d202f4d9249 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.txt @@ -39,6 +39,7 @@ Optional Properties (Required for ti,am654-sdhci-5.1 and ti,j721e-sdhci-8bit): Valid values are 33, 40, 50, 66 and 100 ohms. Optional Properties: - ti,strobe-sel: strobe select delay for HS400 speed mode. Default value: 0x0. + - ti,clkbuf-sel: Clock Delay Buffer Select Example: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index b8e1d2b7aea9..3b602fd6180b 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -54,6 +54,21 @@ Required properties: - qcom,dll-config: Chipset and Platform specific value. Use this field to specify the DLL_CONFIG register value as per Hardware Programming Guide. +Optional Properties: +* Following bus parameters are required for interconnect bandwidth scaling: +- interconnects: Pairs of phandles and interconnect provider specifier + to denote the edge source and destination ports of + the interconnect path. + +- interconnect-names: For sdhc, we have two main paths. + 1. Data path : sdhc to ddr + 2. Config path : cpu to sdhc + For Data interconnect path the name supposed to be + is "sdhc-ddr" and for config interconnect path it is + "cpu-sdhc". + Please refer to Documentation/devicetree/bindings/ + interconnect/ for more details. + Example: sdhc_1: sdhci@f9824900 { @@ -71,6 +86,9 @@ Example: clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; clock-names = "core", "iface"; + interconnects = <&qnoc MASTER_SDCC_ID &qnoc SLAVE_DDR_ID>, + <&qnoc MASTER_CPU_ID &qnoc SLAVE_SDCC_ID>; + interconnect-names = "sdhc-ddr","cpu-sdhc"; qcom,dll-config = <0x000f642c>; qcom,ddr-config = <0x80040868>; 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/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt deleted file mode 100644 index 393588385c6e..000000000000 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ /dev/null @@ -1,75 +0,0 @@ -* Freescale General-Purpose Media Interface (GPMI) - -The GPMI nand controller provides an interface to control the -NAND flash chips. - -Required properties: - - compatible : should be "fsl,<chip>-gpmi-nand", chip can be: - * imx23 - * imx28 - * imx6q - * imx6sx - * imx7d - - reg : should contain registers location and length for gpmi and bch. - - reg-names: Should contain the reg names "gpmi-nand" and "bch" - - interrupts : BCH interrupt number. - - interrupt-names : Should be "bch". - - dmas: DMA specifier, consisting of a phandle to DMA controller node - and GPMI DMA channel ID. - Refer to dma.txt and fsl-mxs-dma.txt for details. - - dma-names: Must be "rx-tx". - - clocks : clocks phandle and clock specifier corresponding to each clock - specified in clock-names. - - clock-names : The "gpmi_io" clock is always required. Which clocks are - exactly required depends on chip: - * imx23/imx28 : "gpmi_io" - * imx6q/sx : "gpmi_io", "gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch" - * imx7d : "gpmi_io", "gpmi_bch_apb" - -Optional properties: - - nand-on-flash-bbt: boolean to enable on flash bbt option if not - present false - - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC - strength required. The required ECC strength is - automatically discoverable for some flash - (e.g., according to the ONFI standard). - However, note that if this strength is not - discoverable or this property is not enabled, - the software may chooses an implementation-defined - ECC scheme. - - fsl,no-blockmark-swap: Don't swap the bad block marker from the OOB - area with the byte in the data area but rely on the - flash based BBT for identifying bad blocks. - NOTE: this is only valid in conjunction with - 'nand-on-flash-bbt'. - WARNING: on i.MX28 blockmark swapping cannot be - disabled for the BootROM in the FCB. Thus, - partitions written from Linux with this feature - turned on may not be accessible by the BootROM - code. - - nand-ecc-strength: integer representing the number of bits to correct - per ECC step. Needs to be a multiple of 2. - - nand-ecc-step-size: integer representing the number of data bytes - that are covered by a single ECC step. The driver - supports 512 and 1024. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Examples: - -gpmi-nand@8000c000 { - compatible = "fsl,imx28-gpmi-nand"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x8000c000 2000>, <0x8000a000 2000>; - reg-names = "gpmi-nand", "bch"; - interrupts = <41>; - interrupt-names = "bch"; - dmas = <&dma_apbh 4>; - dma-names = "rx-tx"; - - partition@0 { - ... - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml new file mode 100644 index 000000000000..354cb63feea3 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale General-Purpose Media Interface (GPMI) binding + +maintainers: + - Han Xu <han.xu@nxp.com> + +allOf: + - $ref: "nand-controller.yaml" + +description: | + The GPMI nand controller provides an interface to control the NAND + flash chips. The device tree may optionally contain sub-nodes + describing partitions of the address space. See partition.txt for + more detail. + +properties: + compatible: + enum: + - fsl,imx23-gpmi-nand + - fsl,imx28-gpmi-nand + - fsl,imx6q-gpmi-nand + - fsl,imx6sx-gpmi-nand + - fsl,imx7d-gpmi-nand + + reg: + items: + - description: Address and length of gpmi block. + - description: Address and length of bch block. + + reg-names: + items: + - const: gpmi-nand + - const: bch + + interrupts: + maxItems: 1 + + interrupt-names: + const: bch + + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + + clocks: + minItems: 1 + maxItems: 5 + items: + - description: SoC gpmi io clock + - description: SoC gpmi apb clock + - description: SoC gpmi bch clock + - description: SoC gpmi bch apb clock + - description: SoC per1 bch clock + + clock-names: + minItems: 1 + maxItems: 5 + items: + - const: gpmi_io + - const: gpmi_apb + - const: gpmi_bch + - const: gpmi_bch_apb + - const: per1_bch + + fsl,use-minimum-ecc: + type: boolean + description: | + Protect this NAND flash with the minimum ECC strength required. + The required ECC strength is automatically discoverable for some + flash (e.g., according to the ONFI standard). However, note that + if this strength is not discoverable or this property is not enabled, + the software may chooses an implementation-defined ECC scheme. + + fsl,no-blockmark-swap: + type: boolean + description: | + Don't swap the bad block marker from the OOB area with the byte in + the data area but rely on the flash based BBT for identifying bad blocks. + NOTE: this is only valid in conjunction with 'nand-on-flash-bbt'. + WARNING: on i.MX28 blockmark swapping cannot be disabled for the BootROM + in the FCB. Thus, partitions written from Linux with this feature turned + on may not be accessible by the BootROM code. + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - clock-names + - dmas + - dma-names + +unevaluatedProperties: false + +examples: + - | + nand-controller@8000c000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-gpmi-nand"; + reg = <0x8000c000 0x2000>, <0x8000a000 0x2000>; + reg-names = "gpmi-nand", "bch"; + interrupts = <41>; + interrupt-names = "bch"; + clocks = <&clks 50>; + clock-names = "gpmi_io"; + dmas = <&dma_apbh 4>; + dma-names = "rx-tx"; + }; diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.txt b/Documentation/devicetree/bindings/mtd/mxc-nand.txt deleted file mode 100644 index 2857c628fba4..000000000000 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Freescale's mxc_nand - -Required properties: -- compatible: "fsl,imxXX-nand" -- reg: address range of the nfc block -- interrupts: irq to be used -- nand-bus-width: see nand-controller.yaml -- nand-ecc-mode: see nand-controller.yaml -- nand-on-flash-bbt: see nand-controller.yaml - -Example: - - nand@d8000000 { - compatible = "fsl,imx27-nand"; - reg = <0xd8000000 0x1000>; - interrupts = <29>; - nand-bus-width = <8>; - nand-ecc-mode = "hw"; - }; diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml new file mode 100644 index 000000000000..ee4d1d026fd8 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mxc-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale's mxc_nand binding + +maintainers: + - Uwe Kleine-König <u.kleine-koenig@pengutronix.de> + +allOf: + - $ref: "nand-controller.yaml" + +properties: + compatible: + const: fsl,imx27-nand + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + nand-controller@d8000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx27-nand"; + reg = <0xd8000000 0x1000>; + interrupts = <29>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + }; 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/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 64c20c92c07d..85fefe3a0444 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -22,6 +22,7 @@ select: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac required: - compatible @@ -36,6 +37,7 @@ allOf: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac then: properties: @@ -95,6 +97,7 @@ properties: - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - amlogic,meson-g12a-dwmac contains: enum: - snps,dwmac-3.70a diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt index f66bb7ecdb82..bf7328aba330 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.txt +++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt @@ -1,257 +1,4 @@ Distributed Switch Architecture Device Tree Bindings ---------------------------------------------------- -Switches are true Linux devices and can be probed by any means. Once -probed, they register to the DSA framework, passing a node -pointer. This node is expected to fulfil the following binding, and -may contain additional properties as required by the device it is -embedded within. - -Required properties: - -- ports : A container for child nodes representing switch ports. - -Optional properties: - -- dsa,member : A two element list indicates which DSA cluster, and position - within the cluster a switch takes. <0 0> is cluster 0, - switch 0. <0 1> is cluster 0, switch 1. <1 0> is cluster 1, - switch 0. A switch not part of any cluster (single device - hanging off a CPU port) must not specify this property - -The ports container has the following properties - -Required properties: - -- #address-cells : Must be 1 -- #size-cells : Must be 0 - -Each port children node must have the following mandatory properties: -- reg : Describes the port address in the switch - -An uplink/downlink port between switches in the cluster has the following -mandatory property: - -- link : Should be a list of phandles to other switch's DSA - port. This port is used as the outgoing port - towards the phandle ports. The full routing - information must be given, not just the one hop - routes to neighbouring switches. - -A CPU port has the following mandatory property: - -- ethernet : Should be a phandle to a valid Ethernet device node. - This host device is what the switch port is - connected to. - -A user port has the following optional property: - -- label : Describes the label associated with this port, which - will become the netdev name. - -Port child nodes may also contain the following optional standardised -properties, described in binding documents: - -- phy-handle : Phandle to a PHY on an MDIO bus. See - Documentation/devicetree/bindings/net/ethernet.txt - for details. - -- phy-mode : See - Documentation/devicetree/bindings/net/ethernet.txt - for details. - -- fixed-link : Fixed-link subnode describing a link to a non-MDIO - managed entity. See - Documentation/devicetree/bindings/net/fixed-link.txt - for details. - -The MAC address will be determined using the optional properties -defined in ethernet.txt. - -Example - -The following example shows three switches on three MDIO busses, -linked into one DSA cluster. - -&mdio1 { - #address-cells = <1>; - #size-cells = <0>; - - switch0: switch0@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan0"; - }; - - port@1 { - reg = <1>; - label = "lan1"; - local-mac-address = [00 00 00 00 00 00]; - }; - - port@2 { - reg = <2>; - label = "lan2"; - }; - - switch0port5: port@5 { - reg = <5>; - phy-mode = "rgmii-txid"; - link = <&switch1port6 - &switch2port9>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - port@6 { - reg = <6>; - ethernet = <&fec1>; - fixed-link { - speed = <100>; - full-duplex; - }; - }; - }; - }; -}; - -&mdio2 { - #address-cells = <1>; - #size-cells = <0>; - - switch1: switch1@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 1>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan3"; - phy-handle = <&switch1phy0>; - }; - - port@1 { - reg = <1>; - label = "lan4"; - phy-handle = <&switch1phy1>; - }; - - port@2 { - reg = <2>; - label = "lan5"; - phy-handle = <&switch1phy2>; - }; - - switch1port5: port@5 { - reg = <5>; - link = <&switch2port9>; - phy-mode = "rgmii-txid"; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - switch1port6: port@6 { - reg = <6>; - phy-mode = "rgmii-txid"; - link = <&switch0port5>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - mdio-bus { - #address-cells = <1>; - #size-cells = <0>; - switch1phy0: switch1phy0@0 { - reg = <0>; - }; - switch1phy1: switch1phy0@1 { - reg = <1>; - }; - switch1phy2: switch1phy0@2 { - reg = <2>; - }; - }; - }; -}; - -&mdio4 { - #address-cells = <1>; - #size-cells = <0>; - - switch2: switch2@0 { - compatible = "marvell,mv88e6085"; - reg = <0>; - - dsa,member = <0 2>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan6"; - }; - - port@1 { - reg = <1>; - label = "lan7"; - }; - - port@2 { - reg = <2>; - label = "lan8"; - }; - - port@3 { - reg = <3>; - label = "optical3"; - fixed-link { - speed = <1000>; - full-duplex; - link-gpios = <&gpio6 2 - GPIO_ACTIVE_HIGH>; - }; - }; - - port@4 { - reg = <4>; - label = "optical4"; - fixed-link { - speed = <1000>; - full-duplex; - link-gpios = <&gpio6 3 - GPIO_ACTIVE_HIGH>; - }; - }; - - switch2port9: port@9 { - reg = <9>; - phy-mode = "rgmii-txid"; - link = <&switch1port5 - &switch0port5>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; -}; +See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documenation. diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml new file mode 100644 index 000000000000..faea214339ca --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/dsa.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ethernet Switch Device Tree Bindings + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Vivien Didelot <vivien.didelot@gmail.com> + +description: + This binding represents Ethernet Switches which have a dedicated CPU + port. That port is usually connected to an Ethernet Controller of the + SoC. Such setups are typical for embedded devices. + +select: false + +properties: + $nodename: + pattern: "^switch(@.*)?$" + + dsa,member: + minItems: 2 + maxItems: 2 + description: + A two element list indicates which DSA cluster, and position within the + cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0, + switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster + (single device hanging off a CPU port) must not specify this property + $ref: /schemas/types.yaml#/definitions/uint32-array + +patternProperties: + "^(ethernet-)?ports$": + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^(ethernet-)?port@[0-9]+$": + type: object + description: Ethernet switch ports + + properties: + reg: + description: Port number + + label: + description: + Describes the label associated with this port, which will become + the netdev name + $ref: /schemas/types.yaml#definitions/string + + link: + description: + Should be a list of phandles to other switch's DSA port. This + port is used as the outgoing port towards the phandle ports. The + full routing information must be given, not just the one hop + routes to neighbouring switches + $ref: /schemas/types.yaml#definitions/phandle-array + + ethernet: + description: + Should be a phandle to a valid Ethernet device node. This host + device is what the switch port is connected to + $ref: /schemas/types.yaml#definitions/phandle + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + required: + - reg + + additionalProperties: false + +oneOf: + - required: + - ports + - required: + - ethernet-ports + +... diff --git a/Documentation/devicetree/bindings/net/dsa/ocelot.txt b/Documentation/devicetree/bindings/net/dsa/ocelot.txt index 66a129fea705..7a271d070b72 100644 --- a/Documentation/devicetree/bindings/net/dsa/ocelot.txt +++ b/Documentation/devicetree/bindings/net/dsa/ocelot.txt @@ -4,10 +4,15 @@ Microchip Ocelot switch driver family Felix ----- -The VSC9959 core is currently the only switch supported by the driver, and is -found in the NXP LS1028A. It is a PCI device, part of the larger ENETC root -complex. As a result, the ethernet-switch node is a sub-node of the PCIe root -complex node and its "reg" property conforms to the parent node bindings: +Currently the switches supported by the felix driver are: + +- VSC9959 (Felix) +- VSC9953 (Seville) + +The VSC9959 switch is found in the NXP LS1028A. It is a PCI device, part of the +larger ENETC root complex. As a result, the ethernet-switch node is a sub-node +of the PCIe root complex node and its "reg" property conforms to the parent +node bindings: * reg: Specifies PCIe Device Number and Function Number of the endpoint device, in this case for the Ethernet L2Switch it is PF5 (of device 0, bus 0). @@ -114,3 +119,95 @@ Example: }; }; }; + +The VSC9953 switch is found inside NXP T1040. It is a platform device with the +following required properties: + +- compatible: + Must be "mscc,vsc9953-switch". + +Supported PHY interface types (appropriate SerDes protocol setting changes are +needed in the RCW binary): + +* phy_mode = "internal": on ports 8 and 9 +* phy_mode = "sgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7 +* phy_mode = "qsgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7 + +Example: + +&soc { + ethernet-switch@800000 { + #address-cells = <0x1>; + #size-cells = <0x0>; + compatible = "mscc,vsc9953-switch"; + little-endian; + reg = <0x800000 0x290000>; + + ports { + #address-cells = <0x1>; + #size-cells = <0x0>; + + port@0 { + reg = <0x0>; + label = "swp0"; + }; + + port@1 { + reg = <0x1>; + label = "swp1"; + }; + + port@2 { + reg = <0x2>; + label = "swp2"; + }; + + port@3 { + reg = <0x3>; + label = "swp3"; + }; + + port@4 { + reg = <0x4>; + label = "swp4"; + }; + + port@5 { + reg = <0x5>; + label = "swp5"; + }; + + port@6 { + reg = <0x6>; + label = "swp6"; + }; + + port@7 { + reg = <0x7>; + label = "swp7"; + }; + + port@8 { + reg = <0x8>; + phy-mode = "internal"; + ethernet = <&enet0>; + + fixed-link { + speed = <2500>; + full-duplex; + }; + }; + + port@9 { + reg = <0x9>; + phy-mode = "internal"; + status = "disabled"; + + fixed-link { + speed = <2500>; + full-duplex; + }; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 9b1f1147ca36..a9e547ac7905 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -162,6 +162,18 @@ properties: description: Specifies a reference to a node representing a SFP cage. + rx-internal-delay-ps: + description: | + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable RX internal delays. If this property is + present then the PHY applies the RX delay. + + tx-internal-delay-ps: + description: | + RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for + PHY's that have configurable TX internal delays. If this property is + present then the PHY applies the TX delay. + required: - reg diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml index d6a3bf8550eb..26afb556dfae 100644 --- a/Documentation/devicetree/bindings/net/mdio.yaml +++ b/Documentation/devicetree/bindings/net/mdio.yaml @@ -39,6 +39,13 @@ properties: and must therefore be appropriately determined based on all devices requirements (maximum value of all per-device RESET pulse widths). + reset-post-delay-us: + description: + Delay after reset deassert in microseconds. It applies to all MDIO + devices and it's determined by how fast all devices are ready for + communication. This delay happens just before e.g. Ethernet PHY + type ID auto detection. + clock-frequency: description: Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3 diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt index 5ff37c68c941..87a27d775d48 100644 --- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt @@ -31,6 +31,8 @@ Optional properties: VSC8531_LINK_100_ACTIVITY (2), VSC8531_LINK_ACTIVITY (0) and VSC8531_DUPLEX_COLLISION (8). +- load-save-gpios : GPIO used for the load/save operation of the PTP + hardware clock (PHC). Table: 1 - Edge rate change @@ -67,4 +69,5 @@ Example: vsc8531,edge-slowdown = <7>; vsc8531,led-0-mode = <LINK_1000_ACTIVITY>; vsc8531,led-1-mode = <LINK_100_ACTIVITY>; + load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml index f15a5e5e4859..c488f24ed38f 100644 --- a/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.yaml @@ -44,7 +44,7 @@ examples: uart1 { pinctrl-names = "default"; pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; - uart-has-rtscts = <1>; + uart-has-rtscts; bluetooth { compatible = "realtek,rtl8723bs-bt"; diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml index 554dcd7a40a9..c6716ac6cbcc 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml @@ -24,7 +24,7 @@ description: | IEEE 802.3 Standard Media Independent Interface (MII), the IEEE 802.3 Gigabit Media Independent Interface (GMII) or Reduced GMII (RGMII). - Specifications about the charger can be found at: + Specifications about the Ethernet PHY can be found at: https://www.ti.com/lit/gpn/dp83867ir properties: diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 5b69ef03bbf7..cf40b469c719 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: TI DP83869 ethernet PHY allOf: - - $ref: "ethernet-controller.yaml#" + - $ref: "ethernet-phy.yaml#" maintainers: - Dan Murphy <dmurphy@ti.com> @@ -24,7 +24,7 @@ description: | conversions. The DP83869HM can also support Bridge Conversion from RGMII to SGMII and SGMII to RGMII. - Specifications about the charger can be found at: + Specifications about the Ethernet PHY can be found at: http://www.ti.com/lit/ds/symlink/dp83869hm.pdf properties: @@ -64,6 +64,18 @@ properties: Operational mode for the PHY. If this is not set then the operational mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values + rx-internal-delay-ps: + description: Delay is in pico seconds + enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, + 3250, 3500, 3750, 4000 ] + default: 2000 + + tx-internal-delay-ps: + description: Delay is in pico seconds + enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000, + 3250, 3500, 3750, 4000 ] + default: 2000 + required: - reg @@ -80,5 +92,7 @@ examples: ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>; ti,max-output-impedance = "true"; ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>; + rx-internal-delay-ps = <2000>; + tx-internal-delay-ps = <2000>; }; }; diff --git a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml new file mode 100644 index 000000000000..2c320eb2a8c4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/microchip,wilc1000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip WILC wireless devicetree bindings + +maintainers: + - Adham Abozaeid <adham.abozaeid@microchip.com> + - Ajay Singh <ajay.kathat@microchip.com> + +description: + The wilc1000 chips can be connected via SPI or SDIO. This document + describes the binding to connect wilc devices. + +properties: + compatible: + const: microchip,wilc1000 + + spi-max-frequency: true + + interrupts: + maxItems: 1 + + clocks: + description: phandle to the clock connected on rtc clock line. + maxItems: 1 + + clock-names: + const: rtc + +required: + - compatible + - interrupts + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + wifi@0 { + compatible = "microchip,wilc1000"; + spi-max-frequency = <48000000>; + reg = <0>; + interrupt-parent = <&pioC>; + interrupts = <27 0>; + clocks = <&pck1>; + clock-names = "rtc"; + }; + }; + + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3>; + non-removable; + vmmc-supply = <&vcc_mmc1_reg>; + vqmmc-supply = <&vcc_3v3_reg>; + bus-width = <4>; + wifi@0 { + compatible = "microchip,wilc1000"; + reg = <0>; + interrupt-parent = <&pioC>; + interrupts = <27 0>; + clocks = <&pck1>; + clock-names = "rtc"; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index daf1321d76ad..6687ab720304 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -15,14 +15,17 @@ allOf: properties: compatible: - enum: - - allwinner,sun4i-a10-sid - - allwinner,sun7i-a20-sid - - allwinner,sun8i-a83t-sid - - allwinner,sun8i-h3-sid - - allwinner,sun50i-a64-sid - - allwinner,sun50i-h5-sid - - allwinner,sun50i-h6-sid + oneOf: + - const: allwinner,sun4i-a10-sid + - const: allwinner,sun7i-a20-sid + - const: allwinner,sun8i-a83t-sid + - const: allwinner,sun8i-h3-sid + - const: allwinner,sun50i-a64-sid + - items: + - const: allwinner,sun50i-a100-sid + - const: allwinner,sun50i-a64-sid + - const: allwinner,sun50i-h5-sid + - const: allwinner,sun50i-h6-sid reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml new file mode 100644 index 000000000000..d10a0cf91ba7 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/qcom,qfprom.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc, QFPROM Efuse bindings + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + const: qcom,qfprom + + reg: + # If the QFPROM is read-only OS image then only the corrected region + # needs to be provided. If the QFPROM is writable then all 4 regions + # must be provided. + oneOf: + - items: + - description: The corrected region. + - items: + - description: The corrected region. + - description: The raw region. + - description: The config region. + - description: The security control region. + + # Clock must be provided if QFPROM is writable from the OS image. + clocks: + maxItems: 1 + clock-names: + const: core + + # Supply reference must be provided if QFPROM is writable from the OS image. + vcc-supply: + description: Our power supply. + + # Needed if any child nodes are present. + "#address-cells": + const: 1 + "#size-cells": + const: 1 + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + efuse@784000 { + compatible = "qcom,qfprom"; + reg = <0 0x00784000 0 0x8ff>, + <0 0x00780000 0 0x7a0>, + <0 0x00782000 0 0x100>, + <0 0x00786000 0 0x1fff>; + clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>; + clock-names = "core"; + #address-cells = <1>; + #size-cells = <1>; + + vcc-supply = <&vreg_l11a_1p8>; + + hstx-trim-primary@25b { + reg = <0x25b 0x1>; + bits = <1 3>; + }; + }; + }; + + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + efuse@784000 { + compatible = "qcom,qfprom"; + reg = <0 0x00784000 0 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + + hstx-trim-primary@1eb { + reg = <0x1eb 0x1>; + bits = <1 4>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/qfprom.txt b/Documentation/devicetree/bindings/nvmem/qfprom.txt deleted file mode 100644 index 26fe878d5c86..000000000000 --- a/Documentation/devicetree/bindings/nvmem/qfprom.txt +++ /dev/null @@ -1,35 +0,0 @@ -= Qualcomm QFPROM device tree bindings = - -This binding is intended to represent QFPROM which is found in most QCOM SOCs. - -Required properties: -- compatible: should be "qcom,qfprom" -- reg: Should contain registers location and length - -= Data cells = -Are child nodes of qfprom, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example: - - qfprom: qfprom@700000 { - compatible = "qcom,qfprom"; - reg = <0x00700000 0x8000>; - ... - /* Data cells */ - tsens_calibration: calib@404 { - reg = <0x4404 0x10>; - }; - }; - - -= Data consumers = -Are device nodes which consume nvmem data cells. - -For example: - - tsens { - ... - nvmem-cells = <&tsens_calibration>; - nvmem-cell-names = "calibration"; - }; 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/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml new file mode 100644 index 000000000000..9a2e779e6d38 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/brcm,bcm63xx-usbh-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: BCM63xx USBH PHY + +maintainers: + - Álvaro Fernández Rojas <noltari@gmail.com> + +properties: + compatible: + enum: + - brcm,bcm6318-usbh-phy + - brcm,bcm6328-usbh-phy + - brcm,bcm6358-usbh-phy + - brcm,bcm6362-usbh-phy + - brcm,bcm6368-usbh-phy + - brcm,bcm63268-usbh-phy + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: usbh + - const: usb_ref + + resets: + maxItems: 1 + + "#phy-cells": + const: 1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - "#phy-cells" + +if: + properties: + compatible: + enum: + - brcm,bcm6318-usbh-phy + - brcm,bcm6328-usbh-phy + - brcm,bcm6362-usbh-phy + - brcm,bcm63268-usbh-phy +then: + properties: + power-domains: + maxItems: 1 + required: + - power-domains +else: + properties: + power-domains: false + +examples: + - | + usbh: usb-phy@10001700 { + compatible = "brcm,bcm6368-usbh-phy"; + reg = <0x10001700 0x38>; + clocks = <&periph_clk 15>; + clock-names = "usbh"; + resets = <&periph_rst 12>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt index ad49e5c01334..8b5a7a28a35b 100644 --- a/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt +++ b/Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt @@ -12,6 +12,13 @@ Required properties: - #address-cells: should be 1. - #size-cells: should be 0. +Optional properties: + +- reg-names: must be "comphy" as the first name, and "conf". +- reg: must contain the comphy register location and length as the first + pair, followed by an optional configuration register address and + length pair. + A sub-node is required for each comphy lane provided by the comphy. Required properties (child nodes): @@ -24,7 +31,8 @@ Example: comphy: phy@18300 { compatible = "marvell,armada-380-comphy"; - reg = <0x18300 0x100>; + reg-names = "comphy", "conf"; + reg = <0x18300 0x100>, <0x18460 4>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml new file mode 100644 index 000000000000..23887ebe08fd --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,ipq806x-usb-phy-hs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ipq806x usb DWC3 HS PHY CONTROLLER + +maintainers: + - Ansuel Smith <ansuelsmth@gmail.com> + +description: + DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer + controllers used in ipq806x. Each DWC3 PHY controller should have its + own node. + +properties: + compatible: + const: qcom,ipq806x-usb-phy-hs + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: ref + - const: xo + +required: + - compatible + - "#phy-cells" + - reg + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-ipq806x.h> + + hs_phy_0: phy@110f8800 { + compatible = "qcom,ipq806x-usb-phy-hs"; + reg = <0x110f8800 0x30>; + clocks = <&gcc USB30_0_UTMI_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml new file mode 100644 index 000000000000..fa30c24b4405 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,ipq806x-usb-phy-ss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ipq806x usb DWC3 SS PHY CONTROLLER + +maintainers: + - Ansuel Smith <ansuelsmth@gmail.com> + +description: + DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer + controllers used in ipq806x. Each DWC3 PHY controller should have its + own node. + +properties: + compatible: + const: qcom,ipq806x-usb-phy-ss + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + items: + - const: ref + - const: xo + + qcom,rx-eq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for rx_eq. + default: 4 + maximum: 7 + + qcom,tx-deamp-3_5db: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for transmit preemphasis. + default: 23 + maximum: 63 + + qcom,mpll: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Override value for mpll. + default: 0 + maximum: 7 + +required: + - compatible + - "#phy-cells" + - reg + - clocks + - clock-names + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-ipq806x.h> + + ss_phy_0: phy@110f8830 { + compatible = "qcom,ipq806x-usb-phy-ss"; + reg = <0x110f8830 0x30>; + clocks = <&gcc USB30_0_MASTER_CLK>; + clock-names = "ref"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f80f8896d527..e4cd4a1deae9 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq8074-qmp-pcie-phy + - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy - qcom,msm8996-qmp-ufs-phy - qcom,msm8996-qmp-usb3-phy @@ -161,6 +162,7 @@ allOf: compatible: contains: enum: + - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-usb3-phy - qcom,msm8998-qmp-pcie-phy - qcom,msm8998-qmp-usb3-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index b5a6195de7ff..9ba62dcb1e5d 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -18,6 +18,7 @@ properties: oneOf: - items: - enum: + - qcom,ipq8074-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy - items: diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 440f09fddf93..829e8c7e467a 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -21,6 +21,7 @@ properties: - renesas,usb2-phy-r8a774a1 # RZ/G2M - renesas,usb2-phy-r8a774b1 # RZ/G2N - renesas,usb2-phy-r8a774c0 # RZ/G2E + - renesas,usb2-phy-r8a774e1 # RZ/G2H - renesas,usb2-phy-r8a7795 # R-Car H3 - renesas,usb2-phy-r8a7796 # R-Car M3-W - renesas,usb2-phy-r8a77961 # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index 68cf9dd0390d..f3ef738a3ff6 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -15,6 +15,7 @@ properties: - enum: - renesas,r8a774a1-usb3-phy # RZ/G2M - renesas,r8a774b1-usb3-phy # RZ/G2N + - renesas,r8a774e1-usb3-phy # RZ/G2H - renesas,r8a7795-usb3-phy # R-Car H3 - renesas,r8a7796-usb3-phy # R-Car M3-W - renesas,r8a77961-usb3-phy # R-Car M3-W+ diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml new file mode 100644 index 000000000000..636cc501b54f --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,ufs-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SoC series UFS PHY Device Tree Bindings + +maintainers: + - Alim Akhtar <alim.akhtar@samsung.com> + +properties: + "#phy-cells": + const: 0 + + compatible: + enum: + - samsung,exynos7-ufs-phy + + reg: + maxItems: 1 + + reg-names: + items: + - const: phy-pma + + clocks: + items: + - description: PLL reference clock + - description: symbol clock for input symbol ( rx0-ch0 symbol clock) + - description: symbol clock for input symbol ( rx1-ch1 symbol clock) + - description: symbol clock for output symbol ( tx0 symbol clock) + + clock-names: + items: + - const: ref_clk + - const: rx1_symbol_clk + - const: rx0_symbol_clk + - const: tx0_symbol_clk + + samsung,pmu-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle for PMU system controller interface, used to + control pmu registers bits for ufs m-phy + +required: + - "#phy-cells" + - compatible + - reg + - reg-names + - clocks + - clock-names + - samsung,pmu-syscon + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos7-clk.h> + + ufs_phy: ufs-phy@15571800 { + compatible = "samsung,exynos7-ufs-phy"; + reg = <0x15571800 0x240>; + reg-names = "phy-pma"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <0>; + clocks = <&clock_fsys1 SCLK_COMBO_PHY_EMBEDDED_26M>, + <&clock_fsys1 PHYCLK_UFS20_RX1_SYMBOL_USER>, + <&clock_fsys1 PHYCLK_UFS20_RX0_SYMBOL_USER>, + <&clock_fsys1 PHYCLK_UFS20_TX0_SYMBOL_USER>; + clock-names = "ref_clk", "rx1_symbol_clk", + "rx0_symbol_clk", "tx0_symbol_clk"; + + }; +... diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml index f88d36207b87..c871d462c952 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml @@ -31,12 +31,16 @@ properties: clocks: minItems: 1 - maxItems: 2 + maxItems: 3 clock-names: oneOf: - const: link # for PXs2 - - items: # for PXs3 + - items: # for PXs3 with phy-ext + - const: link + - const: phy + - const: phy-ext + - items: # for others - const: link - const: phy diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml new file mode 100644 index 000000000000..bcec422d7734 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml @@ -0,0 +1,104 @@ +# 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/phy/ti,phy-gmii-sel.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: CPSW Port's Interface Mode Selection PHY Tree Bindings + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +description: | + TI am335x/am437x/dra7(am5)/dm814x CPSW3G Ethernet Subsystem supports + two 10/100/1000 Ethernet ports with selectable G/MII, RMII, and RGMII interfaces. + The interface mode is selected by configuring the MII mode selection register(s) + (GMII_SEL) in the System Control Module chapter (SCM). GMII_SEL register(s) and + bit fields placement in SCM are different between SoCs while fields meaning + is the same. + +--------------+ + +-------------------------------+ |SCM | + | CPSW | | +---------+ | + | +--------------------------------+gmii_sel | | + | | | | +---------+ | + | +----v---+ +--------+ | +--------------+ + | |Port 1..<--+-->GMII/MII<-------> + | | | | | | | + | +--------+ | +--------+ | + | | | + | | +--------+ | + | | | RMII <-------> + | +--> | | + | | +--------+ | + | | | + | | +--------+ | + | | | RGMII <-------> + | +--> | | + | +--------+ | + +-------------------------------+ + + CPSW Port's Interface Mode Selection PHY describes MII interface mode between + CPSW Port and Ethernet PHY which depends on Eth PHY and board configuration. + | + CPSW Port's Interface Mode Selection PHY device should defined as child device + of SCM node (scm_conf) and can be attached to each CPSW port node using standard + PHY bindings. + +properties: + compatible: + enum: + - ti,am3352-phy-gmii-sel + - ti,dra7xx-phy-gmii-sel + - ti,am43xx-phy-gmii-sel + - ti,dm814-phy-gmii-sel + - ti,am654-phy-gmii-sel + + reg: + description: Address and length of the register set for the device + + '#phy-cells': true + +allOf: + - if: + properties: + compatible: + contains: + enum: + - ti,dra7xx-phy-gmii-sel + - ti,dm814-phy-gmii-sel + - ti,am654-phy-gmii-sel + then: + properties: + '#phy-cells': + const: 1 + description: CPSW port number (starting from 1) + - if: + properties: + compatible: + contains: + enum: + - ti,am3352-phy-gmii-sel + - ti,am43xx-phy-gmii-sel + then: + properties: + '#phy-cells': + const: 2 + description: | + - CPSW port number (starting from 1) + - RMII refclk mode + +required: + - compatible + - reg + - '#phy-cells' + +additionalProperties: false + +examples: + - | + phy_gmii_sel: phy-gmii-sel@650 { + compatible = "ti,am3352-phy-gmii-sel"; + reg = <0x650 0x4>; + #phy-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt b/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt deleted file mode 100644 index 83b78c1c0644..000000000000 --- a/Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt +++ /dev/null @@ -1,69 +0,0 @@ -CPSW Port's Interface Mode Selection PHY Tree Bindings ------------------------------------------------ - -TI am335x/am437x/dra7(am5)/dm814x CPSW3G Ethernet Subsystem supports -two 10/100/1000 Ethernet ports with selectable G/MII, RMII, and RGMII interfaces. -The interface mode is selected by configuring the MII mode selection register(s) -(GMII_SEL) in the System Control Module chapter (SCM). GMII_SEL register(s) and -bit fields placement in SCM are different between SoCs while fields meaning -is the same. - +--------------+ - +-------------------------------+ |SCM | - | CPSW | | +---------+ | - | +--------------------------------+gmii_sel | | - | | | | +---------+ | - | +----v---+ +--------+ | +--------------+ - | |Port 1..<--+-->GMII/MII<-------> - | | | | | | | - | +--------+ | +--------+ | - | | | - | | +--------+ | - | | | RMII <-------> - | +--> | | - | | +--------+ | - | | | - | | +--------+ | - | | | RGMII <-------> - | +--> | | - | +--------+ | - +-------------------------------+ - -CPSW Port's Interface Mode Selection PHY describes MII interface mode between -CPSW Port and Ethernet PHY which depends on Eth PHY and board configuration. - -CPSW Port's Interface Mode Selection PHY device should defined as child device -of SCM node (scm_conf) and can be attached to each CPSW port node using standard -PHY bindings (See phy/phy-bindings.txt). - -Required properties: -- compatible : Should be "ti,am3352-phy-gmii-sel" for am335x platform - "ti,dra7xx-phy-gmii-sel" for dra7xx/am57xx platform - "ti,am43xx-phy-gmii-sel" for am43xx platform - "ti,dm814-phy-gmii-sel" for dm814x platform - "ti,am654-phy-gmii-sel" for AM654x/J721E platform -- reg : Address and length of the register set for the device -- #phy-cells : must be 2. - cell 1 - CPSW port number (starting from 1) - cell 2 - RMII refclk mode - -Examples: - phy_gmii_sel: phy-gmii-sel { - compatible = "ti,am3352-phy-gmii-sel"; - reg = <0x650 0x4>; - #phy-cells = <2>; - }; - - mac: ethernet@4a100000 { - compatible = "ti,am335x-cpsw","ti,cpsw"; - ... - - cpsw_emac0: slave@4a100200 { - ... - phys = <&phy_gmii_sel 1 1>; - }; - - cpsw_emac1: slave@4a100300 { - ... - phys = <&phy_gmii_sel 2 1>; - }; - }; diff --git a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml new file mode 100644 index 000000000000..04d5654efb38 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/xlnx,zynqmp-psgtr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP Gigabit Transceiver PHY Device Tree Bindings + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + This binding describes the Xilinx ZynqMP Gigabit Transceiver (GTR) PHY. The + GTR provides four lanes and is used by USB, SATA, PCIE, Display port and + Ethernet SGMII controllers. + +properties: + "#phy-cells": + const: 4 + description: | + The cells contain the following arguments. + + - description: The GTR lane + minimum: 0 + maximum: 3 + - description: The PHY type + enum: + - PHY_TYPE_DP + - PHY_TYPE_PCIE + - PHY_TYPE_SATA + - PHY_TYPE_SGMII + - PHY_TYPE_USB + - description: The PHY instance + minimum: 0 + maximum: 1 # for DP, SATA or USB + maximum: 3 # for PCIE or SGMII + - description: The reference clock number + minimum: 0 + maximum: 3 + + compatible: + enum: + - xlnx,zynqmp-psgtr-v1.1 + - xlnx,zynqmp-psgtr + + clocks: + minItems: 1 + maxItems: 4 + description: | + Clock for each PS_MGTREFCLK[0-3] reference clock input. Unconnected + inputs shall not have an entry. + + clock-names: + minItems: 1 + maxItems: 4 + items: + pattern: "^ref[0-3]$" + + reg: + items: + - description: SERDES registers block + - description: SIOU registers block + + reg-names: + items: + - const: serdes + - const: siou + + xlnx,tx-termination-fix: + description: | + Include this for fixing functional issue with the TX termination + resistance in GT, which can be out of spec for the XCZU9EG silicon + version. + type: boolean + +required: + - "#phy-cells" + - compatible + - reg + - reg-names + +if: + properties: + compatible: + const: xlnx,zynqmp-psgtr-v1.1 + +then: + properties: + xlnx,tx-termination-fix: false + +additionalProperties: false + +examples: + - | + phy: phy@fd400000 { + compatible = "xlnx,zynqmp-psgtr-v1.1"; + reg = <0xfd400000 0x40000>, + <0xfd3d0000 0x1000>; + reg-names = "serdes", "siou"; + clocks = <&refclks 3>, <&refclks 2>, <&refclks 0>; + clock-names = "ref1", "ref2", "ref3"; + #phy-cells = <4>; + }; + +... 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/mti,mips-cpc.txt b/Documentation/devicetree/bindings/power/mti,mips-cpc.txt deleted file mode 100644 index c6b82511ae8a..000000000000 --- a/Documentation/devicetree/bindings/power/mti,mips-cpc.txt +++ /dev/null @@ -1,8 +0,0 @@ -Binding for MIPS Cluster Power Controller (CPC). - -This binding allows a system to specify where the CPC registers are -located. - -Required properties: -compatible : Should be "mti,mips-cpc". -regs: Should describe the address & size of the CPC register region. diff --git a/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml new file mode 100644 index 000000000000..ccdeaece169e --- /dev/null +++ b/Documentation/devicetree/bindings/power/mti,mips-cpc.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/mti,mips-cpc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPS Cluster Power Controller + +description: | + Defines a location of the MIPS Cluster Power Controller registers. + +maintainers: + - Paul Burton <paulburton@kernel.org> + +properties: + compatible: + const: mti,mips-cpc + + reg: + description: | + Base address and size of an unoccupied memory region, which will be + used to map the MIPS CPC registers block. + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + cpc@1bde0000 { + compatible = "mti,mips-cpc"; + reg = <0x1bde0000 0x8000>; + }; +... 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/property-units.txt b/Documentation/devicetree/bindings/property-units.txt index c80a110c1e26..218f99fa311f 100644 --- a/Documentation/devicetree/bindings/property-units.txt +++ b/Documentation/devicetree/bindings/property-units.txt @@ -17,6 +17,7 @@ Time/Frequency -ms : millisecond -us : microsecond -ns : nanosecond +-ps : picosecond Distance ---------------------------------------- diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index fc799b0577d4..188679cb8b8c 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml @@ -18,9 +18,6 @@ description: |+ Be aware that the clocksource driver supports only uniprocessor systems. -allOf: - - $ref: pwm.yaml# - properties: compatible: enum: @@ -63,7 +60,8 @@ properties: interrupts: description: - One interrupt per timer, starting at timer 0. + One interrupt per timer, starting at timer 0. Necessary only for SoCs which + use PWM clocksource. minItems: 1 maxItems: 5 @@ -88,12 +86,27 @@ required: - clocks - clock-names - compatible - - interrupts - "#pwm-cells" - reg additionalProperties: false +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-pwm + - samsung,s3c6400-pwm + - samsung,s5p6440-pwm + - samsung,s5pc100-pwm + then: + required: + - interrupts + examples: - | pwm@7f006000 { 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/reset/socionext,uniphier-reset.yaml b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml new file mode 100644 index 000000000000..4c9b0ebf6869 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml @@ -0,0 +1,112 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/socionext,uniphier-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: UniPhier reset controller + +maintainers: + - Masahiro Yamada <yamada.masahiro@socionext.com> + +properties: + compatible: + oneOf: + - description: System reset + enum: + - socionext,uniphier-ld4-reset + - socionext,uniphier-pro4-reset + - socionext,uniphier-sld8-reset + - socionext,uniphier-pro5-reset + - socionext,uniphier-pxs2-reset + - socionext,uniphier-ld6b-reset + - socionext,uniphier-ld11-reset + - socionext,uniphier-ld20-reset + - socionext,uniphier-pxs3-reset + - description: Media I/O (MIO) reset, SD reset + enum: + - socionext,uniphier-ld4-mio-reset + - socionext,uniphier-pro4-mio-reset + - socionext,uniphier-sld8-mio-reset + - socionext,uniphier-pro5-sd-reset + - socionext,uniphier-pxs2-sd-reset + - socionext,uniphier-ld11-mio-reset + - socionext,uniphier-ld11-sd-reset + - socionext,uniphier-ld20-sd-reset + - socionext,uniphier-pxs3-sd-reset + - description: Peripheral reset + enum: + - socionext,uniphier-ld4-peri-reset + - socionext,uniphier-pro4-peri-reset + - socionext,uniphier-sld8-peri-reset + - socionext,uniphier-pro5-peri-reset + - socionext,uniphier-pxs2-peri-reset + - socionext,uniphier-ld11-peri-reset + - socionext,uniphier-ld20-peri-reset + - socionext,uniphier-pxs3-peri-reset + - description: Analog signal amplifier reset + enum: + - socionext,uniphier-ld11-adamv-reset + - socionext,uniphier-ld20-adamv-reset + + "#reset-cells": + const: 1 + +additionalProperties: false + +required: + - compatible + - "#reset-cells" + +examples: + - | + sysctrl@61840000 { + compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon"; + reg = <0x61840000 0x4000>; + + reset { + compatible = "socionext,uniphier-ld11-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + mioctrl@59810000 { + compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon"; + reg = <0x59810000 0x800>; + + reset { + compatible = "socionext,uniphier-ld11-mio-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + perictrl@59820000 { + compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon"; + reg = <0x59820000 0x200>; + + reset { + compatible = "socionext,uniphier-ld11-peri-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; + + - | + adamv@57920000 { + compatible = "socionext,uniphier-ld11-adamv", "simple-mfd", "syscon"; + reg = <0x57920000 0x1000>; + + reset { + compatible = "socionext,uniphier-ld11-adamv-reset"; + #reset-cells = <1>; + }; + + // other nodes ... + }; diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt index e320a8cc9e4d..88e06e5e8d23 100644 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt @@ -1,123 +1,4 @@ -UniPhier reset controller - - -System reset ------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-reset" - for LD4 SoC - "socionext,uniphier-pro4-reset" - for Pro4 SoC - "socionext,uniphier-sld8-reset" - for sLD8 SoC - "socionext,uniphier-pro5-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-reset" - for LD11 SoC - "socionext,uniphier-ld20-reset" - for LD20 SoC - "socionext,uniphier-pxs3-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - sysctrl@61840000 { - compatible = "socionext,uniphier-ld11-sysctrl", - "simple-mfd", "syscon"; - reg = <0x61840000 0x4000>; - - reset { - compatible = "socionext,uniphier-ld11-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Media I/O (MIO) reset, SD reset -------------------------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-mio-reset" - for LD4 SoC - "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC - "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC - "socionext,uniphier-pro5-sd-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-sd-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO) - "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD) - "socionext,uniphier-ld20-sd-reset" - for LD20 SoC - "socionext,uniphier-pxs3-sd-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - mioctrl@59810000 { - compatible = "socionext,uniphier-ld11-mioctrl", - "simple-mfd", "syscon"; - reg = <0x59810000 0x800>; - - reset { - compatible = "socionext,uniphier-ld11-mio-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Peripheral reset ----------------- - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld4-peri-reset" - for LD4 SoC - "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC - "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC - "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC - "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC - "socionext,uniphier-ld11-peri-reset" - for LD11 SoC - "socionext,uniphier-ld20-peri-reset" - for LD20 SoC - "socionext,uniphier-pxs3-peri-reset" - for PXs3 SoC -- #reset-cells: should be 1. - -Example: - - perictrl@59820000 { - compatible = "socionext,uniphier-ld11-perictrl", - "simple-mfd", "syscon"; - reg = <0x59820000 0x200>; - - reset { - compatible = "socionext,uniphier-ld11-peri-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; - - -Analog signal amplifier reset ------------------------------ - -Required properties: -- compatible: should be one of the following: - "socionext,uniphier-ld11-adamv-reset" - for LD11 SoC - "socionext,uniphier-ld20-adamv-reset" - for LD20 SoC -- #reset-cells: should be 1. - -Example: - - adamv@57920000 { - compatible = "socionext,uniphier-ld11-adamv", - "simple-mfd", "syscon"; - reg = <0x57920000 0x1000>; - - adamv_rst: reset { - compatible = "socionext,uniphier-ld11-adamv-reset"; - #reset-cells = <1>; - }; - - other nodes ... - }; +UniPhier glue reset controller Peripheral core reset in glue layer diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt deleted file mode 100644 index c797bc9d77d2..000000000000 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt +++ /dev/null @@ -1,20 +0,0 @@ -* i.MX25 Real Time Clock controller - -Required properties: -- compatible: should be: "fsl,imx25-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- clocks: should contain the phandle for the rtc clock -- interrupts: rtc alarm interrupt - -Optional properties: -- interrupts: dryice security violation interrupt (second entry) - -Example: - -rtc@53ffc000 { - compatible = "fsl,imx25-rtc"; - reg = <0x53ffc000 0x4000>; - clocks = <&clks 81>; - interrupts = <25 56>; -}; diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml new file mode 100644 index 000000000000..06bd737821c1 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/imxdi-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX25 Real Time Clock controller + +maintainers: + - Roland Stigge <stigge@antcom.de> + +properties: + compatible: + const: fsl,imx25-rtc + + reg: + maxItems: 1 + + interrupts: + items: + - description: rtc alarm interrupt + - description: dryice security violation interrupt + minItems: 1 + maxItems: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + rtc@53ffc000 { + compatible = "fsl,imx25-rtc"; + reg = <0x53ffc000 0x4000>; + clocks = <&clks 81>; + interrupts = <25>, <56>; + }; diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt b/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt deleted file mode 100644 index 968ac820254b..000000000000 --- a/Documentation/devicetree/bindings/rtc/sa1100-rtc.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Marvell Real Time Clock controller - -Required properties: -- compatible: should be "mrvl,sa1100-rtc" -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: Should be two. The first interrupt number is the rtc alarm - interrupt and the second interrupt number is the rtc hz interrupt. -- interrupt-names: Assign name of irq resource. - -Example: - rtc: rtc@d4010000 { - compatible = "mrvl,mmp-rtc"; - reg = <0xd4010000 0x1000>; - interrupts = <5>, <6>; - interrupt-names = "rtc 1Hz", "rtc alarm"; - }; diff --git a/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml new file mode 100644 index 000000000000..482e5af215b3 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sa1100-rtc.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/sa1100-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell Real Time Clock controller bindings + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Alessandro Zummo <a.zummo@towertech.it> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + - Rob Herring <robh+dt@kernel.org> + +properties: + compatible: + enum: + - mrvl,sa1100-rtc + - mrvl,mmp-rtc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + minItems: 2 + + interrupt-names: + items: + - const: 'rtc 1Hz' + - const: 'rtc alarm' + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + rtc: rtc@d4010000 { + compatible = "mrvl,mmp-rtc"; + reg = <0xd4010000 0x1000>; + interrupts = <5>, <6>; + interrupt-names = "rtc 1Hz", "rtc alarm"; + }; + +... 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/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt index f11f295c8450..3d55dd64b1be 100644 --- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt +++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt @@ -5,7 +5,8 @@ SPI0, and the other known as the "Universal SPI Master"; part of the auxiliary block. This binding applies to the SPI0 controller. Required properties: -- compatible: Should be "brcm,bcm2835-spi". +- compatible: Should be one of "brcm,bcm2835-spi" for BCM2835/2836/2837 or + "brcm,bcm2711-spi" for BCM2711 or "brcm,bcm7211-spi" for BCM7211. - reg: Should contain register location and length. - interrupts: Should contain interrupt. - clocks: The clock feeding the SPI controller. 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 53a60c1721e6..95462e071ab4 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: QCOM SoC Temperature Sensor (TSENS) maintainers: - - Amit Kucheria <amit.kucheria@linaro.org> + - Amit Kucheria <amitk@kernel.org> description: | QCOM SoCs have TSENS IP to allow temperature measurement. There are currently @@ -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/qoriq-thermal.txt b/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt deleted file mode 100644 index 28f2cbaf1702..000000000000 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.txt +++ /dev/null @@ -1,71 +0,0 @@ -* Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs - -Required properties: -- compatible : Must include "fsl,qoriq-tmu" or "fsl,imx8mq-tmu". The - version of the device is determined by the TMU IP Block Revision - Register (IPBRR0) at offset 0x0BF8. - Table of correspondences between IPBRR0 values and example chips: - Value Device - ---------- ----- - 0x01900102 T1040 -- reg : Address range of TMU registers. -- interrupts : Contains the interrupt for TMU. -- fsl,tmu-range : The values to be programmed into TTRnCR, as specified by - the SoC reference manual. The first cell is TTR0CR, the second is - TTR1CR, etc. -- fsl,tmu-calibration : A list of cell pairs containing temperature - calibration data, as specified by the SoC reference manual. - The first cell of each pair is the value to be written to TTCFGR, - and the second is the value to be written to TSCFGR. -- #thermal-sensor-cells : Must be 1. The sensor specifier is the monitoring - site ID, and represents the "n" in TRITSRn and TRATSRn. - -Optional property: -- little-endian : If present, the TMU registers are little endian. If absent, - the default is big endian. -- clocks : the clock for clocking the TMU silicon. - -Example: - -tmu@f0000 { - compatible = "fsl,qoriq-tmu"; - reg = <0xf0000 0x1000>; - interrupts = <18 2 0 0>; - fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>; - fsl,tmu-calibration = <0x00000000 0x00000025 - 0x00000001 0x00000028 - 0x00000002 0x0000002d - 0x00000003 0x00000031 - 0x00000004 0x00000036 - 0x00000005 0x0000003a - 0x00000006 0x00000040 - 0x00000007 0x00000044 - 0x00000008 0x0000004a - 0x00000009 0x0000004f - 0x0000000a 0x00000054 - - 0x00010000 0x0000000d - 0x00010001 0x00000013 - 0x00010002 0x00000019 - 0x00010003 0x0000001f - 0x00010004 0x00000025 - 0x00010005 0x0000002d - 0x00010006 0x00000033 - 0x00010007 0x00000043 - 0x00010008 0x0000004b - 0x00010009 0x00000053 - - 0x00020000 0x00000010 - 0x00020001 0x00000017 - 0x00020002 0x0000001f - 0x00020003 0x00000029 - 0x00020004 0x00000031 - 0x00020005 0x0000003c - 0x00020006 0x00000042 - 0x00020007 0x0000004d - 0x00020008 0x00000056 - - 0x00030000 0x00000012 - 0x00030001 0x0000001d>; - #thermal-sensor-cells = <1>; -}; diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml new file mode 100644 index 000000000000..f09e8723ca2b --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs + +maintainers: + - Anson Huang <Anson.Huang@nxp.com> + +properties: + compatible: + description: | + The version of the device is determined by the TMU IP Block Revision + Register (IPBRR0) at offset 0x0BF8. + Table of correspondences between IPBRR0 values and example chips: + Value Device + ---------- ----- + 0x01900102 T1040 + enum: + - fsl,qoriq-tmu + - fsl,imx8mq-tmu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + fsl,tmu-range: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + description: | + The values to be programmed into TTRnCR, as specified by the SoC + reference manual. The first cell is TTR0CR, the second is TTR1CR, etc. + maxItems: 4 + + fsl,tmu-calibration: + $ref: '/schemas/types.yaml#/definitions/uint32-matrix' + description: | + A list of cell pairs containing temperature calibration data, as + specified by the SoC reference manual. The first cell of each pair + is the value to be written to TTCFGR, and the second is the value + to be written to TSCFGR. + items: + items: + - description: value for TTCFGR + - description: value for TSCFGR + minItems: 1 + maxItems: 64 + + little-endian: + description: | + boolean, if present, the TMU registers are little endian. If absent, + the default is big endian. + type: boolean + + clocks: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - fsl,tmu-range + - fsl,tmu-calibration + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + tmu@f0000 { + compatible = "fsl,qoriq-tmu"; + reg = <0xf0000 0x1000>; + interrupts = <18 2 0 0>; + fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>; + fsl,tmu-calibration = <0x00000000 0x00000025>, + <0x00000001 0x00000028>, + <0x00000002 0x0000002d>, + <0x00000003 0x00000031>, + <0x00000004 0x00000036>, + <0x00000005 0x0000003a>, + <0x00000006 0x00000040>, + <0x00000007 0x00000044>, + <0x00000008 0x0000004a>, + <0x00000009 0x0000004f>, + <0x0000000a 0x00000054>, + <0x00010000 0x0000000d>, + <0x00010001 0x00000013>, + <0x00010002 0x00000019>, + <0x00010003 0x0000001f>, + <0x00010004 0x00000025>, + <0x00010005 0x0000002d>, + <0x00010006 0x00000033>, + <0x00010007 0x00000043>, + <0x00010008 0x0000004b>, + <0x00010009 0x00000053>, + <0x00020000 0x00000010>, + <0x00020001 0x00000017>, + <0x00020002 0x0000001f>, + <0x00020003 0x00000029>, + <0x00020004 0x00000031>, + <0x00020005 0x0000003c>, + <0x00020006 0x00000042>, + <0x00020007 0x0000004d>, + <0x00020008 0x00000056>, + <0x00030000 0x00000012>, + <0x00030001 0x0000001d>; + #thermal-sensor-cells = <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/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index 03893e6a2f57..371fb02a4351 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -116,7 +116,9 @@ patternProperties: - ingenic,jz4740-watchdog - ingenic,jz4780-watchdog - items: - - const: ingenic,jz4770-watchdog + - enum: + - ingenic,jz4770-watchdog + - ingenic,jz4725b-watchdog - const: ingenic,jz4740-watchdog reg: @@ -142,6 +144,7 @@ patternProperties: oneOf: - enum: - ingenic,jz4740-pwm + - ingenic,jz4725b-pwm - items: - enum: - ingenic,jz4770-pwm diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt deleted file mode 100644 index b8f02c663521..000000000000 --- a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.txt +++ /dev/null @@ -1,17 +0,0 @@ -* Marvell MMP Timer controller - -Required properties: -- compatible : Should be "mrvl,mmp-timer". -- reg : Address and length of the register set of timer controller. -- interrupts : Should be the interrupt number. - -Optional properties: -- clocks : Should contain a single entry describing the clock input. - -Example: - timer0: timer@d4014000 { - compatible = "mrvl,mmp-timer"; - reg = <0xd4014000 0x100>; - interrupts = <13>; - clocks = <&coreclk 2>; - }; diff --git a/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml new file mode 100644 index 000000000000..1fbc260a0cbd --- /dev/null +++ b/Documentation/devicetree/bindings/timer/mrvl,mmp-timer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/mrvl,mmp-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell MMP Timer bindings + +maintainers: + - Daniel Lezcano <daniel.lezcano@linaro.org> + - Thomas Gleixner <tglx@linutronix.de> + - Rob Herring <robh+dt@kernel.org> + +properties: + $nodename: + pattern: '^timer@[a-f0-9]+$' + + compatible: + const: mrvl,mmp-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + timer@d4014000 { + compatible = "mrvl,mmp-timer"; + reg = <0xd4014000 0x100>; + interrupts = <13>; + clocks = <&coreclk 2>; + }; + +... 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/usb/brcm,bdc.txt b/Documentation/devicetree/bindings/usb/brcm,bdc.txt index 63e63af3bf59..c9f52b97cef1 100644 --- a/Documentation/devicetree/bindings/usb/brcm,bdc.txt +++ b/Documentation/devicetree/bindings/usb/brcm,bdc.txt @@ -4,7 +4,7 @@ Broadcom USB Device Controller (BDC) Required properties: - compatible: must be one of: - "brcm,bdc-v0.16" + "brcm,bdc-udc-v2" "brcm,bdc" - reg: the base register address and length - interrupts: the interrupt line for this controller @@ -21,7 +21,7 @@ On Broadcom STB platforms, these properties are required: Example: bdc@f0b02000 { - compatible = "brcm,bdc-v0.16"; + compatible = "brcm,bdc-udc-v2"; reg = <0xf0b02000 0xfc4>; interrupts = <0x0 0x60 0x0>; phys = <&usbphy_0 0x0>; diff --git a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml index a81b0b1a2226..2d61166ea5cf 100644 --- a/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml +++ b/Documentation/devicetree/bindings/usb/ingenic,jz4770-phy.yaml @@ -4,10 +4,11 @@ $id: http://devicetree.org/schemas/usb/ingenic,jz4770-phy.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ingenic JZ4770 USB PHY devicetree bindings +title: Ingenic SoCs USB PHY devicetree bindings maintainers: - Paul Cercueil <paul@crapouillou.net> + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> properties: $nodename: @@ -16,6 +17,9 @@ properties: compatible: enum: - ingenic,jz4770-phy + - ingenic,jz4780-phy + - ingenic,x1000-phy + - ingenic,x1830-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml new file mode 100644 index 000000000000..add9f7b66da0 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/renesas,usb-xhci.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/renesas,usb-xhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas USB xHCI controllers + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> + +allOf: + - $ref: "usb-hcd.yaml" + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,xhci-r8a7742 # RZ/G1H + - renesas,xhci-r8a7743 # RZ/G1M + - renesas,xhci-r8a7744 # RZ/G1N + - renesas,xhci-r8a7790 # R-Car H2 + - renesas,xhci-r8a7791 # R-Car M2-W + - renesas,xhci-r8a7793 # R-Car M2-N + - const: renesas,rcar-gen2-xhci # R-Car Gen2 and RZ/G1 + - items: + - enum: + - renesas,xhci-r8a774a1 # RZ/G2M + - renesas,xhci-r8a774b1 # RZ/G2N + - renesas,xhci-r8a774c0 # RZ/G2E + - renesas,xhci-r8a7795 # R-Car H3 + - renesas,xhci-r8a7796 # R-Car M3-W + - renesas,xhci-r8a77961 # R-Car M3-W+ + - renesas,xhci-r8a77965 # R-Car M3-N + - renesas,xhci-r8a77990 # R-Car E3 + - const: renesas,rcar-gen3-xhci # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + maxItems: 1 + items: + - const: usb + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + xhci0: usb@ee000000 { + compatible = "renesas,xhci-r8a7795", "renesas,rcar-gen3-xhci"; + reg = <0xee000000 0xc00>; + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 328>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 328>; + }; diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index f127535feb0b..804b9b4f6654 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -11,22 +11,36 @@ maintainers: properties: compatible: - oneOf: - - const: "ti,keystone-dwc3" - - const: "ti,am654-dwc3" + items: + - enum: + - ti,keystone-dwc3 + - ti,am654-dwc3 reg: maxItems: 1 - description: Address and length of the register set for the USB subsystem on - the SOC. + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true interrupts: maxItems: 1 - description: The irq number of this device that is used to interrupt the MPU. - clocks: - description: Clock ID for USB functional clock. + minItems: 1 + maxItems: 2 + + assigned-clocks: + minItems: 1 + maxItems: 2 + + assigned-clock-parents: + minItems: 1 + maxItems: 2 power-domains: description: Should contain a phandle to a PM domain provider node @@ -42,33 +56,42 @@ properties: phy-names: items: - - const: "usb3-phy" + - const: usb3-phy + + dma-coherent: true - dwc3: + dma-ranges: true + +patternProperties: + "usb@[a-f0-9]+$": + type: object description: This is the node representing the DWC3 controller instance Documentation/devicetree/bindings/usb/dwc3.txt required: - compatible - reg + - "#address-cells" + - "#size-cells" + - ranges - interrupts - - clocks + +additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> - usb: usb@2680000 { + dwc3@2680000 { compatible = "ti,keystone-dwc3"; #address-cells = <1>; #size-cells = <1>; reg = <0x2680000 0x10000>; clocks = <&clkusb>; - clock-names = "usb"; interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; ranges; - dwc3@2690000 { + usb@2690000 { compatible = "synopsys,dwc3"; reg = <0x2690000 0x70000>; interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index b120dd6612a2..0c5cff84a969 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -7,24 +7,6 @@ Required properties: - "marvell,armada3700-xhci" for Armada 37xx SoCs - "marvell,armada-375-xhci" for Armada 375 SoCs - "marvell,armada-380-xhci" for Armada 38x SoCs - - "renesas,xhci-r8a7742" for r8a7742 SoC - - "renesas,xhci-r8a7743" for r8a7743 SoC - - "renesas,xhci-r8a7744" for r8a7744 SoC - - "renesas,xhci-r8a774a1" for r8a774a1 SoC - - "renesas,xhci-r8a774b1" for r8a774b1 SoC - - "renesas,xhci-r8a774c0" for r8a774c0 SoC - - "renesas,xhci-r8a7790" for r8a7790 SoC - - "renesas,xhci-r8a7791" for r8a7791 SoC - - "renesas,xhci-r8a7793" for r8a7793 SoC - - "renesas,xhci-r8a7795" for r8a7795 SoC - - "renesas,xhci-r8a7796" for r8a77960 SoC - - "renesas,xhci-r8a77961" for r8a77961 SoC - - "renesas,xhci-r8a77965" for r8a77965 SoC - - "renesas,xhci-r8a77990" for r8a77990 SoC - - "renesas,rcar-gen2-xhci" for a generic R-Car Gen2 or RZ/G1 compatible - device - - "renesas,rcar-gen3-xhci" for a generic R-Car Gen3 or RZ/G2 compatible - device - "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI - "xhci-platform" (deprecated) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 60add08259e9..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,.*": @@ -1167,6 +1169,8 @@ patternProperties: description: Xiaomi Technology Co., Ltd. "^xillybus,.*": description: Xillybus Ltd. + "^xingbangda,.*": + description: Shenzhen Xingbangda Display Technology Co., Ltd "^xinpeng,.*": description: Shenzhen Xinpeng Technology Co., Ltd "^xlnx,.*": @@ -1177,6 +1181,8 @@ patternProperties: description: Shenzhen Xunlong Software CO.,Limited "^xylon,.*": description: Xylon + "^ylm,.*": + description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": description: YSH & ATIL "^yones-toptech,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt index 21af30fbb81f..0a575f329f6e 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.txt +++ b/Documentation/devicetree/bindings/virtio/mmio.txt @@ -1,6 +1,6 @@ * virtio memory mapped device -See http://ozlabs.org/~rusty/virtio-spec/ for more details. +See https://ozlabs.org/~rusty/virtio-spec/ for more details. Required properties: 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/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 63dec76d1d8d..100bfd227265 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: cpu access -Fence Poll Support -~~~~~~~~~~~~~~~~~~ +Implicit Fence Poll Support +~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. kernel-doc:: drivers/dma-buf/dma-buf.c - :doc: fence polling + :doc: implicit fence polling Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -133,6 +133,18 @@ DMA Fences .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: DMA fences overview +DMA Fence Cross-Driver Contract +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence cross-driver contract + +DMA Fence Signalling Annotations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: fence signalling annotation + DMA Fences Functions Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -166,3 +178,73 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +Indefinite DMA Fences +~~~~~~~~~~~~~~~~~~~~ + +At various times &dma_fence with an indefinite time until dma_fence_wait() +finishes have been proposed. Examples include: + +* Future fences, used in HWC1 to signal when a buffer isn't used by the display + any longer, and created with the screen update that makes the buffer visible. + The time this fence completes is entirely under userspace's control. + +* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet + been set. Used to asynchronously delay command submission. + +* Userspace fences or gpu futexes, fine-grained locking within a command buffer + that userspace uses for synchronization across engines or with the CPU, which + are then imported as a DMA fence for integration into existing winsys + protocols. + +* Long-running compute command buffers, while still using traditional end of + batch DMA fences for memory management instead of context preemption DMA + fences which get reattached when the compute job is rescheduled. + +Common to all these schemes is that userspace controls the dependencies of these +fences and controls when they fire. Mixing indefinite fences with normal +in-kernel DMA fences does not work, even when a fallback timeout is included to +protect against malicious userspace: + +* Only the kernel knows about all DMA fence dependencies, userspace is not aware + of dependencies injected due to memory management or scheduler decisions. + +* Only userspace knows about all dependencies in indefinite fences and when + exactly they will complete, the kernel has no visibility. + +Furthermore the kernel has to be able to hold up userspace command submission +for memory management needs, which means we must support indefinite fences being +dependent upon DMA fences. If the kernel also support indefinite fences in the +kernel like a DMA fence, like any of the above proposal would, there is the +potential for deadlocks. + +.. kernel-render:: DOT + :alt: Indefinite Fencing Dependency Cycle + :caption: Indefinite Fencing Dependency Cycle + + digraph "Fencing Cycle" { + node [shape=box bgcolor=grey style=filled] + kernel [label="Kernel DMA Fences"] + userspace [label="userspace controlled fences"] + kernel -> userspace [label="memory management"] + userspace -> kernel [label="Future fence, fence proxy, ..."] + + { rank=same; kernel userspace } + } + +This means that the kernel might accidentally create deadlocks +through memory management dependencies which userspace is unaware of, which +randomly hangs workloads until the timeout kicks in. Workloads, which from +userspace's perspective, do not contain a deadlock. In such a mixed fencing +architecture there is no single entity with knowledge of all dependencies. +Thefore preventing such deadlocks from within the kernel is not possible. + +The only solution to avoid dependencies loops is by not allowing indefinite +fences in the kernel. This means: + +* No future fences, proxy fences or userspace fences imported as DMA fences, + with or without a timeout. + +* No DMA fences that signal end of batchbuffer for command submission where + userspace is allowed to use userspace fencing or long running compute + workloads. This also means no implicit fencing for shared buffers in these + cases. diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index b0f32cfc38c2..09a3f66dcd26 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -86,7 +86,9 @@ The details of these operations are: - interleaved_dma: This is common to Slave as well as M2M clients. For slave address of devices' fifo could be already known to the driver. Various types of operations could be expressed by setting - appropriate values to the 'dma_interleaved_template' members. + appropriate values to the 'dma_interleaved_template' members. Cyclic + interleaved DMA transfers are also possible if supported by the channel by + setting the DMA_PREP_REPEAT transfer flag. A non-NULL return of this transfer API represents a "descriptor" for the given transaction. diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index 954422c2b704..ddb0a81a796c 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -239,6 +239,43 @@ 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 + the DMA_PREP_REPEAT transfer flag, is similar to a cyclic transfer in that + it gets automatically repeated when it ends, but can additionally be + replaced by the client. + + - This feature is limited to interleaved transfers, this flag should thus not + be set if the DMA_INTERLEAVE flag isn't set. This limitation is based on + the current needs of DMA clients, support for additional transfer types + should be added in the future if and when the need arises. + +- DMA_LOAD_EOT + + - The device supports replacing repeated transfers at end of transfer (EOT) + by queuing a new transfer with the DMA_PREP_LOAD_EOT flag set. + + - Support for replacing a currently running transfer at another point (such + as end of burst instead of end of transfer) will be added in the future + based on DMA clients needs, if and when the need arises. + These various types will also affect how the source and destination addresses change over time. @@ -399,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 @@ -488,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() @@ -531,6 +571,34 @@ DMA_CTRL_REUSE writes for which the descriptor should be in different format from normal data descriptors. +- DMA_PREP_REPEAT + + - If set, the transfer will be automatically repeated when it ends until a + new transfer is queued on the same channel with the DMA_PREP_LOAD_EOT flag. + If the next transfer to be queued on the channel does not have the + DMA_PREP_LOAD_EOT flag set, the current transfer will be repeated until the + client terminates all transfers. + + - This flag is only supported if the channel reports the DMA_REPEAT + capability. + +- DMA_PREP_LOAD_EOT + + - If set, the transfer will replace the transfer currently being executed at + the end of the transfer. + + - This is the default behaviour for non-repeated transfers, specifying + DMA_PREP_LOAD_EOT for non-repeated transfers will thus make no difference. + + - When using repeated transfers, DMA clients will usually need to set the + DMA_PREP_LOAD_EOT flag on all transfers, otherwise the channel will keep + repeating the last repeated transfer and ignore the new transfers being + queued. Failure to set DMA_PREP_LOAD_EOT will appear as if the channel was + stuck on the previous transfer. + + - This flag is only supported if the channel reports the DMA_LOAD_EOT + capability. + General Design Notes ==================== diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index e0b58c392e4f..eaaaafc21134 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -342,7 +342,8 @@ LED MDIO devm_mdiobus_alloc() devm_mdiobus_alloc_size() - devm_mdiobus_free() + devm_mdiobus_register() + devm_of_mdiobus_register() MEM devm_free_pages() diff --git a/Documentation/driver-api/driver-model/platform.rst b/Documentation/driver-api/driver-model/platform.rst index 334dd4071ae4..1fe5c6c6199c 100644 --- a/Documentation/driver-api/driver-model/platform.rst +++ b/Documentation/driver-api/driver-model/platform.rst @@ -108,7 +108,7 @@ field to hold additional information. Embedded systems frequently need one or more clocks for platform devices, which are normally kept off until they're actively needed (to save power). -System setup also associates those clocks with the device, so that that +System setup also associates those clocks with the device, so that calls to clk_get(&pdev->dev, clock_name) return them as needed. diff --git a/Documentation/driver-api/firmware/built-in-fw.rst b/Documentation/driver-api/firmware/built-in-fw.rst index 396cdf591ac5..bc1c961bace1 100644 --- a/Documentation/driver-api/firmware/built-in-fw.rst +++ b/Documentation/driver-api/firmware/built-in-fw.rst @@ -28,6 +28,6 @@ able to make use of built-in firmware: * Some firmware files may be really large in size. The remote-proc subsystem is an example subsystem which deals with these sorts of firmware * The firmware may need to be scraped out from some device specific location - dynamically, an example is calibration data for for some WiFi chipsets. This + dynamically, an example is calibration data for some WiFi chipsets. This calibration data can be unique per sold device. diff --git a/Documentation/driver-api/firmware/direct-fs-lookup.rst b/Documentation/driver-api/firmware/direct-fs-lookup.rst index 82b4d585a213..e04353d1b06b 100644 --- a/Documentation/driver-api/firmware/direct-fs-lookup.rst +++ b/Documentation/driver-api/firmware/direct-fs-lookup.rst @@ -24,7 +24,7 @@ available. Stuffing the firmware into initramfs resolves this race issue, however note that using initrd does not suffice to address the same race. There are circumstances that justify not wanting to include firmware into -initramfs, such as dealing with large firmware firmware files for the +initramfs, such as dealing with large firmware files for the remote-proc subsystem. For such cases using a userspace fallback mechanism is currently the only viable solution as only userspace can know for sure when the real rootfs is ready and mounted. diff --git a/Documentation/driver-api/firmware/firmware_cache.rst b/Documentation/driver-api/firmware/firmware_cache.rst index c2e69d9c6bf1..417b9e8347f0 100644 --- a/Documentation/driver-api/firmware/firmware_cache.rst +++ b/Documentation/driver-api/firmware/firmware_cache.rst @@ -27,7 +27,7 @@ Some implementation details about the firmware cache setup: uses all synchronous call except :c:func:`request_firmware_into_buf`. * If an asynchronous call is used the firmware cache is only set up for a - device if if the second argument (uevent) to request_firmware_nowait() is + device if the second argument (uevent) to request_firmware_nowait() is true. When uevent is true it requests that a kobject uevent be sent to userspace for the firmware request through the sysfs fallback mechanism if the firmware file is not found. diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst index cd076462d235..0d6ea0329995 100644 --- a/Documentation/driver-api/firmware/request_firmware.rst +++ b/Documentation/driver-api/firmware/request_firmware.rst @@ -76,5 +76,5 @@ firmware. For example if you used request_firmware() and it returns, the driver has the firmware image accessible in fw_entry->{data,size}. If something went wrong request_firmware() returns non-zero and fw_entry is set to NULL. Once your driver is done with processing the firmware it -can call call release_firmware(fw_entry) to release the firmware image +can call release_firmware(fw_entry) to release the firmware image and any related resource. 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/gpio/drivers-on-gpio.rst b/Documentation/driver-api/gpio/drivers-on-gpio.rst index 820b403d50f6..41ec3cc72d32 100644 --- a/Documentation/driver-api/gpio/drivers-on-gpio.rst +++ b/Documentation/driver-api/gpio/drivers-on-gpio.rst @@ -89,6 +89,13 @@ hardware descriptions such as device tree or ACPI: Consumer Electronics Control bus using only GPIO. It is used to communicate with devices on the HDMI bus. +- gpio-charger: drivers/power/supply/gpio-charger.c is used if you need to do + battery charging and all you have to go by to check the presence of the + AC charger or more complex tasks such as indicating charging status using + nothing but GPIO lines, this driver provides that and also a clearly defined + way to pass the charging parameters from hardware descriptions such as the + device tree. + Apart from this there are special GPIO drivers in subsystems like MMC/SD to read card detect and write protect GPIO lines, and in the TTY serial subsystem to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The 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/index.rst b/Documentation/driver-api/index.rst index 3eb0085d5e42..902b93b17235 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -96,6 +96,7 @@ available subsections can be seen below. phy/index pti_intel_mid pwm + pldmfw/index rfkill serial/index sm501 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/pldmfw/driver-ops.rst b/Documentation/driver-api/pldmfw/driver-ops.rst new file mode 100644 index 000000000000..f0654783d3b3 --- /dev/null +++ b/Documentation/driver-api/pldmfw/driver-ops.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +========================= +Driver-specific callbacks +========================= + +The ``pldmfw`` module relies on the device driver for implementing device +specific behavior using the following operations. + +``.match_record`` +----------------- + +The ``.match_record`` operation is used to determine whether a given PLDM +record matches the device being updated. This requires comparing the record +descriptors in the record with information from the device. Many record +descriptors are defined by the PLDM standard, but it is also allowed for +devices to implement their own descriptors. + +The ``.match_record`` operation should return true if a given record matches +the device. + +``.send_package_data`` +---------------------- + +The ``.send_package_data`` operation is used to send the device-specific +package data in a record to the device firmware. If the matching record +provides package data, ``pldmfw`` will call the ``.send_package_data`` +function with a pointer to the package data and with the package data +length. The device driver should send this data to firmware. + +``.send_component_table`` +------------------------- + +The ``.send_component_table`` operation is used to forward component +information to the device. It is called once for each applicable component, +that is, for each component indicated by the matching record. The +device driver should send the component information to the device firmware, +and wait for a response. The provided transfer flag indicates whether this +is the first, last, or a middle component, and is expected to be forwarded +to firmware as part of the component table information. The driver should an +error in the case when the firmware indicates that the component cannot be +updated, or return zero if the component can be updated. + +``.flash_component`` +-------------------- + +The ``.flash_component`` operation is used to inform the device driver to +flash a given component. The driver must perform any steps necessary to send +the component data to the device. + +``.finalize_update`` +-------------------- + +The ``.finalize_update`` operation is used by the ``pldmfw`` library in +order to allow the device driver to perform any remaining device specific +logic needed to finish the update. diff --git a/Documentation/driver-api/pldmfw/file-format.rst b/Documentation/driver-api/pldmfw/file-format.rst new file mode 100644 index 000000000000..b7a9cebe09c6 --- /dev/null +++ b/Documentation/driver-api/pldmfw/file-format.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +================================== +PLDM Firmware file format overview +================================== + +A PLDM firmware package is a binary file which contains a header that +describes the contents of the firmware package. This includes an initial +package header, one or more firmware records, and one or more components +describing the actual flash contents to program. + +This diagram provides an overview of the file format:: + + overall file layout + +----------------------+ + | | + | Package Header | + | | + +----------------------+ + | | + | Device Records | + | | + +----------------------+ + | | + | Component Info | + | | + +----------------------+ + | | + | Package Header CRC | + | | + +----------------------+ + | | + | Component Image 1 | + | | + +----------------------+ + | | + | Component Image 2 | + | | + +----------------------+ + | | + | ... | + | | + +----------------------+ + | | + | Component Image N | + | | + +----------------------+ + +Package Header +============== + +The package header begins with the UUID of the PLDM file format, and +contains information about the version of the format that the file uses. It +also includes the total header size, a release date, the size of the +component bitmap, and an overall package version. + +The following diagram provides an overview of the package header:: + + header layout + +-------------------------+ + | PLDM UUID | + +-------------------------+ + | Format Revision | + +-------------------------+ + | Header Size | + +-------------------------+ + | Release Date | + +-------------------------+ + | Component Bitmap Length | + +-------------------------+ + | Package Version Info | + +-------------------------+ + +Device Records +============== + +The device firmware records area starts with a count indicating the total +number of records in the file, followed by each record. A single device +record describes what device matches this record. All valid PLDM firmware +files must contain at least one record, but optionally may contain more than +one record if they support multiple devices. + +Each record will identify the device it supports via TLVs that describe the +device, such as the PCI device and vendor information. It will also indicate +which set of components that are used by this device. It is possible that +only subset of provided components will be used by a given record. A record +may also optionally contain device-specific package data that will be used +by the device firmware during the update process. + +The following diagram provides an overview of the device record area:: + + area layout + +---------------+ + | | + | Record Count | + | | + +---------------+ + | | + | Record 1 | + | | + +---------------+ + | | + | Record 2 | + | | + +---------------+ + | | + | ... | + | | + +---------------+ + | | + | Record N | + | | + +---------------+ + + record layout + +-----------------------+ + | Record Length | + +-----------------------+ + | Descriptor Count | + +-----------------------+ + | Option Flags | + +-----------------------+ + | Version Settings | + +-----------------------+ + | Package Data Length | + +-----------------------+ + | Applicable Components | + +-----------------------+ + | Version String | + +-----------------------+ + | Descriptor TLVs | + +-----------------------+ + | Package Data | + +-----------------------+ + +Component Info +============== + +The component information area begins with a count of the number of +components. Following this count is a description for each component. The +component information points to the location in the file where the component +data is stored, and includes version data used to identify the version of +the component. + +The following diagram provides an overview of the component area:: + + area layout + +-----------------+ + | | + | Component Count | + | | + +-----------------+ + | | + | Component 1 | + | | + +-----------------+ + | | + | Component 2 | + | | + +-----------------+ + | | + | ... | + | | + +-----------------+ + | | + | Component N | + | | + +-----------------+ + + component layout + +------------------------+ + | Classification | + +------------------------+ + | Component Identifier | + +------------------------+ + | Comparison Stamp | + +------------------------+ + | Component Options | + +------------------------+ + | Activation Method | + +------------------------+ + | Location Offset | + +------------------------+ + | Component Size | + +------------------------+ + | Component Version Info | + +------------------------+ + | Package Data | + +------------------------+ + + +Package Header CRC +================== + +Following the component information is a short 4-byte CRC calculated over +the contents of all of the header information. + +Component Images +================ + +The component images follow the package header information in the PLDM +firmware file. Each of these is simply a binary chunk with its start and +size defined by the matching component structure in the component info area. diff --git a/Documentation/driver-api/pldmfw/index.rst b/Documentation/driver-api/pldmfw/index.rst new file mode 100644 index 000000000000..ad2c33ece30f --- /dev/null +++ b/Documentation/driver-api/pldmfw/index.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +================================== +PLDM Firmware Flash Update Library +================================== + +``pldmfw`` implements functionality for updating the flash on a device using +the PLDM for Firmware Update standard +<https://www.dmtf.org/documents/pmci/pldm-firmware-update-specification-100>. + +.. toctree:: + :maxdepth: 1 + + file-format + driver-ops + +================================== +Overview of the ``pldmfw`` library +================================== + +The ``pldmfw`` library is intended to be used by device drivers for +implementing device flash update based on firmware files following the PLDM +firwmare file format. + +It is implemented using an ops table that allows device drivers to provide +the underlying device specific functionality. + +``pldmfw`` implements logic to parse the packed binary format of the PLDM +firmware file into data structures, and then uses the provided function +operations to determine if the firmware file is a match for the device. If +so, it sends the record and component data to the firmware using the device +specific implementations provided by device drivers. Once the device +firmware indicates that the update may be performed, the firmware data is +sent to the device for programming. + +Parsing the PLDM file +===================== + +The PLDM file format uses packed binary data, with most multi-byte fields +stored in the Little Endian format. Several pieces of data are variable +length, including version strings and the number of records and components. +Due to this, it is not straight forward to index the record, record +descriptors, or components. + +To avoid proliferating access to the packed binary data, the ``pldmfw`` +library parses and extracts this data into simpler structures for ease of +access. + +In order to safely process the firmware file, care is taken to avoid +unaligned access of multi-byte fields, and to properly convert from Little +Endian to CPU host format. Additionally the records, descriptors, and +components are stored in linked lists. + +Performing a flash update +========================= + +To perform a flash update, the ``pldmfw`` module performs the following +steps + +1. Parse the firmware file for record and component information +2. Scan through the records and determine if the device matches any record + in the file. The first matched record will be used. +3. If the matching record provides package data, send this package data to + the device. +4. For each component that the record indicates, send the component data to + the device. For each component, the firmware may respond with an + indication of whether the update is suitable or not. If any component is + not suitable, the update is canceled. +5. For each component, send the binary data to the device firmware for + updating. +6. After all components are programmed, perform any final device-specific + actions to finalize the update. 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/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 1b386076402c..8858cea7bfe0 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -293,6 +293,10 @@ per stream. From ASoC DPCM framework, this stream state maybe linked to int sdw_alloc_stream(char * stream_name); +The SoundWire core provides a sdw_startup_stream() helper function, +typically called during a dailink .startup() callback, which performs +stream allocation and sets the stream pointer for all DAIs +connected to a stream. SDW_STREAM_CONFIGURED ~~~~~~~~~~~~~~~~~~~~~ @@ -509,7 +513,12 @@ In .shutdown() the data structure maintaining stream state are freed up. void sdw_release_stream(struct sdw_stream_runtime * stream); -Not Supported +The SoundWire core provides a sdw_shutdown_stream() helper function, +typically called during a dailink .shutdown() callback, which clears +the stream pointer for all DAIS connected to a stream and releases the +memory allocated for the stream. + + Not Supported ============= 1. A single port with multiple channels supported cannot be used between two diff --git a/Documentation/driver-api/uio-howto.rst b/Documentation/driver-api/uio-howto.rst index 84091cd25dc4..907ffa3b38f5 100644 --- a/Documentation/driver-api/uio-howto.rst +++ b/Documentation/driver-api/uio-howto.rst @@ -274,7 +274,7 @@ fields of ``struct uio_mem``: region, it will show up in the corresponding sysfs node. - ``int memtype``: Required if the mapping is used. Set this to - ``UIO_MEM_PHYS`` if you you have physical memory on your card to be + ``UIO_MEM_PHYS`` if you have physical memory on your card to be mapped. Use ``UIO_MEM_LOGICAL`` for logical memory (e.g. allocated with :c:func:`__get_free_pages()` but not kmalloc()). There's also ``UIO_MEM_VIRTUAL`` for virtual memory. diff --git a/Documentation/driver-api/usb/URB.rst b/Documentation/driver-api/usb/URB.rst index 61a54da9fce9..1e4abc896a0d 100644 --- a/Documentation/driver-api/usb/URB.rst +++ b/Documentation/driver-api/usb/URB.rst @@ -240,7 +240,7 @@ How to do isochronous (ISO) transfers? ====================================== Besides the fields present on a bulk transfer, for ISO, you also -also have to set ``urb->interval`` to say how often to make transfers; it's +have to set ``urb->interval`` to say how often to make transfers; it's often one per frame (which is once every microframe for highspeed devices). The actual interval used will be a power of two that's no bigger than what you specify. You can use the :c:func:`usb_fill_int_urb` macro to fill diff --git a/Documentation/driver-api/xillybus.rst b/Documentation/driver-api/xillybus.rst index 2446ee303c09..a3ab832cb22b 100644 --- a/Documentation/driver-api/xillybus.rst +++ b/Documentation/driver-api/xillybus.rst @@ -273,7 +273,7 @@ buffer is full, the FPGA informs the host about that (appending a XILLYMSG_OPCODE_RELEASEBUF message channel 0 and sending an interrupt if necessary). The host responds by making the data available for reading through the character device. When all data has been read, the host writes on the -the FPGA's buffer control register, allowing the buffer's overwriting. Flow +FPGA's buffer control register, allowing the buffer's overwriting. Flow control mechanisms exist on both sides to prevent underflows and overflows. This is not good enough for creating a TCP/IP-like stream: If the data flow diff --git a/Documentation/fb/ep93xx-fb.rst b/Documentation/fb/ep93xx-fb.rst index 6f7767926d1a..1dd67f4688c7 100644 --- a/Documentation/fb/ep93xx-fb.rst +++ b/Documentation/fb/ep93xx-fb.rst @@ -127,7 +127,7 @@ At least on the EP9315 there is a silicon bug which causes bit 27 of the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is an unofficial errata for this bug at:: - http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + https://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 By default the EP93xx framebuffer driver checks if the allocated physical address has bit 27 set. If it does, then the memory is freed and an 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/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index f54ddfc06a12..c688aba22a8d 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -29,5 +29,5 @@ | sparc: | TODO | | um: | ok | | x86: | ok | - | xtensa: | TODO | + | xtensa: | ok | ----------------------- 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/debugfs.rst b/Documentation/filesystems/debugfs.rst index 1da7a4b7383d..728ab57a611a 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -185,13 +185,17 @@ byte offsets over a base for the register block. If you want to dump an u32 array in debugfs, you can create file with:: + struct debugfs_u32_array { + u32 *array; + u32 n_elements; + }; + void debugfs_create_u32_array(const char *name, umode_t mode, struct dentry *parent, - u32 *array, u32 elements); + struct debugfs_u32_array *array); -The "array" argument provides data, and the "elements" argument is -the number of elements in the array. Note: Once array is created its -size can not be changed. +The "array" argument wraps a pointer to the array's data and the number +of its elements. Note: Once array is created its size can not be changed. There is a helper function to create device related seq_file:: 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/fpga/dfl.rst b/Documentation/fpga/dfl.rst index cae96aa15671..0404fe6ffc74 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -89,6 +89,8 @@ The following functions are exposed through ioctls: - Program bitstream (DFL_FPGA_FME_PORT_PR) - Assign port to PF (DFL_FPGA_FME_PORT_ASSIGN) - Release port from PF (DFL_FPGA_FME_PORT_RELEASE) +- Get number of irqs of FME global error (DFL_FPGA_FME_ERR_GET_IRQ_NUM) +- Set interrupt trigger for FME error (DFL_FPGA_FME_ERR_SET_IRQ) More functions are exposed through sysfs (/sys/class/fpga_region/regionX/dfl-fme.n/): @@ -149,6 +151,10 @@ The following functions are exposed through ioctls: - Map DMA buffer (DFL_FPGA_PORT_DMA_MAP) - Unmap DMA buffer (DFL_FPGA_PORT_DMA_UNMAP) - Reset AFU (DFL_FPGA_PORT_RESET) +- Get number of irqs of port error (DFL_FPGA_PORT_ERR_GET_IRQ_NUM) +- Set interrupt trigger for port error (DFL_FPGA_PORT_ERR_SET_IRQ) +- Get number of irqs of UINT (DFL_FPGA_PORT_UINT_GET_IRQ_NUM) +- Set interrupt trigger for UINT (DFL_FPGA_PORT_UINT_SET_IRQ) DFL_FPGA_PORT_RESET: reset the FPGA Port and its AFU. Userspace can do Port @@ -462,6 +468,19 @@ since they are system-wide counters on FPGA device. The current driver does not support sampling. So "perf record" is unsupported. +Interrupt support +================= +Some FME and AFU private features are able to generate interrupts. As mentioned +above, users could call ioctl (DFL_FPGA_*_GET_IRQ_NUM) to know whether or how +many interrupts are supported for this private feature. Drivers also implement +an eventfd based interrupt handling mechanism for users to get notified when +interrupt happens. Users could set eventfds to driver via +ioctl (DFL_FPGA_*_SET_IRQ), and then poll/select on these eventfds waiting for +notification. +In Current DFL, 3 sub features (Port error, FME global error and AFU interrupt) +support interrupts. + + Add new FIUs support ==================== It's possible that developers made some new function blocks (FIUs) under this 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/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index ee730457bf4e..b89ddd06dabb 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -411,15 +411,3 @@ Legacy CRTC/Modeset Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c :export: - -SHMEM GEM Helper Reference -========================== - -.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c - :doc: overview - -.. kernel-doc:: include/drm/drm_gem_shmem_helper.h - :internal: - -.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c - :export: diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 397314d08f77..3c5ae4f6dfd2 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -460,6 +460,12 @@ HDMI Specific Connector Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: HDMI connector properties +Standard CRTC Properties +------------------------ + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: standard CRTC properties + Plane Composition Properties ---------------------------- @@ -537,3 +543,18 @@ Vertical Blanking and Interrupt Handling Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_vblank.c :export: + +Vertical Blank Work +=================== + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :doc: vblank works + +Vertical Blank Work Functions Reference +--------------------------------------- + +.. kernel-doc:: include/drm/drm_vblank_work.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :export: diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 49d321eb7964..9abee1589c1e 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -179,10 +179,7 @@ GEM Objects Lifetime All GEM objects are reference-counted by the GEM core. References can be acquired and release by calling drm_gem_object_get() and drm_gem_object_put() -respectively. The caller must hold the :c:type:`struct drm_device <drm_device>` -struct_mutex lock when calling drm_gem_object_get(). As a convenience, GEM -provides drm_gem_object_put_unlocked() functions that can be called without -holding the lock. +respectively. When the last reference to a GEM object is released the GEM core calls the :c:type:`struct drm_driver <drm_driver>` gem_free_object_unlocked @@ -373,6 +370,18 @@ GEM CMA Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c :export: +GEM SHMEM Helper Function Reference +----------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c + :doc: overview + +.. kernel-doc:: include/drm/drm_gem_shmem_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c + :export: + GEM VRAM Helper Functions Reference ----------------------------------- 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/gpu/todo.rst b/Documentation/gpu/todo.rst index 658b52f7ffc6..7969f106877d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -157,8 +157,8 @@ private lock. The tricky part is the BO free functions, since those can't reliably take that lock any more. Instead state needs to be protected with suitable subordinate locks or some cleanup work pushed to a worker thread. For performance-critical drivers it might also be better to go with a more -fine-grained per-buffer object and per-context lockings scheme. Currently only the -``msm`` driver still use ``struct_mutex``. +fine-grained per-buffer object and per-context lockings scheme. Currently only +the ``msm`` and `i915` drivers use ``struct_mutex``. Contact: Daniel Vetter, respective driver maintainers @@ -305,7 +305,7 @@ acquire context. Replace the boilerplate code surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() instead. -This should also be done for all places where drm_modest_lock_all() is still +This should also be done for all places where drm_modeset_lock_all() is still used. As a reference, take a look at the conversions already completed in drm core. @@ -327,26 +327,6 @@ Contact: Laurent Pinchart, Daniel Vetter Level: Intermediate (mostly because it is a huge tasks without good partial milestones, not technically itself that challenging) -Convert direct mode.vrefresh accesses to use drm_mode_vrefresh() ----------------------------------------------------------------- - -drm_display_mode.vrefresh isn't guaranteed to be populated. As such, using it -is risky and has been known to cause div-by-zero bugs. Fortunately, drm core -has helper which will use mode.vrefresh if it's !0 and will calculate it from -the timings when it's 0. - -Use simple search/replace, or (more fun) cocci to replace instances of direct -vrefresh access with a call to the helper. Check out -https://lists.freedesktop.org/archives/dri-devel/2019-January/205186.html for -inspiration. - -Once all instances of vrefresh have been converted, remove vrefresh from -drm_display_mode to avoid future use. - -Contact: Sean Paul - -Level: Starter - connector register/unregister fixes ----------------------------------- @@ -392,6 +372,38 @@ Contact: Laurent Pinchart, respective driver maintainers Level: Intermediate +Consolidate custom driver modeset properties +-------------------------------------------- + +Before atomic modeset took place, many drivers where creating their own +properties. Among other things, atomic brought the requirement that custom, +driver specific properties should not be used. + +For this task, we aim to introduce core helpers or reuse the existing ones +if available: + +A quick, unconfirmed, examples list. + +Introduce core helpers: +- audio (amdgpu, intel, gma500, radeon) +- brightness, contrast, etc (armada, nouveau) - overlay only (?) +- broadcast rgb (gma500, intel) +- colorkey (armada, nouveau, rcar) - overlay only (?) +- dither (amdgpu, nouveau, radeon) - varies across drivers +- underscan family (amdgpu, radeon, nouveau) + +Already in core: +- colorspace (sti) +- tv format names, enhancements (gma500, intel) +- tv overscan, margins, etc. (gma500, intel) +- zorder (omapdrm) - same as zpos (?) + + +Contact: Emil Velikov, respective driver maintainers + +Level: Intermediate + + Core refactorings ================= diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 0b41b051d021..339ed5fecd2e 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -185,7 +185,7 @@ enhancing the kernel code to adapt as a kernel module and also did the implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree. -0) http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 -1) http://lists.freedesktop.org/archives/xorg/2005-March/006663.html -2) http://lists.freedesktop.org/archives/xorg/2005-March/006745.html -3) http://lists.freedesktop.org/archives/xorg/2007-October/029507.html +0) https://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 +1) https://lists.freedesktop.org/archives/xorg/2005-March/006663.html +2) https://lists.freedesktop.org/archives/xorg/2005-March/006745.html +3) https://lists.freedesktop.org/archives/xorg/2007-October/029507.html diff --git a/Documentation/hwmon/adc128d818.rst b/Documentation/hwmon/adc128d818.rst index 6753468932ab..d2488023430f 100644 --- a/Documentation/hwmon/adc128d818.rst +++ b/Documentation/hwmon/adc128d818.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: I2C 0x1d, 0x1e, 0x1f, 0x2d, 0x2e, 0x2f - Datasheet: Publicly available at the TI website http://www.ti.com/ + Datasheet: Publicly available at the TI website https://www.ti.com/ Author: Guenter Roeck diff --git a/Documentation/hwmon/adm1026.rst b/Documentation/hwmon/adm1026.rst index 35d63e6498a3..66f996fa3031 100644 --- a/Documentation/hwmon/adm1026.rst +++ b/Documentation/hwmon/adm1026.rst @@ -10,7 +10,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.onsemi.com/PowerSolutions/product.do?id=ADM1026 + https://www.onsemi.com/PowerSolutions/product.do?id=ADM1026 Authors: - Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing diff --git a/Documentation/hwmon/adm1031.rst b/Documentation/hwmon/adm1031.rst index a677c3ab5574..be74ec1f3e73 100644 --- a/Documentation/hwmon/adm1031.rst +++ b/Documentation/hwmon/adm1031.rst @@ -10,7 +10,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/en/prod/0%2C2877%2CADM1030%2C00.html + https://www.analog.com/en/prod/0%2C2877%2CADM1030%2C00.html * Analog Devices ADM1031 @@ -20,7 +20,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/en/prod/0%2C2877%2CADM1031%2C00.html + https://www.analog.com/en/prod/0%2C2877%2CADM1031%2C00.html Authors: - Alexandre d'Alton <alex@alexdalton.org> diff --git a/Documentation/hwmon/adm1275.rst b/Documentation/hwmon/adm1275.rst index 49966ed70ec6..ce6528f90e4a 100644 --- a/Documentation/hwmon/adm1275.rst +++ b/Documentation/hwmon/adm1275.rst @@ -49,7 +49,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf + Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1293_1294.pdf Author: Guenter Roeck <linux@roeck-us.net> diff --git a/Documentation/hwmon/adt7410.rst b/Documentation/hwmon/adt7410.rst index 24caaa83c8ec..3f5a43561bf1 100644 --- a/Documentation/hwmon/adt7410.rst +++ b/Documentation/hwmon/adt7410.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf * Analog Devices ADT7420 Prefix: 'adt7420' @@ -20,7 +20,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf * Analog Devices ADT7310 @@ -30,7 +30,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf * Analog Devices ADT7320 @@ -40,7 +40,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf Author: Hartmut Knaack <knaack.h@gmx.de> diff --git a/Documentation/hwmon/corsair-cpro.rst b/Documentation/hwmon/corsair-cpro.rst new file mode 100644 index 000000000000..751f95476b57 --- /dev/null +++ b/Documentation/hwmon/corsair-cpro.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver corsair-cpro +========================== + +Supported devices: + + * Corsair Commander Pro + * Corsair Commander Pro (1000D) + +Author: Marius Zachmann + +Description +----------- + +This driver implements the sysfs interface for the Corsair Commander Pro. +The Corsair Commander Pro is a USB device with 6 fan connectors, +4 temperature sensor connectors and 2 Corsair LED connectors. +It can read the voltage levels on the SATA power connector. + +Usage Notes +----------- + +Since it is a USB device, hotswapping is possible. The device is autodetected. + +Sysfs entries +------------- + +======================= ===================================================================== +in0_input Voltage on SATA 12v +in1_input Voltage on SATA 5v +in2_input Voltage on SATA 3.3v +temp[1-4]_input Temperature on connected temperature sensors +fan[1-6]_input Connected fan rpm. +fan[1-6]_label Shows fan type as detected by the device. +fan[1-6]_target Sets fan speed target rpm. + When reading, it reports the last value if it was set by the driver. + Otherwise returns an error. +pwm[1-6] Sets the fan speed. Values from 0-255. Can only be read if pwm + was set directly. +======================= ===================================================================== diff --git a/Documentation/hwmon/emc1403.rst b/Documentation/hwmon/emc1403.rst index 3a4913b63ef3..0de9616b24ed 100644 --- a/Documentation/hwmon/emc1403.rst +++ b/Documentation/hwmon/emc1403.rst @@ -12,7 +12,7 @@ Supported chips: Datasheets: - http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf - - http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414 @@ -33,7 +33,7 @@ Supported chips: Datasheet: - - http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf * SMSC / Microchip EMC1423, EMC1424 @@ -43,7 +43,7 @@ Supported chips: Datasheet: - - http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf + - https://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf Author: Kalhan Trisal <kalhan.trisal@intel.com diff --git a/Documentation/hwmon/f71882fg.rst b/Documentation/hwmon/f71882fg.rst index 5c0b7b0db150..38e30fbd4806 100644 --- a/Documentation/hwmon/f71882fg.rst +++ b/Documentation/hwmon/f71882fg.rst @@ -145,7 +145,7 @@ motherboard, so the driver assumes that the BIOS set the method properly. Note that the lowest numbered temperature zone trip point corresponds to -to the border between the highest and one but highest temperature zones, and +the border between the highest and one but highest temperature zones, and vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp to low temp! This is how things are implemented in the IC, and the driver mimics this. diff --git a/Documentation/hwmon/ina209.rst b/Documentation/hwmon/ina209.rst index 64322075a145..162256131517 100644 --- a/Documentation/hwmon/ina209.rst +++ b/Documentation/hwmon/ina209.rst @@ -10,7 +10,7 @@ Supported chips: Addresses scanned: - Datasheet: - http://www.ti.com/lit/gpn/ina209 + https://www.ti.com/lit/gpn/ina209 Author: - Paul Hays <Paul.Hays@cattail.ca> diff --git a/Documentation/hwmon/ina2xx.rst b/Documentation/hwmon/ina2xx.rst index ed81f5416331..f78a5cd44c4c 100644 --- a/Documentation/hwmon/ina2xx.rst +++ b/Documentation/hwmon/ina2xx.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA220 @@ -21,7 +21,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA226 @@ -31,7 +31,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA230 @@ -41,7 +41,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ * Texas Instruments INA231 @@ -51,7 +51,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ Author: Lothar Felten <lothar.felten@gmail.com> diff --git a/Documentation/hwmon/ina3221.rst b/Documentation/hwmon/ina3221.rst index 297f7323b441..8c12c54d2c24 100644 --- a/Documentation/hwmon/ina3221.rst +++ b/Documentation/hwmon/ina3221.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/ + https://www.ti.com/ Author: Andrew F. Davis <afd@ti.com> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 55ff4b7c5349..750d3a975d82 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -47,6 +47,7 @@ Hardware Monitoring Kernel Drivers bel-pfe bt1-pvt coretemp + corsair-cpro da9052 da9055 dell-smm-hwmon diff --git a/Documentation/hwmon/jc42.rst b/Documentation/hwmon/jc42.rst index 5b14b49bb6f7..19d10512f6c0 100644 --- a/Documentation/hwmon/jc42.rst +++ b/Documentation/hwmon/jc42.rst @@ -7,7 +7,7 @@ Supported chips: Datasheets: - http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf + https://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A @@ -39,37 +39,37 @@ Supported chips: Datasheets: - http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf - http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf + https://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf * NXP Semiconductors SE97, SE97B, SE98, SE98A Datasheets: - http://www.nxp.com/documents/data_sheet/SE97.pdf + https://www.nxp.com/documents/data_sheet/SE97.pdf - http://www.nxp.com/documents/data_sheet/SE97B.pdf + https://www.nxp.com/documents/data_sheet/SE97B.pdf - http://www.nxp.com/documents/data_sheet/SE98.pdf + https://www.nxp.com/documents/data_sheet/SE98.pdf - http://www.nxp.com/documents/data_sheet/SE98A.pdf + https://www.nxp.com/documents/data_sheet/SE98A.pdf * ON Semiconductor CAT34TS02, CAT6095 Datasheet: - http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF + https://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF - http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF + https://www.onsemi.com/pub/Collateral/CAT6095-D.PDF * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000 diff --git a/Documentation/hwmon/k8temp.rst b/Documentation/hwmon/k8temp.rst index fe9109521056..ab25a73e778f 100644 --- a/Documentation/hwmon/k8temp.rst +++ b/Documentation/hwmon/k8temp.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: PCI space - Datasheet: http://www.amd.com/system/files/TechDocs/32559.pdf + Datasheet: https://www.amd.com/system/files/TechDocs/32559.pdf Author: Rudolf Marek diff --git a/Documentation/hwmon/lm25066.rst b/Documentation/hwmon/lm25066.rst index 30e6e77fb3c8..9f1d7e4d3ca1 100644 --- a/Documentation/hwmon/lm25066.rst +++ b/Documentation/hwmon/lm25066.rst @@ -11,9 +11,9 @@ Supported chips: Datasheets: - http://www.ti.com/lit/gpn/lm25056 + https://www.ti.com/lit/gpn/lm25056 - http://www.ti.com/lit/gpn/lm25056a + https://www.ti.com/lit/gpn/lm25056a * National Semiconductor LM25066 @@ -55,7 +55,7 @@ Supported chips: Datasheet: - http://www.ti.com/product/LM5066I + https://www.ti.com/product/LM5066I Author: Guenter Roeck <linux@roeck-us.net> diff --git a/Documentation/hwmon/lm63.rst b/Documentation/hwmon/lm63.rst index f478132b0408..9e27367d7405 100644 --- a/Documentation/hwmon/lm63.rst +++ b/Documentation/hwmon/lm63.rst @@ -39,7 +39,7 @@ Author: Jean Delvare <jdelvare@suse.de> Thanks go to Tyan and especially Alex Buckingham for setting up a remote access to their S4882 test platform for this driver. - http://www.tyan.com/ + https://www.tyan.com/ Description ----------- diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst index f259bc1fcd91..6ddc5b67ccb5 100644 --- a/Documentation/hwmon/lm70.rst +++ b/Documentation/hwmon/lm70.rst @@ -13,15 +13,15 @@ Supported chips: * Texas Instruments TMP122/TMP124 - Information: http://www.ti.com/product/tmp122 + Information: https://www.ti.com/product/tmp122 * National Semiconductor LM71 - Datasheet: http://www.ti.com/product/LM71 + Datasheet: https://www.ti.com/product/LM71 * National Semiconductor LM74 - Datasheet: http://www.ti.com/product/LM74 + Datasheet: https://www.ti.com/product/LM74 Author: diff --git a/Documentation/hwmon/lm73.rst b/Documentation/hwmon/lm73.rst index 1d6a46844e85..74e909be6ef7 100644 --- a/Documentation/hwmon/lm73.rst +++ b/Documentation/hwmon/lm73.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm73 + https://www.ti.com/product/lm73 Author: Guillaume Ligneul <guillaume.ligneul@gmail.com> diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst index e749f827c002..81257d5fc48f 100644 --- a/Documentation/hwmon/lm75.rst +++ b/Documentation/hwmon/lm75.rst @@ -31,7 +31,7 @@ Supported chips: Datasheet: Publicly available at the Maxim website - http://www.maximintegrated.com/ + https://www.maximintegrated.com/ * Maxim MAX6625, MAX6626, MAX31725, MAX31726 @@ -71,7 +71,7 @@ Supported chips: Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/adt75 + https://www.analog.com/adt75 * ST Microelectronics STDS75 @@ -101,23 +101,23 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/tmp100 + https://www.ti.com/product/tmp100 - http://www.ti.com/product/tmp101 + https://www.ti.com/product/tmp101 - http://www.ti.com/product/tmp105 + https://www.ti.com/product/tmp105 - http://www.ti.com/product/tmp112 + https://www.ti.com/product/tmp112 - http://www.ti.com/product/tmp75 + https://www.ti.com/product/tmp75 - http://www.ti.com/product/tmp75b + https://www.ti.com/product/tmp75b - http://www.ti.com/product/tmp75c + https://www.ti.com/product/tmp75c - http://www.ti.com/product/tmp175 + https://www.ti.com/product/tmp175 - http://www.ti.com/product/tmp275 + https://www.ti.com/product/tmp275 * NXP LM75B, PCT2075 @@ -127,9 +127,9 @@ Supported chips: Datasheet: Publicly available at the NXP website - http://www.nxp.com/documents/data_sheet/LM75B.pdf + https://www.nxp.com/documents/data_sheet/LM75B.pdf - http://www.nxp.com/docs/en/data-sheet/PCT2075.pdf + https://www.nxp.com/docs/en/data-sheet/PCT2075.pdf Author: Frodo Looijaard <frodol@dds.nl> diff --git a/Documentation/hwmon/lm85.rst b/Documentation/hwmon/lm85.rst index faa92f54431c..55e1d9cdaaae 100644 --- a/Documentation/hwmon/lm85.rst +++ b/Documentation/hwmon/lm85.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.ti.com/lit/ds/symlink/lm96000.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/lm96000.pdf * Analog Devices ADM1027 @@ -25,7 +25,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADM1027 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADM1027 * Analog Devices ADT7463 @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 * Analog Devices ADT7468 @@ -41,7 +41,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468 + Datasheet: https://www.onsemi.com/PowerSolutions/product.do?id=ADT7468 * SMSC EMC6D100, SMSC EMC6D101 diff --git a/Documentation/hwmon/lm87.rst b/Documentation/hwmon/lm87.rst index 72fcb577ef2a..b8fec5689648 100644 --- a/Documentation/hwmon/lm87.rst +++ b/Documentation/hwmon/lm87.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c - 0x2e - Datasheet: http://www.analog.com/en/prod/0,2877,ADM1024,00.html + Datasheet: https://www.analog.com/en/prod/0,2877,ADM1024,00.html Authors: diff --git a/Documentation/hwmon/lm90.rst b/Documentation/hwmon/lm90.rst index 78dfc01b47a2..3da8c6e06a36 100644 --- a/Documentation/hwmon/lm90.rst +++ b/Documentation/hwmon/lm90.rst @@ -51,7 +51,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADM1032 + https://www.onsemi.com/PowerSolutions/product.do?id=ADM1032 * Analog Devices ADT7461 @@ -61,7 +61,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461 + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461 * Analog Devices ADT7461A @@ -71,7 +71,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A + https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A * ON Semiconductor NCT1008 @@ -81,7 +81,7 @@ Supported chips: Datasheet: Publicly available at the ON Semiconductor website - http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008 + https://www.onsemi.com/PowerSolutions/product.do?id=NCT1008 * Maxim MAX6646 @@ -263,7 +263,7 @@ Supported chips: Datasheet: Publicly available at TI website - http://www.ti.com/litv/pdf/sbos686 + https://www.ti.com/litv/pdf/sbos686 Author: Jean Delvare <jdelvare@suse.de> diff --git a/Documentation/hwmon/lm93.rst b/Documentation/hwmon/lm93.rst index 49d199b45b67..369e15898af9 100644 --- a/Documentation/hwmon/lm93.rst +++ b/Documentation/hwmon/lm93.rst @@ -133,7 +133,7 @@ Smart Tach Mode (from the datasheet):: four signals are measured within 4 seconds. Smart tach mode is enabled by the driver by writing 1 or 2 (associating the -the fan tachometer with a pwm) to the sysfs file fan<n>_smart_tach. A zero +fan tachometer with a pwm) to the sysfs file fan<n>_smart_tach. A zero will disable the function for that fan. Note that Smart tach mode cannot be enabled if the PWM output frequency is 22500 Hz (see below). diff --git a/Documentation/hwmon/lm95234.rst b/Documentation/hwmon/lm95234.rst index e4c14bea5efd..a44e8f529826 100644 --- a/Documentation/hwmon/lm95234.rst +++ b/Documentation/hwmon/lm95234.rst @@ -9,7 +9,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm95233 + https://www.ti.com/product/lm95233 * National Semiconductor / Texas Instruments LM95234 @@ -17,7 +17,7 @@ Supported chips: Datasheet: Publicly available at the Texas Instruments website - http://www.ti.com/product/lm95234 + https://www.ti.com/product/lm95234 Author: Guenter Roeck <linux@roeck-us.net> diff --git a/Documentation/hwmon/lm95245.rst b/Documentation/hwmon/lm95245.rst index 566d1dc8c5a6..836d9a3f53f9 100644 --- a/Documentation/hwmon/lm95245.rst +++ b/Documentation/hwmon/lm95245.rst @@ -9,7 +9,7 @@ Supported chips: Datasheet: Publicly available at the TI website - http://www.ti.com/lit/ds/symlink/lm95235.pdf + https://www.ti.com/lit/ds/symlink/lm95235.pdf * TI / National Semiconductor LM95245 @@ -17,7 +17,7 @@ Supported chips: Datasheet: Publicly available at the TI website - http://www.ti.com/lit/ds/symlink/lm95245.pdf + https://www.ti.com/lit/ds/symlink/lm95245.pdf Author: Alexander Stein <alexander.stein@systec-electronic.com> diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst index bc5270e5a477..b99a63965cfb 100644 --- a/Documentation/hwmon/ltc2978.rst +++ b/Documentation/hwmon/ltc2978.rst @@ -179,7 +179,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4680 + Datasheet: https://www.analog.com/ltm4680 * Analog Devices LTM4686 @@ -187,7 +187,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4686 + Datasheet: https://www.analog.com/ltm4686 * Analog Devices LTM4700 @@ -195,7 +195,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.analog.com/ltm4700 + Datasheet: https://www.analog.com/ltm4700 diff --git a/Documentation/hwmon/max20730.rst b/Documentation/hwmon/max20730.rst index cea7ae58c2f7..cb0c95b2b1f6 100644 --- a/Documentation/hwmon/max20730.rst +++ b/Documentation/hwmon/max20730.rst @@ -5,6 +5,14 @@ Kernel driver max20730 Supported chips: + * Maxim MAX20710 + + Prefix: 'max20710' + + Addresses scanned: - + + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20710.pdf + * Maxim MAX20730 Prefix: 'max20730' @@ -35,7 +43,7 @@ Author: Guenter Roeck <linux@roeck-us.net> Description ----------- -This driver implements support for Maxim MAX20730, MAX20734, and MAX20743 +This driver implements support for Maxim MAX20710, MAX20730, MAX20734, and MAX20743 Integrated, Step-Down Switching Regulators with PMBus support. The driver is a client driver to the core PMBus driver. diff --git a/Documentation/hwmon/max20751.rst b/Documentation/hwmon/max20751.rst index fe701e07eaf5..f9febefce02d 100644 --- a/Documentation/hwmon/max20751.rst +++ b/Documentation/hwmon/max20751.rst @@ -9,9 +9,9 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX20751.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX20751.pdf - Application note: http://pdfserv.maximintegrated.com/en/an/AN5941.pdf + Application note: https://pdfserv.maximintegrated.com/en/an/AN5941.pdf Author: Guenter Roeck <linux@roeck-us.net> diff --git a/Documentation/hwmon/max31790.rst b/Documentation/hwmon/max31790.rst index 84c62a12ef3a..f301385d8cef 100644 --- a/Documentation/hwmon/max31790.rst +++ b/Documentation/hwmon/max31790.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf + Datasheet: https://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf Author: Il Han <corone.il.han@gmail.com> diff --git a/Documentation/hwmon/max34440.rst b/Documentation/hwmon/max34440.rst index 5744df100a5d..162d289f0814 100644 --- a/Documentation/hwmon/max34440.rst +++ b/Documentation/hwmon/max34440.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34440.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34440.pdf * Maxim MAX34441 @@ -19,7 +19,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34441.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34441.pdf * Maxim MAX34446 @@ -29,7 +29,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34446.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34446.pdf * Maxim MAX34451 @@ -39,7 +39,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34451.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34451.pdf * Maxim MAX34460 @@ -49,7 +49,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34460.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34460.pdf * Maxim MAX34461 @@ -59,7 +59,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX34461.pdf Author: Guenter Roeck <linux@roeck-us.net> diff --git a/Documentation/hwmon/nct6775.rst b/Documentation/hwmon/nct6775.rst index 1d0315c40952..5ba8276aad4b 100644 --- a/Documentation/hwmon/nct6775.rst +++ b/Documentation/hwmon/nct6775.rst @@ -276,5 +276,5 @@ temperature measurement device. As a result, the temperature reported on CPUTIN will not reflect a usable value. It often reports unreasonably high temperatures, and in some cases the reported temperature declines if the actual temperature increases (similar to the raw PECI temperature value - see PECI -specification for details). CPUTIN should therefore be be ignored on ASUS +specification for details). CPUTIN should therefore be ignored on ASUS boards. The CPU temperature on ASUS boards is reported from PECI 0. diff --git a/Documentation/hwmon/pmbus.rst b/Documentation/hwmon/pmbus.rst index 2658ddee70eb..66b3e894612f 100644 --- a/Documentation/hwmon/pmbus.rst +++ b/Documentation/hwmon/pmbus.rst @@ -21,11 +21,11 @@ Supported chips: Datasheets: - http://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF + https://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF - http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF + https://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF - http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF + https://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF * Lineage Power @@ -53,15 +53,15 @@ Supported chips: Datasheets: - http://www.ti.com/lit/gpn/tps40400 + https://www.ti.com/lit/gpn/tps40400 - http://www.ti.com/lit/gpn/tps544b20 + https://www.ti.com/lit/gpn/tps544b20 - http://www.ti.com/lit/gpn/tps544b25 + https://www.ti.com/lit/gpn/tps544b25 - http://www.ti.com/lit/gpn/tps544c20 + https://www.ti.com/lit/gpn/tps544c20 - http://www.ti.com/lit/gpn/tps544c25 + https://www.ti.com/lit/gpn/tps544c25 * Maxim MAX20796 diff --git a/Documentation/hwmon/sht21.rst b/Documentation/hwmon/sht21.rst index f1f5da030108..1bccc8e8aac8 100644 --- a/Documentation/hwmon/sht21.rst +++ b/Documentation/hwmon/sht21.rst @@ -11,7 +11,7 @@ Supported chips: Datasheet: Publicly available at the Sensirion website - http://www.sensirion.com/file/datasheet_sht21 + https://www.sensirion.com/file/datasheet_sht21 @@ -23,7 +23,7 @@ Supported chips: Datasheet: Publicly available at the Sensirion website - http://www.sensirion.com/file/datasheet_sht25 + https://www.sensirion.com/file/datasheet_sht25 diff --git a/Documentation/hwmon/shtc1.rst b/Documentation/hwmon/shtc1.rst index 08380f21ab6a..f38c4c9d2f74 100644 --- a/Documentation/hwmon/shtc1.rst +++ b/Documentation/hwmon/shtc1.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtc1 + Datasheet: https://www.sensirion.com/file/datasheet_shtc1 @@ -19,7 +19,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtw1 + Datasheet: https://www.sensirion.com/file/datasheet_shtw1 @@ -29,7 +29,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.sensirion.com/file/datasheet_shtc3 + Datasheet: https://www.sensirion.com/file/datasheet_shtc3 diff --git a/Documentation/hwmon/sparx5-temp.rst b/Documentation/hwmon/sparx5-temp.rst new file mode 100644 index 000000000000..014080908954 --- /dev/null +++ b/Documentation/hwmon/sparx5-temp.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Microchip SparX-5 SoC +===================== + +Supported chips: + + * VSC7546, VSC7549, VSC755, VSC7556, and VSC7558 (Sparx5 series) + + Prefix: 'sparx5-temp' + + Addresses scanned: - + + Datasheet: Provided by Microchip upon request and under NDA + +Author: Lars Povlsen <lars.povlsen@microchip.com> + +Description +----------- + +The Sparx5 SoC contains a temperature sensor based on the MR74060 +Moortec IP. + +The sensor has a range of -40°C to +125°C and an accuracy of +/-5°C. + +Sysfs entries +------------- + +The following attributes are supported. + +======================= ======================================================== +temp1_input Die temperature (in millidegree Celsius.) +======================= ======================================================== diff --git a/Documentation/hwmon/thmc50.rst b/Documentation/hwmon/thmc50.rst index cfff3885287d..090f040294a3 100644 --- a/Documentation/hwmon/thmc50.rst +++ b/Documentation/hwmon/thmc50.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x2c - 0x2e - Datasheet: http://www.ti.com/ + Datasheet: https://www.ti.com/ Author: Krzysztof Helt <krzysztof.h1@wp.pl> diff --git a/Documentation/hwmon/tmp103.rst b/Documentation/hwmon/tmp103.rst index 205de6148fcb..e195a7d14309 100644 --- a/Documentation/hwmon/tmp103.rst +++ b/Documentation/hwmon/tmp103.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Product info and datasheet: http://www.ti.com/product/tmp103 + Product info and datasheet: https://www.ti.com/product/tmp103 Author: diff --git a/Documentation/hwmon/tmp108.rst b/Documentation/hwmon/tmp108.rst index 5f4266a16cb2..6df7cf1b42f4 100644 --- a/Documentation/hwmon/tmp108.rst +++ b/Documentation/hwmon/tmp108.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: none - Datasheet: http://www.ti.com/product/tmp108 + Datasheet: https://www.ti.com/product/tmp108 Author: diff --git a/Documentation/hwmon/tmp401.rst b/Documentation/hwmon/tmp401.rst index 6a05a0719bc7..14bf1fbf4493 100644 --- a/Documentation/hwmon/tmp401.rst +++ b/Documentation/hwmon/tmp401.rst @@ -47,7 +47,7 @@ Supported chips: Prefix: 'tmp461' - Datasheet: http://www.ti.com/product/tmp461 + Datasheet: https://www.ti.com/product/tmp461 diff --git a/Documentation/hwmon/tmp421.rst b/Documentation/hwmon/tmp421.rst index 1ba926a3605c..ddcd5159c75d 100644 --- a/Documentation/hwmon/tmp421.rst +++ b/Documentation/hwmon/tmp421.rst @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f - Datasheet: http://www.ti.com/product/tmp441 + Datasheet: https://www.ti.com/product/tmp441 * Texas Instruments TMP442 @@ -41,7 +41,7 @@ Supported chips: Addresses scanned: I2C 0x4c and 0x4d - Datasheet: http://www.ti.com/product/tmp442 + Datasheet: https://www.ti.com/product/tmp442 Authors: diff --git a/Documentation/hwmon/tmp513.rst b/Documentation/hwmon/tmp513.rst index 6c8fae4b1a75..f2dfc1677ad9 100644 --- a/Documentation/hwmon/tmp513.rst +++ b/Documentation/hwmon/tmp513.rst @@ -9,13 +9,13 @@ Supported chips: Prefix: 'tmp512' - Datasheet: http://www.ti.com/lit/ds/symlink/tmp512.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/tmp512.pdf * Texas Instruments TMP513 Prefix: 'tmp513' - Datasheet: http://www.ti.com/lit/ds/symlink/tmp513.pdf + Datasheet: https://www.ti.com/lit/ds/symlink/tmp513.pdf Authors: diff --git a/Documentation/hwmon/tps40422.rst b/Documentation/hwmon/tps40422.rst index 8fe3e1c3572e..32a62ccea192 100644 --- a/Documentation/hwmon/tps40422.rst +++ b/Documentation/hwmon/tps40422.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/tps40422 + Datasheet: https://www.ti.com/lit/gpn/tps40422 Author: Zhu Laiwen <richard.zhu@nsn.com> diff --git a/Documentation/hwmon/tps53679.rst b/Documentation/hwmon/tps53679.rst index be94cab78967..c7c589e49789 100644 --- a/Documentation/hwmon/tps53679.rst +++ b/Documentation/hwmon/tps53679.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/tps53647 + Datasheet: https://www.ti.com/lit/gpn/tps53647 * Texas Instruments TPS53667 @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53667 + Datasheet: https://www.ti.com/lit/gpn/TPS53667 * Texas Instruments TPS53679 @@ -25,7 +25,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53679 (short version) + Datasheet: https://www.ti.com/lit/gpn/TPS53679 (short version) * Texas Instruments TPS53681 @@ -33,7 +33,7 @@ Supported chips: Addresses scanned: - - Datasheet: http://www.ti.com/lit/gpn/TPS53681 + Datasheet: https://www.ti.com/lit/gpn/TPS53681 * Texas Instruments TPS53688 diff --git a/Documentation/hwmon/w83627ehf.rst b/Documentation/hwmon/w83627ehf.rst index 74d19ef11e1f..7bb557c94858 100644 --- a/Documentation/hwmon/w83627ehf.rst +++ b/Documentation/hwmon/w83627ehf.rst @@ -96,7 +96,7 @@ sensors. The configured source for each of the temperature sensors is provided in tempX_label. Temperatures are measured in degrees Celsius and measurement resolution is 1 -degC for temp1 and and 0.5 degC for temp2 and temp3. For temp4 and higher, +degC for temp1 and 0.5 degC for temp2 and temp3. For temp4 and higher, resolution is 1 degC for W83667HG-B and 0.0 degC for NCT6775F and NCT6776F. An alarm is triggered when the temperature gets higher than high limit; it stays on until the temperature falls below the hysteresis value. diff --git a/Documentation/hwmon/w83781d.rst b/Documentation/hwmon/w83781d.rst index f36d33dfb704..c2dcb6856012 100644 --- a/Documentation/hwmon/w83781d.rst +++ b/Documentation/hwmon/w83781d.rst @@ -17,7 +17,7 @@ Supported chips: Addresses scanned: I2C 0x28 - 0x2f, ISA 0x290 (8 I/O ports) - Datasheet: http://www.winbond.com + Datasheet: https://www.winbond.com * Winbond W83783S diff --git a/Documentation/hwmon/w83l786ng.rst b/Documentation/hwmon/w83l786ng.rst index 2b7776190de3..06234dea42a2 100644 --- a/Documentation/hwmon/w83l786ng.rst +++ b/Documentation/hwmon/w83l786ng.rst @@ -36,7 +36,7 @@ Temperatures are measured in degrees Celsius and measurement resolution is 1 degC for temp1 and temp2. Fan rotation speeds are reported in RPM (rotations per minute). Fan readings -readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 +can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or 128 for fan 1/2) to give the readings more range or accuracy. Voltage sensors (also known as IN sensors) report their values in millivolts. 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/leds/index.rst b/Documentation/leds/index.rst index 060f4e485897..bc70c6aa7138 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -9,6 +9,7 @@ LEDs leds-class leds-class-flash + leds-class-multicolor ledtrig-oneshot ledtrig-transient ledtrig-usbport diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst new file mode 100644 index 000000000000..c57b98bfd387 --- /dev/null +++ b/Documentation/leds/leds-class-multicolor.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================================== +Multicolor LED handling under Linux +==================================== + +Description +=========== +The multicolor class groups monochrome LEDs and allows controlling two +aspects of the final combined color: hue and lightness. The former is +controlled via the multi_intensity array file and the latter is controlled +via brightness file. + +Multicolor Class Control +======================== +The multicolor class presents files that groups the colors as indexes in an +array. These files are children under the LED parent node created by the +led_class framework. The led_class framework is documented in led-class.rst +within this documentation directory. + +Each colored LED will be indexed under the multi_* files. The order of the +colors will be arbitrary. The multi_index file can be read to determine the +color name to indexed value. + +The multi_index file is an array that contains the string list of the colors as +they are defined in each multi_* array file. + +The multi_intensity is an array that can be read or written to for the +individual color intensities. All elements within this array must be written in +order for the color LED intensities to be updated. + +Directory Layout Example +======================== +root:/sys/class/leds/multicolor:status# ls -lR +-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness +-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index +-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity + +Multicolor Class Brightness Control +=================================== +The brightness level for each LED is calculated based on the color LED +intensity setting divided by the global max_brightness setting multiplied by +the requested brightness. + +led_brightness = brightness * multi_intensity/max_brightness + +Example: +A user first writes the multi_intensity file with the brightness levels +for each LED that are necessary to achieve a certain color output from a +multicolor LED group. + +cat /sys/class/leds/multicolor:status/multi_index +green blue red + +echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity + +red - + intensity = 138 + max_brightness = 255 +green - + intensity = 43 + max_brightness = 255 +blue - + intensity = 226 + max_brightness = 255 + +The user can control the brightness of that multicolor LED group by writing the +global 'brightness' control. Assuming a max_brightness of 255 the user +may want to dim the LED color group to half. The user would write a value of +128 to the global brightness file then the values written to each LED will be +adjusted base on this value. + +cat /sys/class/leds/multicolor:status/max_brightness +255 +echo 128 > /sys/class/leds/multicolor:status/brightness + +adjusted_red_value = 128 * 138/255 = 69 +adjusted_green_value = 128 * 43/255 = 21 +adjusted_blue_value = 128 * 226/255 = 113 + +Reading the global brightness file will return the current brightness value of +the color LED group. + +cat /sys/class/leds/multicolor:status/brightness +128 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/networking/batman-adv.rst b/Documentation/networking/batman-adv.rst index 18020943ba25..74821d29a22f 100644 --- a/Documentation/networking/batman-adv.rst +++ b/Documentation/networking/batman-adv.rst @@ -73,7 +73,7 @@ lower value. This will make the mesh more responsive to topology changes, but will also increase the overhead. Information about the current state can be accessed via the batadv generic -netlink family. batctl provides human readable version via its debug tables +netlink family. batctl provides a human readable version via its debug tables subcommands. @@ -115,8 +115,8 @@ are prefixed with "batman-adv:" So to see just these messages try:: $ dmesg | grep batman-adv When investigating problems with your mesh network, it is sometimes necessary to -see more detail debug messages. This must be enabled when compiling the -batman-adv module. When building batman-adv as part of kernel, use "make +see more detailed debug messages. This must be enabled when compiling the +batman-adv module. When building batman-adv as part of the kernel, use "make menuconfig" and enable the option ``B.A.T.M.A.N. debugging`` (``CONFIG_BATMAN_ADV_DEBUG=y``). @@ -160,7 +160,7 @@ IRC: #batman on irc.freenode.org Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription at - https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) + https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/) You can also contact the Authors: diff --git a/Documentation/networking/dccp.rst b/Documentation/networking/dccp.rst index dde16be04456..91e5c33ba3ff 100644 --- a/Documentation/networking/dccp.rst +++ b/Documentation/networking/dccp.rst @@ -192,6 +192,9 @@ FIONREAD Works as in udp(7): returns in the ``int`` argument pointer the size of the next pending datagram in bytes, or 0 when no datagram is pending. +SIOCOUTQ + Returns the number of unsent data bytes in the socket send queue as ``int`` + into the buffer specified by the argument pointer. Other tunables ============== diff --git a/Documentation/networking/cops.rst b/Documentation/networking/device_drivers/appletalk/cops.rst index 964ba80599a9..964ba80599a9 100644 --- a/Documentation/networking/cops.rst +++ b/Documentation/networking/device_drivers/appletalk/cops.rst diff --git a/Documentation/networking/device_drivers/appletalk/index.rst b/Documentation/networking/device_drivers/appletalk/index.rst new file mode 100644 index 000000000000..de7507f02037 --- /dev/null +++ b/Documentation/networking/device_drivers/appletalk/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +AppleTalk Device Drivers +======================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + cops + ltpc + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/ltpc.rst b/Documentation/networking/device_drivers/appletalk/ltpc.rst index 0ad197fd17ce..0ad197fd17ce 100644 --- a/Documentation/networking/ltpc.rst +++ b/Documentation/networking/device_drivers/appletalk/ltpc.rst diff --git a/Documentation/networking/cxacru-cf.py b/Documentation/networking/device_drivers/atm/cxacru-cf.py index b41d298398c8..b41d298398c8 100644 --- a/Documentation/networking/cxacru-cf.py +++ b/Documentation/networking/device_drivers/atm/cxacru-cf.py diff --git a/Documentation/networking/cxacru.rst b/Documentation/networking/device_drivers/atm/cxacru.rst index 6088af2ffeda..6088af2ffeda 100644 --- a/Documentation/networking/cxacru.rst +++ b/Documentation/networking/device_drivers/atm/cxacru.rst diff --git a/Documentation/networking/fore200e.rst b/Documentation/networking/device_drivers/atm/fore200e.rst index 55df9ec09ac8..55df9ec09ac8 100644 --- a/Documentation/networking/fore200e.rst +++ b/Documentation/networking/device_drivers/atm/fore200e.rst diff --git a/Documentation/networking/device_drivers/atm/index.rst b/Documentation/networking/device_drivers/atm/index.rst new file mode 100644 index 000000000000..7b593f031a60 --- /dev/null +++ b/Documentation/networking/device_drivers/atm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Asynchronous Transfer Mode (ATM) Device Drivers +=============================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + cxacru + fore200e + iphase + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/iphase.rst b/Documentation/networking/device_drivers/atm/iphase.rst index 92d9b757d75a..92d9b757d75a 100644 --- a/Documentation/networking/iphase.rst +++ b/Documentation/networking/device_drivers/atm/iphase.rst diff --git a/Documentation/networking/device_drivers/cable/index.rst b/Documentation/networking/device_drivers/cable/index.rst new file mode 100644 index 000000000000..cce3c4392972 --- /dev/null +++ b/Documentation/networking/device_drivers/cable/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cable Modem Device Drivers +========================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + sb1000 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/sb1000.rst b/Documentation/networking/device_drivers/cable/sb1000.rst index c8582ca4034d..c8582ca4034d 100644 --- a/Documentation/networking/device_drivers/sb1000.rst +++ b/Documentation/networking/device_drivers/cable/sb1000.rst diff --git a/Documentation/networking/device_drivers/cellular/index.rst b/Documentation/networking/device_drivers/cellular/index.rst new file mode 100644 index 000000000000..fc1812d3fc70 --- /dev/null +++ b/Documentation/networking/device_drivers/cellular/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cellular Modem Device Drivers +============================= + +Contents: + +.. toctree:: + :maxdepth: 2 + + qualcomm/rmnet + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst index 70643b58de05..70643b58de05 100644 --- a/Documentation/networking/device_drivers/qualcomm/rmnet.rst +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst diff --git a/Documentation/networking/device_drivers/3com/3c509.rst b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst index 47f706bacdd9..47f706bacdd9 100644 --- a/Documentation/networking/device_drivers/3com/3c509.rst +++ b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst diff --git a/Documentation/networking/device_drivers/3com/vortex.rst b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst index 800add5be338..eab10fc6da5c 100644 --- a/Documentation/networking/device_drivers/3com/vortex.rst +++ b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst @@ -4,8 +4,6 @@ 3Com Vortex device driver ========================= -Documentation/networking/device_drivers/3com/vortex.rst - Andrew Morton 30 April 2000 diff --git a/Documentation/networking/altera_tse.rst b/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst index 7a7040072e58..7a7040072e58 100644 --- a/Documentation/networking/altera_tse.rst +++ b/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst diff --git a/Documentation/networking/device_drivers/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index 11af6388ea87..11af6388ea87 100644 --- a/Documentation/networking/device_drivers/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst diff --git a/Documentation/networking/device_drivers/aquantia/atlantic.rst b/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst index 595ddef1c8b3..595ddef1c8b3 100644 --- a/Documentation/networking/device_drivers/aquantia/atlantic.rst +++ b/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst diff --git a/Documentation/networking/device_drivers/chelsio/cxgb.rst b/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst index 435dce5fa2c7..435dce5fa2c7 100644 --- a/Documentation/networking/device_drivers/chelsio/cxgb.rst +++ b/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst diff --git a/Documentation/networking/device_drivers/cirrus/cs89x0.rst b/Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst index e5c283940ac5..e5c283940ac5 100644 --- a/Documentation/networking/device_drivers/cirrus/cs89x0.rst +++ b/Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst diff --git a/Documentation/networking/device_drivers/davicom/dm9000.rst b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst index d5458da01083..d5458da01083 100644 --- a/Documentation/networking/device_drivers/davicom/dm9000.rst +++ b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst diff --git a/Documentation/networking/device_drivers/dec/de4x5.rst b/Documentation/networking/device_drivers/ethernet/dec/de4x5.rst index e03e9c631879..e03e9c631879 100644 --- a/Documentation/networking/device_drivers/dec/de4x5.rst +++ b/Documentation/networking/device_drivers/ethernet/dec/de4x5.rst diff --git a/Documentation/networking/device_drivers/dec/dmfe.rst b/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst index c4cf809cad84..c4cf809cad84 100644 --- a/Documentation/networking/device_drivers/dec/dmfe.rst +++ b/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst diff --git a/Documentation/networking/device_drivers/dlink/dl2k.rst b/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst index ccdb5d0d7460..ccdb5d0d7460 100644 --- a/Documentation/networking/device_drivers/dlink/dl2k.rst +++ b/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst index 241c6c6f6e68..241c6c6f6e68 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst index 17dbee1ac53e..c50fd46631e0 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst @@ -19,8 +19,10 @@ pool management for network interfaces. This document provides an overview the Linux DPIO driver, its subcomponents, and its APIs. -See Documentation/networking/device_drivers/freescale/dpaa2/overview.rst for -a general overview of DPAA2 and the general DPAA2 driver architecture in Linux. +See +Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst +for a general overview of DPAA2 and the general DPAA2 driver architecture +in Linux. Driver Overview --------------- diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst index cb4c9a0c5a17..682f3986c15b 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst @@ -33,7 +33,8 @@ hardware resources, like queues, do not have a corresponding MC object and are treated as internal resources of other objects. For a more detailed description of the DPAA2 architecture and its object -abstractions see *Documentation/networking/device_drivers/freescale/dpaa2/overview.rst*. +abstractions see +*Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst*. Each Linux net device is built on top of a Datapath Network Interface (DPNI) object and uses Buffer Pools (DPBPs), I/O Portals (DPIOs) and Concentrators diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/index.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst index ee40fcc5ddff..ee40fcc5ddff 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/index.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst index 51e6624fb774..51e6624fb774 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst index d638b5a8aadd..d638b5a8aadd 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst diff --git a/Documentation/networking/device_drivers/freescale/gianfar.rst b/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst index 9c4a91d3824b..9c4a91d3824b 100644 --- a/Documentation/networking/device_drivers/freescale/gianfar.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst diff --git a/Documentation/networking/device_drivers/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 793693cef6e3..793693cef6e3 100644 --- a/Documentation/networking/device_drivers/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst diff --git a/Documentation/networking/hinic.rst b/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst index 867ac8f4e04a..867ac8f4e04a 100644 --- a/Documentation/networking/hinic.rst +++ b/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst new file mode 100644 index 000000000000..cbb75a1818c0 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Ethernet Device Drivers +======================= + +Device drivers for Ethernet and Ethernet-based virtual function devices. + +Contents: + +.. toctree:: + :maxdepth: 2 + + 3com/3c509 + 3com/vortex + amazon/ena + altera/altera_tse + aquantia/atlantic + chelsio/cxgb + cirrus/cs89x0 + dlink/dl2k + davicom/dm9000 + dec/de4x5 + dec/dmfe + freescale/dpaa + freescale/dpaa2/index + freescale/gianfar + google/gve + huawei/hinic + intel/e100 + intel/e1000 + intel/e1000e + intel/fm10k + intel/igb + intel/igbvf + intel/ixgb + intel/ixgbe + intel/ixgbevf + intel/i40e + intel/iavf + intel/ice + marvell/octeontx2 + mellanox/mlx5 + microsoft/netvsc + neterion/s2io + neterion/vxge + netronome/nfp + pensando/ionic + smsc/smc9 + stmicro/stmmac + ti/cpsw + ti/cpsw_switchdev + ti/tlan + toshiba/spider_net + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/e100.rst b/Documentation/networking/device_drivers/ethernet/intel/e100.rst index 3ac21e7119a7..3d4a9ba21946 100644 --- a/Documentation/networking/device_drivers/intel/e100.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e100.rst @@ -41,7 +41,7 @@ Identifying Your Adapter For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Driver Configuration Parameters =============================== @@ -179,7 +179,7 @@ filtering by Support ======= For general information, go to the Intel support website at: -http://www.intel.com/support/ +https://www.intel.com/support/ or the Intel Wired Networking project hosted by Sourceforge at: http://sourceforge.net/projects/e1000 diff --git a/Documentation/networking/device_drivers/intel/e1000.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst index 4aaae0f7d6ba..4aaae0f7d6ba 100644 --- a/Documentation/networking/device_drivers/intel/e1000.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst diff --git a/Documentation/networking/device_drivers/intel/e1000e.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst index f49cd370e7bf..f49cd370e7bf 100644 --- a/Documentation/networking/device_drivers/intel/e1000e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst diff --git a/Documentation/networking/device_drivers/intel/fm10k.rst b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst index 4d279e64e221..9258ef6f515c 100644 --- a/Documentation/networking/device_drivers/intel/fm10k.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst @@ -22,7 +22,7 @@ Ethernet Multi-host Controller. For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Flow Control diff --git a/Documentation/networking/device_drivers/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 8a9b18573688..8a9b18573688 100644 --- a/Documentation/networking/device_drivers/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst diff --git a/Documentation/networking/device_drivers/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 84ac7e75f363..52e037b11c97 100644 --- a/Documentation/networking/device_drivers/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -43,7 +43,7 @@ device. For information on how to identify your adapter, and for the latest NVM/FW images and Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations diff --git a/Documentation/networking/device_drivers/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst index ee43ea57d443..ee43ea57d443 100644 --- a/Documentation/networking/device_drivers/intel/ice.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst diff --git a/Documentation/networking/device_drivers/intel/igb.rst b/Documentation/networking/device_drivers/ethernet/intel/igb.rst index 87e560fe5eaa..d46289e182cf 100644 --- a/Documentation/networking/device_drivers/intel/igb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igb.rst @@ -20,7 +20,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Command Line Parameters diff --git a/Documentation/networking/device_drivers/intel/igbvf.rst b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst index 557fc020ef31..40fa210c5e14 100644 --- a/Documentation/networking/device_drivers/intel/igbvf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst @@ -35,7 +35,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations diff --git a/Documentation/networking/device_drivers/intel/ixgb.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst index ab624f1a44a8..c6a233e68ad6 100644 --- a/Documentation/networking/device_drivers/intel/ixgb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgb.rst @@ -203,7 +203,7 @@ With the 10 Gigabit server adapters, the default Linux configuration will very likely limit the total available throughput artificially. There is a set of configuration changes that, when applied together, will increase the ability of Linux to transmit and receive data. The following enhancements were -originally acquired from settings published at http://www.spec.org/web99/ for +originally acquired from settings published at https://www.spec.org/web99/ for various submitted results using Linux. NOTE: diff --git a/Documentation/networking/device_drivers/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst index f1d5233e5e51..f1d5233e5e51 100644 --- a/Documentation/networking/device_drivers/intel/ixgbe.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst diff --git a/Documentation/networking/device_drivers/intel/ixgbevf.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst index 76bbde736f21..76bbde736f21 100644 --- a/Documentation/networking/device_drivers/intel/ixgbevf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst diff --git a/Documentation/networking/device_drivers/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index 88f508338c5f..88f508338c5f 100644 --- a/Documentation/networking/device_drivers/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst diff --git a/Documentation/networking/device_drivers/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index e9b65035cd47..e9b65035cd47 100644 --- a/Documentation/networking/device_drivers/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst diff --git a/Documentation/networking/device_drivers/microsoft/netvsc.rst b/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst index c3f51c672a68..c3f51c672a68 100644 --- a/Documentation/networking/device_drivers/microsoft/netvsc.rst +++ b/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst diff --git a/Documentation/networking/device_drivers/neterion/s2io.rst b/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst index c5673ec4559b..c5673ec4559b 100644 --- a/Documentation/networking/device_drivers/neterion/s2io.rst +++ b/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst diff --git a/Documentation/networking/device_drivers/neterion/vxge.rst b/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst index 589c6b15c63d..589c6b15c63d 100644 --- a/Documentation/networking/device_drivers/neterion/vxge.rst +++ b/Documentation/networking/device_drivers/ethernet/neterion/vxge.rst diff --git a/Documentation/networking/device_drivers/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst index ada611fb427c..ada611fb427c 100644 --- a/Documentation/networking/device_drivers/netronome/nfp.rst +++ b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst diff --git a/Documentation/networking/device_drivers/pensando/ionic.rst b/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst index 0eabbc347d6c..0eabbc347d6c 100644 --- a/Documentation/networking/device_drivers/pensando/ionic.rst +++ b/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst diff --git a/Documentation/networking/device_drivers/smsc/smc9.rst b/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst index e5eac896a631..e5eac896a631 100644 --- a/Documentation/networking/device_drivers/smsc/smc9.rst +++ b/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst diff --git a/Documentation/networking/device_drivers/stmicro/stmmac.rst b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst index 5d46e5036129..5d46e5036129 100644 --- a/Documentation/networking/device_drivers/stmicro/stmmac.rst +++ b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst diff --git a/Documentation/networking/device_drivers/ti/cpsw.rst b/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst index a88946bd188b..a88946bd188b 100644 --- a/Documentation/networking/device_drivers/ti/cpsw.rst +++ b/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst diff --git a/Documentation/networking/device_drivers/ti/cpsw_switchdev.rst b/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst index 1241ecac73bd..1241ecac73bd 100644 --- a/Documentation/networking/device_drivers/ti/cpsw_switchdev.rst +++ b/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst diff --git a/Documentation/networking/device_drivers/ti/tlan.rst b/Documentation/networking/device_drivers/ethernet/ti/tlan.rst index 4fdc0907f4fc..4fdc0907f4fc 100644 --- a/Documentation/networking/device_drivers/ti/tlan.rst +++ b/Documentation/networking/device_drivers/ethernet/ti/tlan.rst diff --git a/Documentation/networking/device_drivers/toshiba/spider_net.rst b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst index fe5b32be15cd..fe5b32be15cd 100644 --- a/Documentation/networking/device_drivers/toshiba/spider_net.rst +++ b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst diff --git a/Documentation/networking/defza.rst b/Documentation/networking/device_drivers/fddi/defza.rst index 73c2f793ea26..73c2f793ea26 100644 --- a/Documentation/networking/defza.rst +++ b/Documentation/networking/device_drivers/fddi/defza.rst diff --git a/Documentation/networking/device_drivers/fddi/index.rst b/Documentation/networking/device_drivers/fddi/index.rst new file mode 100644 index 000000000000..0b75294e6c8b --- /dev/null +++ b/Documentation/networking/device_drivers/fddi/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Fiber Distributed Data Interface (FDDI) Device Drivers +====================================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + defza + skfp + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/skfp.rst b/Documentation/networking/device_drivers/fddi/skfp.rst index 58f548105c1d..58f548105c1d 100644 --- a/Documentation/networking/skfp.rst +++ b/Documentation/networking/device_drivers/fddi/skfp.rst diff --git a/Documentation/networking/baycom.rst b/Documentation/networking/device_drivers/hamradio/baycom.rst index fe2d010f0e86..fe2d010f0e86 100644 --- a/Documentation/networking/baycom.rst +++ b/Documentation/networking/device_drivers/hamradio/baycom.rst diff --git a/Documentation/networking/device_drivers/hamradio/index.rst b/Documentation/networking/device_drivers/hamradio/index.rst new file mode 100644 index 000000000000..7e731732057b --- /dev/null +++ b/Documentation/networking/device_drivers/hamradio/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Amateur Radio Device Drivers +============================ + +Contents: + +.. toctree:: + :maxdepth: 2 + + baycom + z8530drv + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/z8530drv.rst b/Documentation/networking/device_drivers/hamradio/z8530drv.rst index d2942760f167..d2942760f167 100644 --- a/Documentation/networking/z8530drv.rst +++ b/Documentation/networking/device_drivers/hamradio/z8530drv.rst diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index e18dad11bc72..a3113ffd7a16 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -1,56 +1,22 @@ .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -Vendor Device Drivers -===================== +Hardware Device Drivers +======================= Contents: .. toctree:: :maxdepth: 2 - freescale/dpaa2/index - intel/e100 - intel/e1000 - intel/e1000e - intel/fm10k - intel/igb - intel/igbvf - intel/ixgb - intel/ixgbe - intel/ixgbevf - intel/i40e - intel/iavf - intel/ice - google/gve - marvell/octeontx2 - mellanox/mlx5 - netronome/nfp - pensando/ionic - stmicro/stmmac - 3com/3c509 - 3com/vortex - amazon/ena - aquantia/atlantic - chelsio/cxgb - cirrus/cs89x0 - davicom/dm9000 - dec/de4x5 - dec/dmfe - dlink/dl2k - freescale/dpaa - freescale/gianfar - intel/ipw2100 - intel/ipw2200 - microsoft/netvsc - neterion/s2io - neterion/vxge - qualcomm/rmnet - sb1000 - smsc/smc9 - ti/cpsw_switchdev - ti/cpsw - ti/tlan - toshiba/spider_net + appletalk/index + atm/index + cable/index + cellular/index + ethernet/index + fddi/index + hamradio/index + wan/index + wifi/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/wan/index.rst b/Documentation/networking/device_drivers/wan/index.rst new file mode 100644 index 000000000000..9d9ae94f00b4 --- /dev/null +++ b/Documentation/networking/device_drivers/wan/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Classic WAN Device Drivers +========================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + z8530book + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/z8530book.rst b/Documentation/networking/device_drivers/wan/z8530book.rst index fea2c40e7973..fea2c40e7973 100644 --- a/Documentation/networking/z8530book.rst +++ b/Documentation/networking/device_drivers/wan/z8530book.rst diff --git a/Documentation/networking/device_drivers/wifi/index.rst b/Documentation/networking/device_drivers/wifi/index.rst new file mode 100644 index 000000000000..bf91a87c7acf --- /dev/null +++ b/Documentation/networking/device_drivers/wifi/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Wi-Fi Device Drivers +==================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + intel/ipw2100 + intel/ipw2200 + ray_cs + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/ipw2100.rst b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst index d54ad522f937..883e96355799 100644 --- a/Documentation/networking/device_drivers/intel/ipw2100.rst +++ b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst @@ -78,7 +78,7 @@ such, if you are interested in deploying or shipping a driver as part of solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: -http://www.intel.com/support/wireless/sb/CS-006408.htm +https://www.intel.com/support/wireless/sb/CS-006408.htm 1. Introduction =============== diff --git a/Documentation/networking/device_drivers/intel/ipw2200.rst b/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst index 0cb42d2fd7e5..0cb42d2fd7e5 100644 --- a/Documentation/networking/device_drivers/intel/ipw2200.rst +++ b/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst diff --git a/Documentation/networking/ray_cs.rst b/Documentation/networking/device_drivers/wifi/ray_cs.rst index 9a46d1ae8f20..9a46d1ae8f20 100644 --- a/Documentation/networking/ray_cs.rst +++ b/Documentation/networking/device_drivers/wifi/ray_cs.rst diff --git a/Documentation/networking/devlink/devlink-info.rst b/Documentation/networking/devlink/devlink-info.rst index 3fe11401b838..7572bf6de5c1 100644 --- a/Documentation/networking/devlink/devlink-info.rst +++ b/Documentation/networking/devlink/devlink-info.rst @@ -44,9 +44,11 @@ versions is generally discouraged - here, and via any other Linux API. reported for two ports of the same device or on two hosts of a multi-host device should be identical. - .. note:: ``devlink-info`` API should be extended with a new field - if devices want to report board/product serial number (often - reported in PCI *Vital Product Data* capability). + * - ``board.serial_number`` + - Board serial number of the device. + + This is usually the serial number of the board, often available in + PCI *Vital Product Data*. * - ``fixed`` - Group for hardware identifiers, and versions of components @@ -201,10 +203,6 @@ Future work The following extensions could be useful: - - product serial number - NIC boards often get labeled with a board serial - number rather than ASIC serial number; it'd be useful to add board serial - numbers to the API if they can be retrieved from the device; - - on-disk firmware file names - drivers list the file names of firmware they may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These, however, are per module, rather than per device. It'd be useful to list diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index 2014307fbe63..7a798352b45d 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -405,6 +405,10 @@ be added to the following table: - ``control`` - Traps packets logged during processing of flow action trap (e.g., via tc's trap action) + * - ``early_drop`` + - ``drop`` + - Traps packets dropped due to the RED (Random Early Detection) algorithm + (i.e., early drops) Driver-specific Packet Traps ============================ diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 72ea8d295724..237848d56f9b 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -84,8 +84,20 @@ The ``ice`` driver reports the following versions Regions ======= -The ``ice`` driver enables access to the contents of the Non Volatile Memory -flash chip via the ``nvm-flash`` region. +The ``ice`` driver implements the following regions for accessing internal +device data. + +.. list-table:: regions implemented + :widths: 15 85 + + * - Name + - Description + * - ``nvm-flash`` + - The contents of the entire flash chip, sometimes referred to as + the device's Non Volatile Memory. + * - ``device-caps`` + - The contents of the device firmware's capabilities buffer. Useful to + determine the current state and configuration of the device. Users can request an immediate capture of a snapshot via the ``DEVLINK_CMD_REGION_NEW`` @@ -105,3 +117,42 @@ Users can request an immediate capture of a snapshot via the 0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30 $ devlink region delete pci/0000:01:00.0/nvm-flash snapshot 1 + + $ devlink region new pci/0000:01:00.0/device-caps snapshot 1 + $ devlink region dump pci/0000:01:00.0/device-caps snapshot 1 + 0000000000000000 01 00 01 00 00 00 00 00 01 00 00 00 00 00 00 00 + 0000000000000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000020 02 00 02 01 32 03 00 00 0a 00 00 00 25 00 00 00 + 0000000000000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000040 04 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000060 05 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000080 06 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000a0 08 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000c0 12 00 01 00 01 00 00 00 01 00 01 00 00 00 00 00 + 00000000000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000000e0 13 00 01 00 00 01 00 00 00 00 00 00 00 00 00 00 + 00000000000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000100 14 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000120 15 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000140 16 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000160 17 00 01 00 06 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000180 18 00 01 00 01 00 00 00 01 00 00 00 08 00 00 00 + 0000000000000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001a0 22 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001c0 40 00 01 00 00 08 00 00 08 00 00 00 00 00 00 00 + 00000000000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00000000000001e0 41 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00 + 00000000000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 0000000000000200 42 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00 + 0000000000000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + $ devlink region delete pci/0000:01:00.0/device-caps snapshot 1 diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 82470c36c27a..d53bcb31645a 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -443,10 +443,11 @@ supports. LINKSTATE_GET ============= -Requests link state information. At the moment, only link up/down flag (as -provided by ``ETHTOOL_GLINK`` ioctl command) is provided but some future -extensions are planned (e.g. link down reason). This request does not have any -attributes. +Requests link state information. Link up/down flag (as provided by +``ETHTOOL_GLINK`` ioctl command) is provided. Optionally, extended state might +be provided as well. In general, extended state describes reasons for why a port +is down, or why it operates in some non-obvious mode. This request does not have +any attributes. Request contents: @@ -461,16 +462,135 @@ Kernel response contents: ``ETHTOOL_A_LINKSTATE_LINK`` bool link state (up/down) ``ETHTOOL_A_LINKSTATE_SQI`` u32 Current Signal Quality Index ``ETHTOOL_A_LINKSTATE_SQI_MAX`` u32 Max support SQI value + ``ETHTOOL_A_LINKSTATE_EXT_STATE`` u8 link extended state + ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` u8 link extended substate ==================================== ====== ============================ For most NIC drivers, the value of ``ETHTOOL_A_LINKSTATE_LINK`` returns carrier flag provided by ``netif_carrier_ok()`` but there are drivers which define their own handler. +``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` are +optional values. ethtool core can provide either both +``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE``, +or only ``ETHTOOL_A_LINKSTATE_EXT_STATE``, or none of them. + ``LINKSTATE_GET`` allows dump requests (kernel returns reply messages for all devices supporting the request). +Link extended states: + + ================================================ ============================================ + ``ETHTOOL_LINK_EXT_STATE_AUTONEG`` States relating to the autonegotiation or + issues therein + + ``ETHTOOL_LINK_EXT_STATE_LINK_TRAINING_FAILURE`` Failure during link training + + ``ETHTOOL_LINK_EXT_STATE_LINK_LOGICAL_MISMATCH`` Logical mismatch in physical coding sublayer + or forward error correction sublayer + + ``ETHTOOL_LINK_EXT_STATE_BAD_SIGNAL_INTEGRITY`` Signal integrity issues + + ``ETHTOOL_LINK_EXT_STATE_NO_CABLE`` No cable connected + + ``ETHTOOL_LINK_EXT_STATE_CABLE_ISSUE`` Failure is related to cable, + e.g., unsupported cable + + ``ETHTOOL_LINK_EXT_STATE_EEPROM_ISSUE`` Failure is related to EEPROM, e.g., failure + during reading or parsing the data + + ``ETHTOOL_LINK_EXT_STATE_CALIBRATION_FAILURE`` Failure during calibration algorithm + + ``ETHTOOL_LINK_EXT_STATE_POWER_BUDGET_EXCEEDED`` The hardware is not able to provide the + power required from cable or module + + ``ETHTOOL_LINK_EXT_STATE_OVERHEAT`` The module is overheated + ================================================ ============================================ + +Link extended substates: + + Autoneg substates: + + =============================================================== ================================ + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED`` Peer side is down + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_ACK_NOT_RECEIVED`` Ack not received from peer side + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NEXT_PAGE_EXCHANGE_FAILED`` Next page exchange failed + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED_FORCE_MODE`` Peer side is down during force + mode or there is no agreement of + speed + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_FEC_MISMATCH_DURING_OVERRIDE`` Forward error correction modes + in both sides are mismatched + + ``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_HCD`` No Highest Common Denominator + =============================================================== ================================ + + Link training substates: + + =========================================================================== ==================== + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_FRAME_LOCK_NOT_ACQUIRED`` Frames were not + recognized, the + lock failed + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_INHIBIT_TIMEOUT`` The lock did not + occur before + timeout + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_PARTNER_DID_NOT_SET_RECEIVER_READY`` Peer side did not + send ready signal + after training + process + + ``ETHTOOL_LINK_EXT_SUBSTATE_LT_REMOTE_FAULT`` Remote side is not + ready yet + =========================================================================== ==================== + + Link logical mismatch substates: + + ================================================================ =============================== + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_BLOCK_LOCK`` Physical coding sublayer was + not locked in first phase - + block lock + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_AM_LOCK`` Physical coding sublayer was + not locked in second phase - + alignment markers lock + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_GET_ALIGN_STATUS`` Physical coding sublayer did + not get align status + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_FC_FEC_IS_NOT_LOCKED`` FC forward error correction is + not locked + + ``ETHTOOL_LINK_EXT_SUBSTATE_LLM_RS_FEC_IS_NOT_LOCKED`` RS forward error correction is + not locked + ================================================================ =============================== + + Bad signal integrity substates: + + ================================================================= ============================= + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_LARGE_NUMBER_OF_PHYSICAL_ERRORS`` Large number of physical + errors + + ``ETHTOOL_LINK_EXT_SUBSTATE_BSI_UNSUPPORTED_RATE`` The system attempted to + operate the cable at a rate + that is not formally + supported, which led to + signal integrity issues + ================================================================= ============================= + + Cable issue substates: + + =================================================== ============================================ + ``ETHTOOL_LINK_EXT_SUBSTATE_CI_UNSUPPORTED_CABLE`` Unsupported cable + + ``ETHTOOL_LINK_EXT_SUBSTATE_CI_CABLE_TEST_FAILURE`` Cable test failure + =================================================== ============================================ + DEBUG_GET ========= @@ -1110,6 +1230,42 @@ used to report the amplitude of the reflection for a given pair. | | | ``ETHTOOL_A_CABLE_AMPLITUDE_mV`` | s16 | Reflection amplitude | +-+-+-----------------------------------------+--------+----------------------+ +TUNNEL_INFO +=========== + +Gets information about the tunnel state NIC is aware of. + +Request contents: + + ===================================== ====== ========================== + ``ETHTOOL_A_TUNNEL_INFO_HEADER`` nested request header + ===================================== ====== ========================== + +Kernel response contents: + + +---------------------------------------------+--------+---------------------+ + | ``ETHTOOL_A_TUNNEL_INFO_HEADER`` | nested | reply header | + +---------------------------------------------+--------+---------------------+ + | ``ETHTOOL_A_TUNNEL_INFO_UDP_PORTS`` | nested | all UDP port tables | + +-+-------------------------------------------+--------+---------------------+ + | | ``ETHTOOL_A_TUNNEL_UDP_TABLE`` | nested | one UDP port table | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_SIZE`` | u32 | max size of the | + | | | | | table | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` | bitset | tunnel types which | + | | | | | table can hold | + +-+-+-----------------------------------------+--------+---------------------+ + | | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_ENTRY`` | nested | offloaded UDP port | + +-+-+-+---------------------------------------+--------+---------------------+ + | | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_PORT`` | be16 | UDP port | + +-+-+-+---------------------------------------+--------+---------------------+ + | | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_TYPE`` | u32 | tunnel type | + +-+-+-+---------------------------------------+--------+---------------------+ + +For UDP tunnel table empty ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` indicates that +the table contains static entries, hard-coded by the NIC. + Request translation =================== diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index a1d3e192b9fa..debb59e374de 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -1,5 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +.. _networking-filter: + ======================================================= Linux Socket Filtering aka Berkeley Packet Filter (BPF) ======================================================= diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 0186e276690a..c29496fff81c 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -20,7 +20,6 @@ Contents: ieee802154 j1939 kapi - z8530book msg_zerocopy failover net_dim @@ -39,36 +38,28 @@ Contents: nfc 6lowpan 6pack - altera_tse arcnet-hardware arcnet atm ax25 - baycom bonding cdc_mbim - cops - cxacru dccp dctcp decnet - defza dns_resolver driver eql fib_trie filter - fore200e framerelay generic-hdlc generic_netlink gen_stats gtp - hinic ila ipddp ip_dynaddr - iphase ipsec ip-sysctl ipv6 @@ -77,7 +68,6 @@ Contents: kcm l2tp lapb-module - ltpc mac80211-injection mpls-sysctl multiqueue @@ -97,14 +87,12 @@ Contents: ppp_generic proc_net_tcp radiotap-headers - ray_cs rds regulatory rxrpc sctp secid seg6-sysctl - skfp strparser switchdev tc-actions-env-rules @@ -122,7 +110,6 @@ Contents: xfrm_proc xfrm_sync xfrm_sysctl - z8530drv .. only:: subproject and html diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index 1adead6a4527..03f7beade470 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -589,3 +589,168 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. + +3.2 Special considerations for stacked PTP Hardware Clocks +---------------------------------------------------------- + +There are situations when there may be more than one PHC (PTP Hardware Clock) +in the data path of a packet. The kernel has no explicit mechanism to allow the +user to select which PHC to use for timestamping Ethernet frames. Instead, the +assumption is that the outermost PHC is always the most preferable, and that +kernel drivers collaborate towards achieving that goal. Currently there are 3 +cases of stacked PHCs, detailed below: + +3.2.1 DSA (Distributed Switch Architecture) switches +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These are Ethernet switches which have one of their ports connected to an +(otherwise completely unaware) host Ethernet interface, and perform the role of +a port multiplier with optional forwarding acceleration features. Each DSA +switch port is visible to the user as a standalone (virtual) network interface, +and its network I/O is performed, under the hood, indirectly through the host +interface (redirecting to the host port on TX, and intercepting frames on RX). + +When a DSA switch is attached to a host port, PTP synchronization has to +suffer, since the switch's variable queuing delay introduces a path delay +jitter between the host port and its PTP partner. For this reason, some DSA +switches include a timestamping clock of their own, and have the ability to +perform network timestamping on their own MAC, such that path delays only +measure wire and PHY propagation latencies. Timestamping DSA switches are +supported in Linux and expose the same ABI as any other network interface (save +for the fact that the DSA interfaces are in fact virtual in terms of network +I/O, they do have their own PHC). It is typical, but not mandatory, for all +interfaces of a DSA switch to share the same PHC. + +By design, PTP timestamping with a DSA switch does not need any special +handling in the driver for the host port it is attached to. However, when the +host port also supports PTP timestamping, DSA will take care of intercepting +the ``.ndo_do_ioctl`` calls towards the host port, and block attempts to enable +hardware timestamping on it. This is because the SO_TIMESTAMPING API does not +allow the delivery of multiple hardware timestamps for the same packet, so +anybody else except for the DSA switch port must be prevented from doing so. + +In code, DSA provides for most of the infrastructure for timestamping already, +in generic code: a BPF classifier (``ptp_classify_raw``) is used to identify +PTP event messages (any other packets, including PTP general messages, are not +timestamped), and provides two hooks to drivers: + +- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb + to be transmitted, before actually transmitting it. Typically, a switch will + have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp + becomes available. There may be an IRQ that is raised upon this timestamp's + availability, or the driver might have to poll after invoking + ``dev_queue_xmit()`` towards the host interface. Either way, in the + ``.port_txtstamp()`` method, the driver only needs to save the clone for + later use (when the timestamp becomes available). Each skb is annotated with + a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's + job of keeping track of which clone belongs to which skb. + +- ``.port_rxtstamp()``: The original (and only) timestampable skb is provided + to the driver, for it to annotate it with a timestamp, if that is immediately + available, or defer to later. On reception, timestamps might either be + available in-band (through metadata in the DSA header, or attached in other + ways to the packet), or out-of-band (through another RX timestamping FIFO). + Deferral on RX is typically necessary when retrieving the timestamp needs a + sleepable context. In that case, it is the responsibility of the DSA driver + to call ``netif_rx_ni()`` on the freshly timestamped skb. + +3.2.2 Ethernet PHYs +^^^^^^^^^^^^^^^^^^^ + +These are devices that typically fulfill a Layer 1 role in the network stack, +hence they do not have a representation in terms of a network interface as DSA +switches do. However, PHYs may be able to detect and timestamp PTP packets, for +performance reasons: timestamps taken as close as possible to the wire have the +potential to yield a more stable and precise synchronization. + +A PHY driver that supports PTP timestamping must create a ``struct +mii_timestamper`` and add a pointer to it in ``phydev->mii_ts``. The presence +of this pointer will be checked by the networking stack. + +Since PHYs do not have network interface representations, the timestamping and +ethtool ioctl operations for them need to be mediated by their respective MAC +driver. Therefore, as opposed to DSA switches, modifications need to be done +to each individual MAC driver for PHY timestamping support. This entails: + +- Checking, in ``.ndo_do_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)`` + is true or not. If it is, then the MAC driver should not process this request + but instead pass it on to the PHY using ``phy_mii_ioctl()``. + +- On RX, special intervention may or may not be needed, depending on the + function used to deliver skb's up the network stack. In the case of plain + ``netif_rx()`` and similar, MAC drivers must check whether + ``skb_defer_rx_timestamp(skb)`` is necessary or not - and if it is, don't + call ``netif_rx()`` at all. If ``CONFIG_NETWORK_PHY_TIMESTAMPING`` is + enabled, and ``skb->dev->phydev->mii_ts`` exists, its ``.rxtstamp()`` hook + will be called now, to determine, using logic very similar to DSA, whether + deferral for RX timestamping is necessary. Again like DSA, it becomes the + responsibility of the PHY driver to send the packet up the stack when the + timestamp is available. + + For other skb receive functions, such as ``napi_gro_receive`` and + ``netif_receive_skb``, the stack automatically checks whether + ``skb_defer_rx_timestamp()`` is necessary, so this check is not needed inside + the driver. + +- On TX, again, special intervention might or might not be needed. The + function that calls the ``mii_ts->txtstamp()`` hook is named + ``skb_clone_tx_timestamp()``. This function can either be called directly + (case in which explicit MAC driver support is indeed needed), but the + function also piggybacks from the ``skb_tx_timestamp()`` call, which many MAC + drivers already perform for software timestamping purposes. Therefore, if a + MAC supports software timestamping, it does not need to do anything further + at this stage. + +3.2.3 MII bus snooping devices +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These perform the same role as timestamping Ethernet PHYs, save for the fact +that they are discrete devices and can therefore be used in conjunction with +any PHY even if it doesn't support timestamping. In Linux, they are +discoverable and attachable to a ``struct phy_device`` through Device Tree, and +for the rest, they use the same mii_ts infrastructure as those. See +Documentation/devicetree/bindings/ptp/timestamper.txt for more details. + +3.2.4 Other caveats for MAC drivers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Stacked PHCs, especially DSA (but not only) - since that doesn't require any +modification to MAC drivers, so it is more difficult to ensure correctness of +all possible code paths - is that they uncover bugs which were impossible to +trigger before the existence of stacked PTP clocks. One example has to do with +this line of code, already presented earlier:: + + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS; + +Any TX timestamping logic, be it a plain MAC driver, a DSA switch driver, a PHY +driver or a MII bus snooping device driver, should set this flag. +But a MAC driver that is unaware of PHC stacking might get tripped up by +somebody other than itself setting this flag, and deliver a duplicate +timestamp. +For example, a typical driver design for TX timestamping might be to split the +transmission part into 2 portions: + +1. "TX": checks whether PTP timestamping has been previously enabled through + the ``.ndo_do_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the + current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags & + SKBTX_HW_TSTAMP``"). If this is true, it sets the + "``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as + described above, in the case of a stacked PHC system, this condition should + never trigger, as this MAC is certainly not the outermost PHC. But this is + not where the typical issue is. Transmission proceeds with this packet. + +2. "TX confirmation": Transmission has finished. The driver checks whether it + is necessary to collect any TX timestamp for it. Here is where the typical + issues are: the MAC driver takes a shortcut and only checks whether + "``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``" was set. With a stacked + PHC system, this is incorrect because this MAC driver is not the only entity + in the TX data path who could have enabled SKBTX_IN_PROGRESS in the first + place. + +The correct solution for this problem is for MAC drivers to have a compound +check in their "TX confirmation" portion, not only for +"``skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS``", but also for +"``priv->hwtstamp_tx_enabled == true``". Because the rest of the system ensures +that PTP timestamping is not enabled for anything other than the outermost PHC, +this enhanced check will avoid delivering a duplicated TX timestamp to user +space. diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst index f914e81fd3a6..37773da2bee5 100644 --- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst @@ -428,6 +428,24 @@ by the driver: which were part of a TLS stream. * ``rx_tls_decrypted_bytes`` - number of TLS payload bytes in RX packets which were successfully decrypted. + * ``rx_tls_ctx`` - number of TLS RX HW offload contexts added to device for + decryption. + * ``rx_tls_del`` - number of TLS RX HW offload contexts deleted from device + (connection has finished). + * ``rx_tls_resync_req_pkt`` - number of received TLS packets with a resync + request. + * ``rx_tls_resync_req_start`` - number of times the TLS async resync request + was started. + * ``rx_tls_resync_req_end`` - number of times the TLS async resync request + properly ended with providing the HW tracked tcp-seq. + * ``rx_tls_resync_req_skip`` - number of times the TLS async resync request + procedure was started by not properly ended. + * ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to + the driver was successfully handled. + * ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to + the driver was terminated unsuccessfully. + * ``rx_tls_err`` - number of RX packets which were part of a TLS stream + but were not decrypted due to unexpected error in the state machine. * ``tx_tls_encrypted_packets`` - number of TX packets passed to the device for encryption of their TLS payload. * ``tx_tls_encrypted_bytes`` - number of TLS payload bytes in TX packets 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/usb/gadget_hid.rst b/Documentation/usb/gadget_hid.rst index 098d563040cc..e623416de4f1 100644 --- a/Documentation/usb/gadget_hid.rst +++ b/Documentation/usb/gadget_hid.rst @@ -11,7 +11,7 @@ and HID reports can be sent/received through I/O on the /dev/hidgX character devices. For more details about HID, see the developer page on -http://www.usb.org/developers/hidpage/ +https://www.usb.org/developers/hidpage/ Configuration ============= diff --git a/Documentation/usb/gadget_multi.rst b/Documentation/usb/gadget_multi.rst index 9806b55af301..3a22c1b2f39e 100644 --- a/Documentation/usb/gadget_multi.rst +++ b/Documentation/usb/gadget_multi.rst @@ -142,7 +142,7 @@ Footnotes ========= [1] Remote Network Driver Interface Specification, -[[http://msdn.microsoft.com/en-us/library/ee484414.aspx]]. +[[https://msdn.microsoft.com/en-us/library/ee484414.aspx]]. [2] Communications Device Class Abstract Control Model, spec for this and other USB classes can be found at @@ -150,9 +150,9 @@ and other USB classes can be found at [3] CDC Ethernet Control Model. -[4] [[http://msdn.microsoft.com/en-us/library/ff537109(v=VS.85).aspx]] +[4] [[https://msdn.microsoft.com/en-us/library/ff537109(v=VS.85).aspx]] -[5] [[http://msdn.microsoft.com/en-us/library/ff539234(v=VS.85).aspx]] +[5] [[https://msdn.microsoft.com/en-us/library/ff539234(v=VS.85).aspx]] [6] To put it in some other nice words, Windows failed to respond to any user input. @@ -160,6 +160,6 @@ any user input. [7] You may find [[http://www.cygnal.org/ubb/Forum9/HTML/001050.html]] useful. -[8] http://www.nirsoft.net/utils/usb_devices_view.html +[8] https://www.nirsoft.net/utils/usb_devices_view.html -[9] [[http://msdn.microsoft.com/en-us/library/ff570620.aspx]] +[9] [[https://msdn.microsoft.com/en-us/library/ff570620.aspx]] diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index 4ffa715b0ae8..c569ac6bec58 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf @@ -1,5 +1,5 @@ ; Based on template INF file found at -; <http://msdn.microsoft.com/en-us/library/ff570620.aspx> +; <https://msdn.microsoft.com/en-us/library/ff570620.aspx> ; which was: ; Copyright (c) Microsoft Corporation ; and released under the MLPL as found at: 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. |