vlv: it might be wise if we initialised the flag value...

Otherwise our initial behaviour is "randomly save a bogus PLL
choice" as far as I can see.

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915: fix error path leak in intel_sdvo_write_cmd

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915: Remove silly test

drv_priv->gmbus is an array. Comparing it with NULL is somewhat less useful
than a chocolate teapot.

Possibly we should be testing bus != NULL each iteration of the loop
instead ?

gcc could help by warning too!

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix forcewake related hangs on snb

... by adding seemingly redudant posting reads.

This little dragon lair exploded the first time around when we've
refactored the code a bit to use the common wait_for_atomic_us in
"drm/i915: Group the GT routines together in both code and vtable",
which caused QA to file fdo bug #51738.

Chris Wilson entertained a few approaches to fixing #51738: Replacing
the udelay(1) with the previously-used udelay(10) (or any other
"sufficiently larger" delay), adding a posting read, or ditching the
delay completely and using cpu_relax. We went with the cpu_relax and
"915: Workaround hang with BSD and forcewake on SandyBridge". Which
blew up in fdo bug #52424, but adding the posting read while still
using cpu_relax seems to also fix that, it looks like the
posting read is the important ingriedient to fix these rc6 related
hangs on snb.

Popular theories as to why this is like it is include:
- A herd of pink elephants got royally angered somehow.

- The gpu has internally different functional units and judging by the
  register offsets, the forcewake request register and the forcewake
  ack registers are _not_ in the same functional unit (or at least
  aren't reached through the same routes). Hence the posting read
  syncs up with the wrong block and gets the entire gpu confused.

- ...

As a minimal ducttape fix for 3.6, let's just put these posting reads
into place again. We can try fancier approaches (like adding back the
cpu_relax instead of the udelay) in -next.

This (re-)fixes a regression introduced in

commit 990bbdadabaa51828e475eda86ee5720a4910cc3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 2 11:51:02 2012 -0300

    drm/i915: Group the GT routines together in both code and vtable

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Du Yan <yanx.du@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738u
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.

If a buffer that was the target of a PIPE_CONTROL from userland was a
reused one that hadn't been evicted which had not previously had this
workaround applied, then the early return for a correct
presumed_offset in this function meant we would not bind it into the
GTT and the write would land somewhere else.

Fixes reproducible failures with GL_EXT_timer_query usage in apitrace,
and I also expect it to fix the intermittent OQ issues on snb that
danvet's been working on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48019
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52932
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Carl Worth <cworth@cworth.org>
Tested-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: remove unused variable

the following warning was produced,

drivers/gpu/drm/i915/i915_gem_context.c: In function ‘i915_switch_context’:
drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ‘ret’ [-Wunused-variable]

fix up by removing it

Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915: don't map imported dma-bufs for dmar.

The exporter should have given us pages in the correct place, avoid
the prepare object mapping phase on dmar systems.

This fixes an oops on a GM45/R600 machine, when running the intel/radeon
tests.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Make intel_panel_get_backlight static.

This function isn't used outside of intel_panel.c, so make it static.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Workaround hang with BSD and forcewake on SandyBridge

For reasons that are not apparent to anybody, 990bbdadaba (drm/i915:
Group the GT routines together in both code and vtable) breaks the use
of the BitStream Decoder ring on SandyBridge. The active ingredient of
that patch is the conversion from a udelay(10) to a udelay(1) in the
busy-wait loop of waiting for the forcewake acknowledge. If we restore
that udelay(10) or insert another udelay(1) afterwards (or any wait
longer than 250ns) everything works again. An alternative is also to
remove any delay from the busy-wait loop.

Given that in the atomic sections we want to complete the wait as quick
as possible to avoid blocking the CPU for too long, it makes sense to
remove the delay altogether and simply spin on the exit condition until
it completes. So we replace the udelay(1) with cpu_relax().

Papers over regression from

commit 990bbdadabaa51828e475eda86ee5720a4910cc3
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 2 11:51:02 2012 -0300

    drm/i915: Group the GT routines together in both code and vtable

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make rc6 in sysfs functions conditional

Commit 0136db586c028f71e7cc21cc183064ff0d5919c8 merges rc6 information
into the power group. However, when compiled with CONFIG_PM not set,
modprobing i915 would taint since power_group_name is defined as NULL.

This patch makes these rc6 in sysfs functions conditional upon the
definition of the CONFIG_PM macro to avoid the above-mentioned problem.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181
Cc: stable@vger.kernel.org
Tested-by: Kris Karas <bugs-a12@moonlit-rail.com>
Signed-off-by: Hunt Xu <mhuntxu@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: add more Haswell PCI IDs

Also properly indent the HB IDs.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: correctly order the ring init sequence

We may only start to set up the new register values after having
confirmed that the ring is truely off. Otherwise the hw might lose the
newly written register values. This is caught later on in the init
sequence, when we check whether the register writes have stuck.

Cc: stable@vger.kernel.org
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522
Tested-by: Yang Guang <guang.a.yang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
s390/mm: remove MAX_PHYSADDR_BITS define

It's unused, so remove it.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/sclp_sdias: Add missing break and "fall through"

If the last block of the HSA is read, EVSTATE_ALL_STORED is returned
by SCLP. Because of a missing break in the switch statement two trace
entries are written in this case: "all stored" and "part stored".

This patch adds the missing break and also adds a "fall through"
comment to improve the readability.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Reported-by: David A Gilbert <DavidAGilbert@uk.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/seccomp: add support for system call filtering using BPF

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390: do not clobber personality flags in sys_32_personality()

There are multiple errors in how sys_32_personality() handles personality
flags stored in top three bytes.

- directly comparing current->personality against PER_LINUX32 doesn't work
  in cases when any of the personality flags stored in the top three bytes
  are used.
- directly forcefully setting personality to PER_LINUX32 or PER_LINUX
  discards any flags stored in the top three bytes

Fix the first one by properly using personality() macro to compare only
PER_MASK bytes.
Fix the second one by setting only the bits that should be set, instead of
overwriting the whole value.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/compat: fix compat wrappers for process_vm system calls

The compat wrappers incorrectly called the non compat versions of
the system process_vm system calls.

Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/compat: fix mmap compat system calls

The native 31 bit and the compat behaviour for the mmap system calls differ:

In native 31 bit mode the passed in address for the mmap system call will be
unmodified passed to sys_mmap_pgoff().
In compat mode however the passed in address will be modified with
compat_ptr() which masks out the most significant bit.

The result is that in native 31 bit mode each mmap request (with MAP_FIXED)
will fail where the most significat bit is set, while in compat mode it
may succeed.

This odd behaviour was introduced with d3815898 "[S390] mmap: add missing
compat_ptr conversion to both mmap compat syscalls".

To restore a consistent behaviour accross native and compat mode this
patch functionally reverts the above mentioned commit.

Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
drm/radeon/kms: allow "invalid" DB formats as a means to disable DB

Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:

"- Regression fixer for an OOPS at boot when i915.ko is built-in and
  CONFIG_PM=n, introduce in 3.5 (patch from Hunt Xu)
- Regression fixer for occlusion query failures, the required w/a wasn't
  applied in all cases (thanks to Eric for tracking this on down).
- dmar vs. dma_buf imprt fix (Dave Airlie)
- 2 patches to fight down forcewake issues on snb. This is the stuff I've
  talked about 2 weeks ago already, it's a minefield. Investigation still
  going on, but afaict this is the best we have for now.
- a few minor things to keep coverty&compiler happy (Alan, Davendra,
  Stéphane)
- tons of hsw pci ids - this one is a bit late because internal approval
  sometimes takes a while, but ppl in charge finally agreed that world+dog
  already knows about ult and crw haswell variants ;-)

Wrt regressions I'm aware of:
- the power regression due to semaphores=1. Ben is running around with a
  killawatt, unfortunately we have a hard time reproducing this one. And
  this /shouldn't/ increase power usage. Ben has turned up a few odds bits
  though already.
- the lvds fix in 3.6-rc1 broke a backlight after lid close/open (but can
  be resurrected with a modeset cycle). I guess we anger the bios - I'm
  still looking into this one.
- gmbus broke edid reading on an odd-ball monitor, we need to fall-back.
  Due to vacation (both mine&the reporter's) this is stalling for a final
  patch and a tested-by on it. But issue is fully diagnosed."

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: correctly order the ring init sequence
  drm/i915: add more Haswell PCI IDs
  drm/i915: make rc6 in sysfs functions conditional
  drm/i915: Workaround hang with BSD and forcewake on SandyBridge
  drm/i915: Make intel_panel_get_backlight static.
  i915: don't map imported dma-bufs for dmar.
  drm/i915: remove unused variable
  drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.
  drm/i915: fix forcewake related hangs on snb
  i915: Remove silly test
  i915: fix error path leak in intel_sdvo_write_cmd
  vlv: it might be wise if we initialised the flag value...