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>
NVMe: Add CONFIG_PM_SLEEP to suspend/resume functions

Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
build warning when CONFIG_PM_SLEEP is not selected. This is because
sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
the CONFIG_PM_SLEEP is enabled.

drivers/block/nvme-core.c:2541:12: warning: 'nvme_suspend' defined but not used [-Wunused-function]
drivers/block/nvme-core.c:2550:12: warning: 'nvme_resume' defined but not used [-Wunused-function]

Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
NVMe: Initialize device reference count earlier

If an NVMe device becomes ready but fails to create IO queues, the driver
creates a character device handle so the device can be managed. The
device reference count needs to be initialized before creating the
character device.

Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
NVMe: RCU protected access to io queues

This adds rcu protected access to nvme_queue to fix a race between a
surprise removal freeing the queue and a thread with open reference on
a NVMe block device using that queue.

The queues do not need to be rcu protected during the initialization or
shutdown parts, so I've added a helper function for raw deferencing
to get around the sparse errors.

There is still a hole in the IOCTL path for the same problem, which is
fixed in a subsequent patch.

Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
NVMe: IOCTL path RCU protect queue access

This adds rcu protected access to a queue in the nvme IOCTL path
to fix potential races between a surprise removal and queue usage in
nvme_submit_sync_cmd. The fix holds the rcu_read_lock() here to prevent
the nvme_queue from freeing while this path is executing so it can't
sleep, and so this path will no longer wait for a available command
id should they all be in use at the time a passthrough IOCTL request
is received.

Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
NVMe: Fix divide-by-zero in nvme_trans_io_get_num_cmds

dev->max_hw_sectors may be zero to indicate the device has no limit on
the number of sectors.  nvme_trans_do_nvme_io() should use the software
limit, since this is guaranteed to be non-zero.

Reported-by: Mundu <mundu2510@gmail.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
NVMe: Replace DEFINE_PCI_DEVICE_TABLE

Checkpatch has started warning against using DEFINE_PCI_DEVICE_TABLE,
so replace it.  Also update the copyright date and bump the module
version number to 0.9.

Signed-off-by: Matthew Wilcox <matthew.r.wilcox@intel.com>