Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next

Here's my drm documentation update and driver api polish pull request.
Alex reviewed the entire pile, I've applied a little bit of spelling
polish in a few places since then and otherwise the Usual Suspects (David,
Rob, ...) don't seem up to have another look at it (I've poked them on
irc). So I think it's as good as it gets ;-)

Note that I've dropped the final imx breaker patch since that's blocked on
imx getting sane. Once that's landed I'll ping you to pick up that
straggler.

* 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm: (34 commits)
  drm/imx: remove drm_mode_connector_detach_encoder harder
  drm: kerneldoc polish for drm_crtc.c
  drm: kerneldoc polish for drm_crtc_helper.c
  drm: drop error code for drm_helper_resume_force_mode
  drm/crtc-helper: remove LOCKING from kerneldoc
  drm: remove return value from drm_helper_mode_fill_fb_struct
  drm/doc: Fix misplaced </para>
  drm: remove drm_display_mode->private_size
  drm: polish function kerneldoc for drm_modes.[hc]
  drm/modes: drop maxPitch from drm_mode_validate_size
  drm/modes: drop return value from drm_display_mode_from_videomode
  drm/modes: remove drm_mode_height/width
  drm: extract drm_modes.h for drm_crtc.h functions
  drm: move drm_mode related functions into drm_modes.c
  drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c
  drm/doc: Integrate drm_modes.c kerneldoc
  drm/kms: rip out drm_mode_connector_detach_encoder
  drm/doc: Add function reference documentation for drm_mm.c
  drm/doc: Overview documentation for drm_mm.c
  drm/mm: Remove MM_UNUSED_TARGET
  ...

Merge branch 'drm-intel-next' of git://git.freedesktop.org/git/drm-intel into drm-next

- fine-grained display power domains for byt (Imre)
- runtime pm prep patches for !hsw from Paulo
- WiZ hashing flag updates from Ville
- ppgtt setup cleanup and enabling of full 4G range on bdw (Ben)
- fixes from Jesse for the inherited intial config code
- gpu reset code improvements from Mika
- per-pipe num_planes refactoring from Damien
- stability fixes around bdw forcewake handling and other bdw w/a from Mika
  Ken
- and as usual a pile of smaller fixes all over

* 'drm-intel-next' of git://git.freedesktop.org/git/drm-intel: (107 commits)
  drm/i915: Go OCD on the Makefile
  drm/i915: Implement command buffer parsing logic
  drm/i915: Refactor shmem pread setup
  drm/i915: Avoid div by zero when pixel clock is large
  drm/i915: power domains: add vlv power wells
  drm/i915: factor out intel_set_cpu_fifo_underrun_reporting_nolock
  drm/i915: vlv: factor out valleyview_display_irq_install
  drm/i915: sanity check power well sw state against hw state
  drm/i915: factor out reset_vblank_counter
  drm/i915: sanitize PUNIT register macro definitions
  drm/i915: vlv: keep first level vblank IRQs masked
  drm/i915: check pipe power domain when reading its hw state
  drm/i915: check port power domain when reading the encoder hw state
  drm/i915: get port power domain in connector detect handlers
  drm/i915: add port power domains
  drm/i915: add noop power well handlers instead of NULL checking them
  drm/i915: split power well 'set' handler to separate enable/disable/sync_hw
  drm/i915: add init power domain to always-on power wells
  drm/i915: move power domain macros to intel_pm.c
  drm/i915: Disable full ppgtt by default
  ...

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

Conflicts:
drivers/gpu/drm/i915/Makefile

Makefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion under CONFIG_ACPI.

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

Merge branch 'drm-minor' of git://people.freedesktop.org/~dvdhrm/linux into drm-next

This series contains several cleanups for the DRM-minor handling. All but the
last one reviewed by Daniel and tested by Thierry. Initially, the series
included patches to convert minor-handling to a common base-ID, but have
been NACKed by Daniel so I dropped them and only included the main part in the
last patch. With this in place, drm_global_mutex is no longer needed for
minor-handling (but still for device unregistration..).
There are some pending patches that try to remove the global mutex entirely, but
they need some more reviews and thus are not included.
* 'drm-minor' of git://people.freedesktop.org/~dvdhrm/linux:
  drm: make minors independent of global lock
  drm: inline drm_minor_get_id()
  drm: coding-style fixes in minor handling
  drm: remove redundant minor->device field
  drm: remove unneeded #ifdef CONFIG_DEBUGFS
  drm: rename drm_unplug/get_minor() to drm_minor_register/unregister()
  drm: move drm_put_minor() to drm_minor_free()
  drm: allocate minors early
  drm: add minor-lookup/release helpers
  drm: provide device-refcount
  drm: turn DRM_MINOR_* into enum
  drm: remove unused DRM_MINOR_UNASSIGNED
  drm: skip redundant minor-lookup in open path
  drm: group dev-lifetime related members

Merge branch 'drm-fixes' of git://people.freedesktop.org/~dvdhrm/linux into drm-next

This branch includes 6 minor fixes mainly for udl. Everything non-trivial was
reviewed by Daniel and the patches have been on the list for quite some time.

* 'drm-fixes' of git://people.freedesktop.org/~dvdhrm/linux:
  drm/gem: dont init "ret" in drm_gem_mmap()
  drm/crtc: add sanity checks to create_dumb()
  drm/gem: free vma-node during object-cleanup
  drm/gem: fix indentation
  drm/udl: fix Bpp calculation in dumb_create()
  drm/udl: fix error-path when damage-req fails

drm: make minors independent of global lock

We used to protect minor-lookup and setup by the global drm lock. To
continue our attempts of dropping drm_global_mutex, this patch makes the
minor management independent of it. Furthermore, we make it all atomic and
switch to spin-locks instead of a mutex.

Now that minor-lookup is independent, we also move the
"drm_is_unplugged()" test into the minor-lookup path. There is no reason
to ever return a minor for unplugged objects, so keep that logic internal.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: inline drm_minor_get_id()

We can significantly simplify this helper by using plain multiplication.
Note that we converted the minor-type to an enum earlier so this didn't
work before.

We also fix a minor range-bug here: the limit argument of idr_alloc() is
*exclusive*, not inclusive, so we should use 64 instead of 63 as offset.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: coding-style fixes in minor handling

Properly name goto-labels, remove empty lines and use DRM_ERROR if
possible.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: remove redundant minor->device field

Whenever we access minor->device, we are in a minor->kdev->...->fops
callback so the minor->kdev pointer *must* be valid. Thus, simply use
minor->kdev->devt instead of minor->device and remove the redundant field.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: remove unneeded #ifdef CONFIG_DEBUGFS

No need to check for DEBUGFS, we already have dummy-fallbacks in our
headers.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: rename drm_unplug/get_minor() to drm_minor_register/unregister()

drm_get_minor() no longer allocates objects, and drm_unplug_minor() is now
the exact reverse of it. Rename it to _register/unregister() so their
name actually says what they do.

Furthermore, remove the direct minor-ptr and instead pass the minor-type.
This way we know the actual slot of the minor and can reset it if
required.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: move drm_put_minor() to drm_minor_free()

_put/get() are used for ref-counting, which we clearly don't do here.
Rename it to _free() and also use the common drm_minor_* prefix.
Furthermore, avoid passing the minor directly but instead use the type
like the other functions do, this allows us to reset the slot.

We also drop the redundant call to drm_unplug_minor() as drm_minor_free()
is only used from paths were that has already be called.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: allocate minors early

Instead of waiting for device-registration, we now allocate minor-objects
during device allocation. The minors are not registered or assigned an ID.
This is still postponed to device-registration.

While at it, remove the superfluous output-parameter in drm_get_minor().

The reason for this early allocation is to make
dev->primary/control/render available atomically. So once the device is
alive, all of them are already set and we never have the situation where
one of them is set after another (they're either NULL or set, but never
changed). This will eventually allow us to reduce minor-ID allocation to
one base-ID instead of a single ID for each.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: add minor-lookup/release helpers

Instead of accessing drm_minors_idr directly, this adds a small helper to
hide the internals. This will help us later to remove the drm_global_mutex
requirement for minor-lookup.

Furthermore, this also makes sure that minor->dev is always valid and
takes a reference-count to the device as long as the minor is used in an
open-file. This way, "struct file*"->private_data->dev is guaranteed to be
valid (which it has to, as we cannot reset it).

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: provide device-refcount

Lets not trick ourselves into thinking "drm_device" objects are not
ref-counted. That's just utterly stupid. We manage "drm_minor" objects on
each drm-device and each minor can have an unlimited number of open
handles. Each of these handles has the drm_minor (and thus the drm_device)
as private-data in the file-handle. Therefore, we may not destroy
"drm_device" until all these handles are closed.

It is *not* possible to reset all these pointers atomically and restrict
access to them, and this is *not* how this is done! Instead, we use
ref-counts to make sure the object is valid and not freed.

Note that we currently use "dev->open_count" for that, which is *exactly*
the same as a reference-count, just open coded. So this patch doesn't
change any semantics on DRM devices (well, this patch just introduces the
ref-count, anyway. Follow-up patches will replace open_count by it).

Also note that generic VFS revoke support could allow us to drop this
ref-count again. We could then just synchronously disable any fops->xy()
calls. However, this is not the case, yet, and no such patches are
in sight (and I seriously question the idea of dropping the ref-cnt
again).

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: turn DRM_MINOR_* into enum

Use enum for DRM_MINOR_* constants to avoid hard-coding the IDs.
Furthermore, add a DRM_MINOR_CNT so we can perform range-checks in
follow-ups.

This changes the IDs of the minor-types by -1, but they're not used as
indices so this is fine.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: remove unused DRM_MINOR_UNASSIGNED

This constant is unused, remove it.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: skip redundant minor-lookup in open path

The drm_open_helper() function is only used internally for drm_open() so
we can safely pass in the minor-object directly instead of the minor-id.
This way, we avoid the additional minor IDR lookup, which we already do
twice in drm_stub_open() and drm_open().

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: group dev-lifetime related members

These members are all managed by DRM-core, lets group them together so
they're not split across the whole device.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/gem: dont init "ret" in drm_gem_mmap()

There is no need to initialize this variable, so drop it. Otherwise, the
compiler won't warn if we use it unintialized.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/crtc: add sanity checks to create_dumb()

Lets make sure some basic expressions are always true:
  bpp != NULL
  width != NULL
  height != NULL
  stride = bpp * width < 2^32
  size = stride * height < 2^32
  PAGE_ALIGN(size) < 2^32

At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never happen. These checks allow drivers to do
any 32bit math without having to test for mult-overflows themselves.

The two divisions might hurt performance a bit, but dumb_create() is only
used for scanout-buffers, so that should be fine. We could use 64bit math
to avoid the divisions, but that may be slow on 32bit machines.. Or maybe
there should just be a "safe_mult32()" helper, which currently doesn't
exist (I think?).

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/gem: free vma-node during object-cleanup

All drivers currently need to clean up the vma-node manually. There is no
fancy logic involved so lets just clean it up unconditionally. The
vma-manager correctly catches multiple calls so we are fine.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/gem: fix indentation

Remove double-whitespace and wrong indentation.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/udl: fix Bpp calculation in dumb_create()

Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Use DIV_ROUND_UP() to avoid the problem entirely and make the core more
readable.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/udl: fix error-path when damage-req fails

We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/imx: remove drm_mode_connector_detach_encoder harder

Since the last time I've looked more of this stuff sprouted up. Stomp
it down again.

Repeating the original justification for ripping this all out: There's
absolutely no need to deteach connectors before cleaning them up at
driver unload time. And since drm doesn't support hotplugging kms
objects at all it's positively dangerous to attempt this at runtime.
Luckily imx only detachs at driver cleanup time and hence we can
savely remove this.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: kerneldoc polish for drm_crtc.c

- Standardized on "Returns:" Block.
- Sprinkle missing kerneldoc over all exported functions and all
  ioctls.
- Add a stern warning that driver's really shouldn't use
  drm_mode_group_init_legacy_group.
- Usual attempt at more consistency.
- Add warnings that drm_mode_object_get/put don't do refcounting,
  despite what the names might lead to believe.
- Try to clarify the framebuffer setup/cleanup functions wrt driver
  private framebuffers - I've fallen recently over this when reviewing
  i915 fbdev patches.
- Align function parameters where the kerneldoc has been updated.
- Most of the drm_get_*_name functions aren't thread safe. Add stern
  warnings where this is the case.

Since a lot of the functions in drm_crtc.c are boilerplate to handle
properties and create default sets of them it might be useful to
extract all that code into a new file drm_property.c. Especially since
properties will be used a lot more in the future.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: kerneldoc polish for drm_crtc_helper.c

Most of this is newly added kerneldoc for the hotplug and output
polling code. But I've also thrown in a bit lesser polish, most of it
is tuning down the shouting RETURN: headers.

Overview documentation for the output probing and mode setting support
code will be added in later patches.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: drop error code for drm_helper_resume_force_mode

No driver cares, and it should generally work. Add a big comment
when drivers can't use this for recompense.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/crtc-helper: remove LOCKING from kerneldoc

- It yells.
- WARNing about incorrect locking is harder to ignore, so better
  than kerneldoc.
- Since those have been written per-crtc locks were added ...

So remove them and replace them by appropriate WARNs.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: remove return value from drm_helper_mode_fill_fb_struct

Rightfully no driver ever checked this - it can't fail.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Fix misplaced </para>

Oops. This is a regression from

commit 5d7a951537927555fa1286a338e1b91c3b8b7445
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jan 4 22:31:20 2013 +0100

    drm/doc: updates for new framebuffer lifetime rules

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: remove drm_display_mode->private_size

It' unused and there's also not really any way to make it work with
the current code. So better rip it out.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: polish function kerneldoc for drm_modes.[hc]

- Tune down yelling RETURNS.
- OCD align all the parameters the same.
- Add missing kerneldoc, which also means that we need to include the
  kerneldoc from the drm_modes.h header now.
- Add missing Returns: sections.
- General polish and clarification - especially the kerneldoc for the
  mode creation helpers seems to have been some good specimen of
  copypasta gone wrong.

All actual code changes have all been extracted into prep patches
since there was simply too much to polish.

v2: More polish for the command line modeline functions.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/modes: drop maxPitch from drm_mode_validate_size

Totally unused and actually redundant with maxX for display mode
validation. The fb helper otoh needs to check pitch limits,
but that is delegated into drivers instead.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/modes: drop return value from drm_display_mode_from_videomode

It never fails and no one ever checked anyway.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/modes: remove drm_mode_height/width

There's a neat FIXME asking whether this is really need. I'd
say really no.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: extract drm_modes.h for drm_crtc.h functions

I want to also include kerneldoc from the header (for static inline
functions and structs), but fishing the right pieces out of a giant
header is a real pain. So split things out.

Note that it's not a really clean header with sane include orders, but
given's drm historical knack for giant headers detangling this is a
major task.

v2: Also extract struct drm_cmdline_mode.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: move drm_mode related functions into drm_modes.c

Makes more sense and gives better grouping in the DocBook function
reference sections. To make this possible we need to expose two
functions from drm_crtc.c though. To avoid further namespace pollution
in the system wide headers create a new internal header for such drm
internal symbols.

I expect that longer-term we'll add tons more, but since my goal here
is to polish the kerneldoc that's for another day.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Repleace LOCKING kerneldoc sections in drm_modes.c

There's not really any value in stating that no locking is needed. And
even if the comment is useful, a check for the right mutex at the
beginning of the function is better since that can't be ingored as
easily as a bit of documentation.

Note that drm_mode_probed_add in drm_crtc.c is also changed, the next
patch will move this into drm_modes.c

v2: Don't add locking WARN_ONs where it is not strictly required (i.e.
the two functions to validate/prune mode lists).

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Integrate drm_modes.c kerneldoc

And clean it up so that there's no kerneldoc warnings. There's still a
lot to do with this one here.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/kms: rip out drm_mode_connector_detach_encoder

It's only used by imx, and that one gets it wrong - there's no need
to deteach the encoder before removing it.

And really, neither current drm modesetting code nor all the userspace
we have can handle dynamic changes in the set of possible encoders for
a given connector. So let's just remove this before someone starts
doing something really nasty with it.

As a plus, one less kerneldoc comment to write.

Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Add function reference documentation for drm_mm.c

While at it do a tiny bit of interface cleanup and convert boolean
return values to bool. With this patch all exported functions and inline
helpers which are part of the drm_mm public interface are documented.

Also drop superflous extern function modifiers since most of drm_mm.h
doesn't use them - more consistent that way.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Overview documentation for drm_mm.c

kerneldoc polish will follow in the next patch.

Hopefully documenting the lru scan support a bit better spurs someone
to give this a shot in the ttm eviction code. At least in i915 it
helped quite a lot with memory thrashing on platforms where eviction
was (we've fixed that too meanwhile) fairly expensive.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/mm: Remove MM_UNUSED_TARGET

This was missed in

commit c700c67bae6698fbc6bd20e2ae5dc62ddd367b3b
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Sat Jul 27 13:39:28 2013 +0200

    drm/mm: remove unused API

Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Update copyright

I've done quite a bit of cleanups, clarifications and mostly
integrating kerneldoc. So I guess I should add myself.

Also split up the copyright notices per holder to make it clear which
year ranges are covered.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Add PRIME function references

For giant hilarity the DocBook reference overview is only generated
when in a level 2 section, not in a level 3 section. So we need to
move this up a bit as a side-by-side section to the main PRIME
documentation.

Whatever.

To have a complete set of references add the missing kerneldoc for all
functions exported to modules with the exception of the file private
init/destroy functions - drivers have no business calling those, so
let's just drop the EXPORT_SYMBOL instead.

Also reflow the function parameters to align correctly and break at 80
chars - my OCD couldn't stand them while writing the kerneldoc ;-)

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Clarify PRIME documentation

PRIME fds aren't actually GEM fds but are (like the modeset API)
independent of the underlying buffer manager, as long as that one uses
uint32_t as handles. So move that entire section out of the GEM
section and reword it a bit to clarify which parts of PRIME are
generic, and which are the mandatory pieces for GEM drivers to
correctly implement the GEM lifetime rules. The rewording mostly
consists of not mixing up GEM, PRIME and DRM.

I've considered adding some blurbs to the GEM object lifetime section
about interactions with dma-bufs, but then dropped that. As long as
drivers use the right helpers they should have this all implemented
correctly and hence can be regarded as an implementation detail of the
PRIME/GEM helpers. So no need to confuse driver writers with those
tricky interactions.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/docs: Include hdmi infoframe helper reference

Thierry created such nice kerneldocs, it's a shame we've left them
lingering!

For the fun of it also add a bit of kerneldoc to the header so that we
can also include that. Just in case someone adds kerneldoc in there.

Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Hide legacy horrors better

By consolidating them all into one section at the very end. And to
make double-sure that no one gets confused start with a stern warning
against any use of them. And prefix all subsections with "Legacy".

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Document drm_helper_resume_force_mode

Stumbled over while reviewing all occurences in the DRM doc talking
about suspend/resume.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: No more drm perf counters

Those all died with

commit 0111be42186fc5461b9e9d579014c70869ab3152
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Oct 4 14:53:41 2013 +0300

    drm: Kill drm perf counter leftovers

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Remove the "command submissin and fencing" section

This should be done in the driver chapter instead.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Move the vma offset manager to the right spot

Currently it's sitting in the mode setting helper section, which isn't
quite right. Looks much better in the memory management section next
to TTM and GEM.

Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Reorganize driver documentation

Split up the DocBook into the core drm part and a 2nd part for
driver documentation. As an example add a very (very!) basic
skeleton for i915.

v1: Typo fixes from Dieter.

Cc: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Remove <term> from rendernode docs

The stylesheet doesn't allow this in normal paragraphs.

Cc: David Herrmann <dh.herrmann@gmail.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Clean up and integrate kerneldoc for drm_gem.c

Fairly incomplete, but at least a start.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Fix up kerneldoc in drm_edid.c

v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/doc: Clarify the dumb object interfaces

- This is _not_ a generic interface to create gem objects, but just an
  interface to make early boot services (like boot splash) with a
  generic KMS userspace driver possible. Hence it's better to move
  the documentation for this from the GEM section to the KMS section,
  next to the creation of framebuffer objects.

- Make it really clear that the returned handle isn't necessarily a
  GEM object (it can also be e.g. a TTM handle when running on top of
  vmwgfx).

- Add a paragraph to make it clear that this is just for unaccelarated
  userspace - gpu drivers need to have their own buffer object
  creation ioctl which is hardware specific.

v2: Clarify that the documentation doesn't just apply to GEM-based
drivers only but is now generally valid, as suggested by David.

v3: Polish the intro sentence a bit and one s/objects/handles/ for
clarification, both suggested by Laurent.

v4: More text polish from Laurent's review.

v5: More typo fixes from Dieter.

Cc: Dieter Nützel <Dieter@nuetzel-hh.de>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Go OCD on the Makefile

Chris suggested to split things up a bit into the different parts of
the driver and also sort it all correctly, with the hope that we're
trying to organize things a bit better eventually. It should also
help newcomers to orient themselves a bit better.

v2:
- Move intel_pm.c to the core - to make things perfect we should split
  out the modeset related pm features (psr/fbc) into a separate file.
  Maybe something Rodrigo can do once the PSR patches have settled.

- Split the modesetting sections into core and encoders/outputs.
  intel_ddi.c is a bit funky since it has core hsw+ support and ddi
  output support. Whatever.

v3: Failed to git add ...

v4: Really go ocd, i.e. spelling fix in a comment from Jani.

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>

drm/i915: Implement command buffer parsing logic

The command parser scans batch buffers submitted via execbuffer ioctls before
the driver submits them to hardware. At a high level, it looks for several
things:

1) Commands which are explicitly defined as privileged or which should only be
   used by the kernel driver. The parser generally rejects such commands, with
   the provision that it may allow some from the drm master process.
2) Commands which access registers. To support correct/enhanced userspace
   functionality, particularly certain OpenGL extensions, the parser provides a
   whitelist of registers which userspace may safely access (for both normal and
   drm master processes).
3) Commands which access privileged memory (i.e. GGTT, HWS page, etc). The
   parser always rejects such commands.

See the overview comment in the source for more details.

This patch only implements the logic. Subsequent patches will build the tables
that drive the parser.

v2: Don't set the secure bit if the parser succeeds
Fail harder during init
Makefile cleanup
Kerneldoc cleanup
Clarify module param description
Convert ints to bools in a few places
Move client/subclient defs to i915_reg.h
Remove the bits_count field

OTC-Tracker: AXIA-4631
Change-Id: I50b98c71c6655893291c78a2d1b8954577b37a30
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Refactor shmem pread setup

The command parser is going to need the same synchronization and
setup logic, so factor it out for reuse.

v2: Add a check that the object is backed by shmem

Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Avoid div by zero when pixel clock is large

Make sure the line_time_us isn't zero in the gmch watermarks code as
that would cause a div by zero. This can be triggered by specifying
a very fast pixel clock for the mode.

At some point we should probably just switch over to using the same
math we use on PCH platforms which avoids such intermediate rounded
results.

Also we should verify the user provided mode much more rigorously.
At the moment we accept pretty much anything.

Note that "very fast mode" here means above 74.25 GHz.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add Ville's clarification of what "very fast" means.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: power domains: add vlv power wells

Based on an early draft from Jesse.

Add support for powering on/off the dynamic power wells on VLV by
registering its display and dpio dynamic power wells with the power
domain framework.

For now power on all PHY TX lanes regardless of the actual lane
configuration. Later this can be optimized when the PHY side setup
enables only the required lanes. Atm, it enables all lanes in all
cases.

v2:
- undef function local COND macro after its last use (Ville)
- Take dev_priv->irq_lock around the whole sequence of
  intel_set_cpu_fifo_underrun_reporting_nolock() and
  valleyview_disable_display_irqs(). They are short and releasing
  the lock in between only makes proving correctness more difficult.
- sanitize local var names in vlv_power_well_enabled()
v3:
- rebase on latest -nightly

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict due to my changes in the previous patch.
Also throw in an assert_spin_locked for safety. And finally appease
checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: factor out intel_set_cpu_fifo_underrun_reporting_nolock

Needed by the next patch, wanting to set the underrun reporting as part
of a bigger dev_priv->irq_lock'ed sequence.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Use more customary __ prefix instead of _nolock postfix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: vlv: factor out valleyview_display_irq_install

We'll need to disable/re-enable the display-side IRQs when turning
off/on the VLV display power well. Factor out the helper functions
for this. For now keep the display IRQs enabled by default, so the
functionality doesn't change. This will be changed to enable/disable
the IRQs on-demand when adding support for VLV power wells in an
upcoming patch.

v2:
- take the irq spin lock for the whole enable/disable sequence as
  these can be called with interrupts enabled

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

drm/i915: sanity check power well sw state against hw state

Suggested by Daniel.

v2:
- sanitize the state checking condition, the original was rather
  confusing (partly due to the unfortunate naming of
  i915.disable_power_well) (Ville)
- simpler message+backtrace generation by using WARN instead of WARN_ON
  (Ville)
- check if always-on power wells are truly on all the time

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

drm/i915: factor out reset_vblank_counter

We need to do the same for other platforms in upcoming patches.

v2:
- s/p/pipe (Ville)
- Call the new helper with the vbl_lock already held. The part it
  protects is short, so releasing it between pipes only makes proving
  correctness more difficult.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with Damien's s/p/pipe/ change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: sanitize PUNIT register macro definitions

In the upcoming patches we'll need to access the rest of the fields in
the punit power gating register, so prepare for that.

v2:
- add doc reference for the power well subsystem IDs (Jesse)
- remove IDs for non-existant DPIO_RX[23] subsystems (Jesse)

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

drm/i915: vlv: keep first level vblank IRQs masked

This is a left-over from

commit b7e634cc8dcd320123199a18bae0937b40dc28b8
Author: Imre Deak <imre.deak@intel.com>
Date:   Tue Feb 4 21:35:45 2014 +0200

drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt

where we stopped unmasking the vblank IRQs, but left them enabled in the
IER register. Disable them in IER too.

v2:
- remove comment becoming stale after this change (Ville)

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

drm/i915: check pipe power domain when reading its hw state

We can read out the pipe HW state only if the required power domain is
on. If not we consider the pipe to be off.

v2:
- no change
v3:
- push down the power domain checks into the specific crtc
  get_pipe_config handlers (Daniel)

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

drm/i915: check port power domain when reading the encoder hw state

Since the encoder is tied to its port, we need to make sure the power
domain for that port is on before reading out the encoder HW state.

Note that this also covers also all connector get_hw_state handlers,
since all those just call the corresponding encoder get_hw_state
handler, which checks - after this change - for all power domains
the connector needs.

v2:
- no change
v3:
- push down the power domain checks into the specific encoder
  get_hw_state handlers (Daniel)

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

drm/i915: get port power domain in connector detect handlers

The connector detect and get_mode handlers need to access the port
specific HW blocks to read the EDID etc. Get/put the port power domains
around these handlers.

v2:
- get port power domain for HDMI too (Ville)
- get port power domain for the DP,HDMI audio detect handlers (Jesse)
- Leave the intel_runtime_pm_get/put in the DP detect function in place.
  Instead of just removing them, these should be moved to the appropriate
  power_well enable/disable handlers. We can do this after Paulo's
  'Merge PC8 with runtime PM, v2' patchset.
v3:
- rebased on latest -nightly

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

drm/i915: add port power domains

Parts that poke port specific HW blocks like the encoder HW state
readout or connector hotplug detect code need a way to check whether
required power domains are on or enable/disable these. For this purpose
add a set of power domains that refer to the port HW blocks. Get the
proper port power domains during modeset.

For now when requesting the power domain for a DDI port get it for a 4
lane configuration. This can be optimized later to request only the 2
lane power domain, when proper support is added on the VLV PHY side for
this. Atm, the PHY setup code assumes a 4 lane config in all cases.

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

drm/i915: add noop power well handlers instead of NULL checking them

Reading code free of special cases wins over the small overhead of
calling a noop handler. Suggested by Jesse.

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

drm/i915: split power well 'set' handler to separate enable/disable/sync_hw

Split the 'set' power well handler into an 'enable', 'disable' and
'sync_hw' handler. This maps more conveniently to higher level
operations, for example it allows us to push the hsw package c8 handling
into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS
hand-over setting into the hsw/bdw sync_hw handler.

No functional change.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch's whitespace complaints.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add init power domain to always-on power wells

Whenever we request a power domain it has to guarantee that all HW
resources are enabled that are needed to access a HW register associated
with that power domain. In case a register is on an always-on power well
this won't result in turning on a power well, but it may require
enabling some other HW resource. One such resource is the HSW/BDW device
D0 state that is required for all register accesses and thus for all
power wells/power domains.

So far the init power domain (guaranteeing access to all HW registers)
was part of the default i9xx always-on power well, but not the HSW/BDW
always-on power wells. Add the domain to the latter power wells too.

Atm, all the always-on power wells have noop handlers, so this doesn't
change the functionality.

v2:
- clarify semantics of always-on power wells (Paulo)

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

drm/i915: move power domain macros to intel_pm.c

These macros are used only locally, so move them to the .c file.

No functional change.

v2:
- add init power domain to always-on power wells in the following
  - separate - patch (Paulo)

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

drm/i915: Disable full ppgtt by default

There are too many oustanding issues:

- Fence handling in the current code is broken. There's a patch series
  from me, but it's blocked on and extended review (which includes
  writing the testcases).

- IOMMU mapping handling is broken, we need to properly refcount it -
  currently it gets destroyed when the first vma is unbound, so way
  too early.

- There's a pending reset issue on snb. Since Mika's reset work and
  full ppgtt have been pulled in in separate branches and ended up
  intermittingly breaking each another it's unclear who's the exact
  culprit here.

- We still have persistent evidince of crazy recursion bugs through
  vma_unbind and ppgtt_relase, e.g.

  https://bugs.freedesktop.org/show_bug.cgi?id=73383

  This issue (and a few others meanwhile resolved) have blocked our
  performance measuring/tuning group since 3 months.

- Secure batch dispatching is broken. This is blocking Brad Volkin's
  command checker work since 3 months.

All these issues are confirmed to only happen when full ppgtt is
enabled, falling back to aliasing ppgtt resolves them. But even
aliasing ppgtt itself still has a regression:

- We currently unconditionally bind objects into the aliasing ppgtt,
  which means all priviledged objects like ringbuffers are visible to
  unpriviledged access again. On top of that this also breaks the
  command checker for aliasing ppgtt, since it can't hide the
  validated batch any more.

Furthermore topic/full-ppgtt has never been reviewed:

- Lifetime rules around vma unbinding/release are unclear, resulting
  into this awesome hack called ppgtt_release. Which seems to take the
  blame for most of the recursion fallout.

- Context/ring init works different on gpu reset than anywhere else.
  Such differeneces have in the past always lead to really hard to
  track down bugs.

- Aliasing ppgtt is treated in a bunch of places as a real address
  space, but it isn't - the real address space is always the global
  gtt in that case. This results in a bit a mess between contexts and
  ppgtt object, further complication the context/ppgtt/vma lifetime
  rules.

- We don't have any docs describing the overall concepts introduced
  with full ppgtt. A short, concise overview describing vmas and some
  of the strange bits around them (like the unbound vmas used by
  execbuf, or the new binding rules) really is needed.

Note that a lot of the post topic/full-ppgtt merge fallout has already
been addressed, this entire list here of 10 issues really only contains
the still outstanding issues.

Finally the 3.15 merge window is approaching and I think we need to
use the remaining time to ensure that our fallback option of using
aliasing ppgtt is in solid shape. Hence I think it's time to throw the
switch. While at it demote the helper from static inline status
because really.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move modeset_update_power_wells earlier

These functions will be needed by the valleyview specific power well
update functionality added in an upcoming patch, so move them earlier.

No functional change.

v2:
- no change
v3:
- rebase on latest -nightly

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

drm/i915: fold in __intel_power_well_get/put functions

These functions are used only by a single call site and are simple
enough to just fold them in.

Note that in later patches the parts folded in here are further
simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL
check of the power well enable/disable handlers. All this means that at
the end intel_display_power_get/put() becomes more understandable as we
don't need to jump between two functions when reading the code.

No functional change.

v2:
- clarify the rational for the change (Chris)

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

drm/i915: Unify CHICKEN_PIPESL_1 register definitions

We have two names for the same register CHICKEN_PIPESL_1 and
HSW_PIPE_SLICE_CHICKEN_1. Unify it to just one.

Also rename the FBCQ disable bit to resemble the name we've
given to a similar bit on earlier platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use RMW to update chicken bits in gen7_enable_fbc()

gen7_enable_fbc() may write to some registers which we've already
touched, so use RMW so that we don't undo any previous updates.

Also note that we implemnt WaFbcAsynchFlipDisableFbcQueue:bdw.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW

Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1
registers with 0xffffffff. Move the parens to the correct place
to avoid this.

In particular this caused bit 30 of said registers to be set, which
caused the sprite CSC to produce incorrect results.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reverse dp link param selection, prefer fast over wide again

... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.

This reverts

commit 2514bc510d0c3aadcc5204056bb440fa36845147
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs

I'm pretty sure I'll regret this patch, but otoh I expect we won't
make progress here without poking the devil occasionally.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
Cc: peter@colberg.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Itai BEN YAACOV <candeb@free.fr>
Tested-by: David En <d.engraf@arcor.de>
Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: No need to put forcewake after a reset

As we now have intel_uncore_forcewake_reset() no need
to do explicit put after reset.

v2: rebase

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix i915_switch_context() argument name in kerneldoc

While reading some code, out of boredom, stumbled on a tiny tiny fix.

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

drm/i915: Remove unused to_gem_object() macro

That macro was only ever used to convert ring->private into a gem object
(hence the forceful cast). ring->private doesn't even exist anymore as
it was transmogrified by Chris in:

  commit 0d1aacac36530fce058d7a0db3da7befd5765417
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Mon Aug 26 20:58:11 2013 +0100

      drm/i915: Embed the ring->private within the struct intel_ring_buffer

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

drm/i915: Make i915_gem_retire_requests_ring() static

Its last usage outside of i915_gem.c was removed in:

  commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Mon Jan 27 22:43:07 2014 +0000

     drm/i915: Prevent recursion by retiring requests when the ring is full

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

drm/i915: Don't just say it, actually force edp vdd

This patch fixes the blank screen bug introduced in 3.14-rc1 on the
MacBook Air 6,2. The comments state that we need to force edp vdd so
lets put it back.

The regression was introduced by the following commit:

commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Dec 6 17:32:41 2013 -0200

    drm/i915: don't touch the VDD when disabling the panel

v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make num_sprites a per-pipe value

In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add a for_each_sprite() macro

This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Replace a few for_each_pipe(i) by for_each_pipe(pipe)

Consistency throughout the code base is good and remove some room for
mistakes (as explained in the "drm/i915: Use a pipe variable to cycle
through the pipes" commit)

So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe)
when it's reasonable and practical to do so (eg. when there isn't another
pipe variable already).

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't declare unnecessary shadowing variable

'i' is already defined in the function scope and used elsewhere. Let's
use it instead.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use a pipe variable to cycle through the pipes

I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.

This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time around.

It's all a lame excuse, but it does make it harder to redo the same
mistake.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableAsyncFlipPerfMode:bdw

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Implement WaDisableSDEUnitClockGating:bdw

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable semaphore wait event idle message on BDW

According to BSpec we need to always set this magic bit in ring buffer
mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use DIV_ROUND_UP() when calculating number of required FDI lanes

If we need precisely N lanes to satisfy the FDI bandwidth requirement,
the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP()
to get a more accurate answer.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix DDI port_clock for VGA output

On DDI there's no PLL as such to generate the pixel clock for VGA.
Instead we derive the pixel clock from the FDI link frequency. So
to make .compute_config match what .get_config does, we need to
set the port_clock based on the FDI link frequency.

Note that we don't even check the port_clock when selecting the
PLL for VGA output. We just assume SPLL at 1.35GHz is what we want,
and that does match with the asumption of FDI frequency of 2.7Ghz
we have in intel_fdi_link_freq().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74955
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>