ACPI: Getting cpuindex for acpiid 0x4

acpi_processor-0742 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination

http://bugzilla.kernel.org/show_bug.cgi?id=7286Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

processor_perflib.c::acpi_processor_ppc_notifier() check if the value
returned by the processor's _PPC method is 0 and return failed if so.
This is wrong since 0 indicate that the bios think the processor can go
to the highest frequency.  This patch for example fix the HP NX 6125 to
allow its highest frequency to be available.
Signed-off-by: NBruno Ducrot <ducrot@poupinou.org>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Treat HW coordination as independent CPUs.
This enables per-cpu monintoring of P-states

http://bugzilla.kernel.org/show_bug.cgi?id=5737Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

From: Andrew Morton <akpm@osdl.org>

Work around the oops reported in
http://bugzilla.kernel.org/show_bug.cgi?id=6478.

Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and
reporting.
Acked-by: NDave Jones <davej@codemonkey.org.uk>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

for_each_cpu() actually iterates across all possible CPUs.  We've had mistakes
in the past where people were using for_each_cpu() where they should have been
iterating across only online or present CPUs.  This is inefficient and
possibly buggy.

We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the
future.
Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Semaphore to mutex conversion.

The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: NArjan van de Ven <arjan@infradead.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=5737Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_processor_limit_fops.write was written at run time,
but can be initiailized at compile-time instead.

Similar for acpi_video_bus_POST_fops.write and friends,
but keep doing those at runtime to avoid prototype-hell.
Signed-off-by: NArjan van de Ven <arjan@infradead.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Linux invokes the AML _PDC method (Processor Driver Capabilities)
to tell the BIOS what features it can handle.  While the ACPI
spec says nothing about the OS invoking _PDC multiple times,
doing so with changing bits seems to hopelessly confuse the BIOS
on multiple platforms up to and including crashing the system.

Factor out the _PDC invocation so Linux invokes it only once.

http://bugzilla.kernel.org/show_bug.cgi?id=5483Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=4401Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!