i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

smatch warning:

drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
500 bytes on stack

Refactor so that saved_mode and saved_hwmode are dynamically allocated as opposed
to being automatic variables. 500 bytes seems like it could run the potential for blowing
the kernel stack.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove duplicate inclusion of drm/drm_edid.h

drm/drm_edid.h was included twice.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't prevent CPU idle states

Commit 9ee32fea5f unconditionally prevents the CPU from entering idle states
until intel_dp_aux_ch completes for the first time, which never happens on my
DisplayPort-less intel gfx, causing the CPU to get rather hot.

Signed-off-by: Tomas Janousek <tomi@nomi.cz>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages

On a machine with bit17 swizzling, we need to store the bit17 of the
physical page address in put-pages. This requires a memory allocation,
on average less than a page, which may be difficult to satisfy is the
request to put-pages is on behalf of the shrinker. We could allow that
allocation to pull from the reserved memory pools, but it seems much
safer to preallocate the array for tiled objects on affected machines.

v2: Export i915_gem_object_needs_bit17_swizzle() for reuse.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract common link_m_n helpers

Both the dp and fdi code use the exact same computations (ignore minor
differences in conversion between bits and bytes).

This makes it even more apparent that we have a _massive_ mess between
cpu transcoder/fdi link/pch transcoder and pch link settings. And also
that we have hilarious amounts of confusion between edp and dp
(despite that they're identical at a link level).

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop unnecessary clearing of pch dp transcoder timings

This has originally been added in

commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Wed Apr 7 16:15:54 2010 +0800

    drm/i915: Support for Cougarpoint PCH display pipeline

probably to combat issues with hw state left behind by the BIOS. And
indeed, I've checked out that specific revision, and there is no DP
support yet. So the pch dp transcoder won't be correctly disabled, and
that's important since it requires a rether special disable dance:
Just writing 0 to TRANS_DP_CTL won't cut it, since we need to select
the NONE port when disabling, too.

And indeed, things seem to still work, so let's just remove this.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WARN on !crtc in intel_dp_link_down

This could have happened with the old crtc helper based modeset code,
but can't happen any longer with the new code.

Hence put in a WARN and adjust the comment. If no one hits this, we
can eventually remove it (like a few other such cases across our
code).

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use wait_for_vblank instead of msleep(17)

17 ms is eerily close to 60 Hz ^-1

Unfortunately this goes back to the original DP enabling for ilk, and
unfortunately does not come with a reason for it's existance attached.

Some closer inspection of the code and DP specs shows that we set the
idle link pattern before we disable the port. And it seems like that
the DP spec (or at least our hw) only switch to the idle pattern on
the next vblank. Hence a vblank wait at this spot makes _much_ more
sense than a really long wait.

v2: Rebase fixup.

v3: Add comment requested by Paulo Zanoni saying that we don't really
know what this wait is for.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: rip out pre-production ilk cpu edp w/a

While reading docs I've noticed that this special workaround to select
the 1.6 GHz DP clock only applies to pre-production ilk machines.
Since the registers we're touching here are rather undocumented and
might be harmful on later chips, rip it out.

For the Bspec reference of this w/a look in "vol4g CPU Display
Registers [DevILK]", Section 4.1.7.1 "DP_A—DisplayPort A
Control Register", "DP_PLL_Frequency_Select".

v2: Keep a debug message as a hint in case something regresses.
Requested by Chris Wilson.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move set_pll_edp to intel_dp.c

Now that we enable the cpu edp pll in intel_dp->pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp->mode_set callback. Previously this was not possible because
the encoder ->mode_set callbacks are called after the crtc mode set
callback.

v2: Rebase on top of copy&pasted hsw crtc_mode_set.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set

Especially getting rid of all things lvds is ... great!

v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.

v3:
- handle DP ports correctly (spoted by Paulo)
- don't leave {} behind for a single-line block (again spotted by
  Paulo)
- kill another if (IBX || CPT) block

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: be less verbose when handling gmbus/aux irqs

Having 9500 lines repeated on dmesg does not help me at all.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove duplicate and unused register #defines in i915_reg.h

TRANS_DP_VIDEO_AUDIO is not used at all.
The other 3 has duplicated #defines.

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use _NOTRACE for gmbus/dp aux wait loops

Less clutter in the traces. And in both cases we yell rather loud
into the logs if we time out. Patch suggested by Chris Wilson.

v2: Annotate another I915_READ in dp_aux to be consistent - we filter
out all register io in wait_for and similar loops. Chris also
suggested to mark all dp_aux register access as _NOTRACE, but I think
we should keep all functionally relevant access around, and filter
unneeded bits in userspace after the trace is captured.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: irq-drive the dp aux communication

At least on the platforms that have a dp aux irq and also have it
enabled - vlvhsw should have one, too. But I don't have a machine to
test this on. Judging from docs there's no dp aux interrupt for gm45.

Also, I only have an ivb cpu edp machine, so the dp aux A code for
snb/ilk is untested.

For dpcd probing when nothing is connected it slashes about 5ms of cpu
time (cpu time is now negligible), which agrees with 3 * 5 400 usec
timeouts.

A previous version of this patch increases the time required to go
through the dp_detect cycle (which includes reading the edid) from
around 33 ms to around 40 ms. Experiments indicated that this is
purely due to the irq latency - the hw doesn't allow us to queue up
dp aux transactions and hence irq latency directly affects throughput.
gmbus is much better, there we have a 8 byte buffer, and we get the
irq once another 4 bytes can be queued up.

But by using the pm_qos interface to request the lowest possible cpu
wake-up latency this slowdown completely disappeared.

Since all our output detection logic is single-threaded with the
mode_config mutex right now anyway, I've decide not ot play fancy and
to just reuse the gmbus wait queue. But this would definitely prep the
way to run dp detection on different ports in parallel

v2: Add a timeout for dp aux transfers when using interrupts - the hw
_does_  prevent this with the hw-based 400 usec timeout, but if the
irq somehow doesn't arrive we're screwed. Lesson learned while
developing this ;-)

v3: While at it also convert the busy-loop to wait_for_atomic, so that
we don't run the risk of an infinite loop any more.

v4: Ensure we have the smallest possible irq latency by using the
pm_qos interface.

v5: Add a comment to the code to explain why we frob pm_qos. Suggested
by Chris Wilson.

v6: Disable dp irq for vlv, that's easier than trying to get at docs
and hw.

v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the
dp aux registers aren't at a fixed offset any more, but can be on the
PCH while the DP port is on the cpu die.

Reviewed-by: Imre Deak <imre.deak@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: wire up do aux channel done interrupt

Doesn't do anything yet than call dp_aux_irq_handler.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use gmbus irq to wait for gmbus idle

GMBUS_ACTIVE has inverted sense and so doesn't fit into the
wait_hw_status helper, hence create a new gmbus_wait_idle functions.
Also, we only care about the idle irq event and nothing else, which
allows us to use the wait_event_timeout helper directly without
jumping through hoops to catch NAKs.

Since gen2/3 don't have gmbus interrupts, handle them separately with
the old wait_for macro.

This shaves another few ms off reading EDID from a hdmi screen on my
testbox here. EDID reading with interrupt driven gmbus is now as fast
as with busy-looping gmbus at 28 ms here (with negligible cpu
overhead).

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use the gmbus irq for waits

We need two special things to properly wire this up:
- Add another argument to gmbus_wait_hw_status to pass in the
  correct interrupt bit in gmbus4.
- Since we can only get an irq for one of the two events we want,
  hand-roll the wait_event_timeout code so that we wake up every
  jiffie and can check for NAKs. This way we also subsume gmbus
  support for platforms without interrupts (or where those are not
  yet enabled).

The important bit really is to only enable one gmbus interrupt source
at the same time - with that piece of lore figured out, this seems to
work flawlessly.

Ben Widawsky rightfully complained the lack of measurements for the
claimed benefits (especially since the first version was actually
broken and fell back to bit-banging). Previously reading the 256 byte
hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
Given that transfering the 256 bytes over i2c at wire speed takes
20.5ms alone, the reduction in additional overhead is rather nice.

v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
when booting up an hence result in some spurious interrupts. Since we
clear GMBUS4 after every wait and we do gmbus transfer really early in
the setup sequence to detect displays the window is small, but still
be paranoid and clear it properly.

v3: Clarify the comment that gmbus irq generation can only support one
kind of event, why it bothers us and how we work around that limit.

Cc: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: wire up gmbus irq handler

Only enables the interrupt and puts a irq handler into place, doesn't
do anything yet.

Unfortunately there's no gmbus interrupt support for gen2/3 (safe for
pnv, but there the irq is marked as "Test mode").

v2: Wire up the irq handler for vlv and gen4 properly.

v3: i915_enable_pipestat expects the mask bit, not the status bits ... and
for added hilarity those are rather inconsistently named.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract gmbus_wait_hw_status

The gmbus interrupt generation is rather fiddly: We can only ever
enable one interrupt source (but we always want to check for NAK
in addition to the real bit). And the bits in the gmbus status
register don't map at all to the bis in the irq register.

To prepare for this mess, start by extracting the hw status wait
loop into it's own function, consolidate the NAK error handling a
bit. To keep things flexible, pass in the status bit we care about
(in addition to any NAK signalling).

v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted,
Chris Wilson gladly pointed that out for me. To keep things simple,
ignore that case for  now (we only need to idle the gmbus controller
at the end of an entire i2c transaction, not after every message).

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reorder setup sequence to have irqs for output setup

Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that
well. Noticed since the dp aux code doesn't have an automatic fallback
with a timeout (since the hw provides for that already).

v2: Simple move drm_irq_install before intel_modeset_gem_init, as
suggested by Ben Widawsky.

v3: Now that interrupts are enabled before all connectors are fully
set up, we might fall over serving a HPD interrupt while things are
still being set up. Instead of jumping through massive hoops and
complicating the code with a separate hpd irq enable step, simply
block out the hotplug work item from doing anything until things are
in place.

v4: Actually, we can enable hotplug processing only after the fbdev is
fully set up, since we call down into the fbdev from the hotplug work
functions. So stick the hpd enabling right next to the poll helper
initialization.

v5: We need to enable irqs before intel_modeset_init, since that
function sets up the outputs.

v6: Fixup cleanup sequence, too.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: setup the hangcheck timer early

... together with all the other irq related resources in
intel_irq_init. I've managed to oops in the notify_ring function on my
ilk, presumably because of the powerctx setup call to i915_gpu_idle.

Note that this is only a problem with the reorder irq setup sequence
for irq-driver gmbus/dp aux.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv

This is for legacy legacy stuff, and checking with the leftover
pipe from the previous loop is propably not what we want. Since
pipe == 2 after the loop ... Then we only assing a variable and do
nothing with it.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: haswell has the same irq handlers as ivb

No need to have the exaxt same code twice.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add intel_ring_handle_seqno wrap

If there are pre-wrap values in semaphore-mbox registers after wrap,
syncing against some after-wrap request will complete immediately.
Fix this by emitting ring commands to set mbox registers to zero
when the wrap happens.

v2: Use __intel_ring_begin to emit ring commands, from
Chris Wilson.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add a small comment to handle_seqno_wrap.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Split intel_ring_begin

In preparation for handling ring seqno wrapping, split
intel_ring_begin into helper part which doesn't allocate
seqno.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix debugfs seqno info print to use uint

seqno's are u32 so print accordingly

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add debugfs entry to read/write next_seqno

This is needed for testing seqno wrapping. Be careful to not bump next_seqno
more than 0x7FFFFFFF at a time (between some handled requests) as
i915_seqno_passed() can't handle bigger difference in between.

v2: Address review comments from Chris Wilson.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Squash in fixup to properly remove the debugfs file on driver
unload again.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fixup sparse warnings

- __iomem where there is none (I love how we mix these things up).
- Use gfp_t instead of an other plain type.
- Unconfuse one place about enum pipe vs enum transcoder - for the pch
  transcoder we actually use the pipe enum. Fixup the other cases
  where we assign the pipe to the cpu transcoder with explicit casts.
- Declare the mch_lock properly in a header.

There is still a decent mess in intel_bios.c about __iomem, but heck,
this is x86 and we're allowed to do that.

Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use a space after the cast consistently and fix up the
newly-added cast in i915_irq.c to properly use __iomem.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove check for conflicting relocation write-domains

Simply use the last write-domain set for the object in the batch,
trusting userspace to have correctly flushed the caches between usage as
a write target. This check dates back from the golden age of having only
a single operation per batch with the kernel repeating it for each
cliprect, and conflicts both with userspace trying to efficiently batch
multiple operations and with reducing the kernel overhead of relocation
processing.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Tighten the checks for invalid relocation domains

Be specific for the GPU domains so that we can detect if userspace ever
passed in an invalid combination, as well as accurately reflect the
known GPU domains when printing state.

Fixes i-g-t/gem_exec_bad_domains

References: https://bugs.freedesktop.org/show_bug.cgi?id=57826
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix dieing -> dying typo

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use a slab for object allocation

The primary purpose of this was to debug some use-after-free memory
corruption that was causing an OOPS inside drm/i915. As it turned out
the corruption was being caused elsewhere and i915.ko as a major user of
many objects was being hit hardest.

Indeed as we do frequent the generic kmalloc caches, dedicating one to
ourselves (or at least naming one for us depending upon the core) aids
debugging our own slab usage.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allocate overlay registers from stolen memory

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allocate ringbuffers from stolen memory

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allocate fbcon from stolen memory

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Introduce i915_gem_object_create_stolen()

Allow for the creation of GEM objects backed by stolen memory. As these
are not backed by ordinary pages, we create a fake dma mapping and store
the address in the scatterlist rather than obj->pages.

v2: Mark _i915_gem_object_create_stolen() as static, as noticed by Jesse
Barnes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Support readback of stolen objects upon error

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allow objects to be created with no backing pages, but stolen space

In order to accommodate objects that are not backed by struct pages, but
instead point into a contiguous region of stolen space, we need to make
various changes to avoid dereferencing obj->pages or obj->base.filp.

First introduce a marker for the stolen object, that specifies its
offset into the stolen region and implies that it has no backing pages.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Delay allocation of stolen space for FBC

As FBC is commonly disabled due to limitations of the chipset upon
output configurations, on many systems FBC is never enabled. For those
systems, it is advantageous to make use of the stolen memory for other
objects and so we defer allocation of the FBC chunk until we actually
require it. This increases the likelihood of that allocation failing,
but that in turns means that we are already taking advantage of the
stolen memory!

As well as delaying the allocation from driver initialisation until the
first use of FBC, we also return the stolen block after we finish using
it - allowing greater flexibility in our usage of stolen space. A side
effect of this is that we can then attempt to allocate only the required
amount of space (with a little slack to reduce reallocation rate and
avoid fragmentation).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Avoid clearing preallocated regions from the GTT

As yet we do not do any preallocation (chicken-and-egg problem), but we
may like to preserve anything already allocated by the BIOS or grub and
reuse for own purposes after initialising the driver.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix detection of base of stolen memory

The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.

It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.

Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Introduce an iterator over holes in the drm_mm range manager

This will be used i915 in forthcoming patches in order to measure the
largest contiguous chunk of memory available for enabling chipset
features.

v2: Try to make the macro marginally safer and more readable by not
depending upon the drm_mm_hole_node_end() being non-zero. Note that we
need to open code list_for_each() in order to update the hole_start,
hole_end variable on each iteration and keep the macro sane.

v3: Tidy up few BUG_ONs that fell foul of adding additional tests to
drm_mm_hole_node_start().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Introduce drm_mm_create_block()

To be used later by i915 to preallocate exact blocks of space from the
range manager.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: optimize ilk/snb irq handler

We only need to read/write the south interrupt register if the
corresponding bit is set in the north master interrupt register.
Noticed while reading our interrupt handling code.

Same optimization has already been applied on ivb in

commit 0e43406bcc1868a316eea6012a0a09d992c53521
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 9 21:45:44 2012 +0100

    drm/i915: Simplify interrupt processing for IvyBridge

    We can take advantage that the PCH_IIR is a subordinate register to
    reduce one of the required IIR reads, and that we only need to clear
    interrupts handled to reduce the writes. And by simply tidying the code
    we can reduce the line count and hopefully make it more readable.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915: convert struct spinlock to spinlock_t

spinlock_t should always be used.

  LD      drivers/gpu/drm/i915/built-in.o
  CHECK   drivers/gpu/drm/i915/i915_drv.c
  CC [M]  drivers/gpu/drm/i915/i915_drv.o
  CHECK   drivers/gpu/drm/i915/i915_dma.c
  CC [M]  drivers/gpu/drm/i915/i915_dma.o
  CHECK   drivers/gpu/drm/i915/i915_irq.c
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  CHECK   drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CHECK   drivers/gpu/drm/i915/i915_suspend.c
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CHECK   drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14:    expected unsigned int [unsigned] [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14:    got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
drivers/gpu/drm/i915/i915_gem.c:3706:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39:    expected restricted gfp_t [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39:    got unsigned int [unsigned] [usertype] mask
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CHECK   drivers/gpu/drm/i915/i915_gem_context.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
  CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
  CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CHECK   drivers/gpu/drm/i915/i915_sysfs.c
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CHECK   drivers/gpu/drm/i915/i915_trace_points.c
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CHECK   drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum transcoder  versus
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum pipe  versus
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_display.o
  CHECK   drivers/gpu/drm/i915/intel_crt.c
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CHECK   drivers/gpu/drm/i915/intel_lvds.c
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CHECK   drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60:    expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60:    got void [noderef] <asn:2>*vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42:    expected void const *<noident>
drivers/gpu/drm/i915/intel_bios.c:726:42:    got unsigned char [noderef] [usertype] <asn:2>*
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CHECK   drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum pipe  versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here
  CHECK   drivers/gpu/drm/i915/intel_dp.c
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
  CHECK   drivers/gpu/drm/i915/intel_hdmi.c
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
  CHECK   drivers/gpu/drm/i915/intel_sdvo.c
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CHECK   drivers/gpu/drm/i915/intel_modes.c
  CC [M]  drivers/gpu/drm/i915/intel_modes.o
  CHECK   drivers/gpu/drm/i915/intel_panel.c
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CHECK   drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/intel_pm.o
  CHECK   drivers/gpu/drm/i915/intel_i2c.c
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
  CHECK   drivers/gpu/drm/i915/intel_fb.c
  CC [M]  drivers/gpu/drm/i915/intel_fb.o
  CHECK   drivers/gpu/drm/i915/intel_tv.c
  CC [M]  drivers/gpu/drm/i915/intel_tv.o
  CHECK   drivers/gpu/drm/i915/intel_dvo.c
  CC [M]  drivers/gpu/drm/i915/intel_dvo.o
  CHECK   drivers/gpu/drm/i915/intel_ringbuffer.c
  CC [M]  drivers/gpu/drm/i915/intel_ringbuffer.o
  CHECK   drivers/gpu/drm/i915/intel_overlay.c
  CC [M]  drivers/gpu/drm/i915/intel_overlay.o
  CHECK   drivers/gpu/drm/i915/intel_sprite.c
  CC [M]  drivers/gpu/drm/i915/intel_sprite.o
  CHECK   drivers/gpu/drm/i915/intel_opregion.c
  CC [M]  drivers/gpu/drm/i915/intel_opregion.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7xxx.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7xxx.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7017.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7017.o
  CHECK   drivers/gpu/drm/i915/dvo_ivch.c
  CC [M]  drivers/gpu/drm/i915/dvo_ivch.o
  CHECK   drivers/gpu/drm/i915/dvo_tfp410.c
  CC [M]  drivers/gpu/drm/i915/dvo_tfp410.o
  CHECK   drivers/gpu/drm/i915/dvo_sil164.c
  CC [M]  drivers/gpu/drm/i915/dvo_sil164.o
  CHECK   drivers/gpu/drm/i915/dvo_ns2501.c
  CC [M]  drivers/gpu/drm/i915/dvo_ns2501.o
  CHECK   drivers/gpu/drm/i915/i915_gem_dmabuf.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_dmabuf.o
  CHECK   drivers/gpu/drm/i915/i915_ioc32.c
  CC [M]  drivers/gpu/drm/i915/i915_ioc32.o
  CHECK   drivers/gpu/drm/i915/intel_acpi.c
  CC [M]  drivers/gpu/drm/i915/intel_acpi.o
  LD [M]  drivers/gpu/drm/i915/i915.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      drivers/gpu/drm/i915/i915.mod.o
  LD [M]  drivers/gpu/drm/i915/i915.ko

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: kill intel_dp_link_clock()

Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but
supports DP_LINK_BW_5_4 and is also used by the other drivers.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: invert the log inside intel_prepare_ddi

Do an early return in case we don't have DDI instead of having the
whole function inside an "if" statement.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add HAS_DDI check

And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove Haswell code from ironlake_fdi_pll_enable

This function is not called on Haswell anymore.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: intel_prepare_ddi_buffers should be static

It's not even declared on header files.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: optimize the shmem_pwrite slowpath handling

Since we drop dev->struct_mutex when going through the slowpath, the
object might have been moved out of the cpu domain. Hence we need to
clflush the entire object to ensure that after the ioctl returns,
everything is coherent again (interwoven writes are ill-defined
anyway).

But we only need to do this if we start in the cpu domain and the
object requires flushing for coherency. So don't do the flushing if
the object is coherent anyway or if we've done in-line clfushing
already.

v2: i915_gem_clflush_object already checks whether the object is
coherent and if so, drops the flushing. Hence we don't need to check
that ourselves, simplifying the condition.

v3: Reorder the checks for better clarity (and adjust the comment
accordingly), suggested by Chris Wilson.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: simplify shmem pwrite/pread slowpath handling

The shmem paths for pwrite/pread used a clever trick to hold onto a
single page when dropping the big dev->struct_mutex for the slowpath.
But this ran the risk of reinstating (or not completely purging) the
backing storage when dropping purgeable objects.

Hence the code needed to keep track of whether it ever dropped the
lock, and if it did, manually check whether it needs to re-purge the
backing storage. But thanks to the pages pin count introduced in

commit a5570178c059cec59e9835be20bc8546377fa7b5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:54 2012 +0100

    drm/i915: Pin backing pages whilst exporting through a dmabuf vmap

which allowed us to pin the backing storage and remove that page
reference trick from shmem_pwrite/read in

commit f60d7f0c1d55a935475ab394955cafddefaa6533
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:56 2012 +0100

    drm/i915: Pin backing pages for pread

and

commit 755d22184f1e5015b040acee794542d9cf8a16c5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 4 21:02:55 2012 +0100

    drm/i915: Pin backing pages for pwrite

we can now abolish this check. The slowpath cleanup completely
disappears from pread, and for pwrite we're only left with the domain
fixup in case someone moved the object out of the cpu domain from
under us. A follow-on patch will optimize that a notch more.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too

Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable

A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode

v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether
we shouldn't add an attached_panel pointer to intel_encoder, to
replace the encoder private ->attached_connector pointers, since
that's essentially what we need.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add intel_lvds->reg

To ditch at least some of the PCH_SPLIT ? PCH_LVDS : LVDS code ...

v2: Rebase on top of Jani Nikula's panel rework.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: track is_dual_link in intel_lvds

Yeah, all users (both the clock selection special cases and the lvds
pin pair stuff) are still in common code, but this will change.

v2: Rebase on top of Jani Nikula's panel rework.

v3: Incorporate review from Paulo Zanoni:
- s/__is_dual_link_lvds/compute_is_dual_link_lvds
- kill dev_priv->lvds_val
- drop spurious whitespace change

v4: Add a debug printk to display the dual-link status, as suggested
by Paulo Zanoni in review.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move is_dual_link_lvds to intel_lvds.c

Just a prep patch to make this a property of intel_lvds. Makes more
sense, removes clutter from intel_display.c and eventually I want to
move all the encoder special cases wrt clock handling to encoders
anyway.

v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static
now.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: replace ad-hoc dual-link lvds checks

... with is_dual_link_lvds introduced in

commit b03543857fd75876b96e10d4320b775e95041bb7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Tue Mar 20 13:07:05 2012 +0100

    drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

All these checks predate this commit and have simply been overlooked.
Since we don't support switching between single-link and dual-link
modes anyway, this different checks could at best only get in the way
of refactorings, and in the worst case cause inconsistencies.

v2: Update the comment, we now have a solid way to figure out whether
we need dual-link lvds or not (falling back to vbt values as a last
resort). We still don't know how to switch between dual-link and
single link so leave that part intact. I'm not sure though whether
switching between these two modes makes any sense - we always drive
the panel at its fixed mode (with a fixed bpc) anyway ...

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add encoder->pre_pll_enable callback

Currently we have two encoder specific bits in the common mode_set
functions:
- lvds pin pair enabling
- dp m/n setting and computation

Now the lvds stuff needs to happen before the pll is enabled. Since
that is done in the crtc_mode_set functions, we need to add a new
callback to be able to move them to the encoder code (where they
belong). The dp m/n stuff is a giant mess anyway (since it also
confuses itself with the fdi link m/n handling), so that needs to be
handled separately.

I think that we can move the pll enabling down quite a bit, which
might allow us to eventually merge encoder->pre_enable with this new
pre_pll_enable callback. But for now this will allow us to clean
things up a bit.

Note that vlv doesn't support lvds, hence we don't need to change
anything in there.

v2: Fixup commit message, both suggested from Paulo Zanoni.
- dp m/n doesn't need to happen before pll enabling
- lvds doesn't exist on vlv, hence no changes required in the vlv pll
  function.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/debugfs: Prune a couple of superfluous leading zeros from bo domains

As we do not have any domains occupying the high bits, there is no point
in always printing the leading 00.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill i915_gem_execbuffer_wait_for_flips()

As per Chris Wilson's suggestion make
i915_gem_execbuffer_wait_for_flips() go away.

This was used to stall the GPU ring while there are pending
page flips involving the relevant BO. Ie. while the BO is still
being scanned out by the display controller.

The recommended alternative is to use the page flip events to
wait for the page flips to fully complete before reusing the BO
of the old front buffer. Or use more buffers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Kristian Høgsberg <krh@bitplanet.net>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: don't remove obj->pending_flips, still required due to
reorder patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove duplicate register #defines

Somehow a chunk of unused register defines ended up in the middle of
the PLL defines. They go back to the original kms merging.

The only used #define is SR01, move it to the register name together
with the other legacy vga stuff.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set sync_seqno properly after seqno wrap

i915_gem_handle_seqno_wrap() will zero all sync_seqnos but as the
wrap can happen inside ring->sync_to(), pre wrap seqno was
carried over and overwrote the zeroed sync_seqno.

When wrap is handled, all outstanding requests will be retired and
objects moved to inactive queue, causing their last_read_seqno to be zero.
Use this to update the sync_seqno correctly.

RING_SYNC registers after wrap will contain pre wrap values which
are >= seqno. So injecting the semaphore wait into ring completes
immediately.

Original idea for using last_read_seqno from Chris Wilson.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Include the last semaphore sync point in the error-state

Should be useful to know what the driver thought the other ring's seqno
was when it last used a semaphore.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Rearrange code to only have a single method for waiting upon the ring

Replace the wait for the ring to be clear with the more common wait for
the ring to be idle. The principle advantage is one less exported
intel_ring_wait function, and the removal of a hardcoded value.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Simplify flushing activity on the ring

As we now always preallocate the seqno before writing to the ring, we
can trivially test if we have any pending activity on the ring by
inspecting the olr. This makes it then possible to flush operations that
are not normally associated with a request, like power-management.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Preallocate next seqno before touching the ring

Based on the work by Mika Kuoppala, we realised that we need to handle
seqno wraparound prior to committing our changes to the ring. The most
obvious point then is to grab the seqno inside intel_ring_begin(), and
then to reuse that seqno for all ring operations until the next request.
As intel_ring_begin() can fail, the callers must already be prepared to
handle such failure and so we can safely add further checks.

This patch looks like it should be split up into the interface
changes and the tweaks to move seqno wrapping from the execbuffer into
the core seqno increment. However, I found no easy way to break it into
incremental steps without introducing further broken behaviour.

v2: Mika found a silly mistake and a subtle error in the existing code;
inside i915_gem_retire_requests() we were resetting the sync_seqno of
the target ring based on the seqno from this ring - which are only
related by the order of their allocation, not retirement. Hence we were
applying the optimisation that the rings were synchronised too early,
fortunately the only real casualty there is the handling of seqno
wrapping.

v3: Do not forget to reset the sync_seqno upon module reinitialisation,
ala resume.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: force restore on lid open

There seem to be indeed some awkwards machines around, mostly those
without OpRegion support, where the firmware changes the display hw
state behind our backs when closing the lid.

This force-restore logic has been originally introduced in

commit c1c7af60892070e4b82ad63bbfb95ae745056de0
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time

but after the modeset-rework we've disabled it in the vain hope that
it's no longer required:

commit 3b7a89fce3e3dc96b549d6d829387b4439044d0d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 17 22:27:21 2012 +0200

    drm/i915: fix OOPS in lid_notify

Alas, no.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
Tested-by: Krzysztof Mazur <krzysiek@podlesie.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Wait upon the last request seqno, rather than a future seqno

In commit 69c2fc891343cb5217c866d10709343cff190bdc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 12:41:03 2012 +0100

    drm/i915: Remove the per-ring write list

the explicit flush was removed from i915_ring_idle(). However, we
continued to wait upon the next seqno which now did not correspond to
any request (except for the unusual condition of a failure to queue a
request after execbuffer) and so would wait indefinitely.

This has an important side-effect that i915_gpu_idle() does not cause
the seqno to be incremented. This is vital if we are to be able to idle
the GPU to handle seqno wraparound, as in subsequent patches.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix possible NULL dereference of dev_priv

Dereference dev_priv only after we know it is valid.
Found with smatch.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Increase the response time for slow SDVO devices

Some devices may respond very slowly and only flag that the reply is
pending within the first 15us response window. Be kind to such devices
and wait a further 15ms, before checking for the pending reply. This
moves the existing special case delay of 30ms down from the detection
routine into the common path and pretends to explain it...

v2: Simplify the loop constructs as suggested by Jani Nikula.

References: https://bugs.freedesktop.org/show_bug.cgi?id=36997
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set the VIC of the mode on the AVI InfoFrame

We currently set "0" as the VIC value of the AVI InfoFrames. According
to the specs this should be fine and work for every mode, so to my
point of view we can't consider the current behavior as a bug. The
problem is that  we recently received a bug report (Kernel bug #50371)
from a user that has an AV receiver that gives a black screen for any
mode with VIC set to 0.

So in order to make at least some modes work for him, this patch sets
the correct VIC number when sending AVI InfoFrames.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: add drm_mode_cea_vic

This function returns the VIC of the mode. This value can be used when
creating AVI InfoFrames.

Cc: Thierry Reding <thierry.reding@avionic-design.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix pte updates in ggtt clear range

This bug was introduced by me:
commit e76e9aebcdbfebae8f4cd147e3c0f800d36e97f3
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sun Nov 4 09:21:27 2012 -0800

    drm/i915: Stop using AGP layer for GEN6+

The existing code uses memset_io which follows memset semantics in only
guaranteeing a write of individual bytes. Since a PTE entry is 4 bytes,
this can only be correct if the scratch page address is 0.

This caused unsightly errors when we clear the range at load time,
though I'm not really sure what the heck is referencing that memory
anyway. I caught this is because I believe we have some other bug where
the display is doing reads of memory we feel should be cleared (or we
are relying on scratch pages to be a specific value).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: promote Haswell to full support

Since it should be working a little bit better now.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Report the origin of the LVDS fixed panel mode

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: resolve conflict around the call to intel_crtc_mode_get. And
add the missing NULL check Chris spotted while at it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: LVDS fallback to fixed-mode if EDID not present

Use the recorded panel fixed-mode to populate the get_modes() request in
the absence of an EDID.

Fixes regression from
commit 9cd300e038d492af4990b04e127e0bd2df64b1ca
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Oct 19 14:51:52 2012 +0300

    drm/i915: Move cached EDID to intel_connector

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the retval-changing hunk, as suggested by Jani in his
review and acked by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/sdvo: kfree the intel_sdvo_connector, not drm_connector, on destroy

Since the base fields in both struct intel_connector and struct
intel_sdvo_connector are at the beginning of the enclosing struct, the
pointers are essentially the same, but there is no requirement or guarantee
that this is always the case. Kfree the enclosing intel_sdvo_connector
pointer that was originally allocated, not the enclosed drm_connector, in
case someone ever rearranges the structs.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drm_connector_property -> drm_object_property

v2: Rebased.

Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1)
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use drm_send_vblank_event() helper

Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use pci_resource functions for BARs.

This was leftover crap from kill-agp. The current code is theoretically
broken for 64b bars. (I resist removing theoretically because I am too
lazy to test).

We still need to ioremap things ourselves because we want to ioremap_wc
the PTEs.

v2: Forgot to kill the tmp variable in v1

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Borrow our struct_mutex for the direct reclaim

If we have hit oom whilst holding our struct_mutex, then currently we
cannot reap our own GPU buffers which likely pin most of memory, making
an outright OOM more likely. So if we are running in direct reclaim and
already hold the mutex, attempt to free buffers knowing that the
original function can not continue until we return.

v2: Add a note explaining that the mutex may be stolen due to
pre-emption, and that is bad.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Defer assignment of obj->gtt_space until after all possible mallocs

As we may invoke the shrinker whilst trying to allocate memory to hold
the gtt_space for this object, we need to be careful not to mark the
drm_mm_node as activated (by assigning it to this object) before we
have finished our sequence of allocations.

Note: We also need to move the binding of the object into the actual
pagetables down a bit. The best way seems to be to move it out into
the callsites.

Reported-by: Imre Deak <imre.deak@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added small note to commit message to summarize review
discussion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Apply the IBX transcoder A w/a for HDMI to SDVO as well

As the SDVO/HDMI registers are multiplex, it is safe to assume that the
w/a required for HDMI on IbexPoint, namely that the SDVO register cannot
both be disabled and have selected transcoder B, is also required for
SDVO. At least the modeset state checker detects that the transcoder
selection is left in the undefined state, and so it appears sensible to
apply the w/a:

[ 1814.480052] WARNING: at drivers/gpu/drm/i915/intel_display.c:1487 assert_pch_hdmi_disabled+0xad/0xb5()
[ 1814.480053] Hardware name: Libretto W100
[ 1814.480054] IBX PCH hdmi port still using transcoder B

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaMbcDriverBootEnable on Haswell

Also document the WA name for the previous gens that implement it.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix intel_ddi_get_cdclk_freq for ULT machines

For now, this code is just used by the eDP AUX channel frequency.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make the panel fitter work on pipes B and C on Haswell

This goes on a separate patch since it won't apply on the stable
trees and there's nothing using panel fitter on HSW on the older
Kernels.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make the panel fitter work on pipes B and C on IVB

I actually found this problem on Haswell, but then discovered Ivy
Bridge also has it by reading the spec.

I don't have the hardware to test this.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't intel_crt_init if DDI A has 4 lanes

DDI A and E have 4 lanes to share, so if DDI A is using 4 lanes,
there's nothing left for DDI E, which means there's no CRT port on the
machine.

The bit we're checking here is programmed at system boot and it cannot
be changed afterwards, so we cannot change the amount of lanes
reserved for each DDI port.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make DP work on LPT-LP machines

We need to enable a special bit, otherwise none of the DP functions
requiring the PCH will work.

Version 2: store the PCH ID inside dev_priv, as suggested by Daniel
Vetter.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix false positive "Unclaimed write" messages

We don't check if the "unclaimed register" bit is set before we call
writel, so if it was already set before, we might print a misleading
message about "unclaimed write" on the wrong register.

This patch makes us check the unclaimed bit before the writel, so we
can print a new "Unknown unclaimed register before writing to %x"
message.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use cpu/pch transcoder on intel_enable_pipe

This function runs on Haswell, so set the correct pch_transcoder and
cpu_transcoder variables. This fixes an assertion failure on Haswell
VGA.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't limit Haswell CRT encoder to pipe A

This is a full revert of 59c859d6f2e78344945e8a8406a194156176bc4e:
    drm/i915: account for only one PCH receiver on Haswell

Now that the PCH code is fixed to be able use the only PCH transcoder
independently of the pipe and CPU transcoder, we can revert this.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Resolve conflict due to the rebasing of dinq on top of
drm-next.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Flush outstanding unpin tasks before pageflipping

If we accumulate unpin tasks because we are pageflipping faster than the
system can schedule its workers, we can effectively create a
pin-leak. The solution taken here is to limit the number of unpin tasks
we have per-crtc and to flush those outstanding tasks if we accumulate
too many. This should prevent any jitter in the normal case, and also
prevent the hang if we should run too fast.

Note: It is important that we switch from the system workqueue to our
own dev_priv->wq since all work items on that queue are guaranteed to
only need the dev->struct_mutex and not any modeset resources. For
otherwise if we have a work item ahead in the queue which needs the
modeset lock (like the output detect work used by both polling or
hpd), this work and so the unpin work will never execute since the
pageflip code already holds that lock. Unfortunately there's no
lockdep support for this scenario in the workqueue code.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Added note about workqueu deadlock.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56337
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: resurrect panel lid handling

But disabled by default. This essentially reverts

commit bcd5023c961a44c7149936553b6929b2b233dd27
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Mar 14 14:17:55 2011 +1000

    drm/i915: disable opregion lid detection for now

but leaves the autodetect mode disabled. There's also the explicit lid
status option added in

commit fca874092597ef946b8f07031d8c31c58b212144
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Feb 17 13:44:48 2011 +0000

    drm/i915: Add a module parameter to ignore lid status

Which overloaded the meaning for the panel_ignore_lid parameter even
more. To fix up this mess, give the non-negative numbers 0,1 the
original meaning back and use negative numbers to force a given state.
So now we have

1  - disable autodetect, return unknown
0  - enable autodetect
-1 - force to disconnected/lid closed
-2 - force to connected/lid open

v2: My C programmer license has been revoked ...

v3: Beautify the code a bit, as suggested by Chris Wilson.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27622
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable DP audio for Haswell

This patch adds the missing code to send ELD for Haswell DisplayPort,
based on Xingchao's original patch.

A test was performed with HSW-D machine and NEC EA232Wmi DP monitor.

Cc: Xingchao Wang <xingchao.wang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pin the object whilst faulting it in

In order to prevent reaping of the object whilst setting it up to
handle the pagefault, we need to mark it as pinned. This has the nice
side-effect of eliminating some special cases from the pagefault handler
as well!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Guard pages being reaped by OOM whilst binding-to-GTT

In the circumstances that the shrinker is allowed to steal the mutex
in order to reap pages, we need to be careful to prevent it operating on
the current object and shooting ourselves in the foot.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove bogus test for a present execbuffer

The intention of checking obj->gtt_offset!=0 is to verify that the
target object was listed in the execbuffer and had been bound into the
GTT. This is guarranteed by the earlier rearrangement to split the
execbuffer operation into reserve and relocation phases and then
verified by the check that the target handle had been processed during
the reservation phase.

However, the actual checking of obj->gtt_offset==0 is bogus as we can
indeed reference an object at offset 0. For instance, the framebuffer
installed by the BIOS often resides at offset 0 - causing EINVAL as we
legimately try to render using the stolen fb.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>