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>

It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

i915_error_object_create() is called from the timer interrupt and hence
can corrupt the KM_USER0 slot.  Use KM_IRQ0 instead.
Reported-by: NJaswinder Singh Rajput <jaswinderlinux@gmail.com>
Tested-by: NJaswinder Singh Rajput <jaswinderlinux@gmail.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes up include paths for i915_trace.h by setting additional CFLAGS
for i915_trace_points.c to include the $src directory. The required
TRACE_INCLUDE_PATH is then "."
Signed-off-by: NPeter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

This lru tracks fences, not objects, so move it to where it belongs.
As a side effect, this nicely shrinks drm_i915_gem_object by two
pointers.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Makes no sense and complicates matters for pipelined tiling changes.
So don't allow it and return -EBUSY.

v2: Fix reference leak. Thanks to Owain Ainsworth for spotting this.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

If we're both RGB and TMDS capable, we'll have set up one connector for
each.  When determining connectivity, require analog/digital state in
the EDID block to match analog/digital support in the connector.
Otherwise, both DVI and VGA will appear to be connected.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Multifunction SDVO cards stopped working after 14571b4c, and would report
something that looked remarkably like an ADD2 SPD ROM instead of EDID.
This appears to be because DDC bus selection was utterly horked by that
commit; controlled_output was no longer always a single bit, so
intel_sdvo_select_ddc_bus would pick bus 0, which is (unsurprisingly)
the SPD ROM bus, not a DDC bus.

So, instead of that, let's just use the DDC bus the child device table
tells us to use.  I'm guessing at the bitmask and shifting from VBIOS
dumps, but it can't possibly be worse.

cf. https://bugzilla.redhat.com/584229Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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>

By idling the GPU and discarding everything we can when under extreme
memory pressure, the number of OOM-killer events is dramatically
reduced. For instance, this makes it possible to run
firefox-planet-gnome.trace again on my swapless 512MiB i915.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Spatial dither is better than nothing, but ST is even better.

(from ajax's followup message:)
  I noticed this with:

  http://ajax.fedorapeople.org/YellowFlower.jpg

  set as my desktop background in Gnome on a 1280x800 machine (in
  particular, a Sony Vaio VPCB1 with 6-bit panel and a rather bright black
  level).  Easiest way to test this is by poking at PIPEACONF with
  intel_reg_write directly:

  % sudo intel_reg_write 0x70008 0xc0000040 # no dither
  % sudo intel_reg_write 0x70008 0xc0000050 # spatial
  % sudo intel_reg_write 0x70008 0xc0000054 # ST

  I notice it especially strongly in the relatively flat dark area in the
  top left.  Closer than about 18" I can see a noticeable checkerboard
  pattern with plain spatial dithering.  ST smooths that out; I can still
  tell that it's lacking color precision, but it's not offensive.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

My PIPE_CONTROL fix (just sent via Eric's tree) was buggy; I was
testing a whole set of patches together and missed a conversion to the
new HAS_PIPE_CONTROL macro, which will cause breakage on non-Ironlake
965 class chips.  Fortunately, the fix is trivial and has been tested.

Be sure to use the HAS_PIPE_CONTROL macro in i915_get_gem_seqno, or
we'll end up reading the wrong graphics memory, likely causing hangs,
crashes, or worse.
Reported-by: NZdenek Kabelac <zdenek.kabelac@gmail.com>
Reported-by: NToralf Förster <toralf.foerster@gmx.de>
Tested-by: NToralf Förster <toralf.foerster@gmx.de>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since 965, the hardware has supported the PIPE_CONTROL command, which
provides fine grained GPU cache flushing control.  On recent chipsets,
this instruction is required for reliable interrupt and sequence number
reporting in the driver.

So add support for this instruction, including workarounds, on Ironlake
and Sandy Bridge hardware.

https://bugs.freedesktop.org/show_bug.cgi?id=27108Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
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>

Eric mentioned on irc this patch was bad, so revert it.

This reverts commit fb8b5a39.
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Luckily the change is quite a little bit less invasive than I've
feared.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Thanks to the to_intel_bo helper, this change is rather trivial.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just embed it and adjust the pointers, No other changes (that's
for later patches).
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just preparation, no functional change.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When drivers embed the core gem object into their own structures,
they'll have to do this. Temporarily this results in an ugly

kfree(gem_obj);

in every gem driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Current code is definitely crap: Largest pitch allowed spills into
the TILING_Y bit of the fence registers ... :(

I've rewritten the limits check under the assumption that 3rd gen hw
has a 3d pitch limit of 8kb (like 2nd gen). This is supported by an
otherwise totally misleading XXX comment.

This bug mostly resulted in tiling-corrupted pixmaps because the kernel
allowed too wide buffers to be tiled. Bug brought to the light by the
xf86-video-intel 2.11 release because that unconditionally enabled
tiling for pixmaps, relying on the kernel to check things. Tiling for
the framebuffer was not affected because the ddx does some additional
checks there ensure the buffer is within hw-limits.

v2: Instead of computing the value that would be written into the
hw fence registers and then checking the limits simply check whether
the stride is above the 8kb limit. To better document the hw, add
some WARN_ONs in i915_write_fence_reg like I've done for the i830
case (using the right limits).
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27449Tested-by: NAlexander Lam <lambchop468@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

PORT_HOTPLUG_EN has allready been setup in i915_driver_irq_postinstall(),
when intel_dp_detect() runs.

Delete the DP[BCD]_HOTPLUG_INT_EN defines, they are not referenced anymore.

I found this while searching for a fix for
        https://bugzilla.redhat.com/show_bug.cgi?id=528312Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NEric Anholt <eric@anholt.net>

we used to set the DIDL in the output device detected order.
But some BIOSes requires it to be initialized in the ACPI device order.
e.g. the value of the first field in DIDL stands for the first
ACPI video output device in ACPI namespace.

Now we initialize the DIDL using the device id, i.e. _ADR return value,
of each ACPI video device, if it is not 0.
https://bugzilla.kernel.org/show_bug.cgi?id=15054Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This should be a small power savings. Tested on Lenovo T410 (Ironlake), LVDS
VGA and DisplayPort, up to 1920x1200R.

v2: Add Sandybridge support, fix obvious math error.
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

pci.ids and the datasheet both say it's 358e, not 35e8.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.

v2: Handle 830m correctly too.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

Update the self-refresh watermark for display plane/cursor and enable
the memory self-refresh on Ironlake. The watermark is also updated for
the active display plane.

More than 1W idle power is saved on one Ironlake laptop after enabling
memory self-refresh.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Previously, after setting up the Pineview CxSR state, i9xx_update_wm would
get called and overwrite our state.

BTW: We will disable the self-refresh and never enable it any more if we
can't find the appropriate the latency on pineview plaftorm. In such case
the update_wm callback will be NULL.

The bitmask macro is also defined to access the corresponding fifo
watermark register.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Otherwise it will cause that S-video output becomes black/white when
switching to other TV format.

http://bugs.freedesktop.org/show_bug.cgi?id=23916Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NArnold <arnold.erbsloeh@web.de>
Tested-by: NBazin <bazin.cz@gmail.com>
Tested-by: NNigel <nigel_tuck@eircom.net>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

SDVO on Ibexpeak PCH with Ironlake is multiplexed with
HDMIB port, and only has SDVOB port.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The existing code handling the DPMS ON event is much more careful to
ensure that these registers are enabled according to strict sequencing
requirements. Enabling these early in mode_set simply defeats that.
Signed-off-by: NCarl Worth <cworth@cworth.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>

This reverts commit 6070a4a9.

The quirk for this SDVO device on IBM specific board is just a hack
in old code which showed the broken multifunction SDVO support in
the driver. Multifunction SDVO patch provided the right fix for it.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>