Merge branch 'linus' into timers/core
Make sure the upstream fixes are applied before adding further modifications.
This commit is contained in:
Thomas Gleixner
commit
c3b5d3cea5
11
CREDITS
11
CREDITS
|
|
@ -2049,6 +2049,10 @@ D: pirq addr, CS5535 alsa audio driver
|
|||
S: Gurgaon, India
|
||||
S: Kuala Lumpur, Malaysia
|
||||
|
||||
N: Mohit Kumar
|
||||
D: ST Microelectronics SPEAr13xx PCI host bridge driver
|
||||
D: Synopsys Designware PCI host bridge driver
|
||||
|
||||
N: Gabor Kuti
|
||||
M: seasons@falcon.sch.bme.hu
|
||||
M: seasons@makosteszta.sote.hu
|
||||
|
|
@ -3705,6 +3709,13 @@ N: Dirk Verworner
|
|||
D: Co-author of German book ``Linux-Kernel-Programmierung''
|
||||
D: Co-founder of Berlin Linux User Group
|
||||
|
||||
N: Andrew Victor
|
||||
E: linux@maxim.org.za
|
||||
W: http://maxim.org.za/at91_26.html
|
||||
D: First maintainer of Atmel ARM-based SoC, aka AT91
|
||||
D: Introduced support for at91rm9200, the first chip of AT91 family
|
||||
S: South Africa
|
||||
|
||||
N: Riku Voipio
|
||||
E: riku.voipio@iki.fi
|
||||
D: Author of PCA9532 LED and Fintek f75375s hwmon driver
|
||||
|
|
|
|||
|
|
@ -222,3 +222,13 @@ Description:
|
|||
The number of blocks that are marked as reserved, if any, in
|
||||
this partition. These are typically used to store the in-flash
|
||||
bad block table (BBT).
|
||||
|
||||
What: /sys/class/mtd/mtdX/offset
|
||||
Date: March 2015
|
||||
KernelVersion: 4.1
|
||||
Contact: linux-mtd@lists.infradead.org
|
||||
Description:
|
||||
For a partition, the offset of that partition from the start
|
||||
of the master device in bytes. This attribute is absent on
|
||||
main devices, so it can be used to distinguish between
|
||||
partitions and devices that aren't partitions.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,11 @@ Description: This file controls the keyboard backlight operation mode, valid
|
|||
* 0x2 -> AUTO (also called TIMER)
|
||||
* 0x8 -> ON
|
||||
* 0x10 -> OFF
|
||||
Note that the kernel 3.16 onwards this file accepts all listed
|
||||
Note that from kernel 3.16 onwards this file accepts all listed
|
||||
parameters, kernel 3.15 only accepts the first two (FN-Z and
|
||||
AUTO).
|
||||
Also note that toggling this value on type 1 devices, requires
|
||||
a reboot for changes to take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
|
||||
|
|
@ -67,15 +69,72 @@ Description: This file shows the current keyboard backlight type,
|
|||
* 2 -> Type 2, supporting modes TIMER, ON and OFF
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Sleep & Charge charging mode, which
|
||||
can be:
|
||||
* 0 -> Disabled (0x00)
|
||||
* 1 -> Alternate (0x09)
|
||||
* 2 -> Auto (0x21)
|
||||
* 3 -> Typical (0x11)
|
||||
Note that from kernel 4.1 onwards this file accepts all listed
|
||||
values, kernel 4.0 only supports the first three.
|
||||
Note that this feature only works when connected to power, if
|
||||
you want to use it under battery, see the entry named
|
||||
"sleep_functions_on_battery"
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Sleep Functions under battery, and
|
||||
set the level at which point they will be disabled, accepted
|
||||
values can be:
|
||||
* 0 -> Disabled
|
||||
* 1-100 -> Battery level to disable sleep functions
|
||||
Currently it prints two values, the first one indicates if the
|
||||
feature is enabled or disabled, while the second one shows the
|
||||
current battery level set.
|
||||
Note that when the value is set to disabled, the sleep function
|
||||
will only work when connected to power.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the USB Rapid Charge state, which can be:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
|
||||
Date: January 23, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Sleep & Music state, which values can be:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that this feature only works when connected to power, if
|
||||
you want to use it under battery, see the entry named
|
||||
"sleep_functions_on_battery"
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file shows the current version of the driver
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the state of the internal fan, valid
|
||||
values are:
|
||||
|
|
@ -83,8 +142,8 @@ Description: This file controls the state of the internal fan, valid
|
|||
* 1 -> ON
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Special Functions (hotkeys) operation
|
||||
mode, valid values are:
|
||||
|
|
@ -94,21 +153,29 @@ Description: This file controls the Special Functions (hotkeys) operation
|
|||
and the hotkeys are accessed via FN-F{1-12}.
|
||||
In the "Special Functions" mode, the F{1-12} keys trigger the
|
||||
hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls whether the laptop should turn ON whenever
|
||||
the LID is opened, valid values are:
|
||||
* 0 -> Disabled
|
||||
* 1 -> Enabled
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
|
||||
Date: February, 2015
|
||||
KernelVersion: 3.20
|
||||
Date: February 12, 2015
|
||||
KernelVersion: 4.0
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls whether the USB 3 functionality, valid
|
||||
values are:
|
||||
Description: This file controls the USB 3 functionality, valid values are:
|
||||
* 0 -> Disabled (Acts as a regular USB 2)
|
||||
* 1 -> Enabled (Full USB 3 functionality)
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
What: /sys/class/leds/dell::kbd_backlight/als_enabled
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the automatic keyboard
|
||||
illumination mode on some systems that have an ambient
|
||||
light sensor. Write 1 to this file to enable the auto
|
||||
mode, 0 to disable it.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/als_setting
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to specifiy the on/off threshold value,
|
||||
as reported by the ambient light sensor.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to control the input triggers that
|
||||
turn on the keyboard backlight illumination that is
|
||||
disabled because of inactivity.
|
||||
Read the file to see the triggers available. The ones
|
||||
enabled are preceded by '+', those disabled by '-'.
|
||||
|
||||
To enable a trigger, write its name preceded by '+' to
|
||||
this file. To disable a trigger, write its name preceded
|
||||
by '-' instead.
|
||||
|
||||
For example, to enable the keyboard as trigger run:
|
||||
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
To disable it:
|
||||
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
|
||||
|
||||
Note that not all the available triggers can be configured.
|
||||
|
||||
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
Date: December 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
|
||||
Pali Rohár <pali.rohar@gmail.com>
|
||||
Description:
|
||||
This file allows to specify the interval after which the
|
||||
keyboard illumination is disabled because of inactivity.
|
||||
The timeouts are expressed in seconds, minutes, hours and
|
||||
days, for which the symbols are 's', 'm', 'h' and 'd'
|
||||
respectively.
|
||||
|
||||
To configure the timeout, write to this file a value along
|
||||
with any the above units. If no unit is specified, the value
|
||||
is assumed to be expressed in seconds.
|
||||
|
||||
For example, to set the timeout to 10 minutes run:
|
||||
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
|
||||
|
||||
Note that when this file is read, the returned value might be
|
||||
expressed in a different unit than the one used when the timeout
|
||||
was set.
|
||||
|
||||
Also note that only some timeouts are supported and that
|
||||
some systems might fall back to a specific timeout in case
|
||||
an invalid timeout is written to this file.
|
||||
|
|
@ -2491,7 +2491,7 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</listitem>
|
||||
<listitem>
|
||||
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
|
||||
changes flag. See <xref linkend="changes-flags"/>.</para>
|
||||
changes flag. See <xref linkend="ctrl-changes-flags"/>.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
|
|
|||
|
|
@ -143,86 +143,28 @@
|
|||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>v4l</structfield></entry>
|
||||
<entry><structfield>dev</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for V4L sub-devices and nodes only.</entry>
|
||||
<entry>Valid for (sub-)devices that create a single device node.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>V4L device node major number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
<entry>Device node major number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>V4L device node minor number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>fb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for frame buffer nodes only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>Frame buffer device node major number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>Frame buffer device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>alsa</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for ALSA devices only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>card</structfield></entry>
|
||||
<entry>ALSA card number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>device</structfield></entry>
|
||||
<entry>ALSA device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>subdevice</structfield></entry>
|
||||
<entry>ALSA sub-device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>int</entry>
|
||||
<entry><structfield>dvb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>DVB card number</entry>
|
||||
<entry>Device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw</structfield>[180]</entry>
|
||||
<entry><structfield>raw</structfield>[184]</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
|
|
@ -253,8 +195,24 @@
|
|||
<entry>ALSA card</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
|
||||
<entry>DVB card</entry>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
|
||||
<entry>DVB frontend devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
|
||||
<entry>DVB demux devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
|
||||
<entry>DVB DVR devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
|
||||
<entry>DVB CAM devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
|
||||
<entry>DVB network devnode</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
|
||||
|
|
@ -282,6 +240,10 @@
|
|||
it in some digital video standard, with appropriate embedded timing
|
||||
signals.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
|
||||
<entry>TV and/or radio tuner</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -303,45 +303,6 @@ for a pixel lie next to each other in memory.</para>
|
|||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR24">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
|
||||
<entry>'BGR3'</entry>
|
||||
|
|
@ -404,6 +365,46 @@ for a pixel lie next to each other in memory.</para>
|
|||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-ABGR32">
|
||||
<entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry>
|
||||
<entry>'AR24'</entry>
|
||||
|
|
|
|||
|
|
@ -38,10 +38,10 @@ columns and rows.</para>
|
|||
</row>
|
||||
<row>
|
||||
<entry>start + 4:</entry>
|
||||
<entry>R<subscript>10</subscript></entry>
|
||||
<entry>B<subscript>11</subscript></entry>
|
||||
<entry>R<subscript>12</subscript></entry>
|
||||
<entry>B<subscript>13</subscript></entry>
|
||||
<entry>B<subscript>10</subscript></entry>
|
||||
<entry>G<subscript>11</subscript></entry>
|
||||
<entry>B<subscript>12</subscript></entry>
|
||||
<entry>G<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
|
|
@ -52,10 +52,10 @@ columns and rows.</para>
|
|||
</row>
|
||||
<row>
|
||||
<entry>start + 12:</entry>
|
||||
<entry>R<subscript>30</subscript></entry>
|
||||
<entry>B<subscript>31</subscript></entry>
|
||||
<entry>R<subscript>32</subscript></entry>
|
||||
<entry>B<subscript>33</subscript></entry>
|
||||
<entry>B<subscript>30</subscript></entry>
|
||||
<entry>G<subscript>31</subscript></entry>
|
||||
<entry>B<subscript>32</subscript></entry>
|
||||
<entry>G<subscript>33</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="topbot" colsep="1" rowsep="1">
|
||||
<tgroup cols="5" align="center" border="1">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
|
|
|
|||
|
|
@ -29,12 +29,12 @@ and Cr planes have half as many pad bytes after their rows. In other
|
|||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
|
||||
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
<title><constant>V4L2_PIX_FMT_YUV420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
|
|
|
|||
|
|
@ -80,9 +80,9 @@ padding bytes after the last line of an image cross a system page
|
|||
boundary. Input devices may write padding bytes, the value is
|
||||
undefined. Output devices ignore the contents of padding
|
||||
bytes.</para><para>When the image format is planar the
|
||||
<structfield>bytesperline</structfield> value applies to the largest
|
||||
<structfield>bytesperline</structfield> value applies to the first
|
||||
plane and is divided by the same factor as the
|
||||
<structfield>width</structfield> field for any smaller planes. For
|
||||
<structfield>width</structfield> field for the other planes. For
|
||||
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
|
||||
padding bytes following each line as the Y plane. To avoid ambiguities
|
||||
drivers must return a <structfield>bytesperline</structfield> value
|
||||
|
|
@ -182,14 +182,14 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>bytesperline</structfield></entry>
|
||||
<entry>Distance in bytes between the leftmost pixels in two adjacent
|
||||
lines. See &v4l2-pix-format;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>reserved[7]</structfield></entry>
|
||||
<entry><structfield>reserved[6]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
|
|
@ -483,8 +483,8 @@ is the Y'CbCr encoding identifier (&v4l2-ycbcr-encoding;) to specify non-standar
|
|||
Y'CbCr encodings and the third is the quantization identifier (&v4l2-quantization;)
|
||||
to specify non-standard quantization methods. Most of the time only the colorspace
|
||||
field of &v4l2-pix-format; or &v4l2-pix-format-mplane; needs to be filled in. Note
|
||||
that the default R'G'B' quantization is always full range for all colorspaces,
|
||||
so this won't be mentioned explicitly for each colorspace description.</para>
|
||||
that the default R'G'B' quantization is full range for all colorspaces except for
|
||||
BT.2020 which uses limited range R'G'B' quantization.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-colorspace">
|
||||
<title>V4L2 Colorspaces</title>
|
||||
|
|
@ -598,7 +598,8 @@ so this won't be mentioned explicitly for each colorspace description.</para>
|
|||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_DEFAULT</constant></entry>
|
||||
<entry>Use the default quantization encoding as defined by the colorspace.
|
||||
This is always full range for R'G'B' and usually limited range for Y'CbCr.</entry>
|
||||
This is always full range for R'G'B' (except for the BT.2020 colorspace) and usually
|
||||
limited range for Y'CbCr.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_QUANTIZATION_FULL_RANGE</constant></entry>
|
||||
|
|
@ -620,8 +621,8 @@ is mapped to [16…235]. Cb and Cr are mapped from [-0.5…0.5] to [16
|
|||
|
||||
<section>
|
||||
<title>Detailed Colorspace Descriptions</title>
|
||||
<section>
|
||||
<title id="col-smpte-170m">Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<section id="col-smpte-170m">
|
||||
<title>Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
|
||||
<para>The <xref linkend="smpte170m" /> standard defines the colorspace used by NTSC and PAL and by SDTV
|
||||
in general. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
|
|
@ -666,8 +667,7 @@ as the SMPTE C set, so this colorspace is sometimes called SMPTE C as well.</par
|
|||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The transfer function defined for SMPTE 170M is the same as the
|
||||
one defined in Rec. 709. Normally L is in the range [0…1], but for the extended
|
||||
gamut xvYCC encoding values outside that range are allowed.</term>
|
||||
one defined in Rec. 709.</term>
|
||||
<listitem>
|
||||
<para>L' = -1.099(-L)<superscript>0.45</superscript> + 0.099 for L ≤ -0.018</para>
|
||||
<para>L' = 4.5L for -0.018 < L < 0.018</para>
|
||||
|
|
@ -702,29 +702,10 @@ defined in the <xref linkend="itu601" /> standard and this colorspace is sometim
|
|||
though BT.601 does not mention any color primaries.</para>
|
||||
<para>The default quantization is limited range, but full range is possible although
|
||||
rarely seen.</para>
|
||||
<para>The <constant>V4L2_YCBCR_ENC_601</constant> encoding as described above is the
|
||||
default for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_709</constant>,
|
||||
in which case the Rec. 709 Y'CbCr encoding is used.</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.299R' + 0.587G' + 0.114B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 encoding can also be used by selecting
|
||||
<constant>V4L2_YCBCR_ENC_XV709</constant>. The xvYCC encodings always use full range
|
||||
quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-rec709">Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<section id="col-rec709">
|
||||
<title>Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
|
||||
<para>The <xref linkend="itu709" /> standard defines the colorspace used by HDTV in general. The default
|
||||
Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_709</constant>. The default Y'CbCr quantization is
|
||||
limited range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
|
|
@ -803,26 +784,39 @@ rarely seen.</para>
|
|||
<para>The <constant>V4L2_YCBCR_ENC_709</constant> encoding described above is the default
|
||||
for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_601</constant>, in which
|
||||
case the BT.601 Y'CbCr encoding is used.</para>
|
||||
<para>Two additional extended gamut Y'CbCr encodings are also possible with this colorspace:</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 709 encoding (<constant>V4L2_YCBCR_ENC_XV709</constant>, <xref linkend="xvycc" />)
|
||||
is similar to the Rec. 709 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 255) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 255)</para>
|
||||
<para>Cb = (224 / 255) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 255) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
<para>Y' = (219 / 256) * (0.2126R' + 0.7152G' + 0.0722B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.1146R' - 0.3854G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.4542G' - 0.0458B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
|
||||
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
|
||||
[0…1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
|
||||
<listitem>
|
||||
<para>Y' = (219 / 256) * (0.299R' + 0.587G' + 0.114B') + (16 / 256)</para>
|
||||
<para>Cb = (224 / 256) * (-0.169R' - 0.331G' + 0.5B')</para>
|
||||
<para>Cr = (224 / 256) * (0.5R' - 0.419G' - 0.081B')</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>Y' is clamped to the range [0…1] and Cb and Cr are clamped
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 601 encoding can also be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV601</constant>. The xvYCC encodings always use full
|
||||
range quantization.</para>
|
||||
to the range [-0.5…0.5]. The non-standard xvYCC 709 or xvYCC 601 encodings can be used by
|
||||
selecting <constant>V4L2_YCBCR_ENC_XV709</constant> or <constant>V4L2_YCBCR_ENC_XV601</constant>.
|
||||
The xvYCC encodings always use full range quantization.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-srgb">Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<section id="col-srgb">
|
||||
<title>Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
|
||||
<para>The <xref linkend="srgb" /> standard defines the colorspace used by most webcams and computer graphics. The
|
||||
default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SYCC</constant>. The default Y'CbCr quantization
|
||||
is full range. The chromaticities of the primary colors and the white reference are:</para>
|
||||
|
|
@ -898,8 +892,8 @@ encoding, it is not. The <constant>V4L2_YCBCR_ENC_XV601</constant> scales and of
|
|||
values before quantization, but this encoding does not do that.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-adobergb">Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<section id="col-adobergb">
|
||||
<title>Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
|
||||
<para>The <xref linkend="adobergb" /> standard defines the colorspace used by computer graphics
|
||||
that use the AdobeRGB colorspace. This is also known as the <xref linkend="oprgb" /> standard.
|
||||
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr
|
||||
|
|
@ -970,12 +964,12 @@ clamped to the range [-0.5…0.5]. This transform is identical to one defin
|
|||
SMPTE 170M/BT.601. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-bt2020">Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<section id="col-bt2020">
|
||||
<title>Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
|
||||
<para>The <xref linkend="itu2020" /> standard defines the colorspace used by Ultra-high definition
|
||||
television (UHDTV). The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_BT2020</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
|
||||
the white reference are:</para>
|
||||
The default R'G'B' quantization is limited range (!), and so is the default Y'CbCr quantization.
|
||||
The chromaticities of the primary colors and the white reference are:</para>
|
||||
<table frame="none">
|
||||
<title>BT.2020 Chromaticities</title>
|
||||
<tgroup cols="3" align="left">
|
||||
|
|
@ -1032,7 +1026,7 @@ the white reference are:</para>
|
|||
<term>The luminance (Y') and color difference (Cb and Cr) are obtained with the
|
||||
following <constant>V4L2_YCBCR_ENC_BT2020</constant> encoding:</term>
|
||||
<listitem>
|
||||
<para>Y' = 0.2627R' + 0.6789G' + 0.0593B'</para>
|
||||
<para>Y' = 0.2627R' + 0.6780G' + 0.0593B'</para>
|
||||
<para>Cb = -0.1396R' - 0.3604G' + 0.5B'</para>
|
||||
<para>Cr = 0.5R' - 0.4598G' - 0.0402B'</para>
|
||||
</listitem>
|
||||
|
|
@ -1046,7 +1040,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
<varlistentry>
|
||||
<term>Luma:</term>
|
||||
<listitem>
|
||||
<para>Yc' = (0.2627R + 0.6789G + 0.0593B)'</para>
|
||||
<para>Yc' = (0.2627R + 0.6780G + 0.0593B)'</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
@ -1054,7 +1048,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
<varlistentry>
|
||||
<term>B' - Yc' ≤ 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.9404</para>
|
||||
<para>Cbc = (B' - Yc') / 1.9404</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
@ -1062,7 +1056,7 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
<varlistentry>
|
||||
<term>B' - Yc' > 0:</term>
|
||||
<listitem>
|
||||
<para>Cbc = (B' - Y') / 1.5816</para>
|
||||
<para>Cbc = (B' - Yc') / 1.5816</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
@ -1086,8 +1080,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
clamped to the range [-0.5…0.5]. The Yc'CbcCrc quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-smpte-240m">Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<section id="col-smpte-240m">
|
||||
<title>Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
|
||||
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during the early days of HDTV (1988-1998).
|
||||
It has been superseded by Rec. 709. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SMPTE240M</constant>.
|
||||
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and the
|
||||
|
|
@ -1159,8 +1153,8 @@ following <constant>V4L2_YCBCR_ENC_SMPTE240M</constant> encoding:</term>
|
|||
clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysm">Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<section id="col-sysm">
|
||||
<title>Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
|
||||
<para>This standard defines the colorspace used by NTSC in 1953. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
|
|
@ -1237,8 +1231,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-sysbg">Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<section id="col-sysbg">
|
||||
<title>Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
|
||||
<para>The <xref linkend="tech3213" /> standard defines the colorspace used by PAL/SECAM in 1975. In practice this
|
||||
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
|
||||
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
|
||||
|
|
@ -1311,8 +1305,8 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range
|
|||
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="col-jpeg">Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<section id="col-jpeg">
|
||||
<title>Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
|
||||
<para>This colorspace defines the colorspace used by most (Motion-)JPEG formats. The chromaticities
|
||||
of the primary colors and the white reference are identical to sRGB. The Y'CbCr encoding is
|
||||
<constant>V4L2_YCBCR_ENC_601</constant> with full range quantization where
|
||||
|
|
|
|||
|
|
@ -482,6 +482,36 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RBG888-1X24">
|
||||
<entry>MEDIA_BUS_FMT_RBG888_1X24</entry>
|
||||
<entry>0x100e</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-8;
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB666-1X24_CPADHI">
|
||||
<entry>MEDIA_BUS_FMT_RGB666_1X24_CPADHI</entry>
|
||||
<entry>0x1015</entry>
|
||||
|
|
@ -711,6 +741,43 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-RGB888-1X32-PADHI">
|
||||
<entry>MEDIA_BUS_FMT_RGB888_1X32_PADHI</entry>
|
||||
<entry>0x100f</entry>
|
||||
<entry></entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>0</entry>
|
||||
<entry>r<subscript>7</subscript></entry>
|
||||
<entry>r<subscript>6</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>7</subscript></entry>
|
||||
<entry>g<subscript>6</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>b<subscript>7</subscript></entry>
|
||||
<entry>b<subscript>6</subscript></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
@ -2575,6 +2642,294 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-UYVY12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_UYVY12_2X12</entry>
|
||||
<entry>0x201c</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-VYUY12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_VYUY12_2X12</entry>
|
||||
<entry>0x201d</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUYV12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_YUYV12_2X12</entry>
|
||||
<entry>0x201e</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YVYU12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_YVYU12_2X12</entry>
|
||||
<entry>0x201f</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-UYVY8-1X16">
|
||||
<entry>MEDIA_BUS_FMT_UYVY8_1X16</entry>
|
||||
<entry>0x200f</entry>
|
||||
|
|
@ -3047,6 +3402,36 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-VUY8-1X24">
|
||||
<entry>MEDIA_BUS_FMT_VUY8_1X24</entry>
|
||||
<entry>0x201a</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-8;
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUV8-1X24">
|
||||
<entry>MEDIA_BUS_FMT_YUV8_1X24</entry>
|
||||
<entry>0x2025</entry>
|
||||
|
|
@ -3084,368 +3469,6 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUV10-1X30">
|
||||
<entry>MEDIA_BUS_FMT_YUV10_1X30</entry>
|
||||
<entry>0x2016</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-AYUV8-1X32">
|
||||
<entry>MEDIA_BUS_FMT_AYUV8_1X32</entry>
|
||||
<entry>0x2017</entry>
|
||||
<entry></entry>
|
||||
<entry>a<subscript>7</subscript></entry>
|
||||
<entry>a<subscript>6</subscript></entry>
|
||||
<entry>a<subscript>5</subscript></entry>
|
||||
<entry>a<subscript>4</subscript></entry>
|
||||
<entry>a<subscript>3</subscript></entry>
|
||||
<entry>a<subscript>2</subscript></entry>
|
||||
<entry>a<subscript>1</subscript></entry>
|
||||
<entry>a<subscript>0</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-UYVY12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_UYVY12_2X12</entry>
|
||||
<entry>0x201c</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-VYUY12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_VYUY12_2X12</entry>
|
||||
<entry>0x201d</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUYV12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_YUYV12_2X12</entry>
|
||||
<entry>0x201e</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YVYU12-2X12">
|
||||
<entry>MEDIA_BUS_FMT_YVYU12_2X12</entry>
|
||||
<entry>0x201f</entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>v<subscript>11</subscript></entry>
|
||||
<entry>v<subscript>10</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>y<subscript>11</subscript></entry>
|
||||
<entry>y<subscript>10</subscript></entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
&dash-ent-20;
|
||||
<entry>u<subscript>11</subscript></entry>
|
||||
<entry>u<subscript>10</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-UYVY12-1X24">
|
||||
<entry>MEDIA_BUS_FMT_UYVY12_1X24</entry>
|
||||
<entry>0x2020</entry>
|
||||
|
|
@ -3686,6 +3709,80 @@ see <xref linkend="colorspaces" />.</entry>
|
|||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-YUV10-1X30">
|
||||
<entry>MEDIA_BUS_FMT_YUV10_1X30</entry>
|
||||
<entry>0x2016</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>y<subscript>9</subscript></entry>
|
||||
<entry>y<subscript>8</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>9</subscript></entry>
|
||||
<entry>u<subscript>8</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>9</subscript></entry>
|
||||
<entry>v<subscript>8</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="MEDIA-BUS-FMT-AYUV8-1X32">
|
||||
<entry>MEDIA_BUS_FMT_AYUV8_1X32</entry>
|
||||
<entry>0x2017</entry>
|
||||
<entry></entry>
|
||||
<entry>a<subscript>7</subscript></entry>
|
||||
<entry>a<subscript>6</subscript></entry>
|
||||
<entry>a<subscript>5</subscript></entry>
|
||||
<entry>a<subscript>4</subscript></entry>
|
||||
<entry>a<subscript>3</subscript></entry>
|
||||
<entry>a<subscript>2</subscript></entry>
|
||||
<entry>a<subscript>1</subscript></entry>
|
||||
<entry>a<subscript>0</subscript></entry>
|
||||
<entry>y<subscript>7</subscript></entry>
|
||||
<entry>y<subscript>6</subscript></entry>
|
||||
<entry>y<subscript>5</subscript></entry>
|
||||
<entry>y<subscript>4</subscript></entry>
|
||||
<entry>y<subscript>3</subscript></entry>
|
||||
<entry>y<subscript>2</subscript></entry>
|
||||
<entry>y<subscript>1</subscript></entry>
|
||||
<entry>y<subscript>0</subscript></entry>
|
||||
<entry>u<subscript>7</subscript></entry>
|
||||
<entry>u<subscript>6</subscript></entry>
|
||||
<entry>u<subscript>5</subscript></entry>
|
||||
<entry>u<subscript>4</subscript></entry>
|
||||
<entry>u<subscript>3</subscript></entry>
|
||||
<entry>u<subscript>2</subscript></entry>
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
<entry>v<subscript>7</subscript></entry>
|
||||
<entry>v<subscript>6</subscript></entry>
|
||||
<entry>v<subscript>5</subscript></entry>
|
||||
<entry>v<subscript>4</subscript></entry>
|
||||
<entry>v<subscript>3</subscript></entry>
|
||||
<entry>v<subscript>2</subscript></entry>
|
||||
<entry>v<subscript>1</subscript></entry>
|
||||
<entry>v<subscript>0</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -136,6 +136,7 @@ Remote Controller chapter.</contrib>
|
|||
<year>2012</year>
|
||||
<year>2013</year>
|
||||
<year>2014</year>
|
||||
<year>2015</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
|
||||
Pawel Osciak</holder>
|
||||
|
|
@ -151,6 +152,14 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.21</revnumber>
|
||||
<date>2015-02-13</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>Fix documentation for media controller device nodes and add support for DVB device nodes.
|
||||
Add support for Tuner sub-device.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>3.19</revnumber>
|
||||
<date>2014-12-05</date>
|
||||
|
|
|
|||
|
|
@ -59,6 +59,11 @@ constant except when switching the video standard. Remember this
|
|||
switch can occur implicit when switching the video input or
|
||||
output.</para>
|
||||
|
||||
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
|
||||
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</para>
|
||||
|
||||
<para>This ioctl must be implemented for video capture or output devices that
|
||||
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
|
||||
|
||||
|
|
@ -73,9 +78,7 @@ support cropping and/or scaling and/or have non-square pixels, and for overlay d
|
|||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@
|
|||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Type of the event.</entry>
|
||||
<entry>Type of the event, see <xref linkend="event-type" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
|
|
@ -154,6 +154,113 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="event-type">
|
||||
<title>Event Types</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_ALL</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>All events. V4L2_EVENT_ALL is valid only for
|
||||
VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_VSYNC</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>This event is triggered on the vertical sync.
|
||||
This event has a &v4l2-event-vsync; associated with it.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_EOS</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>This event is triggered when the end of a stream is reached.
|
||||
This is typically used with MPEG decoders to report to the application
|
||||
when the last of the MPEG stream has been decoded.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry><para>This event requires that the <structfield>id</structfield>
|
||||
matches the control ID from which you want to receive events.
|
||||
This event is triggered if the control's value changes, if a
|
||||
button control is pressed or if the control's flags change.
|
||||
This event has a &v4l2-event-ctrl; associated with it. This struct
|
||||
contains much of the same information as &v4l2-queryctrl; and
|
||||
&v4l2-control;.</para>
|
||||
|
||||
<para>If the event is generated due to a call to &VIDIOC-S-CTRL; or
|
||||
&VIDIOC-S-EXT-CTRLS;, then the event will <emphasis>not</emphasis> be sent to
|
||||
the file handle that called the ioctl function. This prevents
|
||||
nasty feedback loops. If you <emphasis>do</emphasis> want to get the
|
||||
event, then set the <constant>V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK</constant>
|
||||
flag.
|
||||
</para>
|
||||
|
||||
<para>This event type will ensure that no information is lost when
|
||||
more events are raised than there is room internally. In that
|
||||
case the &v4l2-event-ctrl; of the second-oldest event is kept,
|
||||
but the <structfield>changes</structfield> field of the
|
||||
second-oldest event is ORed with the <structfield>changes</structfield>
|
||||
field of the oldest event.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>
|
||||
<para>Triggered immediately when the reception of a
|
||||
frame has begun. This event has a
|
||||
&v4l2-event-frame-sync; associated with it.</para>
|
||||
|
||||
<para>If the hardware needs to be stopped in the case of a
|
||||
buffer underrun it might not be able to generate this event.
|
||||
In such cases the <structfield>frame_sequence</structfield>
|
||||
field in &v4l2-event-frame-sync; will not be incremented. This
|
||||
causes two consecutive frame sequence numbers to have n times
|
||||
frame interval in between them.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
|
||||
<entry>5</entry>
|
||||
<entry>
|
||||
<para>This event is triggered when a source parameter change is
|
||||
detected during runtime by the video device. It can be a
|
||||
runtime resolution change triggered by a video decoder or the
|
||||
format change happening on an input connector.
|
||||
This event requires that the <structfield>id</structfield>
|
||||
matches the input index (when used with a video device node)
|
||||
or the pad index (when used with a subdevice node) from which
|
||||
you want to receive events.</para>
|
||||
|
||||
<para>This event has a &v4l2-event-src-change; associated
|
||||
with it. The <structfield>changes</structfield> bitfield denotes
|
||||
what has changed for the subscribed pad. If multiple events
|
||||
occurred before application could dequeue them, then the changes
|
||||
will have the ORed value of all the events generated.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
|
||||
<entry>6</entry>
|
||||
<entry>
|
||||
<para>Triggered whenever the motion detection state for one or more of the regions
|
||||
changes. This event has a &v4l2-event-motion-det; associated with it.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
|
||||
<entry>0x08000000</entry>
|
||||
<entry>Base event number for driver-private events.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-event-vsync">
|
||||
<title>struct <structname>v4l2_event_vsync</structname></title>
|
||||
<tgroup cols="3">
|
||||
|
|
@ -177,7 +284,7 @@
|
|||
<entry>__u32</entry>
|
||||
<entry><structfield>changes</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
|
||||
<entry>A bitmask that tells what has changed. See <xref linkend="ctrl-changes-flags" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -309,8 +416,8 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="changes-flags">
|
||||
<title>Changes</title>
|
||||
<table pgwide="1" frame="none" id="ctrl-changes-flags">
|
||||
<title>Control Changes</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
|
|
@ -318,9 +425,9 @@
|
|||
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
|
||||
<entry>0x0001</entry>
|
||||
<entry>This control event was triggered because the value of the control
|
||||
changed. Special case: if a button control is pressed, then this
|
||||
event is sent as well, even though there is not explicit value
|
||||
associated with a button control.</entry>
|
||||
changed. Special cases: Volatile controls do no generate this event;
|
||||
If a control has the <constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant>
|
||||
flag set, then this event is sent as well, regardless its value.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>
|
||||
|
|
|
|||
|
|
@ -70,6 +70,11 @@ structure or returns the &EINVAL; if cropping is not supported.</para>
|
|||
<constant>VIDIOC_S_CROP</constant> ioctl with a pointer to this
|
||||
structure.</para>
|
||||
|
||||
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
|
||||
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</para>
|
||||
|
||||
<para>The driver first adjusts the requested dimensions against
|
||||
hardware limits, &ie; the bounds given by the capture/output window,
|
||||
and it rounds to the closest possible values of horizontal and
|
||||
|
|
|
|||
|
|
@ -318,10 +318,20 @@ can't generate such frequencies, then the flag will also be cleared.
|
|||
</row>
|
||||
<row>
|
||||
<entry>V4L2_DV_FL_HALF_LINE</entry>
|
||||
<entry>Specific to interlaced formats: if set, then field 1 (aka the odd field)
|
||||
is really one half-line longer and field 2 (aka the even field) is really one half-line
|
||||
shorter, so each field has exactly the same number of half-lines. Whether half-lines can be
|
||||
detected or used depends on the hardware.
|
||||
<entry>Specific to interlaced formats: if set, then the vertical frontporch
|
||||
of field 1 (aka the odd field) is really one half-line longer and the vertical backporch
|
||||
of field 2 (aka the even field) is really one half-line shorter, so each field has exactly
|
||||
the same number of half-lines. Whether half-lines can be detected or used depends on
|
||||
the hardware.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_DV_FL_IS_CE_VIDEO</entry>
|
||||
<entry>If set, then this is a Consumer Electronics (CE) video format.
|
||||
Such formats differ from other formats (commonly called IT formats) in that if
|
||||
R'G'B' encoding is used then by default the R'G'B' values use limited range
|
||||
(i.e. 16-235) as opposed to full range (i.e. 0-255). All formats defined in CEA-861
|
||||
except for the 640x480p59.94 format are CE formats.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
|
|
|
|||
|
|
@ -240,9 +240,9 @@ where padding bytes after the last line of an image cross a system
|
|||
page boundary. Capture devices may write padding bytes, the value is
|
||||
undefined. Output devices ignore the contents of padding
|
||||
bytes.</para><para>When the image format is planar the
|
||||
<structfield>bytesperline</structfield> value applies to the largest
|
||||
<structfield>bytesperline</structfield> value applies to the first
|
||||
plane and is divided by the same factor as the
|
||||
<structfield>width</structfield> field for any smaller planes. For
|
||||
<structfield>width</structfield> field for the other planes. For
|
||||
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
|
||||
padding bytes following each line as the Y plane. To avoid ambiguities
|
||||
drivers must return a <structfield>bytesperline</structfield> value
|
||||
|
|
|
|||
|
|
@ -60,8 +60,8 @@
|
|||
|
||||
<para>To query the cropping (composing) rectangle set &v4l2-selection;
|
||||
<structfield> type </structfield> field to the respective buffer type.
|
||||
Do not use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use
|
||||
Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
|
||||
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and use
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is
|
||||
setting the value of &v4l2-selection; <structfield>target</structfield> field
|
||||
|
|
|
|||
|
|
@ -102,10 +102,10 @@ The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boar
|
|||
<entry>__u32</entry>
|
||||
<entry><structfield>version</structfield></entry>
|
||||
<entry><para>Version number of the driver.</para>
|
||||
<para>Starting on kernel 3.1, the version reported is provided per
|
||||
V4L2 subsystem, following the same Kernel numberation scheme. However, it
|
||||
should not always return the same version as the kernel, if, for example,
|
||||
an stable or distribution-modified kernel uses the V4L2 stack from a
|
||||
<para>Starting with kernel 3.1, the version reported is provided by the
|
||||
V4L2 subsystem following the kernel numbering scheme. However, it
|
||||
may not always return the same version as the kernel if, for example,
|
||||
a stable or distribution-modified kernel uses the V4L2 stack from a
|
||||
newer kernel.</para>
|
||||
<para>The version number is formatted using the
|
||||
<constant>KERNEL_VERSION()</constant> macro:</para></entry>
|
||||
|
|
|
|||
|
|
@ -600,7 +600,9 @@ writing a value will cause the device to carry out a given action
|
|||
changes continuously. A typical example would be the current gain value if the device
|
||||
is in auto-gain mode. In such a case the hardware calculates the gain value based on
|
||||
the lighting conditions which can change over time. Note that setting a new value for
|
||||
a volatile control will have no effect. The new value will just be ignored.</entry>
|
||||
a volatile control will have no effect and no <constant>V4L2_EVENT_CTRL_CH_VALUE</constant>
|
||||
will be sent, unless the <constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant> flag
|
||||
(see below) is also set. Otherwise the new value will just be ignored.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant></entry>
|
||||
|
|
@ -610,6 +612,14 @@ using one of the pointer fields of &v4l2-ext-control;. This flag is set for cont
|
|||
that are an array, string, or have a compound type. In all cases you have to set a
|
||||
pointer to memory containing the payload of the control.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant></entry>
|
||||
<entry>0x0200</entry>
|
||||
<entry>The value provided to the control will be propagated to the driver
|
||||
even if remains constant. This is required when the control represents an action
|
||||
on the hardware. For example: clearing an error flag or triggering the flash. All the
|
||||
controls of the type <constant>V4L2_CTRL_TYPE_BUTTON</constant> have this flag set.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -67,9 +67,9 @@
|
|||
|
||||
<para>To enumerate frame intervals applications initialize the
|
||||
<structfield>index</structfield>, <structfield>pad</structfield>,
|
||||
<structfield>code</structfield>, <structfield>width</structfield> and
|
||||
<structfield>height</structfield> fields of
|
||||
&v4l2-subdev-frame-interval-enum; and call the
|
||||
<structfield>which</structfield>, <structfield>code</structfield>,
|
||||
<structfield>width</structfield> and <structfield>height</structfield>
|
||||
fields of &v4l2-subdev-frame-interval-enum; and call the
|
||||
<constant>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</constant> ioctl with a pointer
|
||||
to this structure. Drivers fill the rest of the structure or return
|
||||
an &EINVAL; if one of the input fields is invalid. All frame intervals are
|
||||
|
|
@ -123,7 +123,12 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry><structfield>which</structfield></entry>
|
||||
<entry>Frame intervals to be enumerated, from &v4l2-subdev-format-whence;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -61,9 +61,9 @@
|
|||
ioctl.</para>
|
||||
|
||||
<para>To enumerate frame sizes applications initialize the
|
||||
<structfield>pad</structfield>, <structfield>code</structfield> and
|
||||
<structfield>index</structfield> fields of the
|
||||
&v4l2-subdev-mbus-code-enum; and call the
|
||||
<structfield>pad</structfield>, <structfield>which</structfield> ,
|
||||
<structfield>code</structfield> and <structfield>index</structfield>
|
||||
fields of the &v4l2-subdev-mbus-code-enum; and call the
|
||||
<constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant> ioctl with a pointer to
|
||||
the structure. Drivers fill the minimum and maximum frame sizes or return
|
||||
an &EINVAL; if one of the input parameters is invalid.</para>
|
||||
|
|
@ -127,7 +127,12 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry><structfield>which</structfield></entry>
|
||||
<entry>Frame sizes to be enumerated, from &v4l2-subdev-format-whence;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -56,8 +56,8 @@
|
|||
</note>
|
||||
|
||||
<para>To enumerate media bus formats available at a given sub-device pad
|
||||
applications initialize the <structfield>pad</structfield> and
|
||||
<structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and
|
||||
applications initialize the <structfield>pad</structfield>, <structfield>which</structfield>
|
||||
and <structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and
|
||||
call the <constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant> ioctl with a
|
||||
pointer to this structure. Drivers fill the rest of the structure or return
|
||||
an &EINVAL; if either the <structfield>pad</structfield> or
|
||||
|
|
@ -93,7 +93,12 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry><structfield>which</structfield></entry>
|
||||
<entry>Media bus format codes to be enumerated, from &v4l2-subdev-format-whence;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -60,7 +60,9 @@
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>Type of the event.</entry>
|
||||
<entry>Type of the event, see <xref linkend="event-type" />. Note that
|
||||
<constant>V4L2_EVENT_ALL</constant> can be used with VIDIOC_UNSUBSCRIBE_EVENT
|
||||
for unsubscribing all events at once.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -84,113 +86,6 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="event-type">
|
||||
<title>Event Types</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_ALL</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>All events. V4L2_EVENT_ALL is valid only for
|
||||
VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_VSYNC</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>This event is triggered on the vertical sync.
|
||||
This event has a &v4l2-event-vsync; associated with it.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_EOS</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>This event is triggered when the end of a stream is reached.
|
||||
This is typically used with MPEG decoders to report to the application
|
||||
when the last of the MPEG stream has been decoded.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_CTRL</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry><para>This event requires that the <structfield>id</structfield>
|
||||
matches the control ID from which you want to receive events.
|
||||
This event is triggered if the control's value changes, if a
|
||||
button control is pressed or if the control's flags change.
|
||||
This event has a &v4l2-event-ctrl; associated with it. This struct
|
||||
contains much of the same information as &v4l2-queryctrl; and
|
||||
&v4l2-control;.</para>
|
||||
|
||||
<para>If the event is generated due to a call to &VIDIOC-S-CTRL; or
|
||||
&VIDIOC-S-EXT-CTRLS;, then the event will <emphasis>not</emphasis> be sent to
|
||||
the file handle that called the ioctl function. This prevents
|
||||
nasty feedback loops. If you <emphasis>do</emphasis> want to get the
|
||||
event, then set the <constant>V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK</constant>
|
||||
flag.
|
||||
</para>
|
||||
|
||||
<para>This event type will ensure that no information is lost when
|
||||
more events are raised than there is room internally. In that
|
||||
case the &v4l2-event-ctrl; of the second-oldest event is kept,
|
||||
but the <structfield>changes</structfield> field of the
|
||||
second-oldest event is ORed with the <structfield>changes</structfield>
|
||||
field of the oldest event.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>
|
||||
<para>Triggered immediately when the reception of a
|
||||
frame has begun. This event has a
|
||||
&v4l2-event-frame-sync; associated with it.</para>
|
||||
|
||||
<para>If the hardware needs to be stopped in the case of a
|
||||
buffer underrun it might not be able to generate this event.
|
||||
In such cases the <structfield>frame_sequence</structfield>
|
||||
field in &v4l2-event-frame-sync; will not be incremented. This
|
||||
causes two consecutive frame sequence numbers to have n times
|
||||
frame interval in between them.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
|
||||
<entry>5</entry>
|
||||
<entry>
|
||||
<para>This event is triggered when a source parameter change is
|
||||
detected during runtime by the video device. It can be a
|
||||
runtime resolution change triggered by a video decoder or the
|
||||
format change happening on an input connector.
|
||||
This event requires that the <structfield>id</structfield>
|
||||
matches the input index (when used with a video device node)
|
||||
or the pad index (when used with a subdevice node) from which
|
||||
you want to receive events.</para>
|
||||
|
||||
<para>This event has a &v4l2-event-src-change; associated
|
||||
with it. The <structfield>changes</structfield> bitfield denotes
|
||||
what has changed for the subscribed pad. If multiple events
|
||||
occurred before application could dequeue them, then the changes
|
||||
will have the ORed value of all the events generated.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
|
||||
<entry>6</entry>
|
||||
<entry>
|
||||
<para>Triggered whenever the motion detection state for one or more of the regions
|
||||
changes. This event has a &v4l2-event-motion-det; associated with it.</para>
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
|
||||
<entry>0x08000000</entry>
|
||||
<entry>Base event number for driver-private events.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="event-flags">
|
||||
<title>Event Flags</title>
|
||||
<tgroup cols="3">
|
||||
|
|
|
|||
|
|
@ -505,7 +505,10 @@ at module load time (for a module) with:
|
|||
|
||||
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.
|
||||
It is *NOT* i2c-<n> itself.
|
||||
It is *NOT* i2c-<n> itself. Also, the comparison is done ignoring
|
||||
spaces, so if the name is "This is an I2C chip" you can say
|
||||
adapter_name=ThisisanI2cchip. This is because it's hard to pass in
|
||||
spaces in kernel parameters.
|
||||
|
||||
The debug flags are bit flags for each BMC found, they are:
|
||||
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
subdir-y := accounting arm auxdisplay blackfin connector \
|
||||
subdir-y := accounting auxdisplay blackfin connector \
|
||||
filesystems filesystems ia64 laptops mic misc-devices \
|
||||
networking pcmcia prctl ptp spi timers vDSO video4linux \
|
||||
watchdog
|
||||
|
|
|
|||
|
|
@ -253,7 +253,7 @@ input driver:
|
|||
GPIO support
|
||||
~~~~~~~~~~~~
|
||||
ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
|
||||
and GpioInt. These resources are used be used to pass GPIO numbers used by
|
||||
and GpioInt. These resources can be used to pass GPIO numbers used by
|
||||
the device to the driver. ACPI 5.1 extended this with _DSD (Device
|
||||
Specific Data) which made it possible to name the GPIOs among other things.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
_DSD Device Properties Related to GPIO
|
||||
--------------------------------------
|
||||
|
||||
With the release of ACPI 5.1 and the _DSD configuration objecte names
|
||||
can finally be given to GPIOs (and other things as well) returned by
|
||||
_CRS. Previously, we were only able to use an integer index to find
|
||||
With the release of ACPI 5.1, the _DSD configuration object finally
|
||||
allows names to be given to GPIOs (and other things as well) returned
|
||||
by _CRS. Previously, we were only able to use an integer index to find
|
||||
the corresponding GPIO, which is pretty error prone (it depends on
|
||||
the _CRS output ordering, for example).
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,6 @@ IXP4xx
|
|||
- Intel IXP4xx Network processor.
|
||||
Makefile
|
||||
- Build sourcefiles as part of the Documentation-build for arm
|
||||
msm/
|
||||
- MSM specific documentation
|
||||
Netwinder
|
||||
- Netwinder specific documentation
|
||||
Porting
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
subdir-y := SH-Mobile
|
||||
|
|
@ -96,6 +96,11 @@ EBU Armada family
|
|||
88F6820
|
||||
88F6828
|
||||
|
||||
Armada 390/398 Flavors:
|
||||
88F6920
|
||||
88F6928
|
||||
Product infos: http://www.marvell.com/embedded-processors/armada-39x/
|
||||
|
||||
Armada XP Flavors:
|
||||
MV78230
|
||||
MV78260
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
# List of programs to build
|
||||
hostprogs-y := vrl4
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
HOSTCFLAGS_vrl4.o += -I$(objtree)/usr/include -I$(srctree)/tools/include
|
||||
|
|
@ -1,170 +0,0 @@
|
|||
/*
|
||||
* vrl4 format generator
|
||||
*
|
||||
* Copyright (C) 2010 Simon Horman
|
||||
*
|
||||
* This file is subject to the terms and conditions of the GNU General Public
|
||||
* License. See the file "COPYING" in the main directory of this archive
|
||||
* for more details.
|
||||
*/
|
||||
|
||||
/*
|
||||
* usage: vrl4 < zImage > out
|
||||
* dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1
|
||||
*
|
||||
* Reads a zImage from stdin and writes a vrl4 image to stdout.
|
||||
* In practice this means writing a padded vrl4 header to stdout followed
|
||||
* by the zImage.
|
||||
*
|
||||
* The padding places the zImage at ALIGN bytes into the output.
|
||||
* The vrl4 uses ALIGN + START_BASE as the start_address.
|
||||
* This is where the mask ROM will jump to after verifying the header.
|
||||
*
|
||||
* The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN.
|
||||
* That is, the mask ROM will load the padded header (ALIGN bytes)
|
||||
* And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image,
|
||||
* whichever is smaller.
|
||||
*
|
||||
* The zImage is not modified in any way.
|
||||
*/
|
||||
|
||||
#define _BSD_SOURCE
|
||||
#include <endian.h>
|
||||
#include <unistd.h>
|
||||
#include <stdint.h>
|
||||
#include <stdio.h>
|
||||
#include <errno.h>
|
||||
#include <tools/endian.h>
|
||||
|
||||
struct hdr {
|
||||
uint32_t magic1;
|
||||
uint32_t reserved1;
|
||||
uint32_t magic2;
|
||||
uint32_t reserved2;
|
||||
uint16_t copy_size;
|
||||
uint16_t boot_options;
|
||||
uint32_t reserved3;
|
||||
uint32_t start_address;
|
||||
uint32_t reserved4;
|
||||
uint32_t reserved5;
|
||||
char reserved6[308];
|
||||
};
|
||||
|
||||
#define DECLARE_HDR(h) \
|
||||
struct hdr (h) = { \
|
||||
.magic1 = htole32(0xea000000), \
|
||||
.reserved1 = htole32(0x56), \
|
||||
.magic2 = htole32(0xe59ff008), \
|
||||
.reserved3 = htole16(0x1) }
|
||||
|
||||
/* Align to 512 bytes, the MMCIF sector size */
|
||||
#define ALIGN_BITS 9
|
||||
#define ALIGN (1 << ALIGN_BITS)
|
||||
|
||||
#define START_BASE 0xe55b0000
|
||||
|
||||
/*
|
||||
* With an alignment of 512 the header uses the first sector.
|
||||
* There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM.
|
||||
* So there are 127 sectors left for the boot programme. But in practice
|
||||
* Only a small portion of a zImage is needed, 16 sectors should be more
|
||||
* than enough.
|
||||
*
|
||||
* Note that this sets how much of the zImage is copied by the mask ROM.
|
||||
* The entire zImage is present after the header and is loaded
|
||||
* by the code in the boot program (which is the first portion of the zImage).
|
||||
*/
|
||||
#define MAX_BOOT_PROG_LEN (16 * 512)
|
||||
|
||||
#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1))
|
||||
|
||||
static ssize_t do_read(int fd, void *buf, size_t count)
|
||||
{
|
||||
size_t offset = 0;
|
||||
ssize_t l;
|
||||
|
||||
while (offset < count) {
|
||||
l = read(fd, buf + offset, count - offset);
|
||||
if (!l)
|
||||
break;
|
||||
if (l < 0) {
|
||||
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
||||
continue;
|
||||
perror("read");
|
||||
return -1;
|
||||
}
|
||||
offset += l;
|
||||
}
|
||||
|
||||
return offset;
|
||||
}
|
||||
|
||||
static ssize_t do_write(int fd, const void *buf, size_t count)
|
||||
{
|
||||
size_t offset = 0;
|
||||
ssize_t l;
|
||||
|
||||
while (offset < count) {
|
||||
l = write(fd, buf + offset, count - offset);
|
||||
if (l < 0) {
|
||||
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
||||
continue;
|
||||
perror("write");
|
||||
return -1;
|
||||
}
|
||||
offset += l;
|
||||
}
|
||||
|
||||
return offset;
|
||||
}
|
||||
|
||||
static ssize_t write_zero(int fd, size_t len)
|
||||
{
|
||||
size_t i = len;
|
||||
|
||||
while (i--) {
|
||||
const char x = 0;
|
||||
if (do_write(fd, &x, 1) < 0)
|
||||
return -1;
|
||||
}
|
||||
|
||||
return len;
|
||||
}
|
||||
|
||||
int main(void)
|
||||
{
|
||||
DECLARE_HDR(hdr);
|
||||
char boot_program[MAX_BOOT_PROG_LEN];
|
||||
size_t aligned_hdr_len, alligned_prog_len;
|
||||
ssize_t prog_len;
|
||||
|
||||
prog_len = do_read(0, boot_program, sizeof(boot_program));
|
||||
if (prog_len <= 0)
|
||||
return -1;
|
||||
|
||||
aligned_hdr_len = ROUND_UP(sizeof(hdr));
|
||||
hdr.start_address = htole32(START_BASE + aligned_hdr_len);
|
||||
alligned_prog_len = ROUND_UP(prog_len);
|
||||
hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len);
|
||||
|
||||
if (do_write(1, &hdr, sizeof(hdr)) < 0)
|
||||
return -1;
|
||||
if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0)
|
||||
return -1;
|
||||
|
||||
if (do_write(1, boot_program, prog_len) < 0)
|
||||
return 1;
|
||||
|
||||
/* Write out the rest of the kernel */
|
||||
while (1) {
|
||||
prog_len = do_read(0, boot_program, sizeof(boot_program));
|
||||
if (prog_len < 0)
|
||||
return 1;
|
||||
if (prog_len == 0)
|
||||
break;
|
||||
if (do_write(1, boot_program, prog_len) < 0)
|
||||
return 1;
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
ROM-able zImage boot from MMC
|
||||
-----------------------------
|
||||
|
||||
An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and
|
||||
SuperH Mobile ARM will to boot directly from the MMCIF hardware block.
|
||||
|
||||
This is achieved by the mask ROM loading the first portion of the image into
|
||||
MERAM and then jumping to it. This portion contains loader code which
|
||||
copies the entire image to SDRAM and jumps to it. From there the zImage
|
||||
boot code proceeds as normal, uncompressing the image into its final
|
||||
location and then jumping to it.
|
||||
|
||||
This code has been tested on an AP4EB board using the developer 1A eMMC
|
||||
boot mode which is configured using the following jumper settings.
|
||||
The board used for testing required a patched mask ROM in order for
|
||||
this mode to function.
|
||||
|
||||
8 7 6 5 4 3 2 1
|
||||
x|x|x|x|x| |x|
|
||||
S4 -+-+-+-+-+-+-+-
|
||||
| | | | |x| |x on
|
||||
|
||||
The zImage must be written to the MMC card at sector 1 (512 bytes) in
|
||||
vrl4 format. A utility vrl4 is supplied to accomplish this.
|
||||
|
||||
e.g.
|
||||
vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1
|
||||
|
||||
A dual-voltage MMC 4.0 card was used for testing.
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
ROM-able zImage boot from eSD
|
||||
-----------------------------
|
||||
|
||||
An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and
|
||||
SuperH Mobile ARM will to boot directly from the SDHI hardware block.
|
||||
|
||||
This is achieved by the mask ROM loading the first portion of the image into
|
||||
MERAM and then jumping to it. This portion contains loader code which
|
||||
copies the entire image to SDRAM and jumps to it. From there the zImage
|
||||
boot code proceeds as normal, uncompressing the image into its final
|
||||
location and then jumping to it.
|
||||
|
||||
This code has been tested on an mackerel board using the developer 1A eSD
|
||||
boot mode which is configured using the following jumper settings.
|
||||
|
||||
8 7 6 5 4 3 2 1
|
||||
x|x|x|x| |x|x|
|
||||
S4 -+-+-+-+-+-+-+-
|
||||
| | | |x| | |x on
|
||||
|
||||
The eSD card needs to be present in SDHI slot 1 (CN7).
|
||||
As such S1 and S33 also need to be configured as per
|
||||
the notes in arch/arm/mach-shmobile/board-mackerel.c.
|
||||
|
||||
A partial zImage must be written to physical partition #1 (boot)
|
||||
of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to
|
||||
accomplish this.
|
||||
|
||||
e.g.
|
||||
vrl4 < zImage | dd of=/dev/sdX bs=512 count=17
|
||||
|
||||
A full copy of _the same_ zImage should be written to physical partition #1
|
||||
(boot) of the eSD at sector 0. This should _not_ be in vrl4 format.
|
||||
|
||||
vrl4 < zImage | dd of=/dev/sdX bs=512
|
||||
|
||||
Note: The commands above assume that the physical partition has been
|
||||
switched. No such facility currently exists in the Linux Kernel.
|
||||
|
||||
Physical partitions are described in the eSD specification. At the time of
|
||||
writing they are not the same as partitions that are typically configured
|
||||
using fdisk and visible through /proc/partitions
|
||||
|
|
@ -1,176 +0,0 @@
|
|||
This document provides an overview of the msm_gpiomux interface, which
|
||||
is used to provide gpio pin multiplexing and configuration on mach-msm
|
||||
targets.
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
The first-generation API for gpio configuration & multiplexing on msm
|
||||
is the function gpio_tlmm_config(). This function has a few notable
|
||||
shortcomings, which led to its deprecation and replacement by gpiomux:
|
||||
|
||||
The 'disable' parameter: Setting the second parameter to
|
||||
gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral
|
||||
processor in charge of the subsystem to perform a look-up into a
|
||||
low-power table and apply the low-power/sleep setting for the pin.
|
||||
As the msm family evolved this became problematic. Not all pins
|
||||
have sleep settings, not all peripheral processors will accept requests
|
||||
to apply said sleep settings, and not all msm targets have their gpio
|
||||
subsystems managed by a peripheral processor. In order to get consistent
|
||||
behavior on all targets, drivers are forced to ignore this parameter,
|
||||
rendering it useless.
|
||||
|
||||
The 'direction' flag: for all mux-settings other than raw-gpio (0),
|
||||
the output-enable bit of a gpio is hard-wired to a known
|
||||
input (usually VDD or ground). For those settings, the direction flag
|
||||
is meaningless at best, and deceptive at worst. In addition, using the
|
||||
direction flag to change output-enable (OE) directly can cause trouble in
|
||||
gpiolib, which has no visibility into gpio direction changes made
|
||||
in this way. Direction control in gpio mode should be made through gpiolib.
|
||||
|
||||
Key Features of gpiomux
|
||||
=======================
|
||||
|
||||
- A consistent interface across all generations of msm. Drivers can expect
|
||||
the same results on every target.
|
||||
- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib
|
||||
are left to gpiolib and not duplicated here. gpiomux is written with the
|
||||
intent that gpio_chips will call gpiomux reference-counting methods
|
||||
from their request() and free() hooks, providing full integration.
|
||||
- Tabular configuration. Instead of having to call gpio_tlmm_config
|
||||
hundreds of times, gpio configuration is placed in a single table.
|
||||
- Per-gpio sleep. Each gpio is individually reference counted, allowing only
|
||||
those lines which are in use to be put in high-power states.
|
||||
- 0 means 'do nothing': all flags are designed so that the default memset-zero
|
||||
equates to a sensible default of 'no configuration', preventing users
|
||||
from having to provide hundreds of 'no-op' configs for unused or
|
||||
unwanted lines.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
To use gpiomux, provide configuration information for relevant gpio lines
|
||||
in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured",
|
||||
only those lines to be managed by gpiomux need to be specified. Here
|
||||
is a completely fictional example:
|
||||
|
||||
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
|
||||
[12] = {
|
||||
.active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1,
|
||||
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
|
||||
},
|
||||
[34] = {
|
||||
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
|
||||
},
|
||||
};
|
||||
|
||||
To indicate that a gpio is in use, call msm_gpiomux_get() to increase
|
||||
its reference count. To decrease the reference count, call msm_gpiomux_put().
|
||||
|
||||
The effect of this configuration is as follows:
|
||||
|
||||
When the system boots, gpios 12 and 34 will be initialized with their
|
||||
'suspended' configurations. All other gpios, which were left unconfigured,
|
||||
will not be touched.
|
||||
|
||||
When msm_gpiomux_get() is called on gpio 12 to raise its reference count
|
||||
above 0, its active configuration will be applied. Since no other gpio
|
||||
line has a valid active configuration, msm_gpiomux_get() will have no
|
||||
effect on any other line.
|
||||
|
||||
When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference
|
||||
count to 0, their suspended configurations will be applied.
|
||||
Since no other gpio line has a valid suspended configuration, no other
|
||||
gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid
|
||||
active configuration, this is effectively a no-op for gpio 34 as well,
|
||||
with one small caveat, see the section "About Output-Enable Settings".
|
||||
|
||||
All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but
|
||||
they address some important issues. As unused entries (all those
|
||||
except 12 and 34) are zero-filled, gpiomux needs a way to distinguish
|
||||
the used fields from the unused. In addition, the all-zero pattern
|
||||
is a valid configuration! Therefore, gpiomux defines an additional bit
|
||||
which is used to indicate when a field is used. This has the pleasant
|
||||
side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate
|
||||
that a value should not be changed:
|
||||
|
||||
msm_gpiomux_write(0, GPIOMUX_VALID, 0);
|
||||
|
||||
replaces the active configuration of gpio 0 with an all-zero configuration,
|
||||
but leaves the suspended configuration as it was.
|
||||
|
||||
Static Configurations
|
||||
=====================
|
||||
|
||||
To install a static configuration, which is applied at boot and does
|
||||
not change after that, install a configuration with a suspended component
|
||||
but no active component, as in the previous example:
|
||||
|
||||
[34] = {
|
||||
.suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
|
||||
},
|
||||
|
||||
The suspended setting is applied during boot, and the lack of any valid
|
||||
active setting prevents any other setting from being applied at runtime.
|
||||
If other subsystems attempting to access the line is a concern, one could
|
||||
*really* anchor the configuration down by calling msm_gpiomux_get on the
|
||||
line at initialization to move the line into active mode. With the line
|
||||
held, it will never be re-suspended, and with no valid active configuration,
|
||||
no new configurations will be applied.
|
||||
|
||||
But then, if having other subsystems grabbing for the line is truly a concern,
|
||||
it should be reserved with gpio_request instead, which carries an implicit
|
||||
msm_gpiomux_get.
|
||||
|
||||
gpiomux and gpiolib
|
||||
===================
|
||||
|
||||
It is expected that msm gpio_chips will call msm_gpiomux_get() and
|
||||
msm_gpiomux_put() from their request and free hooks, like this fictional
|
||||
example:
|
||||
|
||||
static int request(struct gpio_chip *chip, unsigned offset)
|
||||
{
|
||||
return msm_gpiomux_get(chip->base + offset);
|
||||
}
|
||||
|
||||
static void free(struct gpio_chip *chip, unsigned offset)
|
||||
{
|
||||
msm_gpiomux_put(chip->base + offset);
|
||||
}
|
||||
|
||||
...somewhere in a gpio_chip declaration...
|
||||
.request = request,
|
||||
.free = free,
|
||||
|
||||
This provides important functionality:
|
||||
- It guarantees that a gpio line will have its 'active' config applied
|
||||
when the line is requested, and will not be suspended while the line
|
||||
remains requested; and
|
||||
- It guarantees that gpio-direction settings from gpiolib behave sensibly.
|
||||
See "About Output-Enable Settings."
|
||||
|
||||
This mechanism allows for "auto-request" of gpiomux lines via gpiolib
|
||||
when it is suitable. Drivers wishing more exact control are, of course,
|
||||
free to also use msm_gpiomux_set and msm_gpiomux_get.
|
||||
|
||||
About Output-Enable Settings
|
||||
============================
|
||||
|
||||
Some msm targets do not have the ability to query the current gpio
|
||||
configuration setting. This means that changes made to the output-enable
|
||||
(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux.
|
||||
Therefore, when gpiomux applies a configuration setting, any direction
|
||||
settings which may have been applied by gpiolib are lost and the default
|
||||
input settings are re-applied.
|
||||
|
||||
For this reason, drivers should not assume that gpio direction settings
|
||||
continue to hold if they free and then re-request a gpio. This seems like
|
||||
common sense - after all, anybody could have obtained the line in the
|
||||
meantime - but it needs saying.
|
||||
|
||||
This also means that calls to msm_gpiomux_write will reset the OE bit,
|
||||
which means that if the gpio line is held by a client of gpiolib and
|
||||
msm_gpiomux_write is called, the direction setting has been lost and
|
||||
gpiolib's internal state has been broken.
|
||||
Release gpio lines before reconfiguring them.
|
||||
|
|
@ -0,0 +1,593 @@
|
|||
ACPI Tables
|
||||
-----------
|
||||
The expectations of individual ACPI tables are discussed in the list that
|
||||
follows.
|
||||
|
||||
If a section number is used, it refers to a section number in the ACPI
|
||||
specification where the object is defined. If "Signature Reserved" is used,
|
||||
the table signature (the first four bytes of the table) is the only portion
|
||||
of the table recognized by the specification, and the actual table is defined
|
||||
outside of the UEFI Forum (see Section 5.2.6 of the specification).
|
||||
|
||||
For ACPI on arm64, tables also fall into the following categories:
|
||||
|
||||
-- Required: DSDT, FADT, GTDT, MADT, MCFG, RSDP, SPCR, XSDT
|
||||
|
||||
-- Recommended: BERT, EINJ, ERST, HEST, SSDT
|
||||
|
||||
-- Optional: BGRT, CPEP, CSRT, DRTM, ECDT, FACS, FPDT, MCHI, MPST,
|
||||
MSCT, RASF, SBST, SLIT, SPMI, SRAT, TCPA, TPM2, UEFI
|
||||
|
||||
-- Not supported: BOOT, DBG2, DBGP, DMAR, ETDT, HPET, IBFT, IVRS,
|
||||
LPIT, MSDM, RSDT, SLIC, WAET, WDAT, WDRT, WPBT
|
||||
|
||||
|
||||
Table Usage for ARMv8 Linux
|
||||
----- ----------------------------------------------------------------
|
||||
BERT Section 18.3 (signature == "BERT")
|
||||
== Boot Error Record Table ==
|
||||
Must be supplied if RAS support is provided by the platform. It
|
||||
is recommended this table be supplied.
|
||||
|
||||
BOOT Signature Reserved (signature == "BOOT")
|
||||
== simple BOOT flag table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
BGRT Section 5.2.22 (signature == "BGRT")
|
||||
== Boot Graphics Resource Table ==
|
||||
Optional, not currently supported, with no real use-case for an
|
||||
ARM server.
|
||||
|
||||
CPEP Section 5.2.18 (signature == "CPEP")
|
||||
== Corrected Platform Error Polling table ==
|
||||
Optional, not currently supported, and not recommended until such
|
||||
time as ARM-compatible hardware is available, and the specification
|
||||
suitably modified.
|
||||
|
||||
CSRT Signature Reserved (signature == "CSRT")
|
||||
== Core System Resources Table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
DBG2 Signature Reserved (signature == "DBG2")
|
||||
== DeBuG port table 2 ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
DBGP Signature Reserved (signature == "DBGP")
|
||||
== DeBuG Port table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
DSDT Section 5.2.11.1 (signature == "DSDT")
|
||||
== Differentiated System Description Table ==
|
||||
A DSDT is required; see also SSDT.
|
||||
|
||||
ACPI tables contain only one DSDT but can contain one or more SSDTs,
|
||||
which are optional. Each SSDT can only add to the ACPI namespace,
|
||||
but cannot modify or replace anything in the DSDT.
|
||||
|
||||
DMAR Signature Reserved (signature == "DMAR")
|
||||
== DMA Remapping table ==
|
||||
x86 only table, will not be supported.
|
||||
|
||||
DRTM Signature Reserved (signature == "DRTM")
|
||||
== Dynamic Root of Trust for Measurement table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
ECDT Section 5.2.16 (signature == "ECDT")
|
||||
== Embedded Controller Description Table ==
|
||||
Optional, not currently supported, but could be used on ARM if and
|
||||
only if one uses the GPE_BIT field to represent an IRQ number, since
|
||||
there are no GPE blocks defined in hardware reduced mode. This would
|
||||
need to be modified in the ACPI specification.
|
||||
|
||||
EINJ Section 18.6 (signature == "EINJ")
|
||||
== Error Injection table ==
|
||||
This table is very useful for testing platform response to error
|
||||
conditions; it allows one to inject an error into the system as
|
||||
if it had actually occurred. However, this table should not be
|
||||
shipped with a production system; it should be dynamically loaded
|
||||
and executed with the ACPICA tools only during testing.
|
||||
|
||||
ERST Section 18.5 (signature == "ERST")
|
||||
== Error Record Serialization Table ==
|
||||
On a platform supports RAS, this table must be supplied if it is not
|
||||
UEFI-based; if it is UEFI-based, this table may be supplied. When this
|
||||
table is not present, UEFI run time service will be utilized to save
|
||||
and retrieve hardware error information to and from a persistent store.
|
||||
|
||||
ETDT Signature Reserved (signature == "ETDT")
|
||||
== Event Timer Description Table ==
|
||||
Obsolete table, will not be supported.
|
||||
|
||||
FACS Section 5.2.10 (signature == "FACS")
|
||||
== Firmware ACPI Control Structure ==
|
||||
It is unlikely that this table will be terribly useful. If it is
|
||||
provided, the Global Lock will NOT be used since it is not part of
|
||||
the hardware reduced profile, and only 64-bit address fields will
|
||||
be considered valid.
|
||||
|
||||
FADT Section 5.2.9 (signature == "FACP")
|
||||
== Fixed ACPI Description Table ==
|
||||
Required for arm64.
|
||||
|
||||
The HW_REDUCED_ACPI flag must be set. All of the fields that are
|
||||
to be ignored when HW_REDUCED_ACPI is set are expected to be set to
|
||||
zero.
|
||||
|
||||
If an FACS table is provided, the X_FIRMWARE_CTRL field is to be
|
||||
used, not FIRMWARE_CTRL.
|
||||
|
||||
If PSCI is used (as is recommended), make sure that ARM_BOOT_ARCH is
|
||||
filled in properly -- that the PSCI_COMPLIANT flag is set and that
|
||||
PSCI_USE_HVC is set or unset as needed (see table 5-37).
|
||||
|
||||
For the DSDT that is also required, the X_DSDT field is to be used,
|
||||
not the DSDT field.
|
||||
|
||||
FPDT Section 5.2.23 (signature == "FPDT")
|
||||
== Firmware Performance Data Table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
GTDT Section 5.2.24 (signature == "GTDT")
|
||||
== Generic Timer Description Table ==
|
||||
Required for arm64.
|
||||
|
||||
HEST Section 18.3.2 (signature == "HEST")
|
||||
== Hardware Error Source Table ==
|
||||
Until further error source types are defined, use only types 6 (AER
|
||||
Root Port), 7 (AER Endpoint), 8 (AER Bridge), or 9 (Generic Hardware
|
||||
Error Source). Firmware first error handling is possible if and only
|
||||
if Trusted Firmware is being used on arm64.
|
||||
|
||||
Must be supplied if RAS support is provided by the platform. It
|
||||
is recommended this table be supplied.
|
||||
|
||||
HPET Signature Reserved (signature == "HPET")
|
||||
== High Precision Event timer Table ==
|
||||
x86 only table, will not be supported.
|
||||
|
||||
IBFT Signature Reserved (signature == "IBFT")
|
||||
== iSCSI Boot Firmware Table ==
|
||||
Microsoft defined table, support TBD.
|
||||
|
||||
IVRS Signature Reserved (signature == "IVRS")
|
||||
== I/O Virtualization Reporting Structure ==
|
||||
x86_64 (AMD) only table, will not be supported.
|
||||
|
||||
LPIT Signature Reserved (signature == "LPIT")
|
||||
== Low Power Idle Table ==
|
||||
x86 only table as of ACPI 5.1; future versions have been adapted for
|
||||
use with ARM and will be recommended in order to support ACPI power
|
||||
management.
|
||||
|
||||
MADT Section 5.2.12 (signature == "APIC")
|
||||
== Multiple APIC Description Table ==
|
||||
Required for arm64. Only the GIC interrupt controller structures
|
||||
should be used (types 0xA - 0xE).
|
||||
|
||||
MCFG Signature Reserved (signature == "MCFG")
|
||||
== Memory-mapped ConFiGuration space ==
|
||||
If the platform supports PCI/PCIe, an MCFG table is required.
|
||||
|
||||
MCHI Signature Reserved (signature == "MCHI")
|
||||
== Management Controller Host Interface table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
MPST Section 5.2.21 (signature == "MPST")
|
||||
== Memory Power State Table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
MSDM Signature Reserved (signature == "MSDM")
|
||||
== Microsoft Data Management table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
MSCT Section 5.2.19 (signature == "MSCT")
|
||||
== Maximum System Characteristic Table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
RASF Section 5.2.20 (signature == "RASF")
|
||||
== RAS Feature table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
RSDP Section 5.2.5 (signature == "RSD PTR")
|
||||
== Root System Description PoinTeR ==
|
||||
Required for arm64.
|
||||
|
||||
RSDT Section 5.2.7 (signature == "RSDT")
|
||||
== Root System Description Table ==
|
||||
Since this table can only provide 32-bit addresses, it is deprecated
|
||||
on arm64, and will not be used.
|
||||
|
||||
SBST Section 5.2.14 (signature == "SBST")
|
||||
== Smart Battery Subsystem Table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
SLIC Signature Reserved (signature == "SLIC")
|
||||
== Software LIcensing table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
SLIT Section 5.2.17 (signature == "SLIT")
|
||||
== System Locality distance Information Table ==
|
||||
Optional in general, but required for NUMA systems.
|
||||
|
||||
SPCR Signature Reserved (signature == "SPCR")
|
||||
== Serial Port Console Redirection table ==
|
||||
Required for arm64.
|
||||
|
||||
SPMI Signature Reserved (signature == "SPMI")
|
||||
== Server Platform Management Interface table ==
|
||||
Optional, not currently supported.
|
||||
|
||||
SRAT Section 5.2.16 (signature == "SRAT")
|
||||
== System Resource Affinity Table ==
|
||||
Optional, but if used, only the GICC Affinity structures are read.
|
||||
To support NUMA, this table is required.
|
||||
|
||||
SSDT Section 5.2.11.2 (signature == "SSDT")
|
||||
== Secondary System Description Table ==
|
||||
These tables are a continuation of the DSDT; these are recommended
|
||||
for use with devices that can be added to a running system, but can
|
||||
also serve the purpose of dividing up device descriptions into more
|
||||
manageable pieces.
|
||||
|
||||
An SSDT can only ADD to the ACPI namespace. It cannot modify or
|
||||
replace existing device descriptions already in the namespace.
|
||||
|
||||
These tables are optional, however. ACPI tables should contain only
|
||||
one DSDT but can contain many SSDTs.
|
||||
|
||||
TCPA Signature Reserved (signature == "TCPA")
|
||||
== Trusted Computing Platform Alliance table ==
|
||||
Optional, not currently supported, and may need changes to fully
|
||||
interoperate with arm64.
|
||||
|
||||
TPM2 Signature Reserved (signature == "TPM2")
|
||||
== Trusted Platform Module 2 table ==
|
||||
Optional, not currently supported, and may need changes to fully
|
||||
interoperate with arm64.
|
||||
|
||||
UEFI Signature Reserved (signature == "UEFI")
|
||||
== UEFI ACPI data table ==
|
||||
Optional, not currently supported. No known use case for arm64,
|
||||
at present.
|
||||
|
||||
WAET Signature Reserved (signature == "WAET")
|
||||
== Windows ACPI Emulated devices Table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
WDAT Signature Reserved (signature == "WDAT")
|
||||
== Watch Dog Action Table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
WDRT Signature Reserved (signature == "WDRT")
|
||||
== Watch Dog Resource Table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
WPBT Signature Reserved (signature == "WPBT")
|
||||
== Windows Platform Binary Table ==
|
||||
Microsoft only table, will not be supported.
|
||||
|
||||
XSDT Section 5.2.8 (signature == "XSDT")
|
||||
== eXtended System Description Table ==
|
||||
Required for arm64.
|
||||
|
||||
|
||||
ACPI Objects
|
||||
------------
|
||||
The expectations on individual ACPI objects are discussed in the list that
|
||||
follows:
|
||||
|
||||
Name Section Usage for ARMv8 Linux
|
||||
---- ------------ -------------------------------------------------
|
||||
_ADR 6.1.1 Use as needed.
|
||||
|
||||
_BBN 6.5.5 Use as needed; PCI-specific.
|
||||
|
||||
_BDN 6.5.3 Optional; not likely to be used on arm64.
|
||||
|
||||
_CCA 6.2.17 This method should be defined for all bus masters
|
||||
on arm64. While cache coherency is assumed, making
|
||||
it explicit ensures the kernel will set up DMA as
|
||||
it should.
|
||||
|
||||
_CDM 6.2.1 Optional, to be used only for processor devices.
|
||||
|
||||
_CID 6.1.2 Use as needed.
|
||||
|
||||
_CLS 6.1.3 Use as needed.
|
||||
|
||||
_CRS 6.2.2 Required on arm64.
|
||||
|
||||
_DCK 6.5.2 Optional; not likely to be used on arm64.
|
||||
|
||||
_DDN 6.1.4 This field can be used for a device name. However,
|
||||
it is meant for DOS device names (e.g., COM1), so be
|
||||
careful of its use across OSes.
|
||||
|
||||
_DEP 6.5.8 Use as needed.
|
||||
|
||||
_DIS 6.2.3 Optional, for power management use.
|
||||
|
||||
_DLM 5.7.5 Optional.
|
||||
|
||||
_DMA 6.2.4 Optional.
|
||||
|
||||
_DSD 6.2.5 To be used with caution. If this object is used, try
|
||||
to use it within the constraints already defined by the
|
||||
Device Properties UUID. Only in rare circumstances
|
||||
should it be necessary to create a new _DSD UUID.
|
||||
|
||||
In either case, submit the _DSD definition along with
|
||||
any driver patches for discussion, especially when
|
||||
device properties are used. A driver will not be
|
||||
considered complete without a corresponding _DSD
|
||||
description. Once approved by kernel maintainers,
|
||||
the UUID or device properties must then be registered
|
||||
with the UEFI Forum; this may cause some iteration as
|
||||
more than one OS will be registering entries.
|
||||
|
||||
_DSM Do not use this method. It is not standardized, the
|
||||
return values are not well documented, and it is
|
||||
currently a frequent source of error.
|
||||
|
||||
_DSW 7.2.1 Use as needed; power management specific.
|
||||
|
||||
_EDL 6.3.1 Optional.
|
||||
|
||||
_EJD 6.3.2 Optional.
|
||||
|
||||
_EJx 6.3.3 Optional.
|
||||
|
||||
_FIX 6.2.7 x86 specific, not used on arm64.
|
||||
|
||||
\_GL 5.7.1 This object is not to be used in hardware reduced
|
||||
mode, and therefore should not be used on arm64.
|
||||
|
||||
_GLK 6.5.7 This object requires a global lock be defined; there
|
||||
is no global lock on arm64 since it runs in hardware
|
||||
reduced mode. Hence, do not use this object on arm64.
|
||||
|
||||
\_GPE 5.3.1 This namespace is for x86 use only. Do not use it
|
||||
on arm64.
|
||||
|
||||
_GSB 6.2.7 Optional.
|
||||
|
||||
_HID 6.1.5 Use as needed. This is the primary object to use in
|
||||
device probing, though _CID and _CLS may also be used.
|
||||
|
||||
_HPP 6.2.8 Optional, PCI specific.
|
||||
|
||||
_HPX 6.2.9 Optional, PCI specific.
|
||||
|
||||
_HRV 6.1.6 Optional, use as needed to clarify device behavior; in
|
||||
some cases, this may be easier to use than _DSD.
|
||||
|
||||
_INI 6.5.1 Not required, but can be useful in setting up devices
|
||||
when UEFI leaves them in a state that may not be what
|
||||
the driver expects before it starts probing.
|
||||
|
||||
_IRC 7.2.15 Use as needed; power management specific.
|
||||
|
||||
_LCK 6.3.4 Optional.
|
||||
|
||||
_MAT 6.2.10 Optional; see also the MADT.
|
||||
|
||||
_MLS 6.1.7 Optional, but highly recommended for use in
|
||||
internationalization.
|
||||
|
||||
_OFF 7.1.2 It is recommended to define this method for any device
|
||||
that can be turned on or off.
|
||||
|
||||
_ON 7.1.3 It is recommended to define this method for any device
|
||||
that can be turned on or off.
|
||||
|
||||
\_OS 5.7.3 This method will return "Linux" by default (this is
|
||||
the value of the macro ACPI_OS_NAME on Linux). The
|
||||
command line parameter acpi_os=<string> can be used
|
||||
to set it to some other value.
|
||||
|
||||
_OSC 6.2.11 This method can be a global method in ACPI (i.e.,
|
||||
\_SB._OSC), or it may be associated with a specific
|
||||
device (e.g., \_SB.DEV0._OSC), or both. When used
|
||||
as a global method, only capabilities published in
|
||||
the ACPI specification are allowed. When used as
|
||||
a device-specific method, the process described for
|
||||
using _DSD MUST be used to create an _OSC definition;
|
||||
out-of-process use of _OSC is not allowed. That is,
|
||||
submit the device-specific _OSC usage description as
|
||||
part of the kernel driver submission, get it approved
|
||||
by the kernel community, then register it with the
|
||||
UEFI Forum.
|
||||
|
||||
\_OSI 5.7.2 Deprecated on ARM64. Any invocation of this method
|
||||
will print a warning on the console and return false.
|
||||
That is, as far as ACPI firmware is concerned, _OSI
|
||||
cannot be used to determine what sort of system is
|
||||
being used or what functionality is provided. The
|
||||
_OSC method is to be used instead.
|
||||
|
||||
_OST 6.3.5 Optional.
|
||||
|
||||
_PDC 8.4.1 Deprecated, do not use on arm64.
|
||||
|
||||
\_PIC 5.8.1 The method should not be used. On arm64, the only
|
||||
interrupt model available is GIC.
|
||||
|
||||
_PLD 6.1.8 Optional.
|
||||
|
||||
\_PR 5.3.1 This namespace is for x86 use only on legacy systems.
|
||||
Do not use it on arm64.
|
||||
|
||||
_PRS 6.2.12 Optional.
|
||||
|
||||
_PRT 6.2.13 Required as part of the definition of all PCI root
|
||||
devices.
|
||||
|
||||
_PRW 7.2.13 Use as needed; power management specific.
|
||||
|
||||
_PRx 7.2.8-11 Use as needed; power management specific. If _PR0 is
|
||||
defined, _PR3 must also be defined.
|
||||
|
||||
_PSC 7.2.6 Use as needed; power management specific.
|
||||
|
||||
_PSE 7.2.7 Use as needed; power management specific.
|
||||
|
||||
_PSW 7.2.14 Use as needed; power management specific.
|
||||
|
||||
_PSx 7.2.2-5 Use as needed; power management specific. If _PS0 is
|
||||
defined, _PS3 must also be defined. If clocks or
|
||||
regulators need adjusting to be consistent with power
|
||||
usage, change them in these methods.
|
||||
|
||||
\_PTS 7.3.1 Use as needed; power management specific.
|
||||
|
||||
_PXM 6.2.14 Optional.
|
||||
|
||||
_REG 6.5.4 Use as needed.
|
||||
|
||||
\_REV 5.7.4 Always returns the latest version of ACPI supported.
|
||||
|
||||
_RMV 6.3.6 Optional.
|
||||
|
||||
\_SB 5.3.1 Required on arm64; all devices must be defined in this
|
||||
namespace.
|
||||
|
||||
_SEG 6.5.6 Use as needed; PCI-specific.
|
||||
|
||||
\_SI 5.3.1, Optional.
|
||||
9.1
|
||||
|
||||
_SLI 6.2.15 Optional; recommended when SLIT table is in use.
|
||||
|
||||
_STA 6.3.7, It is recommended to define this method for any device
|
||||
7.1.4 that can be turned on or off.
|
||||
|
||||
_SRS 6.2.16 Optional; see also _PRS.
|
||||
|
||||
_STR 6.1.10 Recommended for conveying device names to end users;
|
||||
this is preferred over using _DDN.
|
||||
|
||||
_SUB 6.1.9 Use as needed; _HID or _CID are preferred.
|
||||
|
||||
_SUN 6.1.11 Optional.
|
||||
|
||||
\_Sx 7.3.2 Use as needed; power management specific.
|
||||
|
||||
_SxD 7.2.16-19 Use as needed; power management specific.
|
||||
|
||||
_SxW 7.2.20-24 Use as needed; power management specific.
|
||||
|
||||
_SWS 7.3.3 Use as needed; power management specific; this may
|
||||
require specification changes for use on arm64.
|
||||
|
||||
\_TTS 7.3.4 Use as needed; power management specific.
|
||||
|
||||
\_TZ 5.3.1 Optional.
|
||||
|
||||
_UID 6.1.12 Recommended for distinguishing devices of the same
|
||||
class; define it if at all possible.
|
||||
|
||||
\_WAK 7.3.5 Use as needed; power management specific.
|
||||
|
||||
|
||||
ACPI Event Model
|
||||
----------------
|
||||
Do not use GPE block devices; these are not supported in the hardware reduced
|
||||
profile used by arm64. Since there are no GPE blocks defined for use on ARM
|
||||
platforms, GPIO-signaled interrupts should be used for creating system events.
|
||||
|
||||
|
||||
ACPI Processor Control
|
||||
----------------------
|
||||
Section 8 of the ACPI specification is currently undergoing change that
|
||||
should be completed in the 6.0 version of the specification. Processor
|
||||
performance control will be handled differently for arm64 at that point
|
||||
in time. Processor aggregator devices (section 8.5) will not be used,
|
||||
for example, but another similar mechanism instead.
|
||||
|
||||
While UEFI constrains what we can say until the release of 6.0, it is
|
||||
recommended that CPPC (8.4.5) be used as the primary model. This will
|
||||
still be useful into the future. C-states and P-states will still be
|
||||
provided, but most of the current design work appears to favor CPPC.
|
||||
|
||||
Further, it is essential that the ARMv8 SoC provide a fully functional
|
||||
implementation of PSCI; this will be the only mechanism supported by ACPI
|
||||
to control CPU power state (including secondary CPU booting).
|
||||
|
||||
More details will be provided on the release of the ACPI 6.0 specification.
|
||||
|
||||
|
||||
ACPI System Address Map Interfaces
|
||||
----------------------------------
|
||||
In Section 15 of the ACPI specification, several methods are mentioned as
|
||||
possible mechanisms for conveying memory resource information to the kernel.
|
||||
For arm64, we will only support UEFI for booting with ACPI, hence the UEFI
|
||||
GetMemoryMap() boot service is the only mechanism that will be used.
|
||||
|
||||
|
||||
ACPI Platform Error Interfaces (APEI)
|
||||
-------------------------------------
|
||||
The APEI tables supported are described above.
|
||||
|
||||
APEI requires the equivalent of an SCI and an NMI on ARMv8. The SCI is used
|
||||
to notify the OSPM of errors that have occurred but can be corrected and the
|
||||
system can continue correct operation, even if possibly degraded. The NMI is
|
||||
used to indicate fatal errors that cannot be corrected, and require immediate
|
||||
attention.
|
||||
|
||||
Since there is no direct equivalent of the x86 SCI or NMI, arm64 handles
|
||||
these slightly differently. The SCI is handled as a normal GPIO-signaled
|
||||
interrupt; given that these are corrected (or correctable) errors being
|
||||
reported, this is sufficient. The NMI is emulated as the highest priority
|
||||
GPIO-signaled interrupt possible. This implies some caution must be used
|
||||
since there could be interrupts at higher privilege levels or even interrupts
|
||||
at the same priority as the emulated NMI. In Linux, this should not be the
|
||||
case but one should be aware it could happen.
|
||||
|
||||
|
||||
ACPI Objects Not Supported on ARM64
|
||||
-----------------------------------
|
||||
While this may change in the future, there are several classes of objects
|
||||
that can be defined, but are not currently of general interest to ARM servers.
|
||||
|
||||
These are not supported:
|
||||
|
||||
-- Section 9.2: ambient light sensor devices
|
||||
|
||||
-- Section 9.3: battery devices
|
||||
|
||||
-- Section 9.4: lids (e.g., laptop lids)
|
||||
|
||||
-- Section 9.8.2: IDE controllers
|
||||
|
||||
-- Section 9.9: floppy controllers
|
||||
|
||||
-- Section 9.10: GPE block devices
|
||||
|
||||
-- Section 9.15: PC/AT RTC/CMOS devices
|
||||
|
||||
-- Section 9.16: user presence detection devices
|
||||
|
||||
-- Section 9.17: I/O APIC devices; all GICs must be enumerable via MADT
|
||||
|
||||
-- Section 9.18: time and alarm devices (see 9.15)
|
||||
|
||||
|
||||
ACPI Objects Not Yet Implemented
|
||||
--------------------------------
|
||||
While these objects have x86 equivalents, and they do make some sense in ARM
|
||||
servers, there is either no hardware available at present, or in some cases
|
||||
there may not yet be a non-ARM implementation. Hence, they are currently not
|
||||
implemented though that may change in the future.
|
||||
|
||||
Not yet implemented are:
|
||||
|
||||
-- Section 10: power source and power meter devices
|
||||
|
||||
-- Section 11: thermal management
|
||||
|
||||
-- Section 12: embedded controllers interface
|
||||
|
||||
-- Section 13: SMBus interfaces
|
||||
|
||||
-- Section 17: NUMA support (prototypes have been submitted for
|
||||
review)
|
||||
|
|
@ -0,0 +1,505 @@
|
|||
ACPI on ARMv8 Servers
|
||||
---------------------
|
||||
ACPI can be used for ARMv8 general purpose servers designed to follow
|
||||
the ARM SBSA (Server Base System Architecture) [0] and SBBR (Server
|
||||
Base Boot Requirements) [1] specifications. Please note that the SBBR
|
||||
can be retrieved simply by visiting [1], but the SBSA is currently only
|
||||
available to those with an ARM login due to ARM IP licensing concerns.
|
||||
|
||||
The ARMv8 kernel implements the reduced hardware model of ACPI version
|
||||
5.1 or later. Links to the specification and all external documents
|
||||
it refers to are managed by the UEFI Forum. The specification is
|
||||
available at http://www.uefi.org/specifications and documents referenced
|
||||
by the specification can be found via http://www.uefi.org/acpi.
|
||||
|
||||
If an ARMv8 system does not meet the requirements of the SBSA and SBBR,
|
||||
or cannot be described using the mechanisms defined in the required ACPI
|
||||
specifications, then ACPI may not be a good fit for the hardware.
|
||||
|
||||
While the documents mentioned above set out the requirements for building
|
||||
industry-standard ARMv8 servers, they also apply to more than one operating
|
||||
system. The purpose of this document is to describe the interaction between
|
||||
ACPI and Linux only, on an ARMv8 system -- that is, what Linux expects of
|
||||
ACPI and what ACPI can expect of Linux.
|
||||
|
||||
|
||||
Why ACPI on ARM?
|
||||
----------------
|
||||
Before examining the details of the interface between ACPI and Linux, it is
|
||||
useful to understand why ACPI is being used. Several technologies already
|
||||
exist in Linux for describing non-enumerable hardware, after all. In this
|
||||
section we summarize a blog post [2] from Grant Likely that outlines the
|
||||
reasoning behind ACPI on ARMv8 servers. Actually, we snitch a good portion
|
||||
of the summary text almost directly, to be honest.
|
||||
|
||||
The short form of the rationale for ACPI on ARM is:
|
||||
|
||||
-- ACPI’s bytecode (AML) allows the platform to encode hardware behavior,
|
||||
while DT explicitly does not support this. For hardware vendors, being
|
||||
able to encode behavior is a key tool used in supporting operating
|
||||
system releases on new hardware.
|
||||
|
||||
-- ACPI’s OSPM defines a power management model that constrains what the
|
||||
platform is allowed to do into a specific model, while still providing
|
||||
flexibility in hardware design.
|
||||
|
||||
-- In the enterprise server environment, ACPI has established bindings (such
|
||||
as for RAS) which are currently used in production systems. DT does not.
|
||||
Such bindings could be defined in DT at some point, but doing so means ARM
|
||||
and x86 would end up using completely different code paths in both firmware
|
||||
and the kernel.
|
||||
|
||||
-- Choosing a single interface to describe the abstraction between a platform
|
||||
and an OS is important. Hardware vendors would not be required to implement
|
||||
both DT and ACPI if they want to support multiple operating systems. And,
|
||||
agreeing on a single interface instead of being fragmented into per OS
|
||||
interfaces makes for better interoperability overall.
|
||||
|
||||
-- The new ACPI governance process works well and Linux is now at the same
|
||||
table as hardware vendors and other OS vendors. In fact, there is no
|
||||
longer any reason to feel that ACPI is only belongs to Windows or that
|
||||
Linux is in any way secondary to Microsoft in this arena. The move of
|
||||
ACPI governance into the UEFI forum has significantly opened up the
|
||||
specification development process, and currently, a large portion of the
|
||||
changes being made to ACPI is being driven by Linux.
|
||||
|
||||
Key to the use of ACPI is the support model. For servers in general, the
|
||||
responsibility for hardware behaviour cannot solely be the domain of the
|
||||
kernel, but rather must be split between the platform and the kernel, in
|
||||
order to allow for orderly change over time. ACPI frees the OS from needing
|
||||
to understand all the minute details of the hardware so that the OS doesn’t
|
||||
need to be ported to each and every device individually. It allows the
|
||||
hardware vendors to take responsibility for power management behaviour without
|
||||
depending on an OS release cycle which is not under their control.
|
||||
|
||||
ACPI is also important because hardware and OS vendors have already worked
|
||||
out the mechanisms for supporting a general purpose computing ecosystem. The
|
||||
infrastructure is in place, the bindings are in place, and the processes are
|
||||
in place. DT does exactly what Linux needs it to when working with vertically
|
||||
integrated devices, but there are no good processes for supporting what the
|
||||
server vendors need. Linux could potentially get there with DT, but doing so
|
||||
really just duplicates something that already works. ACPI already does what
|
||||
the hardware vendors need, Microsoft won’t collaborate on DT, and hardware
|
||||
vendors would still end up providing two completely separate firmware
|
||||
interfaces -- one for Linux and one for Windows.
|
||||
|
||||
|
||||
Kernel Compatibility
|
||||
--------------------
|
||||
One of the primary motivations for ACPI is standardization, and using that
|
||||
to provide backward compatibility for Linux kernels. In the server market,
|
||||
software and hardware are often used for long periods. ACPI allows the
|
||||
kernel and firmware to agree on a consistent abstraction that can be
|
||||
maintained over time, even as hardware or software change. As long as the
|
||||
abstraction is supported, systems can be updated without necessarily having
|
||||
to replace the kernel.
|
||||
|
||||
When a Linux driver or subsystem is first implemented using ACPI, it by
|
||||
definition ends up requiring a specific version of the ACPI specification
|
||||
-- it's baseline. ACPI firmware must continue to work, even though it may
|
||||
not be optimal, with the earliest kernel version that first provides support
|
||||
for that baseline version of ACPI. There may be a need for additional drivers,
|
||||
but adding new functionality (e.g., CPU power management) should not break
|
||||
older kernel versions. Further, ACPI firmware must also work with the most
|
||||
recent version of the kernel.
|
||||
|
||||
|
||||
Relationship with Device Tree
|
||||
-----------------------------
|
||||
ACPI support in drivers and subsystems for ARMv8 should never be mutually
|
||||
exclusive with DT support at compile time.
|
||||
|
||||
At boot time the kernel will only use one description method depending on
|
||||
parameters passed from the bootloader (including kernel bootargs).
|
||||
|
||||
Regardless of whether DT or ACPI is used, the kernel must always be capable
|
||||
of booting with either scheme (in kernels with both schemes enabled at compile
|
||||
time).
|
||||
|
||||
|
||||
Booting using ACPI tables
|
||||
-------------------------
|
||||
The only defined method for passing ACPI tables to the kernel on ARMv8
|
||||
is via the UEFI system configuration table. Just so it is explicit, this
|
||||
means that ACPI is only supported on platforms that boot via UEFI.
|
||||
|
||||
When an ARMv8 system boots, it can either have DT information, ACPI tables,
|
||||
or in some very unusual cases, both. If no command line parameters are used,
|
||||
the kernel will try to use DT for device enumeration; if there is no DT
|
||||
present, the kernel will try to use ACPI tables, but only if they are present.
|
||||
In neither is available, the kernel will not boot. If acpi=force is used
|
||||
on the command line, the kernel will attempt to use ACPI tables first, but
|
||||
fall back to DT if there are no ACPI tables present. The basic idea is that
|
||||
the kernel will not fail to boot unless it absolutely has no other choice.
|
||||
|
||||
Processing of ACPI tables may be disabled by passing acpi=off on the kernel
|
||||
command line; this is the default behavior.
|
||||
|
||||
In order for the kernel to load and use ACPI tables, the UEFI implementation
|
||||
MUST set the ACPI_20_TABLE_GUID to point to the RSDP table (the table with
|
||||
the ACPI signature "RSD PTR "). If this pointer is incorrect and acpi=force
|
||||
is used, the kernel will disable ACPI and try to use DT to boot instead; the
|
||||
kernel has, in effect, determined that ACPI tables are not present at that
|
||||
point.
|
||||
|
||||
If the pointer to the RSDP table is correct, the table will be mapped into
|
||||
the kernel by the ACPI core, using the address provided by UEFI.
|
||||
|
||||
The ACPI core will then locate and map in all other ACPI tables provided by
|
||||
using the addresses in the RSDP table to find the XSDT (eXtended System
|
||||
Description Table). The XSDT in turn provides the addresses to all other
|
||||
ACPI tables provided by the system firmware; the ACPI core will then traverse
|
||||
this table and map in the tables listed.
|
||||
|
||||
The ACPI core will ignore any provided RSDT (Root System Description Table).
|
||||
RSDTs have been deprecated and are ignored on arm64 since they only allow
|
||||
for 32-bit addresses.
|
||||
|
||||
Further, the ACPI core will only use the 64-bit address fields in the FADT
|
||||
(Fixed ACPI Description Table). Any 32-bit address fields in the FADT will
|
||||
be ignored on arm64.
|
||||
|
||||
Hardware reduced mode (see Section 4.1 of the ACPI 5.1 specification) will
|
||||
be enforced by the ACPI core on arm64. Doing so allows the ACPI core to
|
||||
run less complex code since it no longer has to provide support for legacy
|
||||
hardware from other architectures. Any fields that are not to be used for
|
||||
hardware reduced mode must be set to zero.
|
||||
|
||||
For the ACPI core to operate properly, and in turn provide the information
|
||||
the kernel needs to configure devices, it expects to find the following
|
||||
tables (all section numbers refer to the ACPI 5.1 specfication):
|
||||
|
||||
-- RSDP (Root System Description Pointer), section 5.2.5
|
||||
|
||||
-- XSDT (eXtended System Description Table), section 5.2.8
|
||||
|
||||
-- FADT (Fixed ACPI Description Table), section 5.2.9
|
||||
|
||||
-- DSDT (Differentiated System Description Table), section
|
||||
5.2.11.1
|
||||
|
||||
-- MADT (Multiple APIC Description Table), section 5.2.12
|
||||
|
||||
-- GTDT (Generic Timer Description Table), section 5.2.24
|
||||
|
||||
-- If PCI is supported, the MCFG (Memory mapped ConFiGuration
|
||||
Table), section 5.2.6, specifically Table 5-31.
|
||||
|
||||
If the above tables are not all present, the kernel may or may not be
|
||||
able to boot properly since it may not be able to configure all of the
|
||||
devices available.
|
||||
|
||||
|
||||
ACPI Detection
|
||||
--------------
|
||||
Drivers should determine their probe() type by checking for a null
|
||||
value for ACPI_HANDLE, or checking .of_node, or other information in
|
||||
the device structure. This is detailed further in the "Driver
|
||||
Recommendations" section.
|
||||
|
||||
In non-driver code, if the presence of ACPI needs to be detected at
|
||||
runtime, then check the value of acpi_disabled. If CONFIG_ACPI is not
|
||||
set, acpi_disabled will always be 1.
|
||||
|
||||
|
||||
Device Enumeration
|
||||
------------------
|
||||
Device descriptions in ACPI should use standard recognized ACPI interfaces.
|
||||
These may contain less information than is typically provided via a Device
|
||||
Tree description for the same device. This is also one of the reasons that
|
||||
ACPI can be useful -- the driver takes into account that it may have less
|
||||
detailed information about the device and uses sensible defaults instead.
|
||||
If done properly in the driver, the hardware can change and improve over
|
||||
time without the driver having to change at all.
|
||||
|
||||
Clocks provide an excellent example. In DT, clocks need to be specified
|
||||
and the drivers need to take them into account. In ACPI, the assumption
|
||||
is that UEFI will leave the device in a reasonable default state, including
|
||||
any clock settings. If for some reason the driver needs to change a clock
|
||||
value, this can be done in an ACPI method; all the driver needs to do is
|
||||
invoke the method and not concern itself with what the method needs to do
|
||||
to change the clock. Changing the hardware can then take place over time
|
||||
by changing what the ACPI method does, and not the driver.
|
||||
|
||||
In DT, the parameters needed by the driver to set up clocks as in the example
|
||||
above are known as "bindings"; in ACPI, these are known as "Device Properties"
|
||||
and provided to a driver via the _DSD object.
|
||||
|
||||
ACPI tables are described with a formal language called ASL, the ACPI
|
||||
Source Language (section 19 of the specification). This means that there
|
||||
are always multiple ways to describe the same thing -- including device
|
||||
properties. For example, device properties could use an ASL construct
|
||||
that looks like this: Name(KEY0, "value0"). An ACPI device driver would
|
||||
then retrieve the value of the property by evaluating the KEY0 object.
|
||||
However, using Name() this way has multiple problems: (1) ACPI limits
|
||||
names ("KEY0") to four characters unlike DT; (2) there is no industry
|
||||
wide registry that maintains a list of names, minimzing re-use; (3)
|
||||
there is also no registry for the definition of property values ("value0"),
|
||||
again making re-use difficult; and (4) how does one maintain backward
|
||||
compatibility as new hardware comes out? The _DSD method was created
|
||||
to solve precisely these sorts of problems; Linux drivers should ALWAYS
|
||||
use the _DSD method for device properties and nothing else.
|
||||
|
||||
The _DSM object (ACPI Section 9.14.1) could also be used for conveying
|
||||
device properties to a driver. Linux drivers should only expect it to
|
||||
be used if _DSD cannot represent the data required, and there is no way
|
||||
to create a new UUID for the _DSD object. Note that there is even less
|
||||
regulation of the use of _DSM than there is of _DSD. Drivers that depend
|
||||
on the contents of _DSM objects will be more difficult to maintain over
|
||||
time because of this; as of this writing, the use of _DSM is the cause
|
||||
of quite a few firmware problems and is not recommended.
|
||||
|
||||
Drivers should look for device properties in the _DSD object ONLY; the _DSD
|
||||
object is described in the ACPI specification section 6.2.5, but this only
|
||||
describes how to define the structure of an object returned via _DSD, and
|
||||
how specific data structures are defined by specific UUIDs. Linux should
|
||||
only use the _DSD Device Properties UUID [5]:
|
||||
|
||||
-- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
|
||||
|
||||
-- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
|
||||
|
||||
The UEFI Forum provides a mechanism for registering device properties [4]
|
||||
so that they may be used across all operating systems supporting ACPI.
|
||||
Device properties that have not been registered with the UEFI Forum should
|
||||
not be used.
|
||||
|
||||
Before creating new device properties, check to be sure that they have not
|
||||
been defined before and either registered in the Linux kernel documentation
|
||||
as DT bindings, or the UEFI Forum as device properties. While we do not want
|
||||
to simply move all DT bindings into ACPI device properties, we can learn from
|
||||
what has been previously defined.
|
||||
|
||||
If it is necessary to define a new device property, or if it makes sense to
|
||||
synthesize the definition of a binding so it can be used in any firmware,
|
||||
both DT bindings and ACPI device properties for device drivers have review
|
||||
processes. Use them both. When the driver itself is submitted for review
|
||||
to the Linux mailing lists, the device property definitions needed must be
|
||||
submitted at the same time. A driver that supports ACPI and uses device
|
||||
properties will not be considered complete without their definitions. Once
|
||||
the device property has been accepted by the Linux community, it must be
|
||||
registered with the UEFI Forum [4], which will review it again for consistency
|
||||
within the registry. This may require iteration. The UEFI Forum, though,
|
||||
will always be the canonical site for device property definitions.
|
||||
|
||||
It may make sense to provide notice to the UEFI Forum that there is the
|
||||
intent to register a previously unused device property name as a means of
|
||||
reserving the name for later use. Other operating system vendors will
|
||||
also be submitting registration requests and this may help smooth the
|
||||
process.
|
||||
|
||||
Once registration and review have been completed, the kernel provides an
|
||||
interface for looking up device properties in a manner independent of
|
||||
whether DT or ACPI is being used. This API should be used [6]; it can
|
||||
eliminate some duplication of code paths in driver probing functions and
|
||||
discourage divergence between DT bindings and ACPI device properties.
|
||||
|
||||
|
||||
Programmable Power Control Resources
|
||||
------------------------------------
|
||||
Programmable power control resources include such resources as voltage/current
|
||||
providers (regulators) and clock sources.
|
||||
|
||||
With ACPI, the kernel clock and regulator framework is not expected to be used
|
||||
at all.
|
||||
|
||||
The kernel assumes that power control of these resources is represented with
|
||||
Power Resource Objects (ACPI section 7.1). The ACPI core will then handle
|
||||
correctly enabling and disabling resources as they are needed. In order to
|
||||
get that to work, ACPI assumes each device has defined D-states and that these
|
||||
can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and _PS3;
|
||||
in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 is for
|
||||
turning a device full off.
|
||||
|
||||
There are two options for using those Power Resources. They can:
|
||||
|
||||
-- be managed in a _PSx method which gets called on entry to power
|
||||
state Dx.
|
||||
|
||||
-- be declared separately as power resources with their own _ON and _OFF
|
||||
methods. They are then tied back to D-states for a particular device
|
||||
via _PRx which specifies which power resources a device needs to be on
|
||||
while in Dx. Kernel then tracks number of devices using a power resource
|
||||
and calls _ON/_OFF as needed.
|
||||
|
||||
The kernel ACPI code will also assume that the _PSx methods follow the normal
|
||||
ACPI rules for such methods:
|
||||
|
||||
-- If either _PS0 or _PS3 is implemented, then the other method must also
|
||||
be implemented.
|
||||
|
||||
-- If a device requires usage or setup of a power resource when on, the ASL
|
||||
should organize that it is allocated/enabled using the _PS0 method.
|
||||
|
||||
-- Resources allocated or enabled in the _PS0 method should be disabled
|
||||
or de-allocated in the _PS3 method.
|
||||
|
||||
-- Firmware will leave the resources in a reasonable state before handing
|
||||
over control to the kernel.
|
||||
|
||||
Such code in _PSx methods will of course be very platform specific. But,
|
||||
this allows the driver to abstract out the interface for operating the device
|
||||
and avoid having to read special non-standard values from ACPI tables. Further,
|
||||
abstracting the use of these resources allows the hardware to change over time
|
||||
without requiring updates to the driver.
|
||||
|
||||
|
||||
Clocks
|
||||
------
|
||||
ACPI makes the assumption that clocks are initialized by the firmware --
|
||||
UEFI, in this case -- to some working value before control is handed over
|
||||
to the kernel. This has implications for devices such as UARTs, or SoC-driven
|
||||
LCD displays, for example.
|
||||
|
||||
When the kernel boots, the clocks are assumed to be set to reasonable
|
||||
working values. If for some reason the frequency needs to change -- e.g.,
|
||||
throttling for power management -- the device driver should expect that
|
||||
process to be abstracted out into some ACPI method that can be invoked
|
||||
(please see the ACPI specification for further recommendations on standard
|
||||
methods to be expected). The only exceptions to this are CPU clocks where
|
||||
CPPC provides a much richer interface than ACPI methods. If the clocks
|
||||
are not set, there is no direct way for Linux to control them.
|
||||
|
||||
If an SoC vendor wants to provide fine-grained control of the system clocks,
|
||||
they could do so by providing ACPI methods that could be invoked by Linux
|
||||
drivers. However, this is NOT recommended and Linux drivers should NOT use
|
||||
such methods, even if they are provided. Such methods are not currently
|
||||
standardized in the ACPI specification, and using them could tie a kernel
|
||||
to a very specific SoC, or tie an SoC to a very specific version of the
|
||||
kernel, both of which we are trying to avoid.
|
||||
|
||||
|
||||
Driver Recommendations
|
||||
----------------------
|
||||
DO NOT remove any DT handling when adding ACPI support for a driver. The
|
||||
same device may be used on many different systems.
|
||||
|
||||
DO try to structure the driver so that it is data-driven. That is, set up
|
||||
a struct containing internal per-device state based on defaults and whatever
|
||||
else must be discovered by the driver probe function. Then, have the rest
|
||||
of the driver operate off of the contents of that struct. Doing so should
|
||||
allow most divergence between ACPI and DT functionality to be kept local to
|
||||
the probe function instead of being scattered throughout the driver. For
|
||||
example:
|
||||
|
||||
static int device_probe_dt(struct platform_device *pdev)
|
||||
{
|
||||
/* DT specific functionality */
|
||||
...
|
||||
}
|
||||
|
||||
static int device_probe_acpi(struct platform_device *pdev)
|
||||
{
|
||||
/* ACPI specific functionality */
|
||||
...
|
||||
}
|
||||
|
||||
static int device_probe(struct platform_device *pdev)
|
||||
{
|
||||
...
|
||||
struct device_node node = pdev->dev.of_node;
|
||||
...
|
||||
|
||||
if (node)
|
||||
ret = device_probe_dt(pdev);
|
||||
else if (ACPI_HANDLE(&pdev->dev))
|
||||
ret = device_probe_acpi(pdev);
|
||||
else
|
||||
/* other initialization */
|
||||
...
|
||||
/* Continue with any generic probe operations */
|
||||
...
|
||||
}
|
||||
|
||||
DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it
|
||||
clear the different names the driver is probed for, both from DT and from
|
||||
ACPI:
|
||||
|
||||
static struct of_device_id virtio_mmio_match[] = {
|
||||
{ .compatible = "virtio,mmio", },
|
||||
{ }
|
||||
};
|
||||
MODULE_DEVICE_TABLE(of, virtio_mmio_match);
|
||||
|
||||
static const struct acpi_device_id virtio_mmio_acpi_match[] = {
|
||||
{ "LNRO0005", },
|
||||
{ }
|
||||
};
|
||||
MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
|
||||
|
||||
|
||||
ASWG
|
||||
----
|
||||
The ACPI specification changes regularly. During the year 2014, for instance,
|
||||
version 5.1 was released and version 6.0 substantially completed, with most of
|
||||
the changes being driven by ARM-specific requirements. Proposed changes are
|
||||
presented and discussed in the ASWG (ACPI Specification Working Group) which
|
||||
is a part of the UEFI Forum.
|
||||
|
||||
Participation in this group is open to all UEFI members. Please see
|
||||
http://www.uefi.org/workinggroup for details on group membership.
|
||||
|
||||
It is the intent of the ARMv8 ACPI kernel code to follow the ACPI specification
|
||||
as closely as possible, and to only implement functionality that complies with
|
||||
the released standards from UEFI ASWG. As a practical matter, there will be
|
||||
vendors that provide bad ACPI tables or violate the standards in some way.
|
||||
If this is because of errors, quirks and fixups may be necessary, but will
|
||||
be avoided if possible. If there are features missing from ACPI that preclude
|
||||
it from being used on a platform, ECRs (Engineering Change Requests) should be
|
||||
submitted to ASWG and go through the normal approval process; for those that
|
||||
are not UEFI members, many other members of the Linux community are and would
|
||||
likely be willing to assist in submitting ECRs.
|
||||
|
||||
|
||||
Linux Code
|
||||
----------
|
||||
Individual items specific to Linux on ARM, contained in the the Linux
|
||||
source code, are in the list that follows:
|
||||
|
||||
ACPI_OS_NAME This macro defines the string to be returned when
|
||||
an ACPI method invokes the _OS method. On ARM64
|
||||
systems, this macro will be "Linux" by default.
|
||||
The command line parameter acpi_os=<string>
|
||||
can be used to set it to some other value. The
|
||||
default value for other architectures is "Microsoft
|
||||
Windows NT", for example.
|
||||
|
||||
ACPI Objects
|
||||
------------
|
||||
Detailed expectations for ACPI tables and object are listed in the file
|
||||
Documentation/arm64/acpi_object_usage.txt.
|
||||
|
||||
|
||||
References
|
||||
----------
|
||||
[0] http://silver.arm.com -- document ARM-DEN-0029, or newer
|
||||
"Server Base System Architecture", version 2.3, dated 27 Mar 2014
|
||||
|
||||
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0044a/Server_Base_Boot_Requirements.pdf
|
||||
Document ARM-DEN-0044A, or newer: "Server Base Boot Requirements, System
|
||||
Software on ARM Platforms", dated 16 Aug 2014
|
||||
|
||||
[2] http://www.secretlab.ca/archives/151, 10 Jan 2015, Copyright (c) 2015,
|
||||
Linaro Ltd., written by Grant Likely. A copy of the verbatim text (apart
|
||||
from formatting) is also in Documentation/arm64/why_use_acpi.txt.
|
||||
|
||||
[3] AMD ACPI for Seattle platform documentation:
|
||||
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Seattle_ACPI_Guide.pdf
|
||||
|
||||
[4] http://www.uefi.org/acpi -- please see the link for the "ACPI _DSD Device
|
||||
Property Registry Instructions"
|
||||
|
||||
[5] http://www.uefi.org/acpi -- please see the link for the "_DSD (Device
|
||||
Specific Data) Implementation Guide"
|
||||
|
||||
[6] Kernel code for the unified device property interface can be found in
|
||||
include/linux/property.h and drivers/base/property.c.
|
||||
|
||||
|
||||
Authors
|
||||
-------
|
||||
Al Stone <al.stone@linaro.org>
|
||||
Graeme Gregory <graeme.gregory@linaro.org>
|
||||
Hanjun Guo <hanjun.guo@linaro.org>
|
||||
|
||||
Grant Likely <grant.likely@linaro.org>, for the "Why ACPI on ARM?" section
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
* ARC Performance Counters
|
||||
|
||||
The ARC700 can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters
|
||||
|
||||
Note that:
|
||||
* The ARC 700 PCT does not support interrupts; although HW events may be
|
||||
counted, the HW events themselves cannot serve as a trigger for a sample.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,arc700-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,arc700-pct";
|
||||
};
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
* ARC Performance Monitor Unit
|
||||
|
||||
The ARC 700 can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits.
|
||||
|
||||
Note that:
|
||||
* ARC 700 refers to a family of ARC processor cores;
|
||||
- There is only one type of PMU available for the whole family;
|
||||
- The PMU may support different sets of events; supported events are probed
|
||||
at boot time, as required by the reference manual.
|
||||
|
||||
* The ARC 700 PMU does not support interrupts; although HW events may be
|
||||
counted, the HW events themselves cannot serve as a trigger for a sample.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,arc700-pmu"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,arc700-pmu";
|
||||
};
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
Annapurna Labs Alpine Platform Device Tree Bindings
|
||||
---------------------------------------------------------------
|
||||
|
||||
Boards in the Alpine family shall have the following properties:
|
||||
|
||||
* Required root node properties:
|
||||
compatible: must contain "al,alpine"
|
||||
|
||||
* Example:
|
||||
|
||||
/ {
|
||||
model = "Annapurna Labs Alpine Dev Board";
|
||||
compatible = "al,alpine";
|
||||
|
||||
...
|
||||
}
|
||||
|
||||
* CPU node:
|
||||
|
||||
The Alpine platform includes cortex-a15 cores.
|
||||
enable-method: must be "al,alpine-smp" to allow smp [1]
|
||||
|
||||
Example:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
enable-method = "al,alpine-smp";
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <2>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <3>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
* Alpine CPU resume registers
|
||||
|
||||
The CPU resume register are used to define required resume address after
|
||||
reset.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-cpu-resume".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
cpu_resume {
|
||||
compatible = "al,alpine-cpu-resume";
|
||||
reg = <0xfbff5ed0 0x30>;
|
||||
};
|
||||
|
||||
* Alpine System-Fabric Service Registers
|
||||
|
||||
The System-Fabric Service Registers allow various operation on CPU and
|
||||
system fabric, like powering CPUs off.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
nb_service {
|
||||
compatible = "al,alpine-sysfabric-service", "syscon";
|
||||
reg = <0xfb070000 0x10000>;
|
||||
};
|
||||
|
||||
[1] arm/cpu-enable-method/al,alpine-smp
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Altera's SoCFPGA platform device tree bindings
|
||||
---------------------------------------------
|
||||
|
||||
Boards with Cyclone 5 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-cyclone5", "altr,socfpga";
|
||||
|
||||
Boards with Arria 5 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-arria5", "altr,socfpga";
|
||||
|
||||
Boards with Arria 10 SoC:
|
||||
Required root node properties:
|
||||
compatible = "altr,socfpga-arria10", "altr,socfpga";
|
||||
|
|
@ -8,3 +8,7 @@ Boards with the Amlogic Meson6 SoC shall have the following properties:
|
|||
Boards with the Amlogic Meson8 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson8";
|
||||
|
||||
Board compatible values:
|
||||
- "geniatech,atv1200"
|
||||
- "minix,neo-x8"
|
||||
|
|
|
|||
|
|
@ -17,7 +17,10 @@ to deliver its interrupts via SPIs.
|
|||
- interrupts : Interrupt list for secure, non-secure, virtual and
|
||||
hypervisor timers, in that order.
|
||||
|
||||
- clock-frequency : The frequency of the main counter, in Hz. Optional.
|
||||
- clock-frequency : The frequency of the main counter, in Hz. Should be present
|
||||
only where necessary to work around broken firmware which does not configure
|
||||
CNTFRQ on all CPUs to a uniform correct value. Use of this property is
|
||||
strongly discouraged; fix your firmware unless absolutely impossible.
|
||||
|
||||
- always-on : a boolean property. If present, the timer is powered through an
|
||||
always-on power domain, therefore it never loses context.
|
||||
|
|
@ -46,7 +49,8 @@ Example:
|
|||
|
||||
- compatible : Should at least contain "arm,armv7-timer-mem".
|
||||
|
||||
- clock-frequency : The frequency of the main counter, in Hz. Optional.
|
||||
- clock-frequency : The frequency of the main counter, in Hz. Should be present
|
||||
only when firmware has not configured the MMIO CNTFRQ registers.
|
||||
|
||||
- reg : The control frame base address.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
Marvell Armada 39x Platforms Device Tree Bindings
|
||||
-------------------------------------------------
|
||||
|
||||
Boards with a SoC of the Marvell Armada 39x family shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
- compatible: must contain "marvell,armada390"
|
||||
|
||||
In addition, boards using the Marvell Armada 398 SoC shall have the
|
||||
following property before the previous one:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "marvell,armada398"
|
||||
|
||||
Example:
|
||||
|
||||
compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390";
|
||||
|
|
@ -46,10 +46,12 @@ PIT Timer required properties:
|
|||
shared across all System Controller members.
|
||||
|
||||
System Timer (ST) required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-st"
|
||||
- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
TC/TCLIB Timer required properties:
|
||||
- compatible: Should be "atmel,<chip>-tcb".
|
||||
|
|
|
|||
|
|
@ -94,8 +94,11 @@ specific to ARM.
|
|||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "arm,cci-400-pmu"
|
||||
|
||||
Definition: Must contain one of:
|
||||
"arm,cci-400-pmu,r0"
|
||||
"arm,cci-400-pmu,r1"
|
||||
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
|
||||
secure acces to CCI registers
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: Integer cells. A register entry, expressed
|
||||
|
|
|
|||
|
|
@ -61,7 +61,6 @@ Example:
|
|||
compatible = "arm,coresight-etb10", "arm,primecell";
|
||||
reg = <0 0x20010000 0 0x1000>;
|
||||
|
||||
coresight-default-sink;
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
========================================================
|
||||
Secondary CPU enable-method "al,alpine-smp" binding
|
||||
========================================================
|
||||
|
||||
This document describes the "al,alpine-smp" method for
|
||||
enabling secondary CPUs. To apply to all CPUs, a single
|
||||
"al,alpine-smp" enable method should be defined in the
|
||||
"cpus" node.
|
||||
|
||||
Enable method name: "al,alpine-smp"
|
||||
Compatible machines: "al,alpine"
|
||||
Compatible CPUs: "arm,cortex-a15"
|
||||
Related properties: (none)
|
||||
|
||||
Note:
|
||||
This enable method requires valid nodes compatible with
|
||||
"al,alpine-cpu-resume" and "al,alpine-nb-service"[1].
|
||||
|
||||
Example:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
enable-method = "al,alpine-smp";
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <2>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <3>;
|
||||
};
|
||||
};
|
||||
|
||||
--
|
||||
[1] arm/al,alpine.txt
|
||||
|
|
@ -192,6 +192,7 @@ nodes to be present and contain the properties described below.
|
|||
"brcm,brahma-b15"
|
||||
"marvell,armada-375-smp"
|
||||
"marvell,armada-380-smp"
|
||||
"marvell,armada-390-smp"
|
||||
"marvell,armada-xp-smp"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,kpss-acc-v1"
|
||||
|
|
|
|||
|
|
@ -22,6 +22,9 @@ Optional Properties:
|
|||
- pclkN, clkN: Pairs of parent of input clock and input clock to the
|
||||
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
|
||||
are supported currently.
|
||||
- asbN: Clocks required by asynchronous bridges (ASB) present in
|
||||
the power domain. These clock should be enabled during power
|
||||
domain on/off operations.
|
||||
- power-domains: phandle pointing to the parent power domain, for more details
|
||||
see Documentation/devicetree/bindings/power/power_domain.txt
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +0,0 @@
|
|||
Geniatech platforms device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Geniatech ATV1200
|
||||
- compatible = "geniatech,atv1200"
|
||||
|
|
@ -18,6 +18,8 @@ Main node required properties:
|
|||
"arm,arm11mp-gic"
|
||||
"brcm,brahma-b15-gic"
|
||||
"arm,arm1176jzf-devchip-gic"
|
||||
"qcom,msm-8660-qgic"
|
||||
"qcom,msm-qgic2"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
|
|
|||
|
|
@ -42,6 +42,7 @@ board. Currently known boards are:
|
|||
"lacie,cloudbox"
|
||||
"lacie,inetspace_v2"
|
||||
"lacie,laplug"
|
||||
"lacie,nas2big"
|
||||
"lacie,netspace_lite_v2"
|
||||
"lacie,netspace_max_v2"
|
||||
"lacie,netspace_mini_v2"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,84 @@
|
|||
QCOM Idle States for cpuidle driver
|
||||
|
||||
ARM provides idle-state node to define the cpuidle states, as defined in [1].
|
||||
cpuidle-qcom is the cpuidle driver for Qualcomm SoCs and uses these idle
|
||||
states. Idle states have different enter/exit latency and residency values.
|
||||
The idle states supported by the QCOM SoC are defined as -
|
||||
|
||||
* Standby
|
||||
* Retention
|
||||
* Standalone Power Collapse (Standalone PC or SPC)
|
||||
* Power Collapse (PC)
|
||||
|
||||
Standby: Standby does a little more in addition to architectural clock gating.
|
||||
When the WFI instruction is executed the ARM core would gate its internal
|
||||
clocks. In addition to gating the clocks, QCOM cpus use this instruction as a
|
||||
trigger to execute the SPM state machine. The SPM state machine waits for the
|
||||
interrupt to trigger the core back in to active. This triggers the cache
|
||||
hierarchy to enter standby states, when all cpus are idle. An interrupt brings
|
||||
the SPM state machine out of its wait, the next step is to ensure that the
|
||||
cache hierarchy is also out of standby, and then the cpu is allowed to resume
|
||||
execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
|
||||
driver and is not defined in the DT. The SPM state machine should be
|
||||
configured to execute this state by default and after executing every other
|
||||
state below.
|
||||
|
||||
Retention: Retention is a low power state where the core is clock gated and
|
||||
the memory and the registers associated with the core are retained. The
|
||||
voltage may be reduced to the minimum value needed to keep the processor
|
||||
registers active. The SPM should be configured to execute the retention
|
||||
sequence and would wait for interrupt, before restoring the cpu to execution
|
||||
state. Retention may have a slightly higher latency than Standby.
|
||||
|
||||
Standalone PC: A cpu can power down and warmboot if there is a sufficient time
|
||||
between the time it enters idle and the next known wake up. SPC mode is used
|
||||
to indicate a core entering a power down state without consulting any other
|
||||
cpu or the system resources. This helps save power only on that core. The SPM
|
||||
sequence for this idle state is programmed to power down the supply to the
|
||||
core, wait for the interrupt, restore power to the core, and ensure the
|
||||
system state including cache hierarchy is ready before allowing core to
|
||||
resume. Applying power and resetting the core causes the core to warmboot
|
||||
back into Elevation Level (EL) which trampolines the control back to the
|
||||
kernel. Entering a power down state for the cpu, needs to be done by trapping
|
||||
into a EL. Failing to do so, would result in a crash enforced by the warm boot
|
||||
code in the EL for the SoC. On SoCs with write-back L1 cache, the cache has to
|
||||
be flushed in s/w, before powering down the core.
|
||||
|
||||
Power Collapse: This state is similar to the SPC mode, but distinguishes
|
||||
itself in that the cpu acknowledges and permits the SoC to enter deeper sleep
|
||||
modes. In a hierarchical power domain SoC, this means L2 and other caches can
|
||||
be flushed, system bus, clocks - lowered, and SoC main XO clock gated and
|
||||
voltages reduced, provided all cpus enter this state. Since the span of low
|
||||
power modes possible at this state is vast, the exit latency and the residency
|
||||
of this low power mode would be considered high even though at a cpu level,
|
||||
this essentially is cpu power down. The SPM in this state also may handshake
|
||||
with the Resource power manager (RPM) processor in the SoC to indicate a
|
||||
complete application processor subsystem shut down.
|
||||
|
||||
The idle-state for QCOM SoCs are distinguished by the compatible property of
|
||||
the idle-states device node.
|
||||
|
||||
The devicetree representation of the idle state should be -
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be one of -
|
||||
"qcom,idle-state-ret",
|
||||
"qcom,idle-state-spc",
|
||||
"qcom,idle-state-pc",
|
||||
and "arm,idle-state".
|
||||
|
||||
Other required and optional properties are specified in [1].
|
||||
|
||||
Example:
|
||||
|
||||
idle-states {
|
||||
CPU_SPC: spc {
|
||||
compatible = "qcom,idle-state-spc", "arm,idle-state";
|
||||
entry-latency-us = <150>;
|
||||
exit-latency-us = <200>;
|
||||
min-residency-us = <2000>;
|
||||
};
|
||||
};
|
||||
|
||||
[1]. Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
|
|
@ -2,22 +2,31 @@ SPM AVS Wrapper 2 (SAW2)
|
|||
|
||||
The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
|
||||
Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
|
||||
micro-controller that transitions a piece of hardware (like a processor or
|
||||
power-controller that transitions a piece of hardware (like a processor or
|
||||
subsystem) into and out of low power modes via a direct connection to
|
||||
the PMIC. It can also be wired up to interact with other processors in the
|
||||
system, notifying them when a low power state is entered or exited.
|
||||
|
||||
Multiple revisions of the SAW hardware are supported using these Device Nodes.
|
||||
SAW2 revisions differ in the register offset and configuration data. Also, the
|
||||
same revision of the SAW in different SoCs may have different configuration
|
||||
data due the the differences in hardware capabilities. Hence the SoC name, the
|
||||
version of the SAW hardware in that SoC and the distinction between cpu (big
|
||||
or Little) or cache, may be needed to uniquely identify the SAW register
|
||||
configuration and initialization data. The compatible string is used to
|
||||
indicate this parameter.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: shall contain "qcom,saw2". A more specific value should be
|
||||
one of:
|
||||
"qcom,saw2-v1"
|
||||
"qcom,saw2-v1.1"
|
||||
"qcom,saw2-v2"
|
||||
"qcom,saw2-v2.1"
|
||||
Definition: Must have
|
||||
"qcom,saw2"
|
||||
A more specific value could be one of:
|
||||
"qcom,apq8064-saw2-v1.1-cpu"
|
||||
"qcom,msm8974-saw2-v2.1-cpu"
|
||||
"qcom,apq8084-saw2-v2.1-cpu"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
|
|
@ -26,10 +35,23 @@ PROPERTIES
|
|||
the register region. An optional second element specifies
|
||||
the base address and size of the alias register region.
|
||||
|
||||
- regulator:
|
||||
Usage: optional
|
||||
Value type: boolean
|
||||
Definition: Indicates that this SPM device acts as a regulator device
|
||||
device for the core (CPU or Cache) the SPM is attached
|
||||
to.
|
||||
|
||||
Example:
|
||||
Example 1:
|
||||
|
||||
regulator@2099000 {
|
||||
power-controller@2099000 {
|
||||
compatible = "qcom,saw2";
|
||||
reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
|
||||
regulator;
|
||||
};
|
||||
|
||||
Example 2:
|
||||
saw0: power-controller@f9089000 {
|
||||
compatible = "qcom,apq8084-saw2-v2.1-cpu", "qcom,saw2";
|
||||
reg = <0xf9089000 0x1000>, <0xf9009000 0x1000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -9,11 +9,17 @@ Properties:
|
|||
"qcom,scss-timer" - scorpion subsystem
|
||||
|
||||
- interrupts : Interrupts for the debug timer, the first general purpose
|
||||
timer, and optionally a second general purpose timer in that
|
||||
order.
|
||||
timer, and optionally a second general purpose timer, and
|
||||
optionally as well, 2 watchdog interrupts, in that order.
|
||||
|
||||
- reg : Specifies the base address of the timer registers.
|
||||
|
||||
- clocks: Reference to the parent clocks, one per output clock. The parents
|
||||
must appear in the same order as the clock names.
|
||||
|
||||
- clock-names: The name of the clocks as free-form strings. They should be in
|
||||
the same order as the clocks.
|
||||
|
||||
- clock-frequency : The frequency of the debug timer and the general purpose
|
||||
timer(s) in Hz in that order.
|
||||
|
||||
|
|
@ -29,9 +35,13 @@ Example:
|
|||
compatible = "qcom,scss-timer", "qcom,msm-timer";
|
||||
interrupts = <1 1 0x301>,
|
||||
<1 2 0x301>,
|
||||
<1 3 0x301>;
|
||||
<1 3 0x301>,
|
||||
<1 4 0x301>,
|
||||
<1 5 0x301>;
|
||||
reg = <0x0200a000 0x100>;
|
||||
clock-frequency = <19200000>,
|
||||
<32768>;
|
||||
clocks = <&sleep_clk>;
|
||||
clock-names = "sleep";
|
||||
cpu-offset = <0x40000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
OMAP Control Module bindings
|
||||
|
||||
Control Module contains miscellaneous features under it based on SoC type.
|
||||
Pincontrol is one common feature, and it has a specialized support
|
||||
described in [1]. Typically some clock nodes are also under control module.
|
||||
Syscon is used to share register level access to drivers external to
|
||||
control module driver itself.
|
||||
|
||||
See [2] for documentation about clock/clockdomain nodes.
|
||||
|
||||
[1] Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
|
||||
[2] Documentation/devicetree/bindings/clock/ti/*
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
"ti,am3-scm"
|
||||
"ti,am4-scm"
|
||||
"ti,dm814-scrm"
|
||||
"ti,dm816-scrm"
|
||||
"ti,omap2-scm"
|
||||
"ti,omap3-scm"
|
||||
"ti,omap4-scm-core"
|
||||
"ti,omap4-scm-padconf-core"
|
||||
"ti,omap5-scm-core"
|
||||
"ti,omap5-scm-padconf-core"
|
||||
"ti,dra7-scm-core"
|
||||
- reg: Contains Control Module register address range
|
||||
(base address and length)
|
||||
|
||||
Optional properties:
|
||||
- clocks: clocks for this module
|
||||
- clockdomains: clockdomains for this module
|
||||
|
||||
Examples:
|
||||
|
||||
scm: scm@2000 {
|
||||
compatible = "ti,omap3-scm", "simple-bus";
|
||||
reg = <0x2000 0x2000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x2000 0x2000>;
|
||||
|
||||
omap3_pmx_core: pinmux@30 {
|
||||
compatible = "ti,omap3-padconf",
|
||||
"pinctrl-single";
|
||||
reg = <0x30 0x230>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-controller;
|
||||
pinctrl-single,register-width = <16>;
|
||||
pinctrl-single,function-mask = <0xff1f>;
|
||||
};
|
||||
|
||||
scm_conf: scm_conf@270 {
|
||||
compatible = "syscon";
|
||||
reg = <0x270 0x330>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
scm_clocks: clocks {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
||||
scm_clockdomains: clockdomains {
|
||||
};
|
||||
}
|
||||
|
||||
&scm_clocks {
|
||||
mcbsp5_mux_fck: mcbsp5_mux_fck {
|
||||
#clock-cells = <0>;
|
||||
compatible = "ti,composite-mux-clock";
|
||||
clocks = <&core_96m_fck>, <&mcbsp_clks>;
|
||||
ti,bit-shift = <4>;
|
||||
reg = <0x02d8>;
|
||||
};
|
||||
};
|
||||
|
|
@ -6,6 +6,7 @@ provided by Arteris.
|
|||
Required properties:
|
||||
- compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
|
||||
Should be "ti,omap4-l3-noc" for OMAP4 family
|
||||
Should be "ti,omap5-l3-noc" for OMAP5 family
|
||||
Should be "ti,dra7-l3-noc" for DRA7 family
|
||||
Should be "ti,am4372-l3-noc" for AM43 family
|
||||
- reg: Contains L3 register address range for each noc domain.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
L4 interconnect bindings
|
||||
|
||||
These bindings describe the OMAP SoCs L4 interconnect bus.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ti,omap2-l4" for OMAP2 family l4 core bus
|
||||
Should be "ti,omap2-l4-wkup" for OMAP2 family l4 wkup bus
|
||||
Should be "ti,omap3-l4-core" for OMAP3 family l4 core bus
|
||||
Should be "ti,omap4-l4-cfg" for OMAP4 family l4 cfg bus
|
||||
Should be "ti,omap4-l4-wkup" for OMAP4 family l4 wkup bus
|
||||
Should be "ti,omap5-l4-cfg" for OMAP5 family l4 cfg bus
|
||||
Should be "ti,omap5-l4-wkup" for OMAP5 family l4 wkup bus
|
||||
Should be "ti,dra7-l4-cfg" for DRA7 family l4 cfg bus
|
||||
Should be "ti,dra7-l4-wkup" for DRA7 family l4 wkup bus
|
||||
Should be "ti,am3-l4-wkup" for AM33xx family l4 wkup bus
|
||||
Should be "ti,am4-l4-wkup" for AM43xx family l4 wkup bus
|
||||
- ranges : contains the IO map range for the bus
|
||||
|
||||
Examples:
|
||||
|
||||
l4: l4@48000000 {
|
||||
compatible "ti,omap2-l4", "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x48000000 0x100000>;
|
||||
};
|
||||
|
|
@ -10,14 +10,10 @@ documentation about the individual clock/clockdomain nodes.
|
|||
Required properties:
|
||||
- compatible: Must be one of:
|
||||
"ti,am3-prcm"
|
||||
"ti,am3-scrm"
|
||||
"ti,am4-prcm"
|
||||
"ti,am4-scrm"
|
||||
"ti,omap2-prcm"
|
||||
"ti,omap2-scrm"
|
||||
"ti,omap3-prm"
|
||||
"ti,omap3-cm"
|
||||
"ti,omap3-scrm"
|
||||
"ti,omap4-cm1"
|
||||
"ti,omap4-prm"
|
||||
"ti,omap4-cm2"
|
||||
|
|
@ -29,6 +25,8 @@ Required properties:
|
|||
"ti,dra7-prm"
|
||||
"ti,dra7-cm-core-aon"
|
||||
"ti,dra7-cm-core"
|
||||
"ti,dm814-prcm"
|
||||
"ti,dm816-prcm"
|
||||
- reg: Contains PRCM module register address range
|
||||
(base address and length)
|
||||
- clocks: clocks for this module
|
||||
|
|
|
|||
|
|
@ -22,3 +22,7 @@ Rockchip platforms device tree bindings
|
|||
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
|
||||
or
|
||||
- compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";
|
||||
|
||||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
|
|
|||
|
|
@ -7,8 +7,6 @@ SoCs:
|
|||
compatible = "renesas,emev2"
|
||||
- RZ/A1H (R7S72100)
|
||||
compatible = "renesas,r7s72100"
|
||||
- SH-Mobile AP4 (R8A73720/SH7372)
|
||||
compatible = "renesas,sh7372"
|
||||
- SH-Mobile AG5 (R8A73A00/SH73A0)
|
||||
compatible = "renesas,sh73a0"
|
||||
- R-Mobile APE6 (R8A73A40)
|
||||
|
|
@ -37,8 +35,6 @@ Boards:
|
|||
compatible = "renesas,alt", "renesas,r8a7794"
|
||||
- APE6-EVM
|
||||
compatible = "renesas,ape6evm", "renesas,r8a73a4"
|
||||
- APE6-EVM - Reference Device Tree Implementation
|
||||
compatible = "renesas,ape6evm-reference", "renesas,r8a73a4"
|
||||
- Atmark Techno Armadillo-800 EVA
|
||||
compatible = "renesas,armadillo800eva"
|
||||
- BOCK-W
|
||||
|
|
@ -57,12 +53,8 @@ Boards:
|
|||
compatible = "renesas,kzm9d", "renesas,emev2"
|
||||
- Kyoto Microcomputer Co. KZM-A9-GT
|
||||
compatible = "renesas,kzm9g", "renesas,sh73a0"
|
||||
- Kyoto Microcomputer Co. KZM-A9-GT - Reference Device Tree Implementation
|
||||
compatible = "renesas,kzm9g-reference", "renesas,sh73a0"
|
||||
- Lager (RTP0RC7790SEB00010S)
|
||||
compatible = "renesas,lager", "renesas,r8a7790"
|
||||
- Mackerel (R0P7372LC0016RL, AP4 EVM 2nd)
|
||||
compatible = "renesas,mackerel"
|
||||
- Marzen
|
||||
compatible = "renesas,marzen", "renesas,r8a7779"
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,32 @@
|
|||
NVIDIA Tegra Activity Monitor
|
||||
|
||||
The activity monitor block collects statistics about the behaviour of other
|
||||
components in the system. This information can be used to derive the rate at
|
||||
which the external memory needs to be clocked in order to serve all requests
|
||||
from the monitored clients.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "nvidia,tegra<chip>-actmon"
|
||||
- reg: offset and length of the register set for the device
|
||||
- interrupts: standard interrupt property
|
||||
- clocks: Must contain a phandle and clock specifier pair for each entry in
|
||||
clock-names. See ../../clock/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- actmon
|
||||
- emc
|
||||
- resets: Must contain an entry for each entry in reset-names. See
|
||||
../../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- actmon
|
||||
|
||||
Example:
|
||||
actmon@6000c800 {
|
||||
compatible = "nvidia,tegra124-actmon";
|
||||
reg = <0x0 0x6000c800 0x0 0x400>;
|
||||
interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&tegra_car TEGRA124_CLK_ACTMON>,
|
||||
<&tegra_car TEGRA124_CLK_EMC>;
|
||||
clock-names = "actmon", "emc";
|
||||
resets = <&tegra_car 119>;
|
||||
reset-names = "actmon";
|
||||
};
|
||||
|
|
@ -1,7 +1,8 @@
|
|||
* OMAP OCP2SCP - ocp interface to scp interface
|
||||
|
||||
properties:
|
||||
- compatible : Should be "ti,omap-ocp2scp"
|
||||
- compatible : Should be "ti,am437x-ocp2scp" for AM437x processor
|
||||
Should be "ti,omap-ocp2scp" for all others
|
||||
- reg : Address and length of the register set for the device
|
||||
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||
- ranges : the child address space are mapped 1:1 onto the parent address space
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
Renesas Bus State Controller (BSC)
|
||||
==================================
|
||||
|
||||
The Renesas Bus State Controller (BSC, sometimes called "LBSC within Bus
|
||||
Bridge", or "External Bus Interface") can be found in several Renesas ARM SoCs.
|
||||
It provides an external bus for connecting multiple external devices to the
|
||||
SoC, driving several chip select lines, for e.g. NOR FLASH, Ethernet and USB.
|
||||
|
||||
While the BSC is a fairly simple memory-mapped bus, it may be part of a PM
|
||||
domain, and may have a gateable functional clock.
|
||||
Before a device connected to the BSC can be accessed, the PM domain
|
||||
containing the BSC must be powered on, and the functional clock
|
||||
driving the BSC must be enabled.
|
||||
|
||||
The bindings for the BSC extend the bindings for "simple-pm-bus".
|
||||
|
||||
|
||||
Required properties
|
||||
- compatible: Must contain an SoC-specific value, and "renesas,bsc" and
|
||||
"simple-pm-bus" as fallbacks.
|
||||
SoC-specific values can be:
|
||||
"renesas,bsc-r8a73a4" for R-Mobile APE6 (r8a73a4)
|
||||
"renesas,bsc-sh73a0" for SH-Mobile AG5 (sh73a0)
|
||||
- #address-cells, #size-cells, ranges: Must describe the mapping between
|
||||
parent address and child address spaces.
|
||||
- reg: Must contain the base address and length to access the bus controller.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: Must contain a reference to the BSC interrupt, if available.
|
||||
- clocks: Must contain a reference to the functional clock, if available.
|
||||
- power-domains: Must contain a reference to the PM domain, if available.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
bsc: bus@fec10000 {
|
||||
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
|
||||
"simple-pm-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0 0x20000000>;
|
||||
reg = <0xfec10000 0x400>;
|
||||
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&zb_clk>;
|
||||
power-domains = <&pd_a4s>;
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Simple Power-Managed Bus
|
||||
========================
|
||||
|
||||
A Simple Power-Managed Bus is a transparent bus that doesn't need a real
|
||||
driver, as it's typically initialized by the boot loader.
|
||||
|
||||
However, its bus controller is part of a PM domain, or under the control of a
|
||||
functional clock. Hence, the bus controller's PM domain and/or clock must be
|
||||
enabled for child devices connected to the bus (either on-SoC or externally)
|
||||
to function.
|
||||
|
||||
While "simple-pm-bus" follows the "simple-bus" set of properties, as specified
|
||||
in ePAPR, it is not an extension of "simple-bus".
|
||||
|
||||
|
||||
Required properties:
|
||||
- compatible: Must contain at least "simple-pm-bus".
|
||||
Must not contain "simple-bus".
|
||||
It's recommended to let this be preceded by one or more
|
||||
vendor-specific compatible values.
|
||||
- #address-cells, #size-cells, ranges: Must describe the mapping between
|
||||
parent address and child address spaces.
|
||||
|
||||
Optional platform-specific properties for clock or PM domain control (at least
|
||||
one of them is required):
|
||||
- clocks: Must contain a reference to the functional clock(s),
|
||||
- power-domains: Must contain a reference to the PM domain.
|
||||
Please refer to the binding documentation for the clock and/or PM domain
|
||||
providers for more details.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
bsc: bus@fec10000 {
|
||||
compatible = "renesas,bsc-sh73a0", "renesas,bsc",
|
||||
"simple-pm-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0 0x20000000>;
|
||||
reg = <0xfec10000 0x400>;
|
||||
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&zb_clk>;
|
||||
power-domains = <&pd_a4s>;
|
||||
};
|
||||
|
|
@ -9,6 +9,8 @@ Required Properties:
|
|||
- "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
|
||||
- "samsung,exynos3250-cmu-dmc" - controller compatible with
|
||||
Exynos3250 SoC for Dynamic Memory Controller domain.
|
||||
- "samsung,exynos3250-cmu-isp" - ISP block clock controller compatible
|
||||
with Exynos3250 SOC
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
|
@ -36,6 +38,12 @@ Example 1: Examples of clock controller nodes are listed below.
|
|||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_isp: clock-controller@10048000 {
|
||||
compatible = "samsung,exynos3250-cmu-isp";
|
||||
reg = <0x10048000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: UART controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,462 @@
|
|||
* Samsung Exynos5433 CMU (Clock Management Units)
|
||||
|
||||
The Exynos5433 clock controller generates and supplies clock to various
|
||||
controllers within the Exynos5433 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP
|
||||
which generates clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
|
||||
domains and bus clocks.
|
||||
- "samsung,exynos5433-cmu-cpif" - clock controller compatible for CMU_CPIF
|
||||
which generates clocks for LLI (Low Latency Interface) IP.
|
||||
- "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF
|
||||
which generates clocks for DRAM Memory Controller domain.
|
||||
- "samsung,exynos5433-cmu-peric" - clock controller compatible for CMU_PERIC
|
||||
which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
|
||||
- "samsung,exynos5433-cmu-peris" - clock controller compatible for CMU_PERIS
|
||||
which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
|
||||
- "samsung,exynos5433-cmu-fsys" - clock controller compatible for CMU_FSYS
|
||||
which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
|
||||
- "samsung,exynos5433-cmu-g2d" - clock controller compatible for CMU_G2D
|
||||
which generates clocks for G2D/MDMA IPs.
|
||||
- "samsung,exynos5433-cmu-disp" - clock controller compatible for CMU_DISP
|
||||
which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
|
||||
- "samsung,exynos5433-cmu-aud" - clock controller compatible for CMU_AUD
|
||||
which generates clocks for Cortex-A5/BUS/AUDIO clocks.
|
||||
- "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
|
||||
and "samsung,exynos5433-cmu-bus2" - clock controller compatible for CMU_BUS
|
||||
which generates global data buses clock and global peripheral buses clock.
|
||||
- "samsung,exynos5433-cmu-g3d" - clock controller compatible for CMU_G3D
|
||||
which generates clocks for 3D Graphics Engine IP.
|
||||
- "samsung,exynos5433-cmu-gscl" - clock controller compatible for CMU_GSCL
|
||||
which generates clocks for GSCALER IPs.
|
||||
- "samsung,exynos5433-cmu-apollo"- clock controller compatible for CMU_APOLLO
|
||||
which generates clocks for Cortex-A53 Quad-core processor.
|
||||
- "samsung,exynos5433-cmu-atlas" - clock controller compatible for CMU_ATLAS
|
||||
which generates clocks for Cortex-A57 Quad-core processor, CoreSight and
|
||||
L2 cache controller.
|
||||
- "samsung,exynos5433-cmu-mscl" - clock controller compatible for CMU_MSCL
|
||||
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
|
||||
- "samsung,exynos5433-cmu-mfc" - clock controller compatible for CMU_MFC
|
||||
which generates clocks for MFC(Multi-Format Codec) IP.
|
||||
- "samsung,exynos5433-cmu-hevc" - clock controller compatible for CMU_HEVC
|
||||
which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
|
||||
- "samsung,exynos5433-cmu-isp" - clock controller compatible for CMU_ISP
|
||||
which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
|
||||
- "samsung,exynos5433-cmu-cam0" - clock controller compatible for CMU_CAM0
|
||||
which generates clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1}
|
||||
IPs.
|
||||
- "samsung,exynos5433-cmu-cam1" - clock controller compatible for CMU_CAM1
|
||||
which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
- clocks: list of the clock controller input clock identifiers,
|
||||
from common clock bindings. Please refer the next section
|
||||
to find the input clocks for a given controller.
|
||||
|
||||
- clock-names: list of the clock controller input clock names,
|
||||
as described in clock-bindings.txt.
|
||||
|
||||
Input clocks for top clock controller:
|
||||
- oscclk
|
||||
- sclk_mphy_pll
|
||||
- sclk_mfc_pll
|
||||
- sclk_bus_pll
|
||||
|
||||
Input clocks for cpif clock controller:
|
||||
- oscclk
|
||||
|
||||
Input clocks for mif clock controller:
|
||||
- oscclk
|
||||
- sclk_mphy_pll
|
||||
|
||||
Input clocks for fsys clock controller:
|
||||
- oscclk
|
||||
- sclk_ufs_mphy
|
||||
- div_aclk_fsys_200
|
||||
- sclk_pcie_100_fsys
|
||||
- sclk_ufsunipro_fsys
|
||||
- sclk_mmc2_fsys
|
||||
- sclk_mmc1_fsys
|
||||
- sclk_mmc0_fsys
|
||||
- sclk_usbhost30_fsys
|
||||
- sclk_usbdrd30_fsys
|
||||
|
||||
Input clocks for g2d clock controller:
|
||||
- oscclk
|
||||
- aclk_g2d_266
|
||||
- aclk_g2d_400
|
||||
|
||||
Input clocks for disp clock controller:
|
||||
- oscclk
|
||||
- sclk_dsim1_disp
|
||||
- sclk_dsim0_disp
|
||||
- sclk_dsd_disp
|
||||
- sclk_decon_tv_eclk_disp
|
||||
- sclk_decon_vclk_disp
|
||||
- sclk_decon_eclk_disp
|
||||
- sclk_decon_tv_vclk_disp
|
||||
- aclk_disp_333
|
||||
|
||||
Input clocks for bus0 clock controller:
|
||||
- aclk_bus0_400
|
||||
|
||||
Input clocks for bus1 clock controller:
|
||||
- aclk_bus1_400
|
||||
|
||||
Input clocks for bus2 clock controller:
|
||||
- oscclk
|
||||
- aclk_bus2_400
|
||||
|
||||
Input clocks for g3d clock controller:
|
||||
- oscclk
|
||||
- aclk_g3d_400
|
||||
|
||||
Input clocks for gscl clock controller:
|
||||
- oscclk
|
||||
- aclk_gscl_111
|
||||
- aclk_gscl_333
|
||||
|
||||
Input clocks for apollo clock controller:
|
||||
- oscclk
|
||||
- sclk_bus_pll_apollo
|
||||
|
||||
Input clocks for atlas clock controller:
|
||||
- oscclk
|
||||
- sclk_bus_pll_atlas
|
||||
|
||||
Input clocks for mscl clock controller:
|
||||
- oscclk
|
||||
- sclk_jpeg_mscl
|
||||
- aclk_mscl_400
|
||||
|
||||
Input clocks for mfc clock controller:
|
||||
- oscclk
|
||||
- aclk_mfc_400
|
||||
|
||||
Input clocks for hevc clock controller:
|
||||
- oscclk
|
||||
- aclk_hevc_400
|
||||
|
||||
Input clocks for isp clock controller:
|
||||
- oscclk
|
||||
- aclk_isp_dis_400
|
||||
- aclk_isp_400
|
||||
|
||||
Input clocks for cam0 clock controller:
|
||||
- oscclk
|
||||
- aclk_cam0_333
|
||||
- aclk_cam0_400
|
||||
- aclk_cam0_552
|
||||
|
||||
Input clocks for cam1 clock controller:
|
||||
- oscclk
|
||||
- sclk_isp_uart_cam1
|
||||
- sclk_isp_spi1_cam1
|
||||
- sclk_isp_spi0_cam1
|
||||
- aclk_cam1_333
|
||||
- aclk_cam1_400
|
||||
- aclk_cam1_552
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/exynos5433.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example 1: Examples of 'oscclk' source clock node are listed below.
|
||||
|
||||
xxti: xxti {
|
||||
compatible = "fixed-clock";
|
||||
clock-output-names = "oscclk";
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
Example 2: Examples of clock controller nodes are listed below.
|
||||
|
||||
cmu_top: clock-controller@10030000 {
|
||||
compatible = "samsung,exynos5433-cmu-top";
|
||||
reg = <0x10030000 0x0c04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_mphy_pll",
|
||||
"sclk_mfc_pll",
|
||||
"sclk_bus_pll";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_cpif CLK_SCLK_MPHY_PLL>,
|
||||
<&cmu_mif CLK_SCLK_MFC_PLL>,
|
||||
<&cmu_mif CLK_SCLK_BUS_PLL>;
|
||||
};
|
||||
|
||||
cmu_cpif: clock-controller@10fc0000 {
|
||||
compatible = "samsung,exynos5433-cmu-cpif";
|
||||
reg = <0x10fc0000 0x0c04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk";
|
||||
clocks = <&xxti>;
|
||||
};
|
||||
|
||||
cmu_mif: clock-controller@105b0000 {
|
||||
compatible = "samsung,exynos5433-cmu-mif";
|
||||
reg = <0x105b0000 0x100c>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_mphy_pll";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_cpif CLK_SCLK_MPHY_PLL>;
|
||||
};
|
||||
|
||||
cmu_peric: clock-controller@14c80000 {
|
||||
compatible = "samsung,exynos5433-cmu-peric";
|
||||
reg = <0x14c80000 0x0b08>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_peris: clock-controller@10040000 {
|
||||
compatible = "samsung,exynos5433-cmu-peris";
|
||||
reg = <0x10040000 0x0b20>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_fsys: clock-controller@156e0000 {
|
||||
compatible = "samsung,exynos5433-cmu-fsys";
|
||||
reg = <0x156e0000 0x0b04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_ufs_mphy",
|
||||
"div_aclk_fsys_200",
|
||||
"sclk_pcie_100_fsys",
|
||||
"sclk_ufsunipro_fsys",
|
||||
"sclk_mmc2_fsys",
|
||||
"sclk_mmc1_fsys",
|
||||
"sclk_mmc0_fsys",
|
||||
"sclk_usbhost30_fsys",
|
||||
"sclk_usbdrd30_fsys";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_cpif CLK_SCLK_UFS_MPHY>,
|
||||
<&cmu_top CLK_DIV_ACLK_FSYS_200>,
|
||||
<&cmu_top CLK_SCLK_PCIE_100_FSYS>,
|
||||
<&cmu_top CLK_SCLK_UFSUNIPRO_FSYS>,
|
||||
<&cmu_top CLK_SCLK_MMC2_FSYS>,
|
||||
<&cmu_top CLK_SCLK_MMC1_FSYS>,
|
||||
<&cmu_top CLK_SCLK_MMC0_FSYS>,
|
||||
<&cmu_top CLK_SCLK_USBHOST30_FSYS>,
|
||||
<&cmu_top CLK_SCLK_USBDRD30_FSYS>;
|
||||
};
|
||||
|
||||
cmu_g2d: clock-controller@12460000 {
|
||||
compatible = "samsung,exynos5433-cmu-g2d";
|
||||
reg = <0x12460000 0x0b08>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"aclk_g2d_266",
|
||||
"aclk_g2d_400";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_ACLK_G2D_266>,
|
||||
<&cmu_top CLK_ACLK_G2D_400>;
|
||||
};
|
||||
|
||||
cmu_disp: clock-controller@13b90000 {
|
||||
compatible = "samsung,exynos5433-cmu-disp";
|
||||
reg = <0x13b90000 0x0c04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_dsim1_disp",
|
||||
"sclk_dsim0_disp",
|
||||
"sclk_dsd_disp",
|
||||
"sclk_decon_tv_eclk_disp",
|
||||
"sclk_decon_vclk_disp",
|
||||
"sclk_decon_eclk_disp",
|
||||
"sclk_decon_tv_vclk_disp",
|
||||
"aclk_disp_333";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_mif CLK_SCLK_DSIM1_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DSIM0_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DSD_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DECON_TV_ECLK_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DECON_VCLK_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DECON_ECLK_DISP>,
|
||||
<&cmu_mif CLK_SCLK_DECON_TV_VCLK_DISP>,
|
||||
<&cmu_mif CLK_ACLK_DISP_333>;
|
||||
};
|
||||
|
||||
cmu_aud: clock-controller@114c0000 {
|
||||
compatible = "samsung,exynos5433-cmu-aud";
|
||||
reg = <0x114c0000 0x0b04>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_bus0: clock-controller@13600000 {
|
||||
compatible = "samsung,exynos5433-cmu-bus0";
|
||||
reg = <0x13600000 0x0b04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "aclk_bus0_400";
|
||||
clocks = <&cmu_top CLK_ACLK_BUS0_400>;
|
||||
};
|
||||
|
||||
cmu_bus1: clock-controller@14800000 {
|
||||
compatible = "samsung,exynos5433-cmu-bus1";
|
||||
reg = <0x14800000 0x0b04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "aclk_bus1_400";
|
||||
clocks = <&cmu_top CLK_ACLK_BUS1_400>;
|
||||
};
|
||||
|
||||
cmu_bus2: clock-controller@13400000 {
|
||||
compatible = "samsung,exynos5433-cmu-bus2";
|
||||
reg = <0x13400000 0x0b04>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "aclk_bus2_400";
|
||||
clocks = <&xxti>, <&cmu_mif CLK_ACLK_BUS2_400>;
|
||||
};
|
||||
|
||||
cmu_g3d: clock-controller@14aa0000 {
|
||||
compatible = "samsung,exynos5433-cmu-g3d";
|
||||
reg = <0x14aa0000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "aclk_g3d_400";
|
||||
clocks = <&xxti>, <&cmu_top CLK_ACLK_G3D_400>;
|
||||
};
|
||||
|
||||
cmu_gscl: clock-controller@13cf0000 {
|
||||
compatible = "samsung,exynos5433-cmu-gscl";
|
||||
reg = <0x13cf0000 0x0b10>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"aclk_gscl_111",
|
||||
"aclk_gscl_333";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_ACLK_GSCL_111>,
|
||||
<&cmu_top CLK_ACLK_GSCL_333>;
|
||||
};
|
||||
|
||||
cmu_apollo: clock-controller@11900000 {
|
||||
compatible = "samsung,exynos5433-cmu-apollo";
|
||||
reg = <0x11900000 0x1088>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "sclk_bus_pll_apollo";
|
||||
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_APOLLO>;
|
||||
};
|
||||
|
||||
cmu_atlas: clock-controller@11800000 {
|
||||
compatible = "samsung,exynos5433-cmu-atlas";
|
||||
reg = <0x11800000 0x1088>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "sclk_bus_pll_atlas";
|
||||
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
|
||||
};
|
||||
|
||||
cmu_mscl: clock-controller@105d0000 {
|
||||
compatible = "samsung,exynos5433-cmu-mscl";
|
||||
reg = <0x105d0000 0x0b10>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_jpeg_mscl",
|
||||
"aclk_mscl_400";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_SCLK_JPEG_MSCL>,
|
||||
<&cmu_top CLK_ACLK_MSCL_400>;
|
||||
};
|
||||
|
||||
cmu_mfc: clock-controller@15280000 {
|
||||
compatible = "samsung,exynos5433-cmu-mfc";
|
||||
reg = <0x15280000 0x0b08>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "aclk_mfc_400";
|
||||
clocks = <&xxti>, <&cmu_top CLK_ACLK_MFC_400>;
|
||||
};
|
||||
|
||||
cmu_hevc: clock-controller@14f80000 {
|
||||
compatible = "samsung,exynos5433-cmu-hevc";
|
||||
reg = <0x14f80000 0x0b08>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk", "aclk_hevc_400";
|
||||
clocks = <&xxti>, <&cmu_top CLK_ACLK_HEVC_400>;
|
||||
};
|
||||
|
||||
cmu_isp: clock-controller@146d0000 {
|
||||
compatible = "samsung,exynos5433-cmu-isp";
|
||||
reg = <0x146d0000 0x0b0c>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"aclk_isp_dis_400",
|
||||
"aclk_isp_400";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_ACLK_ISP_DIS_400>,
|
||||
<&cmu_top CLK_ACLK_ISP_400>;
|
||||
};
|
||||
|
||||
cmu_cam0: clock-controller@120d0000 {
|
||||
compatible = "samsung,exynos5433-cmu-cam0";
|
||||
reg = <0x120d0000 0x0b0c>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"aclk_cam0_333",
|
||||
"aclk_cam0_400",
|
||||
"aclk_cam0_552";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_ACLK_CAM0_333>,
|
||||
<&cmu_top CLK_ACLK_CAM0_400>,
|
||||
<&cmu_top CLK_ACLK_CAM0_552>;
|
||||
};
|
||||
|
||||
cmu_cam1: clock-controller@145d0000 {
|
||||
compatible = "samsung,exynos5433-cmu-cam1";
|
||||
reg = <0x145d0000 0x0b08>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clock-names = "oscclk",
|
||||
"sclk_isp_uart_cam1",
|
||||
"sclk_isp_spi1_cam1",
|
||||
"sclk_isp_spi0_cam1",
|
||||
"aclk_cam1_333",
|
||||
"aclk_cam1_400",
|
||||
"aclk_cam1_552";
|
||||
clocks = <&xxti>,
|
||||
<&cmu_top CLK_SCLK_ISP_UART_CAM1>,
|
||||
<&cmu_top CLK_SCLK_ISP_SPI1_CAM1>,
|
||||
<&cmu_top CLK_SCLK_ISP_SPI0_CAM1>,
|
||||
<&cmu_top CLK_ACLK_CAM1_333>,
|
||||
<&cmu_top CLK_ACLK_CAM1_400>,
|
||||
<&cmu_top CLK_ACLK_CAM1_552>;
|
||||
};
|
||||
|
||||
Example 3: UART controller node that consumes the clock generated by the clock
|
||||
controller.
|
||||
|
||||
serial_0: serial@14C10000 {
|
||||
compatible = "samsung,exynos5433-uart";
|
||||
reg = <0x14C10000 0x100>;
|
||||
interrupts = <0 421 0>;
|
||||
clocks = <&cmu_peric CLK_PCLK_UART0>,
|
||||
<&cmu_peric CLK_SCLK_UART0>;
|
||||
clock-names = "uart", "clk_uart_baud0";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&uart0_bus>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
Fujitsu CRG11 clock driver bindings
|
||||
-----------------------------------
|
||||
|
||||
Required properties :
|
||||
- compatible : Shall contain "fujitsu,mb86s70-crg11"
|
||||
- #clock-cells : Shall be 3 {cntrlr domain port}
|
||||
|
||||
The consumer specifies the desired clock pointing to its phandle.
|
||||
|
||||
Example:
|
||||
|
||||
clock: crg11 {
|
||||
compatible = "fujitsu,mb86s70-crg11";
|
||||
#clock-cells = <3>;
|
||||
};
|
||||
|
||||
mhu: mhu0@2b1f0000 {
|
||||
#mbox-cells = <1>;
|
||||
compatible = "arm,mhu";
|
||||
reg = <0 0x2B1F0000 0x1000>;
|
||||
interrupts = <0 36 4>, /* LP Non-Sec */
|
||||
<0 35 4>, /* HP Non-Sec */
|
||||
<0 37 4>; /* Secure */
|
||||
clocks = <&clock 0 2 1>; /* Cntrlr:0 Domain:2 Port:1 */
|
||||
clock-names = "clk";
|
||||
};
|
||||
|
|
@ -23,6 +23,14 @@ The following is a list of provided IDs and clock names on Armada 380/385:
|
|||
2 = l2clk (L2 Cache clock)
|
||||
3 = ddrclk (DDR clock)
|
||||
|
||||
The following is a list of provided IDs and clock names on Armada 39x:
|
||||
0 = tclk (Internal Bus clock)
|
||||
1 = cpuclk (CPU clock)
|
||||
2 = nbclk (Coherent Fabric clock)
|
||||
3 = hclk (SDRAM Controller Internal Clock)
|
||||
4 = dclk (SDRAM Interface Clock)
|
||||
5 = refclk (Reference Clock)
|
||||
|
||||
The following is a list of provided IDs and clock names on Kirkwood and Dove:
|
||||
0 = tclk (Internal Bus clock)
|
||||
1 = cpuclk (CPU0 clock)
|
||||
|
|
@ -39,6 +47,7 @@ Required properties:
|
|||
"marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
|
||||
"marvell,armada-375-core-clock" - For Armada 375 SoC core clocks
|
||||
"marvell,armada-380-core-clock" - For Armada 380/385 SoC core clocks
|
||||
"marvell,armada-390-core-clock" - For Armada 39x SoC core clocks
|
||||
"marvell,armada-xp-core-clock" - For Armada XP SoC core clocks
|
||||
"marvell,dove-core-clock" - for Dove SoC core clocks
|
||||
"marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
* Gated Clock bindings for Marvell EBU SoCs
|
||||
|
||||
Marvell Armada 370/375/380/385/XP, Dove and Kirkwood allow some
|
||||
Marvell Armada 370/375/380/385/39x/XP, Dove and Kirkwood allow some
|
||||
peripheral clocks to be gated to save some power. The clock consumer
|
||||
should specify the desired clock by having the clock ID in its
|
||||
"clocks" phandle cell. The clock ID is directly mapped to the
|
||||
|
|
@ -77,6 +77,18 @@ ID Clock Peripheral
|
|||
28 xor1 XOR 1
|
||||
30 sata1 SATA 1
|
||||
|
||||
The following is a list of provided IDs for Armada 39x:
|
||||
ID Clock Peripheral
|
||||
-----------------------------------
|
||||
5 pex1 PCIe 1
|
||||
6 pex2 PCIe 2
|
||||
7 pex3 PCIe 3
|
||||
8 pex0 PCIe 0
|
||||
9 usb3h0 USB3 Host 0
|
||||
17 sdio SDIO
|
||||
22 xor0 XOR 0
|
||||
28 xor1 XOR 1
|
||||
|
||||
The following is a list of provided IDs for Armada XP:
|
||||
ID Clock Peripheral
|
||||
-----------------------------------
|
||||
|
|
@ -152,6 +164,7 @@ Required properties:
|
|||
"marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
|
||||
"marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating
|
||||
"marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating
|
||||
"marvell,armada-390-gating-clock" - for Armada 39x SoC clock gating
|
||||
"marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
|
||||
"marvell,dove-gating-clock" - for Dove SoC clock gating
|
||||
"marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
Binding for an external clock signal driven by a PWM pin.
|
||||
|
||||
This binding uses the common clock binding[1] and the common PWM binding[2].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/pwm/pwm.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "pwm-clock".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- pwms : from common PWM binding; this determines the clock frequency
|
||||
via the period given in the PWM specifier.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
- clock-frequency : Exact output frequency, in case the PWM period
|
||||
is not exact but was rounded to nanoseconds.
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "pwm-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <25000000>;
|
||||
clock-output-names = "mipi_mclk";
|
||||
pwms = <&pwm2 0 40>; /* 1 / 40 ns = 25 MHz */
|
||||
};
|
||||
|
|
@ -8,6 +8,7 @@ Required properties :
|
|||
"qcom,gcc-apq8084"
|
||||
"qcom,gcc-ipq8064"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,gcc-msm8916"
|
||||
"qcom,gcc-msm8960"
|
||||
"qcom,gcc-msm8974"
|
||||
"qcom,gcc-msm8974pro"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,25 @@
|
|||
* Renesas R8A7778 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7778. It includes two PLLs and
|
||||
several fixed ratio dividers
|
||||
|
||||
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".
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
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";
|
||||
};
|
||||
|
|
@ -20,6 +20,7 @@ Required properties:
|
|||
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
|
||||
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
|
||||
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
|
||||
"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
|
||||
"allwinner,sun9i-a80-ahb-clk" - for the AHB bus clocks on A80
|
||||
"allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
|
||||
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
|
||||
|
|
@ -66,6 +67,8 @@ Required properties:
|
|||
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
|
||||
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
|
||||
"allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
|
||||
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
|
||||
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
|
||||
|
||||
Required properties for all clocks:
|
||||
- reg : shall be the control register address for the clock.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
Common properties
|
||||
|
||||
The ePAPR specification does not define any properties related to hardware
|
||||
byteswapping, but endianness issues show up frequently in porting Linux to
|
||||
different machine types. This document attempts to provide a consistent
|
||||
way of handling byteswapping across drivers.
|
||||
|
||||
Optional properties:
|
||||
- big-endian: Boolean; force big endian register accesses
|
||||
unconditionally (e.g. ioread32be/iowrite32be). Use this if you
|
||||
know the peripheral always needs to be accessed in BE mode.
|
||||
- little-endian: Boolean; force little endian register accesses
|
||||
unconditionally (e.g. readl/writel). Use this if you know the
|
||||
peripheral always needs to be accessed in LE mode.
|
||||
- native-endian: Boolean; always use register accesses matched to the
|
||||
endianness of the kernel binary (e.g. LE vmlinux -> readl/writel,
|
||||
BE vmlinux -> ioread32be/iowrite32be). In this case no byteswaps
|
||||
will ever be performed. Use this if the hardware "self-adjusts"
|
||||
register endianness based on the CPU's configured endianness.
|
||||
|
||||
If a binding supports these properties, then the binding should also
|
||||
specify the default behavior if none of these properties are present.
|
||||
In such cases, little-endian is the preferred default, but it is not
|
||||
a requirement. The of_device_is_big_endian() and of_fdt_is_big_endian()
|
||||
helper functions do assume that little-endian is the default, because
|
||||
most existing (PCI-based) drivers implicitly default to LE by using
|
||||
readl/writel for MMIO accesses.
|
||||
|
||||
Examples:
|
||||
Scenario 1 : CPU in LE mode & device in LE mode.
|
||||
dev: dev@40031000 {
|
||||
compatible = "name";
|
||||
reg = <0x40031000 0x1000>;
|
||||
...
|
||||
native-endian;
|
||||
};
|
||||
|
||||
Scenario 2 : CPU in LE mode & device in BE mode.
|
||||
dev: dev@40031000 {
|
||||
compatible = "name";
|
||||
reg = <0x40031000 0x1000>;
|
||||
...
|
||||
big-endian;
|
||||
};
|
||||
|
||||
Scenario 3 : CPU in BE mode & device in BE mode.
|
||||
dev: dev@40031000 {
|
||||
compatible = "name";
|
||||
reg = <0x40031000 0x1000>;
|
||||
...
|
||||
native-endian;
|
||||
};
|
||||
|
||||
Scenario 4 : CPU in BE mode & device in LE mode.
|
||||
dev: dev@40031000 {
|
||||
compatible = "name";
|
||||
reg = <0x40031000 0x1000>;
|
||||
...
|
||||
little-endian;
|
||||
};
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Axis Communications AB
|
||||
ARTPEC series SoC Device Tree Bindings
|
||||
|
||||
|
||||
CRISv32 based SoCs are ETRAX FS and ARTPEC-3:
|
||||
|
||||
- compatible = "axis,crisv32";
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
Boards based on the CRIS SoCs:
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following:
|
||||
- "axis,dev88" - for Axis devboard 88 with ETRAX FS
|
||||
|
||||
Optional:
|
||||
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
* CRISv32 Interrupt Controller
|
||||
|
||||
Interrupt controller for the CRISv32 SoCs.
|
||||
|
||||
Main node required properties:
|
||||
|
||||
- compatible : should be:
|
||||
"axis,crisv32-intc"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 1.
|
||||
- reg: physical base address and size of the intc registers map.
|
||||
|
||||
Example:
|
||||
|
||||
intc: interrupt-controller {
|
||||
compatible = "axis,crisv32-intc";
|
||||
reg = <0xb001c000 0x1000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
Applied Micro X-Gene SoC DMA nodes
|
||||
|
||||
DMA nodes are defined to describe on-chip DMA interfaces in
|
||||
APM X-Gene SoC.
|
||||
|
||||
Required properties for DMA interfaces:
|
||||
- compatible: Should be "apm,xgene-dma".
|
||||
- device_type: set to "dma".
|
||||
- reg: Address and length of the register set for the device.
|
||||
It contains the information of registers in the following order:
|
||||
1st - DMA control and status register address space.
|
||||
2nd - Descriptor ring control and status register address space.
|
||||
3rd - Descriptor ring command register address space.
|
||||
4th - Soc efuse register address space.
|
||||
- interrupts: DMA has 5 interrupts sources. 1st interrupt is
|
||||
DMA error reporting interrupt. 2nd, 3rd, 4th and 5th interrupts
|
||||
are completion interrupts for each DMA channels.
|
||||
- clocks: Reference to the clock entry.
|
||||
|
||||
Optional properties:
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
|
||||
Example:
|
||||
dmaclk: dmaclk@1f27c000 {
|
||||
compatible = "apm,xgene-device-clock";
|
||||
#clock-cells = <1>;
|
||||
clocks = <&socplldiv2 0>;
|
||||
reg = <0x0 0x1f27c000 0x0 0x1000>;
|
||||
reg-names = "csr-reg";
|
||||
clock-output-names = "dmaclk";
|
||||
};
|
||||
|
||||
dma: dma@1f270000 {
|
||||
compatible = "apm,xgene-storm-dma";
|
||||
device_type = "dma";
|
||||
reg = <0x0 0x1f270000 0x0 0x10000>,
|
||||
<0x0 0x1f200000 0x0 0x10000>,
|
||||
<0x0 0x1b008000 0x0 0x2000>,
|
||||
<0x0 0x1054a000 0x0 0x100>;
|
||||
interrupts = <0x0 0x82 0x4>,
|
||||
<0x0 0xb8 0x4>,
|
||||
<0x0 0xb9 0x4>,
|
||||
<0x0 0xba 0x4>,
|
||||
<0x0 0xbb 0x4>;
|
||||
dma-coherent;
|
||||
clocks = <&dmaclk 0>;
|
||||
};
|
||||
|
|
@ -38,7 +38,7 @@ dma_apbx: dma-apbx@80024000 {
|
|||
80 81 68 69
|
||||
70 71 72 73
|
||||
74 75 76 77>;
|
||||
interrupt-names = "auart4-rx", "aurat4-tx", "spdif-tx", "empty",
|
||||
interrupt-names = "auart4-rx", "auart4-tx", "spdif-tx", "empty",
|
||||
"saif0", "saif1", "i2c0", "i2c1",
|
||||
"auart0-rx", "auart0-tx", "auart1-rx", "auart1-tx",
|
||||
"auart2-rx", "auart2-tx", "auart3-rx", "auart3-tx";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,56 @@
|
|||
* Ingenic JZ4780 DMA Controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "ingenic,jz4780-dma"
|
||||
- reg: Should contain the DMA controller registers location and length.
|
||||
- interrupts: Should contain the interrupt specifier of the DMA controller.
|
||||
- interrupt-parent: Should be the phandle of the interrupt controller that
|
||||
- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
|
||||
- #dma-cells: Must be <2>. Number of integer cells in the dmas property of
|
||||
DMA clients (see below).
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ingenic,reserved-channels: Bitmask of channels to reserve for devices that
|
||||
need a specific channel. These channels will only be assigned when explicitly
|
||||
requested by a client. The primary use for this is channels 0 and 1, which
|
||||
can be configured to have special behaviour for NAND/BCH when using
|
||||
programmable firmware.
|
||||
|
||||
Example:
|
||||
|
||||
dma: dma@13420000 {
|
||||
compatible = "ingenic,jz4780-dma";
|
||||
reg = <0x13420000 0x10000>;
|
||||
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <10>;
|
||||
|
||||
clocks = <&cgu JZ4780_CLK_PDMA>;
|
||||
|
||||
#dma-cells = <2>;
|
||||
|
||||
ingenic,reserved-channels = <0x3>;
|
||||
};
|
||||
|
||||
DMA clients must use the format described in dma.txt, giving a phandle to the
|
||||
DMA controller plus the following 2 integer cells:
|
||||
|
||||
1. Request type: The DMA request type for transfers to/from the device on
|
||||
the allocated channel, as defined in the SoC documentation.
|
||||
|
||||
2. Channel: If set to 0xffffffff, any available channel will be allocated for
|
||||
the client. Otherwise, the exact channel specified will be used. The channel
|
||||
should be reserved on the DMA controller using the ingenic,reserved-channels
|
||||
property.
|
||||
|
||||
Example:
|
||||
|
||||
uart0: serial@10030000 {
|
||||
...
|
||||
dmas = <&dma 0x14 0xffffffff
|
||||
&dma 0x15 0xffffffff>;
|
||||
dma-names = "tx", "rx";
|
||||
...
|
||||
};
|
||||
|
|
@ -4,6 +4,7 @@ Required properties:
|
|||
- compatible: must be one of the following:
|
||||
* "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
|
||||
* "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
|
||||
* "qcom,bam-v1.7.0" for MSM8916
|
||||
- reg: Address range for DMA registers
|
||||
- interrupts: Should contain the one interrupt shared by all channels
|
||||
- #dma-cells: must be <1>, the cell in the dmas property of the client device
|
||||
|
|
|
|||
|
|
@ -1,29 +0,0 @@
|
|||
* R-Car Audio DMAC peri peri Device Tree bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "renesas,rcar-audmapp"
|
||||
- #dma-cells: should be <1>, see "dmas" property below
|
||||
|
||||
Example:
|
||||
audmapp: audio-dma-pp@0xec740000 {
|
||||
compatible = "renesas,rcar-audmapp";
|
||||
#dma-cells = <1>;
|
||||
|
||||
reg = <0 0xec740000 0 0x200>;
|
||||
};
|
||||
|
||||
|
||||
* DMA client
|
||||
|
||||
Required properties:
|
||||
- dmas: a list of <[DMA multiplexer phandle] [SRS << 8 | DRS]> pairs.
|
||||
where SRS/DRS are specified in the SoC manual.
|
||||
It will be written into PDMACHCR as high 16-bit parts.
|
||||
- dma-names: a list of DMA channel names, one per "dmas" entry
|
||||
|
||||
Example:
|
||||
|
||||
dmas = <&audmapp 0x2d00
|
||||
&audmapp 0x3700>;
|
||||
dma-names = "src0_ssiu0",
|
||||
"dvc0_ssiu0";
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
* Renesas USB DMA Controller Device Tree bindings
|
||||
|
||||
Required Properties:
|
||||
- compatible: must contain "renesas,usb-dmac"
|
||||
- reg: base address and length of the registers block for the DMAC
|
||||
- interrupts: interrupt specifiers for the DMAC, one for each entry in
|
||||
interrupt-names.
|
||||
- interrupt-names: one entry per channel, named "ch%u", where %u is the
|
||||
channel number ranging from zero to the number of channels minus one.
|
||||
- clocks: a list of phandle + clock-specifier pairs.
|
||||
- #dma-cells: must be <1>, the cell specifies the channel number of the DMAC
|
||||
port connected to the DMA client.
|
||||
- dma-channels: number of DMA channels
|
||||
|
||||
Example: R8A7790 (R-Car H2) USB-DMACs
|
||||
|
||||
usb_dmac0: dma-controller@e65a0000 {
|
||||
compatible = "renesas,usb-dmac";
|
||||
reg = <0 0xe65a0000 0 0x100>;
|
||||
interrupts = <0 109 IRQ_TYPE_LEVEL_HIGH
|
||||
0 109 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "ch0", "ch1";
|
||||
clocks = <&mstp3_clks R8A7790_CLK_USBDMAC0>;
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <2>;
|
||||
};
|
||||
|
||||
usb_dmac1: dma-controller@e65b0000 {
|
||||
compatible = "renesas,usb-dmac";
|
||||
reg = <0 0xe65b0000 0 0x100>;
|
||||
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH
|
||||
0 110 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "ch0", "ch1";
|
||||
clocks = <&mstp3_clks R8A7790_CLK_USBDMAC1>;
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <2>;
|
||||
};
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
USB GPIO Extcon device
|
||||
|
||||
This is a virtual device used to generate USB cable states from the USB ID pin
|
||||
connected to a GPIO pin.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "linux,extcon-usb-gpio"
|
||||
- id-gpio: gpio for USB ID pin. See gpio binding.
|
||||
|
||||
Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
|
||||
extcon_usb1 {
|
||||
compatible = "linux,extcon-usb-gpio";
|
||||
id-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
|
||||
}
|
||||
|
||||
&omap_dwc3_1 {
|
||||
extcon = <&extcon_usb1>;
|
||||
};
|
||||
|
|
@ -77,6 +77,7 @@ nxp,pca9556 Octal SMBus and I2C registered interface
|
|||
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
|
||||
nxp,pcf8563 Real-time clock/calendar
|
||||
nxp,pcf85063 Tiny Real-Time Clock
|
||||
oki,ml86v7667 OKI ML86V7667 video decoder
|
||||
ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus
|
||||
pericom,pt7c4338 Real-time Clock Module
|
||||
plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Required properties:
|
|||
|
||||
- compatible : should be one of:
|
||||
"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
|
||||
"samsung,exynos3250-jpeg";
|
||||
"samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg";
|
||||
- reg : address and length of the JPEG codec IP register set;
|
||||
- interrupts : specifies the JPEG codec IP interrupt;
|
||||
- clock-names : should contain:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,39 @@
|
|||
* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
|
||||
|
||||
The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
|
||||
an active array size of 752H x 480V. It is programmable through a simple
|
||||
two-wire serial interface.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: value should be either one among the following
|
||||
(a) "aptina,mt9v022" for MT9V022 color sensor
|
||||
(b) "aptina,mt9v022m" for MT9V022 monochrome sensor
|
||||
(c) "aptina,mt9v024" for MT9V024 color sensor
|
||||
(d) "aptina,mt9v024m" for MT9V024 monochrome sensor
|
||||
(e) "aptina,mt9v032" for MT9V032 color sensor
|
||||
(f) "aptina,mt9v032m" for MT9V032 monochrome sensor
|
||||
(g) "aptina,mt9v034" for MT9V034 color sensor
|
||||
(h) "aptina,mt9v034m" for MT9V034 monochrome sensor
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
|
||||
expressed as a 64-bit big-endian integer.
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
mt9v032@5c {
|
||||
compatible = "aptina,mt9v032";
|
||||
reg = <0x5c>;
|
||||
|
||||
port {
|
||||
mt9v032_out: endpoint {
|
||||
link-frequencies = /bits/ 64
|
||||
<13000000 26600000 27000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
* Omnivision OV2640 CMOS sensor
|
||||
|
||||
The Omnivision OV2640 sensor support multiple resolutions output, such as
|
||||
CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
|
||||
output format.
|
||||
|
||||
Required Properties:
|
||||
- compatible: should be "ovti,ov2640"
|
||||
- clocks: reference to the xvclk input clock.
|
||||
- clock-names: should be "xvclk".
|
||||
|
||||
Optional Properties:
|
||||
- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
|
||||
- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
|
||||
|
||||
The device node must contain one 'port' child node for its digital output
|
||||
video port, in accordance with the video interface bindings defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c1: i2c@f0018000 {
|
||||
ov2640: camera@0x30 {
|
||||
compatible = "ovti,ov2640";
|
||||
reg = <0x30>;
|
||||
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_pck1 &pinctrl_ov2640_pwdn &pinctrl_ov2640_resetb>;
|
||||
|
||||
resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
|
||||
pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
|
||||
|
||||
clocks = <&pck1>;
|
||||
clock-names = "xvclk";
|
||||
|
||||
assigned-clocks = <&pck1>;
|
||||
assigned-clock-rates = <25000000>;
|
||||
|
||||
port {
|
||||
ov2640_0: endpoint {
|
||||
remote-endpoint = <&isi_0>;
|
||||
bus-width = <8>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
* OV2659 1/5-Inch 2Mp SOC Camera
|
||||
|
||||
The Omnivision OV2659 is a 1/5-inch SOC camera, with an active array size of
|
||||
1632H x 1212V. It is programmable through a SCCB. The OV2659 sensor supports
|
||||
multiple resolutions output, such as UXGA, SVGA, 720p. It also can support
|
||||
YUV422, RGB565/555 or raw RGB output formats.
|
||||
|
||||
Required Properties:
|
||||
- compatible: Must be "ovti,ov2659"
|
||||
- reg: I2C slave address
|
||||
- clocks: reference to the xvclk input clock.
|
||||
- clock-names: should be "xvclk".
|
||||
- link-frequencies: target pixel clock frequency.
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
ov2659@30 {
|
||||
compatible = "ovti,ov2659";
|
||||
reg = <0x30>;
|
||||
|
||||
clocks = <&clk_ov2659 0>;
|
||||
clock-names = "xvclk";
|
||||
|
||||
port {
|
||||
ov2659_0: endpoint {
|
||||
remote-endpoint = <&vpfe_ep>;
|
||||
link-frequencies = /bits/ 64 <70000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
OMAP 3 ISP Device Tree bindings
|
||||
===============================
|
||||
|
||||
The DT definitions can be found in include/dt-bindings/media/omap3-isp.h.
|
||||
|
||||
Required properties
|
||||
===================
|
||||
|
||||
compatible : must contain "ti,omap3-isp"
|
||||
|
||||
reg : the two registers sets (physical address and length) for the
|
||||
ISP. The first set contains the core ISP registers up to
|
||||
the end of the SBL block. The second set contains the
|
||||
CSI PHYs and receivers registers.
|
||||
interrupts : the ISP interrupt specifier
|
||||
iommus : phandle and IOMMU specifier for the IOMMU that serves the ISP
|
||||
syscon : the phandle and register offset to the Complex I/O or CSI-PHY
|
||||
register
|
||||
ti,phy-type : 0 -- OMAP3ISP_PHY_TYPE_COMPLEX_IO (e.g. 3430)
|
||||
1 -- OMAP3ISP_PHY_TYPE_CSIPHY (e.g. 3630)
|
||||
#clock-cells : Must be 1 --- the ISP provides two external clocks,
|
||||
cam_xclka and cam_xclkb, at indices 0 and 1,
|
||||
respectively. Please find more information on common
|
||||
clock bindings in ../clock/clock-bindings.txt.
|
||||
|
||||
Port nodes (optional)
|
||||
---------------------
|
||||
|
||||
More documentation on these bindings is available in
|
||||
video-interfaces.txt in the same directory.
|
||||
|
||||
reg : The interface:
|
||||
0 - parallel (CCDC)
|
||||
1 - CSIPHY1 -- CSI2C / CCP2B on 3630;
|
||||
CSI1 -- CSIb on 3430
|
||||
2 - CSIPHY2 -- CSI2A / CCP2B on 3630;
|
||||
CSI2 -- CSIa on 3430
|
||||
|
||||
Optional properties
|
||||
===================
|
||||
|
||||
vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1
|
||||
vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2
|
||||
|
||||
Endpoint nodes
|
||||
--------------
|
||||
|
||||
lane-polarities : lane polarity (required on CSI-2)
|
||||
0 -- not inverted; 1 -- inverted
|
||||
data-lanes : an array of data lanes from 1 to 3. The length can
|
||||
be either 1 or 2. (required on CSI-2)
|
||||
clock-lanes : the clock lane (from 1 to 3). (required on CSI-2)
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
isp@480bc000 {
|
||||
compatible = "ti,omap3-isp";
|
||||
reg = <0x480bc000 0x12fc
|
||||
0x480bd800 0x0600>;
|
||||
interrupts = <24>;
|
||||
iommus = <&mmu_isp>;
|
||||
syscon = <&scm_conf 0x2f0>;
|
||||
ti,phy-type = <OMAP3ISP_PHY_TYPE_CSIPHY>;
|
||||
#clock-cells = <1>;
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -106,6 +106,12 @@ Optional endpoint properties
|
|||
- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for
|
||||
instance, this is the actual frequency of the bus, not bits per clock per
|
||||
lane value. An array of 64-bit unsigned integers.
|
||||
- lane-polarities: an array of polarities of the lanes starting from the clock
|
||||
lane and followed by the data lanes in the same order as in data-lanes.
|
||||
Valid values are 0 (normal) and 1 (inverted). The length of the array
|
||||
should be the combined length of data-lanes and clock-lanes properties.
|
||||
If the lane-polarities property is omitted, the value must be interpreted
|
||||
as 0 (normal). This property is valid for serial busses only.
|
||||
|
||||
|
||||
Example
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
DT bindings for Xilinx video IP cores
|
||||
-------------------------------------
|
||||
|
||||
Xilinx video IP cores process video streams by acting as video sinks and/or
|
||||
sources. They are connected by links through their input and output ports,
|
||||
creating a video pipeline.
|
||||
|
||||
Each video IP core is represented by an AMBA bus child node in the device
|
||||
tree using bindings documented in this directory. Connections between the IP
|
||||
cores are represented as defined in ../video-interfaces.txt.
|
||||
|
||||
The whole pipeline is represented by an AMBA bus child node in the device
|
||||
tree using bindings documented in ./xlnx,video.txt.
|
||||
|
||||
Common properties
|
||||
-----------------
|
||||
|
||||
The following properties are common to all Xilinx video IP cores.
|
||||
|
||||
- xlnx,video-format: This property represents a video format transmitted on an
|
||||
AXI bus between video IP cores, using its VF code as defined in "AXI4-Stream
|
||||
Video IP and System Design Guide" [UG934]. How the format relates to the IP
|
||||
core is decribed in the IP core bindings documentation.
|
||||
|
||||
- xlnx,video-width: This property qualifies the video format with the sample
|
||||
width expressed as a number of bits per pixel component. All components must
|
||||
use the same width.
|
||||
|
||||
- xlnx,cfa-pattern: When the video format is set to Mono/Sensor, this property
|
||||
describes the sensor's color filter array pattern. Supported values are
|
||||
"bggr", "gbrg", "grbg", "rggb" and "mono". If not specified, the pattern
|
||||
defaults to "mono".
|
||||
|
||||
|
||||
[UG934] http://www.xilinx.com/support/documentation/ip_documentation/axi_videoip/v1_0/ug934_axi_videoIP.pdf
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
Xilinx Video Timing Controller (VTC)
|
||||
------------------------------------
|
||||
|
||||
The Video Timing Controller is a general purpose video timing generator and
|
||||
detector.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "xlnx,v-tc-6.1".
|
||||
|
||||
- reg: Physical base address and length of the registers set for the device.
|
||||
|
||||
- clocks: Must contain a clock specifier for the VTC core and timing
|
||||
interfaces clock.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- xlnx,detector: The VTC has a timing detector
|
||||
- xlnx,generator: The VTC has a timing generator
|
||||
|
||||
At least one of the xlnx,detector and xlnx,generator properties must be
|
||||
specified.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
vtc: vtc@43c40000 {
|
||||
compatible = "xlnx,v-tc-6.1";
|
||||
reg = <0x43c40000 0x10000>;
|
||||
|
||||
clocks = <&clkc 15>;
|
||||
xlnx,generator;
|
||||
};
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
Xilinx Video Test Pattern Generator (TPG)
|
||||
-----------------------------------------
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must contain at least one of
|
||||
|
||||
"xlnx,v-tpg-5.0" (TPG version 5.0)
|
||||
"xlnx,v-tpg-6.0" (TPG version 6.0)
|
||||
|
||||
TPG versions backward-compatible with previous versions should list all
|
||||
compatible versions in the newer to older order.
|
||||
|
||||
- reg: Physical base address and length of the registers set for the device.
|
||||
|
||||
- clocks: Reference to the video core clock.
|
||||
|
||||
- xlnx,video-format, xlnx,video-width: Video format and width, as defined in
|
||||
video.txt.
|
||||
|
||||
- port: Video port, using the DT bindings defined in ../video-interfaces.txt.
|
||||
The TPG has a single output port numbered 0.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- xlnx,vtc: A phandle referencing the Video Timing Controller that generates
|
||||
video timings for the TPG test patterns.
|
||||
|
||||
- timing-gpios: Specifier for a GPIO that controls the timing mux at the TPG
|
||||
input. The GPIO active level corresponds to the selection of VTC-generated
|
||||
video timings.
|
||||
|
||||
The xlnx,vtc and timing-gpios properties are mandatory when the TPG is
|
||||
synthesized with two ports and forbidden when synthesized with one port.
|
||||
|
||||
Example:
|
||||
|
||||
tpg_0: tpg@40050000 {
|
||||
compatible = "xlnx,v-tpg-6.0", "xlnx,v-tpg-5.0";
|
||||
reg = <0x40050000 0x10000>;
|
||||
clocks = <&clkc 15>;
|
||||
|
||||
xlnx,vtc = <&vtc_3>;
|
||||
timing-gpios = <&ps7_gpio_0 55 GPIO_ACTIVE_LOW>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
xlnx,video-format = <XVIP_VF_YUV_422>;
|
||||
xlnx,video-width = <8>;
|
||||
|
||||
tpg_in: endpoint {
|
||||
remote-endpoint = <&adv7611_out>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
xlnx,video-format = <XVIP_VF_YUV_422>;
|
||||
xlnx,video-width = <8>;
|
||||
|
||||
tpg1_out: endpoint {
|
||||
remote-endpoint = <&switch_in0>;
|
||||
};
|
||||
}:
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
Xilinx Video IP Pipeline (VIPP)
|
||||
-------------------------------
|
||||
|
||||
General concept
|
||||
---------------
|
||||
|
||||
Xilinx video IP pipeline processes video streams through one or more Xilinx
|
||||
video IP cores. Each video IP core is represented as documented in video.txt
|
||||
and IP core specific documentation, xlnx,v-*.txt, in this directory. The DT
|
||||
node of the VIPP represents as a top level node of the pipeline and defines
|
||||
mappings between DMAs and the video IP cores.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "xlnx,video".
|
||||
|
||||
- dmas, dma-names: List of one DMA specifier and identifier string (as defined
|
||||
in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
|
||||
requires a DMA channel with the identifier string set to "port" followed by
|
||||
the port index.
|
||||
|
||||
- ports: Video port, using the DT bindings defined in ../video-interfaces.txt.
|
||||
|
||||
Required port properties:
|
||||
|
||||
- direction: should be either "input" or "output" depending on the direction
|
||||
of stream.
|
||||
|
||||
Example:
|
||||
|
||||
video_cap {
|
||||
compatible = "xlnx,video";
|
||||
dmas = <&vdma_1 1>, <&vdma_3 1>;
|
||||
dma-names = "port0", "port1";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
direction = "input";
|
||||
vcap0_in0: endpoint {
|
||||
remote-endpoint = <&scaler0_out>;
|
||||
};
|
||||
};
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
direction = "input";
|
||||
vcap0_in1: endpoint {
|
||||
remote-endpoint = <&switch_out1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
* Ingenic JZ4780 NAND/external memory controller (NEMC)
|
||||
|
||||
This file documents the device tree bindings for the NEMC external memory
|
||||
controller in Ingenic JZ4780
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be set to one of:
|
||||
"ingenic,jz4780-nemc" (JZ4780)
|
||||
- reg: Should specify the NEMC controller registers location and length.
|
||||
- clocks: Clock for the NEMC controller.
|
||||
- #address-cells: Must be set to 2.
|
||||
- #size-cells: Must be set to 1.
|
||||
- ranges: A set of ranges for each bank describing the physical memory layout.
|
||||
Each should specify the following 4 integer values:
|
||||
|
||||
<cs number> 0 <physical address of mapping> <size of mapping>
|
||||
|
||||
Each child of the NEMC node describes a device connected to the NEMC.
|
||||
|
||||
Required child node properties:
|
||||
- reg: Should contain at least one register specifier, given in the following
|
||||
format:
|
||||
|
||||
<cs number> <offset> <size>
|
||||
|
||||
Multiple registers can be specified across multiple banks. This is needed,
|
||||
for example, for packaged NAND devices with multiple dies. Such devices
|
||||
should be grouped into a single node.
|
||||
|
||||
Optional child node properties:
|
||||
- ingenic,nemc-bus-width: Specifies the bus width in bits. Defaults to 8 bits.
|
||||
- ingenic,nemc-tAS: Address setup time in nanoseconds.
|
||||
- ingenic,nemc-tAH: Address hold time in nanoseconds.
|
||||
- ingenic,nemc-tBP: Burst pitch time in nanoseconds.
|
||||
- ingenic,nemc-tAW: Access wait time in nanoseconds.
|
||||
- ingenic,nemc-tSTRV: Static memory recovery time in nanoseconds.
|
||||
|
||||
If a child node references multiple banks in its "reg" property, the same value
|
||||
for all optional parameters will be configured for all banks. If any optional
|
||||
parameters are omitted, they will be left unchanged from whatever they are
|
||||
configured to when the NEMC device is probed (which may be the reset value as
|
||||
given in the hardware reference manual, or a value configured by the boot
|
||||
loader).
|
||||
|
||||
Example (NEMC node with a NAND child device attached at CS1):
|
||||
|
||||
nemc: nemc@13410000 {
|
||||
compatible = "ingenic,jz4780-nemc";
|
||||
reg = <0x13410000 0x10000>;
|
||||
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
|
||||
ranges = <1 0 0x1b000000 0x1000000
|
||||
2 0 0x1a000000 0x1000000
|
||||
3 0 0x19000000 0x1000000
|
||||
4 0 0x18000000 0x1000000
|
||||
5 0 0x17000000 0x1000000
|
||||
6 0 0x16000000 0x1000000>;
|
||||
|
||||
clocks = <&cgu JZ4780_CLK_NEMC>;
|
||||
|
||||
nand: nand@1 {
|
||||
compatible = "ingenic,jz4780-nand";
|
||||
reg = <1 0 0x1000000>;
|
||||
|
||||
ingenic,nemc-tAS = <10>;
|
||||
ingenic,nemc-tAH = <5>;
|
||||
ingenic,nemc-tBP = <10>;
|
||||
ingenic,nemc-tAW = <15>;
|
||||
ingenic,nemc-tSTRV = <100>;
|
||||
|
||||
...
|
||||
};
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue