I've been getting more and more quirk reports about this.  It seems
clear at this point that other OSes are not using this for determining
whether the integrated panel should be turned on, and it is not
reliable for doing so.  Better to light up an unintended panel than to
not light up the only usable output on the system.
Signed-off-by: NEric Anholt <eric@anholt.net>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Bug introduced in

commit 10ae9bd2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Feb 1 13:59:17 2010 +0100

    drm/i915: blow away userspace mappings before fence change

The problem is that when there's no fence reg assigned and the object
is mapped at a fenceable offset in the gtt, the userspace mappings won't
be torn down. Which happens on untiled->tiled transition quite often
on 4th gen and later because there fencing does not have any special
alignment constraints (as opposed to 2nd and 3rd gen on which I've tested
the original commit).

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=26993Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Eric Anholt <eric@anholt.net> (fixes OpenArena)
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

We should free "params" before returning.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Cc: stable@kernel.org (for .33)
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes:
  http://bugzilla.kernel.org/show_bug.cgi?id=15527
  NULL pointer dereference in i915_gem_object_save_bit_17_swizzle

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f82b5d2b>] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915]
Call Trace:
[<f82aea55>] ? i915_gem_object_put_pages+0x125/0x150 [i915]
[<f82aeb71>] ? i915_gem_object_get_pages+0xf1/0x110 [i915]
[<f82b0de8>] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915]
[<c02db74d>] ? drm_mm_get_block_generic+0x4d/0x180
[<f82b11cd>] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915]
[<f82ae786>] ? i915_gem_madvise_ioctl+0x86/0x120 [i915]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: maciej.rutecki@gmail.com
Cc: stable@kernel.org
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

IS_GEN6 missed to include SandyBridge mobile chip, which failed in
i915_probe_agp() for memory config detection. Fix it with a device
info flag.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

String constants that are continued on subsequent lines with \ will cause
spurious whitespace in the resulting output.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Eric Anholt <eric@anholt.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
[anholt: whacked it to wrap to 80 columns instead]
Signed-off-by: NEric Anholt <eric@anholt.net>

This could resolve HW deadlocks where a unit downstream of the VS is
waiting for more input, the VS has one vertex queued up but not
dispatched because it hopes to get one more vertex for 2x4 dispatch,
and software isn't handing more vertices down because it's waiting for
rendering to complete.  The B-Spec says you should always have this
bit set.
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NPriit Laes <plaes@plaes.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The continue just after this call with loop around and wait for the
request just added just fine. This leads to slightly more compact code.
Signed-Off-by: NOwain G. Ainsworth <oga@openbsd.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

We probably don't need it for most of the other driver ioctls as well,
but we explicitly did locking when doing the GEM pieces.  On CPU-bound
graphics tasks, the BKL was showing up as 1-2% of CPU time.
Signed-off-by: NEric Anholt <eric@anholt.net>

Values such as max_brightness should be set before backlights are
registered, but the current API doesn't allow that. Add a parameter to
backlight_device_register and update drivers to ensure that they
set this correctly.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>

Constify struct sysfs_ops.

This is part of the ops structure constification
effort started by Arjan van de Ven et al.

Benefits of this constification:

 * prevents modification of data that is shared
   (referenced) by many other structure instances
   at runtime

 * detects/prevents accidental (but not intentional)
   modification attempts on archs that enforce
   read-only kernel data at runtime

 * potentially better optimized code as the compiler
   can assume that the const data cannot be changed

 * the compiler/linker move const data into .rodata
   and therefore exclude them from false sharing
Signed-off-by: NEmese Revfy <re.emese@gmail.com>
Acked-by: NDavid Teigland <teigland@redhat.com>
Acked-by: NMatt Domsch <Matt_Domsch@dell.com>
Acked-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
Acked-by: NHans J. Koch <hjk@linutronix.de>
Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
Acked-by: NJens Axboe <jens.axboe@oracle.com>
Acked-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Convert some drivers who export a single string as class attribute
to the new class_attr_string functions. This removes redundant
code all over.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Passing the attribute to the low level IO functions allows all kinds
of cleanups, by sharing low level IO code without requiring
an own function for every piece of data.

Also drivers can extend the attributes with own data fields
and use that in the low level function.

This makes the class attributes the same as sysdev_class attributes
and plain attributes.

This will allow further cleanups in drivers.

Full tree sweep converting all users.
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit a069c266.

It turns ou that not only was it missing a case (XFS) that needed it,
but perhaps more importantly, people sometimes want to enable new
modules that they hadn't had enabled before, and if such a module uses
list_sort(), it can't easily be inserted any more.

So rather than add a "select LIST_SORT" to the XFS case, just leave it
compiled in.  It's not all _that_ big, after all, and the inconvenience
isn't worth it.
Requested-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Don Mullis <don.mullis@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Build list_sort() only for configs that need it -- those that don't save
~581 bytes (i386).
Signed-off-by: NDon Mullis <don.mullis@gmail.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Artem Bityutskiy <dedekind@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Another undocumented rule of kernel folklore, no default y
config options anymore, apparantly hinting to distros they might
want something isn't preferred anymore.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This driver is in *staging*. Fix the build with the switcheroo off.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon was always including the atpx code unnecessarily, also core
switcheroo was including acpi headers.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Type of iterator was promoted to unsigned long in 64bit systems.

*header is small structure so it is alwas safe to cast return value
of sizeof operator to int.
Signed-off-by: NPauli Nieminen <suokkos@gmail.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Many new laptops now come with 2 gpus, one to be used for low power
modes and one for gaming/on-ac applications. These GPUs are typically
wired to the laptop panel and VGA ports via a multiplexer unit which
is controlled via ACPI methods.

4 combinations of systems typically exist - with 2 ACPI methods.
Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method
ATI/ATI - some ASUS - use ATPX ACPI Method
Intel/Nvidia - - use _DSM ACPI method
Nvidia/Nvidia -  - use _DSM ACPI method.

TODO:
This patch adds support for the ATPX method and initial bits
for the _DSM methods that need to written by someone with
access to the hardware.
Add a proper non-debugfs interface - need to get some proper
testing first.

v2: add power up/down support for both devices
on W500 puts i915/radeon into D3 and cuts power to radeon.

v3: redo probing methods, no DMI list, drm devices call to
register with switcheroo, it tries to find an ATPX method on
any device and once there is two devices + ATPX it inits the
switcher.

v4: ATPX msg handling using buffers - should work on more machines

v5: rearchitect after more mjg59 discussion - move ATPX handling to
    radeon driver.

v6: add file headers + initial nouveau bits (to be filled out).

v7: merge delayed switcher code.

v8: avoid suspend/resume of gpu that is off

v9: rearchitect - mjg59 is always right. - move all ATPX code to
radeon, should allow simpler DSM also proper ATRM handling

v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv

v11: fix bug in resuming Intel for 2nd time.

v12: start fixing up nvidia code blindly.

v13: blindly guess at finishing nvidia code

v14: remove radeon audio hacks - fix up intel resume more like upstream

v15: clean up printks + remove unnecessary igd/dis pointers

mount debugfs

/sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected
 + 2 cards.

DIS - immediate change to discrete
IGD - immediate change to IGD
DDIS - delayed change to discrete
DIGD - delayed change to IGD
ON - turn on not in use
OFF - turn off not in use

Tested on W500 (Intel/ATI) and T500 (Intel/ATI)
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit "disabled" audio on RV710 and RV740 only, leaving RV770 and RV730.
The order is: CHIP_RV770 < CHIP_RV730 < CHIP_RV710 < CHIP_RV740.

It is not needed anway, as we do not even try to enable audio on RV770 and
newer. We call initializing function in r600.c only, not in rv770.c.

If there is something causing green tinges, it's HDMI mode setting for encoder
and I will try to debug that.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

radeon's have a special ability to passthrough writes in their internal
memory space directly to PCI, this ability means that if some of the internal
surfaces like the depth buffer point at 0x0, any writes to these will
go directly to RAM at 0x0 via PCI busmastering.

Now mesa used to always emit clears after emitting state, since the
radeon mesa driver was refactored a year or more ago, it was found it
could generate a clear request without ever sending any setup state to the
card. So the clear would attempt to clear the depth buffer at 0x0, which
would overwrite main memory at this point. fs corruption ensues.

Also once one app did this correctly, it would never get set back to 0
making this messy to reproduce.

The kernel should block this from happening as mesa runs without privs,
though it does require the user be connected to the current running X session.

This patch implements a check to make sure the depth offset has been set
before a depth clear occurs and if it finds one it prints a warning and
ignores the depth clear request. There is also a mesa fix to avoid sending
the badness going into mesa.

This only affects r100/r200 GPUs in user modesetting mode.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Reviewed-by: NCorbin Simpson <MostAwesomeDude@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

rs600 asic was missing set_surface_reg callback leading to
oops.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This IBM system has a multi-function SDVO card that reports both VGA
and TV, but the system has no TV connector.  The TV connector always
reported as connected, which would lead to poor modesetting choices.

https://bugs.freedesktop.org/show_bug.cgi?id=25787Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NVance <liangghv@sg.ibm.com>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

It would be good to disable the LVDS port when we shut down the panel
to save power.  We haven't done so until now because we had trouble
getting the right LVDS parameters from the BIOS.  I think we're past
that now, so enabling and disabling the port should be safe, though it
would probably be made cleaner with some additional changes to the
display code, where we also bang on the LVDS reg to set the pairing
correctly etc.

Seems to save a bit of power (up to 300mW in my basic wattsup
meter testing).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The assumption that an object has only ever one write domain is deeply
threaded into gem (it's even encoded the the singular of the variable
name). Don't let userspace screw us over.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Now that we have an exact gpu write domain tracking, we don't need
to move objects to the active list ourself. i915_add_request will
take care of that under all circumstances.

Idea stolen from a patch by Chris Wilson <chris@chris-wilson.co.uk>.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

We have it, so use it. This required moving the function to avoid
a forward declaration.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

The fence_list should be lru ordered for otherwise we might try
to steal a fence reg from an active object even though there are
fences from inactive objects available. lru ordering was obeyed
for gpu access everywhere save when moving dirty objects from
flushing_list to active_list.

Fixing this cause the code to indent way to much, so I've extracted
the flushing_list processing logic into its on function.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

The spaghetti logic in there tripped up my brain's code parser for a
few secs. Prevent this from happening again by extracting the fence
stealing code into a seperate functions. IMHO this slightly clears up
the code flow.

v2: Beautified according to ickle's comments.
v3: ickle forgot to flush his comment queue ... Now there's also a
we-are-paranoid BUG_ON in there.
v4: I've forgotten to switch on my brain when doing v3. Now the BUG_ON
actually checks something useful.
v5: Clean up a stale comment as noted by Eric Anholt.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

All other accesses take this spinlock, so do this here, too.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

This has a few functional changes against the old code:

* a few more unnecessary loads and stores to the drm_i915_fence_reg
  objects. Also an unnecessary store to the hw fence register.

* zaps any userspace mappings before doing other flushes. Only changes
  anything when userspace does racy stuff against itself.

* also flush GTT domain. This is a noop, but still try to keep the
  bookkeeping correct.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

See http://bugzilla.kernel.org/show_bug.cgi?id=15021

Make sure that the appropriate AGP module is loaded and probed before
trying to set up the DRM.  The DRM already depends on the AGP core,
but in this case we know the specific AGP driver we need too, and can
help users avoid the trap of loading the AGP driver after the DRM
driver.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>