Commit Graph

309575 Commits

Author SHA1 Message Date
Jesse Barnes
a0c4da24ea drm/i915: ValleyView mode setting limits and PLL functions
Add some VLV limit structures and update the PLL code.

v2: resolve conflicts, Vijay to re-post with PLL valid checks and fixed limits
v3: re-add dpio write function
v4: squash in Vijay's fixes for the PLL limits and clean up the m/n finder

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 14:21:23 +02:00
Daniel Vetter
cc889e0f6c drm/i915: disable flushing_list/gpu_write_list
This is just the minimal patch to disable all this code so that we can
do decent amounts of QA before we rip it all out.

The complicating thing is that we need to flush the gpu caches after
the batchbuffer is emitted. Which is past the point of no return where
execbuffer can't fail any more (otherwise we risk submitting the same
batch multiple times).

Hence we need to add a flag to track whether any caches associated
with that ring are dirty. And emit the flush in add_request if that's
the case.

Note that this has a quite a few behaviour changes:
- Caches get flushed/invalidated unconditionally.
- Invalidation now happens after potential inter-ring sync.

I've bantered around a bit with Chris on irc whether this fixes
anything, and it might or might not. The only thing clear is that with
these changes it's much easier to reason about correctness.

Also rip out a lone get_next_request_seqno in the execbuffer
retire_commands function. I've dug around and I couldn't figure out
why that is still there, with the outstanding lazy request stuff it
shouldn't be necessary.

v2: Chris Wilson complained that I also invalidate the read caches
when flushing after a batchbuffer. Now optimized.

v3: Added some comments to explain the new flushing behaviour.

Cc: Eric Anholt <eric@anholt.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 13:54:28 +02:00
Daniel Vetter
8e88a2bd59 drm/i915: don't call modeset_init_hw in i915_reset
It seems to blow up my ilk in all kinds of strange ways. And now that
we're no longer resetting the entire modeset state, it shouldn't be
necessary any longer.

This essentially reverts

commit f817586ceb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 10 15:50:11 2012 +0200

    drm/i915: re-init modeset hw state after gpu reset

safe for the introduction of modeset_init_hw, that one is nice to
prevent code duplication between driver load and resume.

v2: Add a comment to the code to warn future travellers of the dragon
dungeon ahead, suggested by Chris Wilson.

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:31:44 +02:00
Daniel Vetter
5fa8be65e9 drm/i915: return -ENODEV if hw context are not supported
Otherwise userspace has no way to figure this out.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:19:20 +02:00
Daniel Vetter
73c273eb75 drm/i915: simplify context_idr_cleanup
The idr code already passes us the pointer associated with that id, so
no need to look it up again. Also, we'll kill the idr right away, so
there's no issue with leaving these dangling pointers behind - the
current code does the same.

v2: Also drop the file argument, spotted by Ben Widawsky.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:48 +02:00
Daniel Vetter
6f4c45c12c drm/i915/context: shut up compiler
It found some unused variables.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:28 +02:00
Daniel Vetter
0d32601376 drm/i915: return -ENOENT if the context doesn't exist
This is our customary "no such object" errno, not -EINVAL.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:16:08 +02:00
Daniel Vetter
df12c6d5ec drm/i915: initialize the context idr unconditionally
It doesn't hurt and it at least prevents us from OOPSing left and
right at quite a few places. This also allows us to simplify the code
a bit by folding the only line of context_open into the callsite.

We obviuosly also need to run the cleanup code unconditionally, too.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 11:15:37 +02:00
Daniel Vetter
55a6662837 drm/i915: fix module unload after context merge
commit 8e96d9c4d9
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Mon Jun 4 14:42:56 2012 -0700

    drm/i915: reset the GPU on context fini

broke module unload because it reset the gpu before we've stopped
touching it. Later on in the unload sequence the ringbuffer code
complained that the gpu would idle properly (because intel_gpu_reset
only resets the hw and not our sw state).

v2: Reorder things so that we reset the gpu _before_ we release the
backing storage of the default context.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51183
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-20 10:06:29 +02:00
Jesse Barnes
e3f33d46fd drm/i915: add L3 bank clock gating disable on VLV
Prevents a possible hang: WaDisableL3Bank2xClockGate.

v2: only apply to VLV, IVB doesn't need this anymore

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:41:47 +02:00
Jesse Barnes
6edaa7fcf2 drm/i915: add TDL unit clock gating disable for VLV
Another required workaround for a potential hang:
WaDisableTDLUnitClockGating.

v2: only apply this to VLV, IVB doesn't need it anymore (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50245
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:41:14 +02:00
Jesse Barnes
b4ae3f22d2 drm/i915: load boot context at driver init time
According to the bspec for MBCTL:

Driver must set bit in the following scenarios:
  - to realod teh h/w boot context every time it gets loaded through OS
  - after an FLR clears the register (BIOS won't run afterwards)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50237
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:40:48 +02:00
Jesse Barnes
0f846f81a1 drm/i915: disable RCBP and VDS unit clock gating on SNB and VLV
The RCBP workaround still applies on these chips, and we need VDS as well.

v2: remove MB boot fetch that snuck in (Daniel)
    add workaround tags to comments for easier internal tracking (Daniel)
v3: only apply RCPB and VDS on SNB and VLV, IVB doesn't need them (Eugeni)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50251
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 18:37:13 +02:00
Daniel Vetter
e080b915ec drm/i915: fixup hangman rebase goof-up
I've added a bit of logic such that running the hangman test on chips
without any hw reset support at all doesn't wedge the gpu because the
reset failed. This relied on checking for non-null stop_rings.
Unfortunately I've botched a rebase somewhere and stop_rings is still
cleared at the old place before the reset code.

Fix this up so that running the i-g-t tests on gen2/3 doesn't result
in a wedged gpu.

v2: Actually remove the lines instead of adding them twice ... my git
license should be revoked immediately.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:43:54 +02:00
Ben Widawsky
208482232d drm/i915: set IDICOS to medium uncore resources
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.

This derives from a patch originally given to me by Bernard. The docs
are  confusing about the definition names (ie. medium really seems like
max), but it would seem it gives more cache to the GT at the expense of
uncore. This configuration makes the split most in favor of the GT. I've
not tried the other IDICOS values.

Cc: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Acked-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:43:53 +02:00
Ben Widawsky
e158c5aa17 drm/i915: disable contexts on old HW
This got dropped as a result of the last round of comments. I didn't
test it on unsupported HW (which this is likely the case).

Note that this prevents hw context from blowing up on any pre-gen6 hw.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51142
[danvet: Added note and buglink.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 10:01:08 +02:00
Eugeni Dodonov
39fb50f617 drm/i915: properly wait for SBI status
Somehow this went unnoticed in the past reviews, but the condition would
never timeout properly.

This was initially introduced in the v2 of original SBI enabling patch.
Highly embarrassing.

Note that we now actually time out for the read, which resulted in gcc
complaining that we can now return unitialized garbage if that
happens. There's not much we can do here because there's not much
point in thread -EIO all the way down through these functions. Hence
simply shut up the compiler.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: Added note and squashed uninitialized value shut-up into this
patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-18 09:57:07 +02:00
Daniel Vetter
aaa377302b drm/i915/crt: Do not rely upon the HPD presence pin
VGA hotplug detection "works" by measuring the resistance across
certain pins. A lot of kvm switches fumble this and wire up cheap
resistors with the wrong resistance or don't bother at all.

To accomodate these, also try to detect a connected monitor by trying
to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother
with an actual load-detection cycle when the output is life - that
would be actual work to implement because things moved around. This is
the big difference to Chris Wilson's original approach:

commit 9e612a008f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 31 13:08:53 2012 +0100

    drm/i915/crt: Do not rely upon the HPD presence pin

This blew up on Linus' machine because it errornously detected a vga
screen (without and edid and hence only the default modes), leading to
it's prompt removal:

commit 8f53369b75
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jun 8 14:53:06 2012 -0700

    Revert "drm/i915/crt: Do not rely upon the HPD presence pin"

Some digging around in Bspec shows the reason why load detect doesn't work on
newer chips - the legacy VGA load detect bit isn't wired up any longer:

Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4:

"RGB Comparator / Sense. This bit is here for compatibility and will
always return one. Monitor detection must be done be done through the
programming of registers in the MMIO space.
0 = Below threshold
1 = Above threshold"

v2: Add a comment in the code that load detect on hotplug capable
machines is broken and pimp the commit message with a quote of Bspec
to show why.

Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 15:30:32 +02:00
Ben Widawsky
8e96d9c4d9 drm/i915: reset the GPU on context fini
It's the only way we know how to make the GPU actually forget about the
default context.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:21 +02:00
Ben Widawsky
6e0a69dbc8 drm/i915/context: switch contexts with execbuf2
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.

v2: Add checks for context switches on rings not supporting contexts.
Before the code would silently ignore such requests.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:21 +02:00
Ben Widawsky
846248136d drm/i915/context: create & destroy ioctls
Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.

Following convention as usual here causes checkpatch warnings.

v2: with is_initialized, no longer need to init at create
drop the context switch on create (daniel)

v3: Use interruptible lock (Chris)
return -ENODEV in !GEM case (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:20 +02:00
Ben Widawsky
f2ef6eb145 drm/i915: switch to default context on idle
To keep things as sane as possible, switch to the default context before
idling. This should help free context objects, as well as put things in
a more well defined state before suspending.

v2: remove seqno from context switch call (daniel)
return error on failed context switch instead of WARN+continue (daniel)

v3: move idling to i915_gpu idle (from i915_gem_idle) (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:20 +02:00
Ben Widawsky
b9a3906b60 drm/i915: add ccid to error state
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
dfabbcb4f6 drm/i915: use the default context
With the code to do HW context switches in place have the driver load the
default context for the render ring when the driver loads.

The default context will be an ever present context that is available to
switch to at any time for the given ring.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
12b0286f49 drm/i915: possibly invalidate TLB before context switch
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf

[DevSNB] If Flush TLB invalidation Mode is enabled it's the driver's
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries).  This can be done by a pipelined PIPE_CONTROL with TLB inv bit
set immediately before MI_SET_CONTEXT.

On GEN7 the invalidation mode is explicitly set, but this appears to be
lacking for GEN6. Since I don't know the history on this, I've decided
to dynamically read the value at ring init time, and use that value
throughout.

v2: better comment (daniel)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:19 +02:00
Ben Widawsky
cc0f639822 drm/i915: PIPE_CONTROL_TLB_INVALIDATE
This has showed up in several other patches. It's required for the next
context workaround.

I tested this one on its own and saw no differences in basic tests
(performance or otherwise). This patch is relatively likely to cause
regressions, hence why it's split out.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:18 +02:00
Ben Widawsky
e37ec39b18 drm/i915: Ivybridge MI_ARB_ON_OFF context w/a
The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.

FWIW, I eventually want to play with some of the arbitration stuff, and
I'd hate to forget about this.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:18 +02:00
Daniel Vetter
3af7b8572f drm/i915: ensure context objects are bound to the global gtt
This way round we don't introduce and ugly layering violations and use
the interface as I planned to use it.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-14 17:36:17 +02:00
Ben Widawsky
e055684168 drm/i915: context switch implementation
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.

There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.

The context switch code is missing workarounds, they will be implemented
in future patches.

v2: actually do obj->dirty=1 in switch (daniel)
Modified comment around above
Remove flags to context switch (daniel)
Move mi_set_context code to i915_gem_context.c (daniel)
Remove seqno , use lazy request instead (daniel)

v3: use i915_gem_request_next_seqno instead of
      outstanding_lazy_request (Daniel)
remove id's from trace events (Daniel)
Put the context BO in the instruction domain (Daniel)
Don't unref the BO is context switch fails (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:17 +02:00
Ben Widawsky
40521054fd drm/i915: context basic create & destroy
Invent an abstraction for a hw context which is passed around through
the core functions. The main bit a hw context holds is the buffer object
which backs the context. The rest of the members are just helper
functions. Specifically the ring member, which could likely go away if
we decide to never implement whatever other hw context support exists.

Of note here is the introduction of the 64k alignment constraint for the
BO. If contexts become heavily used, we should consider tweaking this
down to 4k. Until the contexts are merged and tested a bit though, I
think 64k is a nice start (based on docs).

Since we don't yet switch contexts, there is really not much complexity
here. Creation/destruction works pretty much as one would expect. An idr
is used to generate the context id numbers which are unique per file
descriptor.

v2: add DRM_DEBUG_DRIVERS to distinguish ENOMEM failures (ben)
convert a BUG_ON to WARN_ON, default destruction is still fatal (ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Ben Widawsky
254f965c39 drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.

Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores.  With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5).  Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.

In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state.  The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.

All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.

There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.

As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.

v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Ben Widawsky
fe1cc68fcb drm/i915: CXT_SIZE register offsets added
The GPUs can have different default context layouts, and the sizes could
vary based on platform or BIOS. In order to back the context object with
a properly sized BO, we must read this register in order to find out a
sufficient size.

Thankfully (sarcarm!), the register moves and changes meanings
throughout generations.

CTX and CXT differences are intentional as that is how it is in the
documentation (prior to GEN6 it was CXT).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-14 17:36:16 +02:00
Seth Forshee
14d94a3d82 drm/i915: ignore pipe select bit when checking for LVDS register initialization
The Lenovo Thinkpad T410 has the LVDS_PIPEB_SELECT bit set in the LVDS
register when booted with the lid closed, even though the LVDS hasn't
really been initialized. Ignore this bit so that the VBT value will be
used instead.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 21:05:06 +02:00
Chris Wilson
93314b5b6f drm/i915: Switch off FBC when disabling the primary plane when obscured
As we switch on/off the primary plane if it is completely obscured by an
overlapping video sprite, we also nee to make sure that we update the
FBC configuration at the same time.

v2: Not all crtcs are intel_crtcs, as spotted by Daniel.
v3: Boot testing rules.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50238
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 20:10:00 +02:00
Daniel Vetter
e188719a28 drm/i915: kick any firmware framebuffers before claiming the gtt
Especially vesafb likes to map everything as uc- (yikes), and if that
mapping hangs around still while we try to map the gtt as wc the
kernel will downgrade our request to uc-, resulting in abyssal
performance.

Unfortunately we can't do this as early as readon does (i.e. as the
first thing we do when initializing the hw) because our fb/mmio space
region moves around on a per-gen basis. So I've had to move it below
the gtt initialization, but that seems to work, too. The important
thing is that we do this before we set up the gtt wc mapping.

Now an altogether different question is why people compile their
kernels with vesafb enabled, but I guess making things just work isn't
bad per se ...

v2:
- s/radeondrmfb/inteldrmfb/
- fix up error handling

v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky.

v4: Jani Nikula complained about the pointless bool primary
initialization.

v5: Don't oops if we can't allocate, noticed by Chris Wilson.

v6: Resolve conflicts with agp rework and fixup whitespace.

Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-13 13:33:42 +02:00
Daniel Vetter
8ecd1a6615 drm/i915: call intel_enable_gtt
When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:21:07 +02:00
Daniel Vetter
32e3cd6ecd agp/intel-gtt: move gart base addres setup
We need this thing much earlier, and it doesn't make sense
in the hw enabling function intel_enable_gtt - this does not
change over a suspend/resume cycle ...

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:20:28 +02:00
Daniel Vetter
14be93ddff drm/i915 + agp/intel-gtt: prep work for direct setup
To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
  code to handle the gpu pdev both being present (for drm/i915) and
  not present (fake agp).
- add refcounting to the remove function so that unloading drm/i915
  doesn't kill the fake agp driver

v2: Fix up the cleanup and refcount, noticed by Jani Nikula.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:19:49 +02:00
Daniel Vetter
7e8f6306fe agp/intel-gtt: don't require the agp bridge on setup
We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.

This is just a prep patch to eventually disable the fake agp
driver on gen6+.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:18:54 +02:00
Daniel Vetter
dd2757f8b5 drm/i915: stop using dev->agp->base
For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev->agp by values we already have at hand.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:18:06 +02:00
Daniel Vetter
9b990de76c agp/intel-gtt: remove dead code
This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.

Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 22:16:05 +02:00
Daniel Vetter
0b9f43a0ee drm/i915: allow pipe A for lvds on gen4
Given the havoc the missing backlight pipe select code might have
caused, let's try to re-enabled pipe A support for lvds on gen4 hw.
Just to see what all blows up ...

Note though that

commit 4add75c43f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Dec 4 17:49:46 2010 +0000

    drm/i915: Allow LVDS to be on pipe A for Ironlake+

claims that this caused tons of spurious wakeups somehow.

More details can be found in the old revert:

commit 12e8ba25ef
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Sep 7 23:39:28 2010 +0100

    Revert "drm/i915: Allow LVDS on pipe A on gen4+"

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:28:40 +02:00
Daniel Vetter
24ded20442 drm/i915: properly enable the blc controller on the right pipe
On gen4+ we have a bitfield to specify from which pipe the backlight
controller should take it's clock. For PCH split platforms we've
already set these up, but only at initialization time. And without
taking into account the 3rd pipe added with ivb.

For gen4, we've completely ignored these. Although we do restrict lvds
to the 2nd pipe, so this is only a problem on machines where we boot
up with the lvds on the first pipe.

So restructure the code to enable the backlight on the right pipe at
modeset time.

v2: For odd reasons panel_enable_backlight gets called twice in a
modeset, so we can't WARN_ON in there if the backlight controller is
switched on already.

v3: backlight enable can also be called through dpms on, so the check
in there is legit. Update the comment to reflect that.

Tested-By: Kamal Mostafa <kamal@canonical.com>
Bugzilla: https://bugs.launchpad.net/bugs/954661
Cc: Carsten Emde <C.Emde@osadl.org>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:27:58 +02:00
Daniel Vetter
7cf4160148 drm/i915: clear up backlight #define confusion on gen4+
- Regroup definitions for BLC_PWM_CTL so that they're all together and
  and ordered according to the bitfields.

- Add all missing definitions for BLC_PWM_CTL2.

- Use the BLM_ (for backlight modulation) prefix consistently.

- Note that combination mode (i.e. also taking the legacy backlight
  control value from pci config space into account) is gen4 only.

- Move the new registers for PCH-split machines up, they're an almost
  match for the gen4 defitions.  Prefix the special PCH-only bits with
  BLM_PCH_. Also add the pipe C select bit for ivb.

- Rip out the second pair of PCH polarity definitions - they're only
  valid on early (pre-production) ilk silicon.

- Adapt the existing code to use the new definitions. This has the
  nice benefit of killing a magic (1 << 30) left behind be Jesse
  Barnes.

No functional changes in this patch.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:25:46 +02:00
Daniel Vetter
534b5a5341 drm/i915: pnv has a backlight polarity control bit, too
We already correctly ignore bit0 on gen < 4, now we also know why ;-)
I've decided that losing that single bit of precision isn't worth the
trouble to sprinkle IS_PINEVIEW checks all over the backlight control
code - that code is way too fragile imo.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:25:03 +02:00
Daniel Vetter
afba018898 drm/i915: ensure HDMI port is disabled inside set_infoframes
This function is supposed to be used at mode set time, so prevent
against future mistakes by adding a WARN().

Based on a patch by Paulo Zanoni, with the check extracted into a
little assert_hdmi_port_disabled helper added to make things self
documenting and move the assert stuff out of line.

[fixed up spelling goof-up while applying.]
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12 19:19:52 +02:00
Ben Widawsky
172cf15d18 drm/i915: Add wait render timeout get param
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>
2012-06-06 12:28:40 +02:00
Ben Widawsky
eac1f14fd1 drm/i915: Inifite timeout for wait ioctl
Change the ns_timeout parameter of the wait ioctl to a signed value.
Doing this allows the kernel to provide an infinite wait when a timeout
of less than 0 is provided. This mimics select/poll.

Initially the parameter was meant to match up with the GL spec 1:1, but
after being made aware of how much 2^64 - 1 nanoseconds actually is, I
do not think anyone will ever notice the loss of 1 bit.

The infinite timeout on waiting is similar to the existing i915
userspace interface with the exception that struct_mutex is dropped
while doing the wait in this ioctl.

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>
2012-06-06 12:25:46 +02:00
Daniel Vetter
de9a35abb3 drm/i915: assert that the IBX port transcoder select w/a is implemented
Let's be a bit more paranoid here.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 09:30:37 +02:00
Daniel Vetter
7a87c28977 drm/i915: implement IBX hdmi transcoder select workaround
Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30:

"[DevIBX] Writing to this bit only takes effect when port is enabled.
Due to hardware issue it is required that this bit be cleared when port
is disabled. To clear this bit software must temporarily enable this
port on transcoder A."

Unfortunately the public Bspec misses totally out on the same language
for HDMIB. Internal Bspec also mentions that one of the bad
side-effects is that DPx can fail to light up on transcoder A if HDMIx
is disabled but using transcoder B.

I've found this while reviewing Bsepc. We already implement the same
workaround for the DP ports.

Also replace a magic 1 with PIPE_B I've found while looking through the
code.

v2: Implement suggestions from Chris Wilson:
- add pipe variable to cut down on code noise
- write the reg value twice to w/a hw issues (Bspec is unclear on
  which bit actually require the write twice stuff, but better be
  paranoid about it)
- untangle the if logic

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-06 09:25:13 +02:00