mirror of
https://github.com/suyu-emu/horinux.git
synced 2026-09-21 14:15:21 -07:00
Merge branch 'linus' into timers/core
Reason: Pick up the hrtimer_clock_to_base_table fix from mainline Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
Thomas Gleixner
@@ -294,6 +294,7 @@
|
||||
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
|
||||
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
|
||||
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
|
||||
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
|
||||
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
|
||||
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
|
||||
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_ENUM_LINKS</para>
|
||||
<para>MEDIA_IOC_SETUP_LINK</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
<refentry id="V4L2-PIX-FMT-Y12">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
|
||||
<refpurpose>Grey-scale image</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a grey-scale image with a depth of 12 bits per pixel. Pixels
|
||||
are stored in 16-bit words with unused high bits padded with 0. The least
|
||||
significant byte is stored at lower memory addresses (little-endian).</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_Y12</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="9" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>Y'<subscript>00low</subscript></entry>
|
||||
<entry>Y'<subscript>00high</subscript></entry>
|
||||
<entry>Y'<subscript>01low</subscript></entry>
|
||||
<entry>Y'<subscript>01high</subscript></entry>
|
||||
<entry>Y'<subscript>02low</subscript></entry>
|
||||
<entry>Y'<subscript>02high</subscript></entry>
|
||||
<entry>Y'<subscript>03low</subscript></entry>
|
||||
<entry>Y'<subscript>03high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
<entry>Y'<subscript>10low</subscript></entry>
|
||||
<entry>Y'<subscript>10high</subscript></entry>
|
||||
<entry>Y'<subscript>11low</subscript></entry>
|
||||
<entry>Y'<subscript>11high</subscript></entry>
|
||||
<entry>Y'<subscript>12low</subscript></entry>
|
||||
<entry>Y'<subscript>12high</subscript></entry>
|
||||
<entry>Y'<subscript>13low</subscript></entry>
|
||||
<entry>Y'<subscript>13high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 16:</entry>
|
||||
<entry>Y'<subscript>20low</subscript></entry>
|
||||
<entry>Y'<subscript>20high</subscript></entry>
|
||||
<entry>Y'<subscript>21low</subscript></entry>
|
||||
<entry>Y'<subscript>21high</subscript></entry>
|
||||
<entry>Y'<subscript>22low</subscript></entry>
|
||||
<entry>Y'<subscript>22high</subscript></entry>
|
||||
<entry>Y'<subscript>23low</subscript></entry>
|
||||
<entry>Y'<subscript>23high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 24:</entry>
|
||||
<entry>Y'<subscript>30low</subscript></entry>
|
||||
<entry>Y'<subscript>30high</subscript></entry>
|
||||
<entry>Y'<subscript>31low</subscript></entry>
|
||||
<entry>Y'<subscript>31high</subscript></entry>
|
||||
<entry>Y'<subscript>32low</subscript></entry>
|
||||
<entry>Y'<subscript>32high</subscript></entry>
|
||||
<entry>Y'<subscript>33low</subscript></entry>
|
||||
<entry>Y'<subscript>33high</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -696,6 +696,7 @@ information.</para>
|
||||
&sub-packed-yuv;
|
||||
&sub-grey;
|
||||
&sub-y10;
|
||||
&sub-y12;
|
||||
&sub-y16;
|
||||
&sub-yuyv;
|
||||
&sub-uyvy;
|
||||
|
||||
@@ -456,6 +456,23 @@
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
|
||||
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
|
||||
<entry>0x3013</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</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="V4L2-MBUS-FMT-SGRBG8-1X8">
|
||||
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
|
||||
<entry>0x3002</entry>
|
||||
@@ -473,6 +490,23 @@
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
|
||||
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
|
||||
<entry>0x3014</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</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>
|
||||
</row>
|
||||
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
|
||||
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
|
||||
<entry>0x300b</entry>
|
||||
@@ -2159,6 +2193,31 @@
|
||||
<entry>u<subscript>1</subscript></entry>
|
||||
<entry>u<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-MBUS-FMT-Y12-1X12">
|
||||
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
|
||||
<entry>0x2013</entry>
|
||||
<entry></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<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="V4L2-MBUS-FMT-UYVY8-1X16">
|
||||
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
|
||||
<entry>0x200f</entry>
|
||||
|
||||
@@ -52,8 +52,10 @@ Brief summary of control files.
|
||||
tasks # attach a task(thread) and show list of threads
|
||||
cgroup.procs # show list of processes
|
||||
cgroup.event_control # an interface for event_fd()
|
||||
memory.usage_in_bytes # show current memory(RSS+Cache) usage.
|
||||
memory.memsw.usage_in_bytes # show current memory+Swap usage
|
||||
memory.usage_in_bytes # show current res_counter usage for memory
|
||||
(See 5.5 for details)
|
||||
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
|
||||
(See 5.5 for details)
|
||||
memory.limit_in_bytes # set/show limit of memory usage
|
||||
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
|
||||
memory.failcnt # show the number of memory usage hits limits
|
||||
@@ -453,6 +455,15 @@ memory under it will be reclaimed.
|
||||
You can reset failcnt by writing 0 to failcnt file.
|
||||
# echo 0 > .../memory.failcnt
|
||||
|
||||
5.5 usage_in_bytes
|
||||
|
||||
For efficiency, as other kernel components, memory cgroup uses some optimization
|
||||
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
|
||||
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
|
||||
value for efficient access. (Of course, when necessary, it's synchronized.)
|
||||
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
|
||||
value in memory.stat(see 5.2).
|
||||
|
||||
6. Hierarchy support
|
||||
|
||||
The memory controller supports a deep hierarchy and hierarchical accounting.
|
||||
|
||||
+19
-17
@@ -14,10 +14,6 @@ Supported chips:
|
||||
Prefix: 'gl523sm'
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
Datasheet:
|
||||
* Intel Xeon Processor
|
||||
Prefix: - any other - may require 'force_adm1021' parameter
|
||||
Addresses scanned: none
|
||||
Datasheet: Publicly available at Intel website
|
||||
* Maxim MAX1617
|
||||
Prefix: 'max1617'
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
@@ -91,21 +87,27 @@ will do no harm, but will return 'old' values. It is possible to make
|
||||
ADM1021-clones do faster measurements, but there is really no good reason
|
||||
for that.
|
||||
|
||||
Xeon support
|
||||
------------
|
||||
|
||||
Some Xeon processors have real max1617, adm1021, or compatible chips
|
||||
within them, with two temperature sensors.
|
||||
Netburst-based Xeon support
|
||||
---------------------------
|
||||
|
||||
Other Xeons have chips with only one sensor.
|
||||
Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
|
||||
2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
|
||||
within them, with two temperature sensors. Other Xeon processors of this
|
||||
era (with 400 MHz FSB) had chips with only one temperature sensor.
|
||||
|
||||
If you have a Xeon, and the adm1021 module loads, and both temperatures
|
||||
appear valid, then things are good.
|
||||
If you have such an old Xeon, and you get two valid temperatures when
|
||||
loading the adm1021 module, then things are good.
|
||||
|
||||
If the adm1021 module doesn't load, you should try this:
|
||||
modprobe adm1021 force_adm1021=BUS,ADDRESS
|
||||
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
|
||||
If nothing happens when loading the adm1021 module, and you are certain
|
||||
that your specific Xeon processor model includes compatible sensors, you
|
||||
will have to explicitly instantiate the sensor chips from user-space. See
|
||||
method 4 in Documentation/i2c/instantiating-devices. Possible slave
|
||||
addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
|
||||
only temp2 will be correct and temp1 will have to be ignored.
|
||||
|
||||
If you have dual Xeons you may have appear to have two separate
|
||||
adm1021-compatible chips, or two single-temperature sensors, at distinct
|
||||
addresses.
|
||||
Previous generations of the Xeon processor (based on Pentium II/III)
|
||||
didn't have these sensors. Next generations of Xeon processors (533 MHz
|
||||
FSB and faster) lost them, until the Core-based generation which
|
||||
introduced integrated digital thermal sensors. These are supported by
|
||||
the coretemp driver.
|
||||
|
||||
@@ -32,6 +32,16 @@ Supported chips:
|
||||
Addresses scanned: I2C 0x4c and 0x4d
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
|
||||
* Analog Devices ADT7461A
|
||||
Prefix: 'adt7461a'
|
||||
Addresses scanned: I2C 0x4c and 0x4d
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
|
||||
* ON Semiconductor NCT1008
|
||||
Prefix: 'nct1008'
|
||||
Addresses scanned: I2C 0x4c and 0x4d
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
|
||||
* Maxim MAX6646
|
||||
Prefix: 'max6646'
|
||||
Addresses scanned: I2C 0x4d
|
||||
@@ -149,7 +159,7 @@ ADM1032:
|
||||
* ALERT is triggered by open remote sensor.
|
||||
* SMBus PEC support for Write Byte and Receive Byte transactions.
|
||||
|
||||
ADT7461:
|
||||
ADT7461, ADT7461A, NCT1008:
|
||||
* Extended temperature range (breaks compatibility)
|
||||
* Lower resolution for remote temperature
|
||||
|
||||
@@ -195,9 +205,9 @@ are exported, one for each channel, but these values are of course linked.
|
||||
Only the local hysteresis can be set from user-space, and the same delta
|
||||
applies to the remote hysteresis.
|
||||
|
||||
The lm90 driver will not update its values more frequently than every
|
||||
other second; reading them more often will do no harm, but will return
|
||||
'old' values.
|
||||
The lm90 driver will not update its values more frequently than configured with
|
||||
the update_interval attribute; reading them more often will do no harm, but will
|
||||
return 'old' values.
|
||||
|
||||
SMBus Alert Support
|
||||
-------------------
|
||||
@@ -205,11 +215,12 @@ SMBus Alert Support
|
||||
This driver has basic support for SMBus alert. When an alert is received,
|
||||
the status register is read and the faulty temperature channel is logged.
|
||||
|
||||
The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
|
||||
alert protocol properly so additional care is needed: the ALERT output is
|
||||
disabled when an alert is received, and is re-enabled only when the alarm
|
||||
is gone. Otherwise the chip would block alerts from other chips in the bus
|
||||
as long as the alarm is active.
|
||||
The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
|
||||
Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
|
||||
properly so additional care is needed: the ALERT output is disabled when
|
||||
an alert is received, and is re-enabled only when the alarm is gone.
|
||||
Otherwise the chip would block alerts from other chips in the bus as long
|
||||
as the alarm is active.
|
||||
|
||||
PEC Support
|
||||
-----------
|
||||
|
||||
@@ -37,7 +37,7 @@ Generic scaling / cropping scheme
|
||||
-1'-
|
||||
|
||||
In the above chart minuses and slashes represent "real" data amounts, points and
|
||||
accents represent "useful" data, basically, CEU scaled amd cropped output,
|
||||
accents represent "useful" data, basically, CEU scaled and cropped output,
|
||||
mapped back onto the client's source plane.
|
||||
|
||||
Such a configuration can be produced by user requests:
|
||||
@@ -65,7 +65,7 @@ Do not touch input rectangle - it is already optimal.
|
||||
|
||||
1. Calculate current sensor scales:
|
||||
|
||||
scale_s = ((3') - (3)) / ((2') - (2))
|
||||
scale_s = ((2') - (2)) / ((3') - (3))
|
||||
|
||||
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
|
||||
current sensor scales onto input window - this is user S_CROP:
|
||||
@@ -80,7 +80,7 @@ window:
|
||||
4. Calculate sensor output window by applying combined scales to real input
|
||||
window:
|
||||
|
||||
width_s_out = ((2') - (2)) / scale_comb
|
||||
width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
|
||||
|
||||
5. Apply iterative sensor S_FMT for sensor output window.
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@ CONTENTS
|
||||
4. Application Programming Interface (API)
|
||||
5. Example Execution Scenarios
|
||||
6. Guidelines
|
||||
7. Debugging
|
||||
|
||||
|
||||
1. Introduction
|
||||
@@ -379,3 +380,42 @@ If q1 has WQ_CPU_INTENSIVE set,
|
||||
* Unless work items are expected to consume a huge amount of CPU
|
||||
cycles, using a bound wq is usually beneficial due to the increased
|
||||
level of locality in wq operations and work item execution.
|
||||
|
||||
|
||||
7. Debugging
|
||||
|
||||
Because the work functions are executed by generic worker threads
|
||||
there are a few tricks needed to shed some light on misbehaving
|
||||
workqueue users.
|
||||
|
||||
Worker threads show up in the process list as:
|
||||
|
||||
root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1]
|
||||
root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2]
|
||||
root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0]
|
||||
root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0]
|
||||
|
||||
If kworkers are going crazy (using too much cpu), there are two types
|
||||
of possible problems:
|
||||
|
||||
1. Something beeing scheduled in rapid succession
|
||||
2. A single work item that consumes lots of cpu cycles
|
||||
|
||||
The first one can be tracked using tracing:
|
||||
|
||||
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
|
||||
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
|
||||
(wait a few secs)
|
||||
^C
|
||||
|
||||
If something is busy looping on work queueing, it would be dominating
|
||||
the output and the offender can be determined with the work item
|
||||
function.
|
||||
|
||||
For the second type of problems it should be possible to just check
|
||||
the stack trace of the offending worker thread.
|
||||
|
||||
$ cat /proc/THE_OFFENDING_KWORKER/stack
|
||||
|
||||
The work item's function should be trivially visible in the stack
|
||||
trace.
|
||||
|
||||
+15
-14
@@ -1032,12 +1032,13 @@ W: http://www.fluff.org/ben/linux/
|
||||
S: Maintained
|
||||
F: arch/arm/mach-s3c64xx/
|
||||
|
||||
ARM/S5P ARM ARCHITECTURES
|
||||
ARM/S5P EXYNOS ARM ARCHITECTURES
|
||||
M: Kukjin Kim <kgene.kim@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-s5p*/
|
||||
F: arch/arm/mach-exynos*/
|
||||
|
||||
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
@@ -2808,7 +2809,7 @@ GPIO SUBSYSTEM
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
S: Maintained
|
||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||
F: Documentation/gpio/gpio.txt
|
||||
F: Documentation/gpio.txt
|
||||
F: drivers/gpio/
|
||||
F: include/linux/gpio*
|
||||
|
||||
@@ -6921,6 +6922,18 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
|
||||
S: Maintained
|
||||
F: drivers/platform/x86
|
||||
|
||||
XEN HYPERVISOR INTERFACE
|
||||
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
S: Supported
|
||||
F: arch/x86/xen/
|
||||
F: drivers/*/xen-*front.c
|
||||
F: drivers/xen/
|
||||
F: arch/x86/include/asm/xen/
|
||||
F: include/xen/
|
||||
|
||||
XEN NETWORK BACKEND DRIVER
|
||||
M: Ian Campbell <ian.campbell@citrix.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
@@ -6942,18 +6955,6 @@ S: Supported
|
||||
F: arch/x86/xen/*swiotlb*
|
||||
F: drivers/xen/*swiotlb*
|
||||
|
||||
XEN HYPERVISOR INTERFACE
|
||||
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
|
||||
L: virtualization@lists.linux-foundation.org
|
||||
S: Supported
|
||||
F: arch/x86/xen/
|
||||
F: drivers/*/xen-*front.c
|
||||
F: drivers/xen/
|
||||
F: arch/x86/include/asm/xen/
|
||||
F: include/xen/
|
||||
|
||||
XFS FILESYSTEM
|
||||
P: Silicon Graphics Inc
|
||||
M: Alex Elder <aelder@sgi.com>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 39
|
||||
EXTRAVERSION = -rc4
|
||||
EXTRAVERSION = -rc5
|
||||
NAME = Flesh-Eating Bats with Fangs
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
@@ -314,7 +314,7 @@ static struct clk timer2_clk = {
|
||||
.name = "timer2",
|
||||
.parent = &pll1_aux_clk,
|
||||
.lpsc = DAVINCI_LPSC_TIMER2,
|
||||
.usecount = 1, /* REVISIT: why can't' this be disabled? */
|
||||
.usecount = 1, /* REVISIT: why can't this be disabled? */
|
||||
};
|
||||
|
||||
static struct clk timer3_clk = {
|
||||
|
||||
@@ -274,7 +274,7 @@ static struct clk timer2_clk = {
|
||||
.name = "timer2",
|
||||
.parent = &pll1_aux_clk,
|
||||
.lpsc = DAVINCI_LPSC_TIMER2,
|
||||
.usecount = 1, /* REVISIT: why can't' this be disabled? */
|
||||
.usecount = 1, /* REVISIT: why can't this be disabled? */
|
||||
};
|
||||
|
||||
static struct clk_lookup dm644x_clks[] = {
|
||||
|
||||
@@ -68,7 +68,7 @@ obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
|
||||
obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
|
||||
|
||||
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
|
||||
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a
|
||||
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
|
||||
|
||||
ifeq ($(CONFIG_PM_VERBOSE),y)
|
||||
CFLAGS_pm_bus.o += -DDEBUG
|
||||
|
||||
@@ -141,14 +141,19 @@ static void __init rx51_init(void)
|
||||
static void __init rx51_map_io(void)
|
||||
{
|
||||
omap2_set_globals_3xxx();
|
||||
rx51_video_mem_init();
|
||||
omap34xx_map_common_io();
|
||||
}
|
||||
|
||||
static void __init rx51_reserve(void)
|
||||
{
|
||||
rx51_video_mem_init();
|
||||
omap_reserve();
|
||||
}
|
||||
|
||||
MACHINE_START(NOKIA_RX51, "Nokia RX-51 board")
|
||||
/* Maintainer: Lauri Leukkunen <lauri.leukkunen@nokia.com> */
|
||||
.boot_params = 0x80000100,
|
||||
.reserve = omap_reserve,
|
||||
.reserve = rx51_reserve,
|
||||
.map_io = rx51_map_io,
|
||||
.init_early = rx51_init_early,
|
||||
.init_irq = omap_init_irq,
|
||||
|
||||
@@ -3116,14 +3116,9 @@ static struct omap_clk omap44xx_clks[] = {
|
||||
CLK(NULL, "dsp_fck", &dsp_fck, CK_443X),
|
||||
CLK("omapdss_dss", "sys_clk", &dss_sys_clk, CK_443X),
|
||||
CLK("omapdss_dss", "tv_clk", &dss_tv_clk, CK_443X),
|
||||
CLK("omapdss_dss", "dss_clk", &dss_dss_clk, CK_443X),
|
||||
CLK("omapdss_dss", "video_clk", &dss_48mhz_clk, CK_443X),
|
||||
CLK("omapdss_dss", "fck", &dss_fck, CK_443X),
|
||||
/*
|
||||
* On OMAP4, DSS ick is a dummy clock; this is needed for compatibility
|
||||
* with OMAP2/3.
|
||||
*/
|
||||
CLK("omapdss_dss", "ick", &dummy_ck, CK_443X),
|
||||
CLK("omapdss_dss", "fck", &dss_dss_clk, CK_443X),
|
||||
CLK("omapdss_dss", "ick", &dss_fck, CK_443X),
|
||||
CLK(NULL, "efuse_ctrl_cust_fck", &efuse_ctrl_cust_fck, CK_443X),
|
||||
CLK(NULL, "emif1_fck", &emif1_fck, CK_443X),
|
||||
CLK(NULL, "emif2_fck", &emif2_fck, CK_443X),
|
||||
|
||||
@@ -247,6 +247,7 @@ struct omap3_cm_regs {
|
||||
u32 per_cm_clksel;
|
||||
u32 emu_cm_clksel;
|
||||
u32 emu_cm_clkstctrl;
|
||||
u32 pll_cm_autoidle;
|
||||
u32 pll_cm_autoidle2;
|
||||
u32 pll_cm_clksel4;
|
||||
u32 pll_cm_clksel5;
|
||||
@@ -319,6 +320,15 @@ void omap3_cm_save_context(void)
|
||||
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
|
||||
cm_context.emu_cm_clkstctrl =
|
||||
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
|
||||
/*
|
||||
* As per erratum i671, ROM code does not respect the PER DPLL
|
||||
* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
|
||||
* In this case, even though this register has been saved in
|
||||
* scratchpad contents, we need to restore AUTO_PERIPH_DPLL
|
||||
* by ourselves. So, we need to save it anyway.
|
||||
*/
|
||||
cm_context.pll_cm_autoidle =
|
||||
omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
|
||||
cm_context.pll_cm_autoidle2 =
|
||||
omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE2);
|
||||
cm_context.pll_cm_clksel4 =
|
||||
@@ -441,6 +451,13 @@ void omap3_cm_restore_context(void)
|
||||
CM_CLKSEL1);
|
||||
omap2_cm_write_mod_reg(cm_context.emu_cm_clkstctrl, OMAP3430_EMU_MOD,
|
||||
OMAP2_CM_CLKSTCTRL);
|
||||
/*
|
||||
* As per erratum i671, ROM code does not respect the PER DPLL
|
||||
* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
|
||||
* In this case, we need to restore AUTO_PERIPH_DPLL by ourselves.
|
||||
*/
|
||||
omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle, PLL_MOD,
|
||||
CM_AUTOIDLE);
|
||||
omap2_cm_write_mod_reg(cm_context.pll_cm_autoidle2, PLL_MOD,
|
||||
CM_AUTOIDLE2);
|
||||
omap2_cm_write_mod_reg(cm_context.pll_cm_clksel4, PLL_MOD,
|
||||
|
||||
@@ -316,8 +316,14 @@ void omap3_save_scratchpad_contents(void)
|
||||
omap2_cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
|
||||
prcm_block_contents.cm_clken_pll =
|
||||
omap2_cm_read_mod_reg(PLL_MOD, CM_CLKEN);
|
||||
/*
|
||||
* As per erratum i671, ROM code does not respect the PER DPLL
|
||||
* programming scheme if CM_AUTOIDLE_PLL..AUTO_PERIPH_DPLL == 1.
|
||||
* Then, in anycase, clear these bits to avoid extra latencies.
|
||||
*/
|
||||
prcm_block_contents.cm_autoidle_pll =
|
||||
omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_AUTOIDLE_PLL);
|
||||
omap2_cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE) &
|
||||
~OMAP3430_AUTO_PERIPH_DPLL_MASK;
|
||||
prcm_block_contents.cm_clksel1_pll =
|
||||
omap2_cm_read_mod_reg(PLL_MOD, OMAP3430_CM_CLKSEL1_PLL);
|
||||
prcm_block_contents.cm_clksel2_pll =
|
||||
|
||||
@@ -1639,6 +1639,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[] = {
|
||||
|
||||
static struct omap_hwmod omap2420_gpio1_hwmod = {
|
||||
.name = "gpio1",
|
||||
.flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
|
||||
.mpu_irqs = omap242x_gpio1_irqs,
|
||||
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio1_irqs),
|
||||
.main_clk = "gpios_fck",
|
||||
@@ -1669,6 +1670,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio2_slaves[] = {
|
||||
|
||||
static struct omap_hwmod omap2420_gpio2_hwmod = {
|
||||
.name = "gpio2",
|
||||
.flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
|
||||
.mpu_irqs = omap242x_gpio2_irqs,
|
||||
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio2_irqs),
|
||||
.main_clk = "gpios_fck",
|
||||
@@ -1699,6 +1701,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio3_slaves[] = {
|
||||
|
||||
static struct omap_hwmod omap2420_gpio3_hwmod = {
|
||||
.name = "gpio3",
|
||||
.flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
|
||||
.mpu_irqs = omap242x_gpio3_irqs,
|
||||
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio3_irqs),
|
||||
.main_clk = "gpios_fck",
|
||||
@@ -1729,6 +1732,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio4_slaves[] = {
|
||||
|
||||
static struct omap_hwmod omap2420_gpio4_hwmod = {
|
||||
.name = "gpio4",
|
||||
.flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
|
||||
.mpu_irqs = omap242x_gpio4_irqs,
|
||||
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio4_irqs),
|
||||
.main_clk = "gpios_fck",
|
||||
@@ -1782,7 +1786,7 @@ static struct omap_hwmod_irq_info omap2420_dma_system_irqs[] = {
|
||||
static struct omap_hwmod_addr_space omap2420_dma_system_addrs[] = {
|
||||
{
|
||||
.pa_start = 0x48056000,
|
||||
.pa_end = 0x4a0560ff,
|
||||
.pa_end = 0x48056fff,
|
||||
.flags = ADDR_TYPE_RT
|
||||
},
|
||||
};
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user