drm/i915: fix overlay on i830M

The overlay on the i830M has a peculiar failure mode: It works the
first time around after boot-up, but consistenly hangs the second time
it's used.

Chris Wilson has dug out a nice errata:

"1.5.12 Clock Gating Disable for Display Register
Address Offset:	06200h–06203h

"Bit 3
Ovrunit Clock Gating Disable.
0 = Clock gating controlled by unit enabling logic
1 = Disable clock gating function
DevALM Errata ALM049: Overlay Clock Gating Must be Disabled:  Overlay
& L2 Cache clock gating must be disabled in order to prevent device
hangs when turning off overlay.SW must turn off Ovrunit clock gating
(6200h) and L2 Cache clock gating (C8h)."

Now I've nowhere found that 0xc8 register and hence couldn't apply the
l2 cache workaround. But I've remembered that part of the magic that
the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache
allocations so that the overlay scaler has some scratch space.

And while pondering how that could explain the hang the 2nd time we
enable the overlay, I've remembered that the old ums overlay code did
_not_ issue the OVERLAY_OFF cmd.

And indeed, disabling the OFF cmd results in the overlay working
flawlessly, so I guess we can workaround the lack of the above
workaround by simply never disabling the overlay engine once it's
enabled.

Note that we have the first part of the above w/a already implemented
in i830_init_clock_gating - leave that as-is to avoid surprises.

v2: Add a comment in the code.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827
Cc: stable@vger.kernel.org
Tested-by: Rhys <rhyspuk@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: VGA needs to be on pipe A on i830M

The bit doesn't stick, and the output is always cloned from pipe A,
even when it's supposed to scan out from pipe B.

Shuts up annoying warnings from the modeset-rework, too.

I've noticed that with this patch we know get and unknown connection
state since the code can't find a suitable pipe for load detection.
But that beats the previous state of affairs, where it tried to use
pipe B, actually used pipe A and concluded that something is connected
(although it's the LVDS on pipe A and nothing on the VGA connector on
pipe B).

I've tried to make load detect work by remapping the pipe->planes
stuff, so that crtc 0 will use pipe B and hence we still have
something left for load-detect on pipe A. But alas, that upset the hw
a bit.

So there's still some things to figure out, but this here will at
least paper over some of the problems.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51265
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: extend the commit message a bit with recent observations.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
arm64: Use pgprot_t as the last argument when invoking __ioremap()

Even if it works with since the types have the same size, the correct
type of the last __ioremap() argument is pgprot_t rather than pteval_t.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
arm64: Move PCI_IOBASE closer to MODULES_VADDR

This is to reuse the same pmd table that is sparsely populated with
the modules space.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
drm/i915: clear the entire sdvo infoframe buffer

Like in the case of native hdmi, which is fixed already in

commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Sep 25 13:23:34 2012 -0300

    drm/i915: make sure we write all the DIP data bytes

we need to clear the entire sdvo buffer to avoid upsetting the
display.

Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.

v2: Cite the right commit above, spotted by Paulo Zanoni.

v3: I'm too stupid to paste the right commit.

v4: Ben Hutchings noticed that I've failed to handle an underflow in
my loop logic, breaking it for i >= length + 8. Since I've just lost C
programmer license, use his solution. Also, make the frustrated 0-base
buffer size a notch more clear.

Reported-and-tested-by: Jürg Billeter <j@bitron.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: stable@vger.kernel.org
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption

cryptd_queue_worker attempts to prevent simultaneous accesses to crypto
workqueue by cryptd_enqueue_request using preempt_disable/preempt_enable.
However cryptd_enqueue_request might be called from softirq context,
so add local_bh_disable/local_bh_enable to prevent data corruption and
panics.

Bug report at http://marc.info/?l=linux-crypto-vger&m=134858649616319&w=2

v2:
 - Disable software interrupts instead of hardware interrupts

Cc: stable@vger.kernel.org
Reported-by: Gurucharan Shetty <gurucharan.shetty@gmail.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
menuconfig: Replace CIRCLEQ by list_head-style lists.

sys/queue.h and CIRCLEQ in particular have proven to cause portability
problems (reported on Debian Sarge, Cygwin and FreeBSD)

Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Tested-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
s390/cio: suppress 2nd path verification during resume

Do not trigger a path verification in the subchannel event
function during resume from hibernate. This will be started
by the pm_restore callback later.

Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/mm: use pmd_large() instead of pmd_huge()

Without CONFIG_HUGETLB_PAGE, pmd_huge() will always return 0. So
pmd_large() should be used instead in places where both transparent
huge pages and hugetlbfs pages can occur.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/thp: respect page protection in pmd_none() and pmd_present()

Similar to pte_none() and pte_present(), the pmd functions should also
respect page protection of huge pages, especially PROT_NONE.
This patch also simplifies massage_pgprot_pmd() by adding new definitions
for huge page protection.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
drm/i915: be less verbose about inability to provide vendor backlight

commit 28dcc2d60cb570d9f549c329b2f51400553412a1
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Sep 3 16:25:12 2012 +0300

    drm/i915: do not expose a dysfunctional backlight interface to userspace

prevents backlight interface creation if the BIOS has not set the backlight
PWM CTL registers that contain the max PWM value. It's apparently normal on
those machines, so demote the message about it to debug level.

Reported-by: Orion Poplawski <orion@cora.nwra.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56330
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Only kick out vesafb if we takeover the fbcon with KMS

Otherwise we may remove the only console for a nomodeset system.

We became more aggressive in our kicking with
commit e188719a2891f01b3100dca4ae3a055fb5a7ab52
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 12 11:28:17 2012 +0200

    drm/i915: kick any firmware framebuffers before claiming the gtt

Reported-and-tested-by: monnier@iro.umontreal.ca
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54615
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # v3.6
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
sparc64: Make montmul/montsqr/mpmul usable in 32-bit threads.

The Montgomery Multiply, Montgomery Square, and Multiple-Precision
Multiply instructions work by loading a combination of the floating
point and multiple register windows worth of integer registers
with the inputs.

These values are 64-bit.  But for 32-bit userland processes we only
save the low 32-bits of each integer register during a register spill.
This is because the register window save area is in the user stack and
has a fixed layout.

Therefore, the only way to use these instruction in 32-bit mode is to
perform the following sequence:

1) Load the top-32bits of a choosen integer register with a sentinel,
   say "-1".  This will be in the outer-most register window.

   The idea is that we're trying to see if the outer-most register
   window gets spilled, and thus the 64-bit values were truncated.

2) Load all the inputs for the montmul/montsqr/mpmul instruction,
   down to the inner-most register window.

3) Execute the opcode.

4) Traverse back up to the outer-most register window.

5) Check the sentinel, if it's still "-1" store the results.
   Otherwise retry the entire sequence.

This retry is extremely troublesome.  If you're just unlucky and an
interrupt or other trap happens, it'll push that outer-most window to
the stack and clear the sentinel when we restore it.

We could retry forever and never make forward progress if interrupts
arrive at a fast enough rate (consider perf events as one example).
So we have do limited retries and fallback to software which is
extremely non-deterministic.

Luckily it's very straightforward to provide a mechanism to let
32-bit applications use a 64-bit stack.  Stacks in 64-bit mode are
biased by 2047 bytes, which means that the lowest bit is set in the
actual %sp register value.

So if we see bit zero set in a 32-bit application's stack we treat
it like a 64-bit stack.

Runtime detection of such a facility is tricky, and cumbersome at
best.  For example, just trying to use a biased stack and seeing if it
works is hard to recover from (the signal handler will need to use an
alt stack, plus something along the lines of longjmp).  Therefore, we
add a system call to report a bitmask of arch specific features like
this in a cheap and less hairy way.

With help from Andy Polyakov.

Signed-off-by: David S. Miller <davem@davemloft.net>
sparc64: Fix cpu strand yielding.

For atomic backoff, we just loop over an exponentially backed off
counter.  This is extremely ineffective as it doesn't actually yield
the cpu strand so that other competing strands can use the cpu core.

In cpus previous to SPARC-T4 we have to do this in a slightly hackish
way, by doing an operation with no side effects that also happens to
mark the strand as unavailable.

The mechanism we choose for this is three reads of the %ccr
(condition-code) register into %g0 (the zero register).

SPARC-T4 has an explicit "pause" instruction, and we'll make use of
that in a subsequent commit.

Yield strands also in cpu_relax().  We really should have done this a
very long time ago.

Signed-off-by: David S. Miller <davem@davemloft.net>
sparc64: Use pause instruction when available.

In atomic backoff and cpu_relax(), use the pause instruction
found on SPARC-T4 and later.

It makes the cpu strand unselectable for the given number of
cycles, unless an intervening disrupting trap occurs.

Signed-off-by: David S. Miller <davem@davemloft.net>
sparc64: Improvde documentation and readability of atomic backoff code.

Document what's going on in asm/backoff.h with a large and descriptive
comment.  Refer to it above the cpu_relax() definition in
asm/processor_64.h

Rename the pause patching section to have "3insn" in it's name like
the other patching sections do.

Based upon feedback from Sam Ravnborg.

Signed-off-by: David S. Miller <davem@davemloft.net>
sparc: Wire up sys_kcmp.

Signed-off-by: David S. Miller <davem@davemloft.net>
qlogicpti: Fix build warning.

The build warns:

drivers/scsi/qlogicpti.c: In function 'qpti_sbus_probe':
drivers/scsi/qlogicpti.c:1316:45: warning: passing argument 1 of 'scsi_host_alloc' discards 'const' qualifier from pointer target type [enabled by default]
include/scsi/scsi_host.h:778:26: note: expected 'struct scsi_host_template *' but argument is of type 'const struct scsi_host_template *'

The problem is that of_device_id->data is a const void pointer.

This is pretty silly in this specific instance, because for all
matched device IDs we set match->data to the same value,
&qpti_template.

So just use that directly instead of the unnecessary and improperly
typed abstraction.

Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: 7565/1: sched: stop sched_clock() during suspend

The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.

This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.

arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.

Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.

This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.

Thanks to Kevin Hilman for helping out with debugging.

Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug
in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make
VFPv3 usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is
booted on a pre-VFPv3 core, the code attempts to save and restore the
d16-d31 VFP registers.  These are only present on non-D16 VFPv3+, so
this results in an undefined instruction exception.  The code didn't
crash before commit 846a136 because the save and restore code was
only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP
flag that affirmatively indicates the presence of the d16-d31
registers:

   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

and some feedback from Måns to clarify the name of the HWCAP flag.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Måns Rullgård <mans.rullgard@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>