linux-toradex.git/Documentation, branch v2.6.32.31

x86: Add IRQ_TIME_ACCOUNTING

2011-02-17T23:37:26+00:00

Commit: e82b8e4ea4f3dffe6e7939f90e78da675fcc450e upstream

This patch adds IRQ_TIME_ACCOUNTING option on x86 and runtime enables it
when TSC is enabled.

This change just enables fine grained irq time accounting, isn't used yet.
Following patches use it for different purposes.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1286237003-12406-6-git-send-email-venki@google.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Mike Galbraith 
Acked-by: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman

Input: i8042 - introduce 'notimeout' blacklist for Dell Vostro V13

2011-02-17T23:36:58+00:00

commit f8313ef1f448006207f12c107123522c8bc00f15 upstream.

i8042 controller present in Dell Vostro V13 errorneously signals spurious
timeouts.

Introduce i8042.notimeout parameter for ignoring i8042-signalled timeouts
and apply this quirk automatically for Dell Vostro V13, based on DMI match.

In addition to that, this machine also needs to be added to nomux blacklist.

Signed-off-by: Jiri Kosina 
Signed-off-by: Dmitry Torokhov 
Cc: Tim Gardner 
Signed-off-by: Greg Kroah-Hartman

Documentation/3c509: document ethtool support

2010-07-05T18:11:10+00:00

commit aa4e2e171385bb77b4da8b760d26dea2aa291587 upstream.

3c509 was changed to support ethtool in 2002, making the 'xcvr' module
parameter obsolete in most cases.  More recently 3c509 was converted
to the modern driver model and this parameter was removed.  Fix the
documentation to refer to ethtool rather than the module parameter.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

hwmon: (ltc4245) Read only one GPIO pin

2010-07-05T18:10:56+00:00

commit df16dd53c575d0cb9dbee20a3149927c862a9ff6 upstream.

Read only one of the GPIO pins as an analog voltage. The ADC can be
switched to a different GPIO pin at runtime, but this is not supported.

Previously, this driver would report the analog voltage of the currently
selected GPIO pin as all three GPIO voltages: in9_input, in10_input and
in11_input.

Signed-off-by: Ira W. Snyder 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

revert "procfs: provide stack information for threads" and its fixup commits

2010-05-26T21:29:19+00:00

commit 34441427aab4bdb3069a4ffcda69a99357abcb2e upstream.

Originally, commit d899bf7b ("procfs: provide stack information for
threads") attempted to introduce a new feature for showing where the
threadstack was located and how many pages are being utilized by the
stack.

Commit c44972f1 ("procfs: disable per-task stack usage on NOMMU") was
applied to fix the NO_MMU case.

Commit 89240ba0 ("x86, fs: Fix x86 procfs stack information for threads on
64-bit") was applied to fix a bug in ia32 executables being loaded.

Commit 9ebd4eba7 ("procfs: fix /proc//stat stack pointer for kernel
threads") was applied to fix a bug which had kernel threads printing a
userland stack address.

Commit 1306d603f ('proc: partially revert "procfs: provide stack
information for threads"') was then applied to revert the stack pages
being used to solve a significant performance regression.

This patch nearly undoes the effect of all these patches.

The reason for reverting these is it provides an unusable value in
field 28.  For x86_64, a fork will result in the task->stack_start
value being updated to the current user top of stack and not the stack
start address.  This unpredictability of the stack_start value makes
it worthless.  That includes the intended use of showing how much stack
space a thread has.

Other architectures will get different values.  As an example, ia64
gets 0.  The do_fork() and copy_process() functions appear to treat the
stack_start and stack_size parameters as architecture specific.

I only partially reverted c44972f1 ("procfs: disable per-task stack usage
on NOMMU") .  If I had completely reverted it, I would have had to change
mm/Makefile only build pagewalk.o when CONFIG_PROC_PAGE_MONITOR is
configured.  Since I could not test the builds without significant effort,
I decided to not change mm/Makefile.

I only partially reverted 89240ba0 ("x86, fs: Fix x86 procfs stack
information for threads on 64-bit") .  I left the KSTK_ESP() change in
place as that seemed worthwhile.

Signed-off-by: Robin Holt 
Cc: Stefani Seibold 
Cc: KOSAKI Motohiro 
Cc: Michal Simek 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

proc: partially revert "procfs: provide stack information for threads"

2010-05-26T21:29:19+00:00

commit 1306d603fcf1f6682f8575d1ff23631a24184b21 upstream.

Commit d899bf7b (procfs: provide stack information for threads) introduced
to show stack information in /proc/{pid}/status.  But it cause large
performance regression.  Unfortunately /proc/{pid}/status is used ps
command too and ps is one of most important component.  Because both to
take mmap_sem and page table walk are heavily operation.

If many process run, the ps performance is,

[before d899bf7b]

% perf stat ps >/dev/null

 Performance counter stats for 'ps':

     4090.435806  task-clock-msecs         #      0.032 CPUs
             229  context-switches         #      0.000 M/sec
               0  CPU-migrations           #      0.000 M/sec
             234  page-faults              #      0.000 M/sec
      8587565207  cycles                   #   2099.425 M/sec
      9866662403  instructions             #      1.149 IPC
      3789415411  cache-references         #    926.409 M/sec
        30419509  cache-misses             #      7.437 M/sec

   128.859521955  seconds time elapsed

[after d899bf7b]

% perf stat  ps  > /dev/null

 Performance counter stats for 'ps':

     4305.081146  task-clock-msecs         #      0.028 CPUs
             480  context-switches         #      0.000 M/sec
               2  CPU-migrations           #      0.000 M/sec
             237  page-faults              #      0.000 M/sec
      9021211334  cycles                   #   2095.480 M/sec
     10605887536  instructions             #      1.176 IPC
      3612650999  cache-references         #    839.160 M/sec
        23917502  cache-misses             #      5.556 M/sec

   152.277819582  seconds time elapsed

Thus, this patch revert it. Fortunately /proc/{pid}/task/{tid}/smaps
provide almost same information. we can use it.

Commit d899bf7b introduced two features:

 1) Add the annotattion of [thread stack: xxxx] mark to
    /proc/{pid}/task/{tid}/maps.
 2) Add StackUsage field to /proc/{pid}/status.

I only revert (2), because I haven't seen (1) cause regression.

Signed-off-by: KOSAKI Motohiro 
Cc: Stefani Seibold 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Alexey Dobriyan 
Cc: "Eric W. Biederman" 
Cc: Randy Dunlap 
Cc: Andrew Morton 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI: introduce kernel parameter acpi_sleep=sci_force_enable

2010-05-12T21:57:11+00:00

commit d7f0eea9e431e1b8b0742a74db1a9490730b2a25 upstream.

Introduce kernel parameter acpi_sleep=sci_force_enable

some laptop requires SCI_EN being set directly on resume,
or else they hung somewhere in the resume code path.

We already have a blacklist for these laptops but we still need
this option, especially when debugging some suspend/resume problems,
in case there are systems that need this workaround and are not yet
in the blacklist.

Signed-off-by: Zhang Rui 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

i2c-i801: Add Intel Cougar Point device IDs

2010-04-26T14:41:32+00:00

commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream.

Add the Intel Cougar Point (PCH) SMBus controller device IDs.

Signed-off-by: Seth Heasley 
Signed-off-by: Jean Delvare 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

thinkpad-acpi: lock down video output state access

2010-04-26T14:41:22+00:00

commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream.

Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.

Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.

This bug could be considered a local DoS I suppose, as it allows any
non-privledged local user to cause some versions of X.org to
hard-crash some ThinkPads.

Reported-by: Jidanni 
Signed-off-by: Henrique de Moraes Holschuh 
Signed-off-by: Greg Kroah-Hartman

thinkpad-acpi: issue backlight class events

2010-04-26T14:41:21+00:00

commit 347a26860e2293b1347996876d3550499c7bb31f upstream.

Take advantage of the new events capabilities of the backlight class to
notify userspace of backlight changes.

This depends on "backlight: Allow drivers to update the core, and
generate events on changes", by Matthew Garrett.

Signed-off-by: Henrique de Moraes Holschuh 
Cc: Matthew Garrett 
Cc: Richard Purdie 
Signed-off-by: Len Brown