It is recommended that we use the Video BIOS tables that were copied
into the OpRegion during POST when initialising the driver. This saves
us from having to furtle around inside the ROM ourselves and possibly
allows the vBIOS to adjust the tables prior to initialisation.

On some systems, such as the Samsung N210, there is no accessible VBIOS
and the only means of finding the VBT is through the OpRegion.

v2: Rearrange the code so that ASLE is enabled along with ACPI
v3: Enable OpRegion parsing even without ACPI
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>

ums-gem code correctly cancels the retire work (at lastclose time),
kms does not do so. Fix this by canceling the work right after ideling
the gpu.

While staring at the code I noticed that the work function is not
static. Fix this, too.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When the module unloads, all users should be gone, hence all bo references
held by userspace, too. This should already result in an idle ringbuffer.
Still, be paranoid and idle gem before starting the unload dance.

Also kill the call to i915_gem_lastclose under an if (kms), it's a noop
for kms.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Kill any outstanding unpin_work when destroying the corresponding
crtc. Then flush the workqueue before the gem teardown, in case
any unpin work is still outstanding.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

With kms, interrupts now get disabled in the modesetting cleanup. So
free the error state afterwards, it currently gets allocated in
the interrupt handler.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

hotplug_work is queued by the hotplug interrupt and only either emits
a hotplug uevent or queues a crt poll slow-work. No other locking.  So
it's safe to cancel this work _after_ irq's have been turned off.  But
before the modesetting objects are destroyed because the hotplug
function accesses them (without locking).

The current code (for kms) only switches irqs off after modesetting
teardown, hence move the irq teardown into the modeset cleanup right
before the crtc cleanup.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is the first patch to clean up module unload races due to
outstanding timers/work. Preparatory step: Thou shalt not destroy
the workqueue when new work might still get enqued.

Now error_work gets queued by the hangcheck timer and only (atomically)
reads the chip wedged status. So cancel it right after the hangcheck
timer is killed. But the hangcheck is armed by interrupts, so move
everything after irqs are disabled.

Also change a del_timer to a del_timer_sync in the ums gem code, the
hangcheck timer is self-rearming.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We were failing when trying to allocate the resource for MMIO of the
MCHBAR because we forgot to specify what type of resource we wanted.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

copy_to_user returns the number of bytes remaining to be copied, but we
want to return a negative error code here.  These are returned to
userspace.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

So set the coherent dma mask accordingly. This dma mask is only used
for physical objects, so it won't really matter allocation-wise.

Now this never really surfaced because sane 32bit kernels only have 1G
of lowmem. But some eager testers (distros?) still carry around the patch
to adjust lowmem via a kconfig option. And the kernel seems to favour
high allocations on boot-up, hence the overlay blowing up reliably.

Because the patch is tiny and nicely shows how broken gen2 is it's imho
worth to merge despite the fact that mucking around with the lowmem/
highmem division is (no longer) supported.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28318
Cc: stable@kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.

This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.

Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.

v2:
fix nouveau pushbuf arg (thanks to Ben for pointing it out)
Reported-by: NLinus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is required by the spec, and without this some 3D programs will
hang after resume from RC6 we enable that.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Some BIOSes will claim a large chunk of stolen space.  Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained.  So clamp the stolen space to 32M and ignore the rest.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others.

Adding the ignored stolen memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Tested-by: NArtem S. Tashkinov <t.artem@mailcity.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

About 0.2W power can be saved on one HP laptop.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We should only free the compressed llb if we allocated it in the first
place otherwise we'll panic at unload time.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes:

drivers/gpu/drm/i915/i915_dma.c: In function ‘i915_setup_compression’:
drivers/gpu/drm/i915/i915_dma.c:1311: error: ‘compressed_llb’ may be used uninitialized in this function
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

intel_cleanup_ring_buffer() calls drm_gem_object_unreference() (as
opposed to drm_gem_object_unreference_unlocked()) so it needs to be
called with "struct_mutex" held.  If we don't hold the lock, it triggers
a BUG_ON(!mutex_is_locked(&dev->struct_mutex));

I also audited the other places that call intel_cleanup_ring_buffer()
and they all hold the lock so they're OK.

This was introduced in: 8187a2b7 "drm/i915: introduce
intel_ring_buffer structure (V2)" and it's a regression from v2.6.34.

Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16247Signed-off-by: NDan Carpenter <error27@gmail.com>
Reported-by: NBenny Halevy <bhalevy@panasas.com>
Tested-by: NBenny Halevy <bhalevy@panasas.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Gen3 chips have slightly different flip commands, and also contain a bit
that indicates whether a "flip pending" interrupt means the flip has
been queued or has been completed.

So implement support for the gen3 flip command, and make sure we use the
flip pending interrupt correctly depending on the value of ECOSKPD bit
0.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The previous commit fixes the problem, these commits make sure we actually
fail properly if it happens again.

I've squashed the commits from Chris since they are all fixing one issue.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will let userland only try to use the new media decode
functionality when the appropriate kernel is present.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Because we aren't in a suspend state the poll will still run when we have switcherooed a card off.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Allow platform devices without PCI resources to be DRM devices.

[airlied: fixup warnings with dev pointers]
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Remove the drm_resource wrappers and directly use the
actual PCI and/or platform functions in their place.

[airlied: fixup nouveau properly to build]
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes /debug/dri/0/i915_gem_interrupt output for status page.
Signed-off-by: NEric Anholt <eric@anholt.net>

Pineview with DDR3 memory has different latencies to enable CxSR.
This patch updates CxSR latency table to add Pineview DDR3 latency
configuration. It also adds one flag "is_ddr3" for checking DDR3
setting in MCHBAR.

Cc: Shaohua Li <shaohua.li@intel.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NLi Peng <peng.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Add power monitoring support to the i915 driver for use by the IPS
driver.  Export the available power info to the IPS driver through a few
new inter-driver hooks.  When used together, the IPS driver and this
patch can significantly increase graphics performance on Ironlake class
chips.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: Fixed 32-bit compile.  stupid obfuscating div_u64()]
Signed-off-by: NEric Anholt <eric@anholt.net>

The BSD (bit stream decoder) ring is used for accessing the BSD engine
which decodes video bitstream for H.264 and VC1 on G45+.  It is
asynchronous with the render ring and has access to separate parts of
the GPU from it, though the render cache is coherent between the two.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The active list and request list move into the ringbuffer structure,
so each can track its active objects in the order they are in that
ring.  The flushing list does not, as it doesn't matter which ring
caused data to end up in the render cache.  Objects gain a pointer to
the ring they are active on (if any).
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Introduces a more complete intel_ring_buffer structure with callbacks
for setup and management of a particular ringbuffer, and converts the
render ring buffer consumers to use it.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NXiang Hai hao <haihao.xiang@intel.com>
[anholt: Fixed up whitespace fail and rebased against prep patches]
Signed-off-by: NEric Anholt <eric@anholt.net>

With the advent of the BSD ring, be clear about which ring this is.
The docs are pretty consistent with calling this the Render engine at
this point.

This is preparation for supporting multiple ringbuffers on Ironlake.
The non-copy-and-paste changes are:
- de-staticing functions
- I915_GEM_GPU_DOMAINS moving to i915_drv.h to be used by both files.
- i915_gem_add_request had only half its implementation
  copy-and-pasted out of the middle of it.

The i915's implementation of KMS requires GEM in order to manage the
memory and execution domains of the framebuffer and associated
resources. By the point at which we detect broken a BIOS and need to
disable GEM, we have already registered ourselves as a KMS driver with
several subsystems. Rather than introducing a fragile unwind and attempt
to continue with UMS, spit out an error and unload the driver.

References:

  [Bug 15754] IP: [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
              BUG: unable to handle kernel NULL pointer dereference at (null)
  https://bugzilla.kernel.org/show_bug.cgi?id=15754

[drm:i915_driver_load] *ERROR* Detected broken video BIOS with
262140/262144kB of video memory stolen.
[drm:i915_driver_load] *ERROR* Disabling GEM. (try reducing stolen
memory or updating the BIOS to fix).
i915 0000:00:02.0: irq 30 for MSI/MSI-X
[drm] set up 255M of stolen space
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
PGD 69719067 PUD 69dda067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/module/snd_seq_oss/initstate
CPU 1
Pid: 867, comm: modprobe Not tainted 2.6.33-ARCH #1 G43Twins-FullHD/To
Be Filled By O.E.M.
RIP: 0010:[<ffffffffa0207589>]  [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
RSP: 0018:ffff8800699f3af8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 0000000000000000
RDX: 0000000000001000 RSI: 0000000000001000 RDI: ffff8800693d0f78
RBP: ffff8800699f3b18 R08: 0000000000001000 R09: 0000000000000000
R10: 2222222222222222 R11: 0000000000000000 R12: ffff880068de70c0
R13: 0000000000001000 R14: 0000000000000000 R15: ffff8800689cb000
FS:  00007fa93f4e5700(0000) GS:ffff880001880000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000695a0000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 867, threadinfo ffff8800699f2000, task ffff8800694f4740)
Stack:
 ffff880068de73c0 ffff880068de70c0 ffff8800689cb000 0000000000001000
<0> ffff8800699f3b68 ffffffffa0299f63 ffff8800693d0f78 0000120068de70c0
<0> ffff8800689cb000 ffff880068de73c0 ffff880068de70c0 ffff8800689cb000
Call Trace:
 [<ffffffffa0299f63>] i915_gem_object_bind_to_gtt+0x83/0x360 [i915]
 [<ffffffffa029a2e5>] i915_gem_object_pin+0xa5/0xb0 [i915]
 [<ffffffffa029a3c5>] i915_gem_init_ringbuffer+0xd5/0x510 [i915]
 [<ffffffffa028dbee>] i915_driver_load+0x4ce/0xd00 [i915]
 [<ffffffffa0205d37>] ? drm_sysfs_device_add+0x87/0xb0 [drm]
 [<ffffffffa0203363>] ? drm_get_minor+0x1d3/0x330 [drm]
 [<ffffffffa02037e6>] drm_get_dev+0x326/0x580 [drm]
 [<ffffffffa02bc0a5>] i915_pci_probe+0x10/0xd0 [i915]
 [<ffffffff811e98a2>] local_pci_probe+0x12/0x20
 [<ffffffff811ea8e0>] pci_device_probe+0x80/0xb0
 [<ffffffff8127b12a>] ? driver_sysfs_add+0x5a/0x90
 [<ffffffff8127b273>] driver_probe_device+0x93/0x1a0
 [<ffffffff8127b413>] __driver_attach+0x93/0xa0
 [<ffffffff8127b380>] ? __driver_attach+0x0/0xa0
 [<ffffffff8127a8f8>] bus_for_each_dev+0x68/0x90
 [<ffffffff8127b0c9>] driver_attach+0x19/0x20
 [<ffffffff8127a0ad>] bus_add_driver+0xcd/0x2d0
 [<ffffffff8127b718>] driver_register+0x78/0x140
 [<ffffffff811eab91>] __pci_register_driver+0x51/0xd0
 [<ffffffffa02d6000>] ? i915_init+0x0/0x52 [i915]
 [<ffffffffa01fdc31>] drm_init+0x111/0x120 [drm]
 [<ffffffff810eb0cd>] ? register_shrinker+0x4d/0x60
 [<ffffffffa02d6000>] ? i915_init+0x0/0x52 [i915]
 [<ffffffffa02d6050>] i915_init+0x50/0x52 [i915]
 [<ffffffff81002047>] do_one_initcall+0x37/0x1a0
 [<ffffffff8108ed17>] sys_init_module+0xd7/0x250
 [<ffffffff81009fc2>] system_call_fastpath+0x16/0x1b
Code: eb 29 49 8b 41 28 31 d2 49 f7 f5 85 d2 74 39 44 89 c0 29 d0 48 89 c2 48 01 f2 49 39 d2 73 29 0f 1f 00 49 89 da 4c 89 d3 4d 89 d9 <4d> 8b 19 49 39 f9 41 0f 18 0b 74 2b 4d 8b 51 30 4d 89 cc 49 39
RIP  [<ffffffffa0207589>] drm_mm_search_free+0x49/0x90 [drm]
 RSP <ffff8800699f3af8>
CR2: 0000000000000000
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.

v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.

v3: add config lock take inside polling, add intel/nouveau poll init/fini calls

v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.

glisse: discard drm_helper_hpd_irq_event

v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We'll turn off outputs etc at unload time, so don't unmap the registers
before doing it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This keeps the memory manager from complaining when we take it down.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

->dev_private at that point is NULL and is initialied only a few lines
later.
Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

PCH is the new name for south bridge from Ironlake/Sandybridge,
which contains most of the display outputs except eDP. This one
adds a probe function to detect current PCH type, and method to
detect Cougarpoint PCH.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.

This patch

a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
c) pushed the fb probing/hotplug control into the driver
d) makes the surface sizes into a structure for ease of passing
This changes the intel/radeon/nouveau drivers to use the new helper.
Signed-off-by: NDave Airlie <airlied@redhat.com>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>