x86/gpu: Add vfunc for Intel graphics stolen memory base address

For gen2 devices we're going to need another way to determine
the stolen memory base address. Make that into a vfunc as well.

Also drop the bogus inline keyword from gen8_stolen_size().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-2-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
x86/gpu: Add Intel graphics stolen memory quirk for gen2 platforms

There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.

The e820 map in said machine looks like this:

	BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
	BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
	BIOS-e820: [mem 0x00000000000ce000-0x00000000000cffff] reserved
	BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
	BIOS-e820: [mem 0x0000000000100000-0x000000001f6effff] usable
	BIOS-e820: [mem 0x000000001f6f0000-0x000000001f6f7fff] ACPI data
	BIOS-e820: [mem 0x000000001f6f8000-0x000000001f6fffff] ACPI NVS
	BIOS-e820: [mem 0x000000001f700000-0x000000001fffffff] reserved
	BIOS-e820: [mem 0x00000000fec10000-0x00000000fec1ffff] reserved
	BIOS-e820: [mem 0x00000000ffb00000-0x00000000ffbfffff] reserved
	BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved

That makes max_low_pfn_mapped = 1f6f0000, so assuming our stolen
memory would start there would place it on top of some ACPI
memory regions. So not a good idea as already stated.

The 9MB region after the ACPI regions at 0x1f700000 however
looks promising given that the macine reports the stolen memory
size to be 8MB. Looking at the PGTBL_CTL register, the GTT
entries are at offset 0x1fee00000, and given that the GTT
entries occupy 128KB, it looks like the stolen memory could
start at 0x1f700000 and the GTT entries would occupy the last
128KB of the stolen memory.

After some more digging through chipset documentation, I've
determined the BIOS first allocates space for something called
TSEG (something to do with SMM) from the top of memory, and then
it allocates the graphics stolen memory below that. Accordind to
the chipset documentation TSEG has a fixed size of 1MB on 855.
So that explains the top 1MB in the e820 region. And it also
confirms that the GTT entries are in fact at the end of the the
stolen memory region.

Derive the stolen memory base address on gen2 the same as the
BIOS does (TOM-TSEG_SIZE-stolen_size). There are a few
differences between the registers on various gen2 chipsets, so a
few different codepaths are required.

865G is again bit more special since it seems to support enough
memory to hit 4GB address space issues. This means the PCI
allocations will also affect the location of the stolen memory.
Fortunately there appears to be the TOUD register which may give
us the correct answer directly. But the chipset docs are a bit
unclear, so I'm not 100% sure that the graphics stolen memory is
always the last thing the BIOS steals. Someone would need to
verify it on a real system.

I tested this on the my 830 and 855 machines, and so far
everything looks peachy.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
x86/gpu: Print the Intel graphics stolen memory range

Print an informative message when reserving the graphics stolen
memory region in the early quirk.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1391628540-23072-4-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
ACPI idle: permit sparse C-state sub-state numbers

Linux uses CPUID.MWAIT.EDX to validate the C-states
reported by ACPI, silently discarding states which
are not supported by the HW.

This test is too restrictive, as some HW now uses
sparse sub-state numbering, so the sub-state number
may be higher than the number of sub-states...

Also, rather than silently ignoring an invalid state,
we should complain about a firmware bug.

In practice...

Bay Trail systems originally supported C6-no-shrink as
MWAIT sub-state 0x58, and in CPUID.MWAIT.EDX 0x03000000
indicated that there were 3 MWAIT-C6 sub-states.
So acpi_idle would discard that C-state because 8 >= 3.

Upon discovering this issue, the ucode was updated so that
C6-no-shrink was also exported as 0x51, and the BIOS was
updated to match.  However, systems shipped with 0x58,
will never get a BIOS update, and this patch allows
Linux to see C6-no-shrink on early Bay Trail.

Signed-off-by: Len Brown <len.brown@intel.com>
intel_idle: allow sparse sub-state numbering, for Bay Trail

Like acpi_idle, intel_idle compared sub-state numbers
to the number of supported sub-states -- discarding
sub-states numbers that were numbered >= the number of states.

But some Bay Trail SOCs use sparse sub-state numbers,
so we can't make such a comparison if we are going
to access those states.

So now we simply check that _some_ sub-states are
supported for the given state, and assume that the
sub-state number in our driver is valid.

In practice, the driver is correct, and even if it were not,
the hardware clips invalid sub-state requests to valid ones.

No entries in the driver require this change,
but Bay Trail will need it.

Signed-off-by: Len Brown <len.brown@intel.com>
intel_idle: support Bay Trail

Bay Trail (BYT) is a family of Silvermont-core Atom Processor SOCs,
including the Intel Atom Processor Z36xxx and Z37xxx Series.

Although it shares the Silvermont core with Avoton,
BYT is optimized for mobile, and thus it supports
different power saving CPU idle states.

Note that not all versions of Bay Trail HW support all
of the states listed in the driver.

Signed-off-by: Len Brown <len.brown@intel.com>
Tested-by: Aubrey Li <aubrey.li@linux.intel.com>
intel_idle: Add CPU model 54 (Atom N2000 series)

Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support
for this, detailed information about potential quirks or limitations are
missing, though. So we just reuse the definition for the previous ATOM
series. Tests on N2800 systems showed that this addition is fine an can
reduce power consumption by about 0.25 W (personally confirmed on Intel
DN2800MT).

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Len Brown <len.brown@intel.com>
tools/power turbostat: simplify output, add Avg_MHz

Use 8 columns for each number ouput.
We don't fit into 80 columns on most machines,
so keep the format simple.

Print frequency in MHz instead of GHz.
We've got 8 columns now, so use them to
show low frequency in a more natural unit.

Many users didn't understand what %c0 meant,
so re-name it to be %Busy.

Add Avg_MHz column, which is the frequency that many
users expect to see -- the total number of cycles executed
over the measurement interval.

People found the previous GHz to be confusing, since
it was the speed only over the non-idle interval.
That measurement has been re-named Bzy_MHz.

Suggested-by: Dirk J. Brandewie
Signed-off-by: Len Brown <len.brown@intel.com>
tools/power turbostat: Run on Broadwell

Signed-off-by: Len Brown <len.brown@intel.com>
microblaze: Rename global function heartbeat()

microblaze:allmodconfig complains for some configurations that 'heartbeat'
is redefined as different kind of symbol. This is seen in test compiles
of watchdog drivers, which often use 'heartbeat' as ststic variable.

Since 'heartbeat' is an unfortunate name for a global function,
rename it to microblaze_heartbeat. Also rename the setup function
to microblaze_setup_heartbeat.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
microblaze: Drop architecture-specific declaration of early_printk

miceroblaze:allmodconfig fails to build, complaining that
early_printk is redeclared.

include/linux/printk.h:114:6: error: static declaration of 'early_printk'
		follows non-static declaration
 void early_printk(const char *s, ...) { }
      ^
In file included from arch/microblaze/include/asm/page.h:19:0,
                 from arch/microblaze/include/asm/io.h:15,
                 from include/linux/io.h:22,
                 from kernel/irq/generic-chip.c:6:
arch/microblaze/include/asm/setup.h:22:6:
		note: previous declaration of 'early_printk' was here
 void early_printk(const char *fmt, ...);

This happens because CONFIG_EARLY_PRINTK is not enabled in this
configuration.

The architecture-specific declaration is not needed; drop it.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
microblaze: Enable pselect6 syscall

Enable this syscall and cleanup comments.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
microblaze: Wire-up preadv/pwritev in syscall table

Enable these two syscalls.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
microblaze: Wire-up new system calls sched_setattr/getattr

Wire-up sched_setattr/getattr syscalls.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
x86, CMCI: Add proper detection of end of CMCI storms

When CMCI storm persists for a long time(at least beyond predefined
threshold. It's 30 seconds for now), we can watch CMCI storm is
detected immediately after it subsides.

...
Dec 10 22:04:29 kernel: CMCI storm detected: switching to poll mode
Dec 10 22:04:59 kernel: CMCI storm subsided: switching to interrupt mode
Dec 10 22:04:59 kernel: CMCI storm detected: switching to poll mode
Dec 10 22:05:29 kernel: CMCI storm subsided: switching to interrupt mode
...

The problem is that our logic that determines that the storm has
ended is incorrect. We announce the end, re-enable interrupts and
realize that the storm is still going on, so we switch back to
polling mode. Rinse, repeat.

When a storm happens we disable signaling of errors via CMCI and begin
polling machine check banks instead. If we find any logged errors,
then we need to set a per-cpu flag so that our per-cpu tests that
check whether the storm is ongoing will see that errors are still
being logged independently of whether mce_notify_irq() says that the
error has been fully processed.

cmci_clear() is not the right tool to disable a bank. It disables the
interrupt for the bank as desired, but it also clears the bit for
this bank in "mce_banks_owned" so we will skip the bank when polling
(so we fail to see that the storm continues because we stop looking).
New cmci_storm_disable_banks() just disables the interrupt while
allowing polling to continue.

Reported-by: William Dauchy <wdauchy@gmail.com>
Signed-off-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
regmap: adds missing braces in regmap_init()

It need to add curly braces because the inner for "if" has
two statements.

coccicheck says:
 drivers/base/regmap/regmap.c:765:2-44:
code aligned with following code on line 766

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
x86/apic: Reinstate error IRQ Pentium erratum 3AP workaround

A change introduced with commit 60283df7ac26a4fe2d56631ca2946e04725e7eaf
("x86/apic: Read Error Status Register correctly") removed a read from the
APIC ESR register made before writing to same required to retrieve the
correct error status on Pentium systems affected by the 3AP erratum[1]:

	"3AP. Writes to Error Register Clears Register

	PROBLEM: The APIC Error register is intended to only be read.
	If there is a write to this register the data in the APIC Error
	register will be cleared and lost.

	IMPLICATION: There is a possibility of clearing the Error
	register status since the write to the register is not
	specifically blocked.

	WORKAROUND: Writes should not occur to the Pentium processor
	APIC Error register.

	STATUS: For the steppings affected see the Summary Table of
	Changes at the beginning of this section."

The steppings affected are actually: B1, B3 and B5.

To avoid this information loss this change avoids the write to
ESR on all Pentium systems where it is actually never needed;
in Pentium processor documentation ESR was noted read-only and
the write only required for future architectural
compatibility[2].

The approach taken is the same as in lapic_setup_esr().

References:

	[1] "Pentium Processor Family Developer's Manual", Intel Corporation,
	    1997, order number 241428-005, Appendix A "Errata and S-Specs for the
	    Pentium Processor Family", p. A-92,

	[2] "Pentium Processor Family Developer's Manual, Volume 3: Architecture
	    and Programming Manual", Intel Corporation, 1995, order number
	    241430-004, Section 19.3.3. "Error Handling In APIC", p. 19-33.

Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Richard Weinberger <richard@nod.at>
Link: http://lkml.kernel.org/r/alpine.LFD.2.11.1404011300010.27402@eddie.linux-mips.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge tag 'please-pull-cmci-storm' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/urgent

Pull RAS/CMCI storm code fix from Tony Luck:

 "Fix the code to tell when a CMCI storm ends by actually
  looking at the machine check banks when we poll while
  interrupts are disabled."

Signed-off-by: Ingo Molnar <mingo@kernel.org>
ARM: probes: fix instruction fetch order with <asm/opcodes.h>

If we are running BE8, the data and instruction endianness do not
match, so use <asm/opcodes.h> to correctly translate memory accesses
into ARM instructions.

Acked-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[taras.kondratiuk@linaro.org: fixed Thumb instruction fetch order]
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
ARM: kprobes-test: use <asm/opcodes.h> for instruction accesses

Ensure we read instructions in the correct endian-ness by using
the <asm/opcodes.h> helper to transform them as necessary.

Acked-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[taras.kondratiuk@linaro.org: fix next_instruction() function]
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>