This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.

It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.

v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: NPeter Antoine <peter.antoine@intel.com>

v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
  tables.  Prefix L3-specific defines consistently with L3_ and
  e/LLC-specific defines with LE_ to avoid this kind of confusion in
  the future.
- Change L3CC WT define back to RESERVED (matches my hardware
  documentation and the original patch, probably a misunderstanding
  of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
  open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
  (Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
  Wilson).
- Add comment about undefined entries being implicitly set to uncached
  for forwards compatibility.
v9 (Francisco Jerez):
- Minor style fixes.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have enough generic hotplug functions sprinkled all over i915_irq.c
to warrant moving them to a file of their own. This should further
underline the distinction between generic code in the new file and
platform specific hotplug and irq code that remains in i915_irq.c.

Add new intel_hpd_init_work to keep work functions static, and rename
get_port_from_pin to intel_hpd_pin_to_port while increasing its
visibility, but keep everything else the same.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 118182e9.

It's causing too much trouble when compile-testing for non-i915 folks.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the patch.)

v2: Kick off a new "Debugging" submenu for i915.ko
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Add "DRM i915" to the menu name as requested by Chris.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This results in a warning when building out of tree:
"cc1: warning: include/drm: No such file or directory [enabled by default]"

Most code already uses #include <drm/foo.h> correctly, so fix the
instances that don't.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Display Context Save and Restore support is needed for
various SKL Display C states like DC5, DC6.

This implementation is added based on first version of DMC CSR program
that we received from h/w team.

Here we are using request_firmware based design.
Finally this firmware should end up in linux-firmware tree.

For SKL platform its mandatory to ensure that we load this
csr program before enabling DC states like DC5/DC6.

As CSR program gets reset on various conditions, we should ensure
to load it during boot and in future change to be added to load
this system resume sequence too.

v1: Initial relese as RFC patch

v2: Design change as per Daniel, Damien and Shobit's review comments
request firmware method followed.

v3: Some optimization and functional changes.
Pulled register defines into drivers/gpu/drm/i915/i915_reg.h
Used kmemdup to allocate and duplicate firmware content.
Ensured to free allocated buffer.

v4: Modified as per review comments from Satheesh and Daniel
Removed temporary buffer.
Optimized number of writes by replacing I915_WRITE with I915_WRITE64.

v5:
Modified as per review comemnts from Damien.
- Changed name for functions and firmware.
- Introduced HAS_CSR.
- Reverted back previous change and used csr_buf with u8 size.
- Using cpu_to_be64 for endianness change.

Modified as per review comments from Imre.
- Modified registers and macro names to be a bit closer to bspec terminology
and the existing register naming in the driver.
- Early return for non SKL platforms in intel_load_csr_program function.
- Added locking around CSR program load function as it may be called
concurrently during system/runtime resume.
- Releasing the fw before loading the program for consistency
- Handled error path during f/w load.

v6: Modified as per review comments from Imre.
- Corrected out_freecsr sequence.

v7: Modified as per review comments from Imre.
Fail loading fw if fw->size%8!=0.

v8: Rebase to latest.

v9: Rebase on top of -nightly (Damien)

v10: Enabled support for dmc firmware ver 1.0.
According to ver 1.0 in a single binary package all the firmware's that are
required for different stepping's of the product will be stored. The package
contains the css header, followed by the package header and the actual dmc
firmwares. Package header contains the firmware/stepping mapping table and
the corresponding firmware offsets to the individual binaries, within the
package. Each individual program binary contains the header and the payload
sections whose size is specified in the header section. This changes are done
to extract the specific firmaware from the package. (Animesh)

v11: Modified as per review comemnts from Imre.
- Added code comment from bpec for header structure elements.
- Added __packed to avoid structure padding.
- Added helper functions for stepping and substepping info.
- Added code comment for CSR_MAX_FW_SIZE.
- Disabled BXT firmware loading, will be enabled with dmc 1.0 support.
- Changed skl_stepping_info based on bspec, earlier used from config DB.
- Removed duplicate call of cpu_to_be* from intel_csr_load_program function.
- Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned.
- Added sanity check for header length.
- Added sanity check for mmio address got from firmware binary.
- kmalloc done separately for dmc header and dmc firmware. (Animesh)

v12: Modified as per review comemnts from Imre.
- Corrected the typo error in skl stepping info structure.
- Added out-of-bound access for skl_stepping_info.
- Sanity check for mmio address modified.
- Sanity check added for stepping and substeppig.
- Modified the intel_dmc_info structure, cache only the required header info. (Animesh)

v13: clarify firmware load error message.
The reason for a firmware loading failure can be obscure if the driver
is built-in. Provide an explanation to the user about the likely reason for
the failure and how to resolve it. (Imre)

v14: Suggested by Jani.
- fix s/I915/CONFIG_DRM_I915/ typo
- add fw_path to the firmware object instead of using a static ptr (Jani)

v15:
1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link
with same name will help not to build kernel again.
2) Changes done as per review comments from Imre.
- Error check removed for intel_csr_ucode_init.
- Moved csr-specific data structure to intel_csr.h and optimization done on structure definition.
- fw->data used directly for parsing the header info & memory allocation
only done separately for payload. (Animesh)

v16:
- No need for out_regs label in i915_driver_load(), so removed it.
- Changed the firmware name as skl_dmc_ver1.bin, followed naming convention <platform>_dmc_<api-version>.bin (Animesh)

Issue: VIZ-2569
Signed-off-by: NA.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Two code changes:
- Extract i915_gem_shrinker_init.
- Inline i915_gem_object_is_purgeable since we open-code it everywhere
  else too.

This already has the benefit of pulling all the shrinker code
together, next patch adds a bit of kerneldoc.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Lots of lines to remove!
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Fixup makefile.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Introduce a PV INFO structure, to facilitate the Intel GVT-g
technology, which is a GPU virtualization solution with mediated
pass-through. This page contains the shared information between
i915 driver and the host emulator. For now, this structure utilizes
an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware
will have the reserved window architecturally defined, and layout
of the page will be added in future BSpec.

The i915 driver load routine detects if it is running in a VM by
reading the contents of this PV INFO page. Thereafter a flag,
vgpu.active is set, and intel_vgpu_active() is used by checking
this flag to conclude if GPU is virtualized with Intel GVT-g. By
now, intel_vgpu_active() will return true, only when the driver
is running as a guest in the Intel GVT-g enhanced environment on
HSW platform.

v2:
take Chris' comments:
        - call the i915_check_vgpu() in intel_uncore_init()
        - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info
take Daniel's comments:
        - put the definition of PV INFO into a new header - i915_vgt_if.h
other changes:
        - access mmio regs by readq/readw in i915_check_vgpu()

v3:
take Daniel's comments:
        - move the i915/vgt interfaces into a new i915_vgpu.c
        - update makefile
        - add kerneldoc to functions which are non-static
        - add a DOC: section describing some of the high-level design
        - update drm docbook
other changes:
        - rename i915_vgt_if.h to i915_vgpu.h

v4:
take Tvrtko's comments:
        - fix a typo in commit message
        - add debug message when vgt version mismatches
        - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO
          structure
Signed-off-by: NYu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NEddie Dong <eddie.dong@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The removed functions can be resurrected in intel_dsi.c as need arises.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add the top-level atomic entrypoints for check/commit.  These won't get
called yet; we still need to either enable the atomic ioctl or switch to
using the non-transitional atomic helpers for legacy operations.

v2:
 - Use plane->pipe rather than plane->possible_crtcs while ensuring that
   only a single CRTC is in use.  Either way will work fine since i915
   drm_plane's are always tied to a single CRTC, but plane->pipe is
   slightly more intuitive. (Ander)
 - Simplify crtc/connector checking logic. (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Switch plane handling to use the atomic plane helpers.  This means that
rather than provide our own implementations of .update_plane() and
.disable_plane(), we expose the lower-level check/prepare/commit/cleanup
entrypoints and let the DRM core implement update/disable for us using
those entrypoints.

The other main change that falls out of this patch is that our
drm_plane's will now always have a valid plane->state that contains the
relevant plane state (initial state is allocated at plane creation).
The base drm_plane_state pointed to holds the requested source/dest
coordinates, and the subclassed intel_plane_state holds the adjusted
values that our driver actually uses.

v2:
 - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
 - Fix a copy/paste comment mistake (Bob)

v3:
 - Use prepare/cleanup functions that we've already factored out
 - Use newly refactored pre_commit/commit/post_commit to avoid sleeping
   during vblank evasion

v4:
 - Rebase to latest di-nightly requires adding an 'old_state' parameter
   to atomic_update;

v5:
 - Must have botched a rebase somewhere and lost some work.  Restore
   state 'dirty' flag to let begin/end code know which planes to
   run the pre_commit/post_commit hooks for.  This would have actually
   shown up as broken in the next commit rather than this one.

v6:
 - Squash kerneldoc patch into this one.
 - Previous patches have now already taken care of most of the
   infrastructure that used to be in this patch.  All we're adding here
   now is some thin wrappers.

v7:
 - Check return of intel_plane_duplicate_state() for allocation
   failures.

v8:
 - Drop unused drm_plane_state -> intel_plane_state cast.  (Ander)
 - Squash in actual transition to plane helpers.  Significant
   refactoring earlier in the patchset has made the combined
   prep+transition much easier to swallow than it was in earlier
   iterations. (Ander)

v9:
 - s/track_fbs/disabled_planes/ in the atomic crtc flags.  The only fb's
   we need to update frontbuffer tracking for are those on a plane about
   to be disabled (since the atomic helpers never call prepare_fb() when
   disabling a plane), so the new name more accurately describes what
   we're actually tracking.

Testcase: igt/kms_plane
Testcase: igt/kms_universal_plane
Testcase: igt/kms_cursor_crc
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future use cases should they arise.

The interface is simple: init to create an empty pool, fini to
clean it up, get to obtain a new buffer. Note that all buffers are
expected to be inactive before cleaning up the pool.

Locking is currently based on the caller holding the struct_mutex.
We already do that in the places where we will use the batch pool
for the command parser.

v2:
- s/BUG_ON/WARN_ON/ for locking assertions
- Remove the cap on pool size
- Switch from alloc/free to init/fini

v3:
- Idiomatic looping structure in _fini
- Correct handling of purged objects
- Don't return a buffer that's too much larger than needed

v4:
- Rebased to latest -nightly

v5:
- Remove _put() function and clean up comments to match

v6:
- Move purged check inside the loop (danvet, from v4 1/7 feedback)

v7:
- Use single list instead of two. (Chris W)
- s/active_list/cache_list
- Squashed in debug patches (Chris W)
  drm/i915: Add a batch pool debugfs file

  It provides some useful information about the buffers in
  the global command parser batch pool.

  v2: rebase on global pool instead of per-ring pools
  v3: rebase

  drm/i915: Add batch pool details to i915_gem_objects debugfs

  To better account for the potentially large memory consumption
  of the batch pool.

v8:
- Keep cache in LRU order (danvet, from v6 1/5 feedback)

Issue: VIZ-4719
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional changes. This is just the begin of a FBC rework.

v2 (Paulo):
  - Revert intel_fbc_init() changed parameter.
  - Revert set_no_fbc_reason() rename.
  - Rebase.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional changes. Just cleaning and reorganizing it.

v2: Rebase it puting it to begin of psr rework. This helps to blame easily
at least latest changes.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In preparation for some additional cleanup. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch includes the Gen9 batch buffer to generate
a 'golden context' for that product family.
Signed-off-by: NArmin Reese <armin.c.reese@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Prep work for some nice documentation. Requires that we export the
display irq enable/disable functions on ilk/ibx. But we already export
them for vlv/i915. So not more inconsistency.

v2: Rebase on top of skl stage 1.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Geez is the audio hack ugly.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Rebased on top of the skl patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I shouldn't ask everyone to do this and fail myself ...

This extracts all the frontbuffer tracking functions into
intel_frontbuffer.c, adds a DOC overview section and also adds the
missing kerneldoc for i915_gem_track_fb and also pulls it into the
same section for convenience.

v2: Don't forget about the header files.

v3: Oops, might check compilation next time around. To make my life
easier drop the increase_pllclock from set_base_atomic since really,
it doesn't matter if you see your Oops or kgdb with a tiny bit of lag.

v4: Try to better explain how to actually use this, requested by Paulo
on irc.

v5: Explain invalidate/flush a bit clearer.

v6: s/business/busyness/
Acked-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Some legacy HW context code assumptions don't make sense for this new
submission method, so we will place this stuff in a separate file.

Note for reviewers: I've carefully considered the best name for this file
and this was my best option (other possibilities were intel_lr_context.c
or intel_execlist.c). I am open to a certain bikeshedding on this matter,
anyway.

And some point in time, it would be a good idea to split intel_lrc.c/.h
even further, but for the moment just shove everything together.

v2: Change to intel_lrc.c

v3: Squash together with the header file addition
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds DP 1.2 MST support on Haswell systems.

Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.

Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders

Changes since v0.2:
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.

Changes since v0.3:
updates for mst apis
more state checker fixes
irq handling improvements
fbcon handling support
improved reference counting of link - fixes redocking.

Changes since v0.4:
handle gpu reset hpd reinit without oopsing
check link status on HPD irqs
fix suspend/resume

Changes since v0.5:
use proper functions to get max link/lane counts
fix another checker backtrace - due to connectors disappearing.
set output type in more places fro, unknown->displayport
don't talk to devices if no HPD asserted
check mst on short irqs only
check link status properly
rebase onto prepping irq changes.
drop unsued force_act

Changes since v0.6:
cleanup unused struct entry.

[airlied: fix some sparse warnings].
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This driver makes use of the generic panel information from the VBT.
Panel information is classified into two - panel configuration and panel
power sequence which is unique to each panel. The generic driver uses the
panel configuration and sequence parsed from VBT block #52 and #53

v2: Address review comments by Jani
    - Move all of the things in driver c file from header
    - Make all functions static
    - Make use of video/mipi_display.c instead of redefining
    - Null checks during sequence execution

v3: Address review comments by Damien
    - Rename the panel driver file as intel_dsi_panel_vbt.c
    - Fix style changes as suggested
    - Correct comments for lp->hs and hs->lp count calculations
    - General updating comments to have more clarity
    - using max() instead of ternary operator
    - Fix names (ui_num, ui_den) while using UI in calculations
    - compute max of lp_to_hs switch and hs_to_lp switch while computing
      hs_lp_switch_count
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).

v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
    to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
     Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
     with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
     within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
     rearrange error path to destroy the mmu_notifier locklessly.
     Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
     allocations of the same userptr range - and notice that
     struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
     for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
     hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
     infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
     be used to fix up the kernel thread's current->mm for use with
     copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
     userptr details elsewhere, and clean up comments based on
     suggestions by Bradley.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: NBrad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

HW guys say that it is not a cool idea to let device
go into rc6 without proper 3d pipeline state.

For each new uninitialized context, generate a
valid null render state to be run on context
creation.

This patch introduces a skeleton with empty states.

v2: - No need to vmap (Chris Wilson)
    - use .c files for state (Daniel Vetter)
    - no need to flush as i915_add_request does it
    - remove parameter for batch alloc size
    - don't wait for the init (Ben Widawsky)

v3: - move to cpu/gpu (Chris Wilson)

Tested-by: Kristen Carlson Accardi <kristen@linux.intel.com> (v1)
Tested-by: NOscar Mateo <oscar.mateo@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NBrad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The whole file is wrapped around in #if defined(CONFIG_DEBUG_FS) anyway,
so skip the file at the build level already.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To avoid build problems and breaking dependencies between ACPI header
files, <acpi/acpi.h> should not be included directly by code outside
of the ACPI core subsystem.  However, that is possible if
<linux/acpi_io.h> is included, because that file contains
a direct inclusion of <acpi/acpi.h>.

For this reason, remove the direct <acpi/acpi.h> inclusion from
<linux/acpi_io.h>, move that file from include/linux/ to include/acpi/
and make <linux/acpi.h> include it for CONFIG_ACPI set along with the
other ACPI header files.  Accordingly, Remove the inclusions of
<linux/acpi_io.h> from everywhere.

Of course, that causes the contents of the new <acpi/acpi_io.h> file
to be available for CONFIG_ACPI set only, so intel_opregion.o that
depends on it should also depend on CONFIG_ACPI (and it really should
not be compiled for CONFIG_ACPI unset anyway).

References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.

Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Boots Just Fine (tm)!

The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.

And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarring.

Also, I'm unsure whether we don't need to somehow kick out vgacon, now
that nothing else gets in the way. But stuff seems to work, so I
don't care. Also everything still works as well with VGA_CONSOLE=n

Also the #ifdef mess needs a bit of a cleanup, follow-up patches will
do just that.

To keep the Kconfig tidy, extract all the i915 options into its own
file.

v2:
- Rebase on top of the preliminary hw support option and the
  intel_drv.h cleanup.
- Shut up warnings in i915_debugfs.c

v3: Use the right CONFIG variable, spotted by Chon Ming.

Cc: Lee, Chon Ming <chon.ming.lee@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2:
 - Grab dpio_lock mutex in vlv_enable_dsi_pll().
 - Add and call vlv_disable_dsi_pll().

v3: Mostly based on Ville's review comments.
 - Only pipe A has DSI PLL lock bit.
 - Add more of CCK REG bit definitions for DSI PLL.
 - Make tables static.
 - Move clock gating out of the clock calculation functions.
 - DSI PLL LDO power gating.
 - Put alternative MNP from table calc behind #ifdef.

v4: s/CKK/CLK/ in the CCK REG bit definitions (Ville).
Signed-off-by: Nymohanma <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This does not include any panel specific sub-encoders yet.

v2: Fix fixed mode handling (Daniel)

v3: Mostly based on Ville's review comments.
 - Fix MIPI_HS_TX_TIMEOUT.
 - DPI_ENABLE only for video mode.
 - Drop ULPS usage for now, use DEVICE_READY only.
 - Set MIPI_INIT_COUNT based on txclkesc.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Rebase due to register bit definition change.

v3: Mostly based on Ville's review comments.
 - Use size_t for length all around.
 - Reuse dsi_vc_send_short in dsi_vc_send_long.
 - Remove stale/incorrect comments.
 - Reverse special packet sent interrupt check.
 - Use DSI controller regs for reading, not adapter.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently, the register access code is split between i915_drv.c and
intel_pm.c. It only bares a superficial resemblance to the reset of the
powermanagement code, so move it all into its own file. This is to ease
further patches to enforce serialised register access.

v2: Scan for random abuse of I915_WRITE_NOTRACE
v3: Take the opportunity to rename the GT functions as uncore. Uncore is
the term used by the hardware design (and bspec) for all functions
outside of the GPU (and CPU) cores in what is also known as the System
Agent.
v4: Rebase onto SNB rc6 fixes
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Wrestle patch into applying and inline
intel_uncore_early_sanitize (plus move the old comment to the new
function). Also keep the _santize postfix for intel_uncore_sanitize.]
[danvet: Squash in fixup spotted by Chris on irc: We need to call
intel_pm_init before intel_uncore_sanitize since the later will call
cancel_work on the delayed rps setup work the former initializes.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move error state generation and stringification to it's
own compilation unit. Sysfs also uses this so it can't be
under CONFIG_DEBUG_FS

This fixes a regression introduced in

commit ef86ddce
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Thu Jun 6 17:38:54 2013 +0300

    drm/i915: add error_state sysfs entry

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66814Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Group both the HSW/LPT SBI interface and VLV IOSF sideband register
accessor functions into a new file. No functional changes.

v2: also move intel_sbi_{read,write} (Daniel)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similarly to how i915_dma.c is shaping up to be the dungeon hole for
all things supporting dri1, create a new one to hide all the crazy
things which are only really useful for ums support. Biggest part is
the register suspend/resume support.

Unfortunately a lot of it is still intermingled with bits and pieces
we might still need, so needs more analysis and needs to stay in
i915_suspend.c for now.
Reviewed-by: NImre Deak <imre.deak@intel.com>

v2: s/modeset_reg/display_reg/ as suggested by Imre, to avoid
confusion between the kernel modeset code and display save/restore to
support ums.

v3: Fixup alphabetical order in the Makefile, spotted by Chris Wilson.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops.
It is in the state of "works for me".
Includes now proper DPMS support. Includes switching between resolutions -
from 640x480 to 1024x768.
Currently assumes that the native display resolution is 1024x768.

The ns2501 seems to be rather critical - if the output PLL is not
running, the chip doesn't seem to be clocked and then doesn't react
on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO
is active before submitting any i2c messages to it. This is
probably to be reviewed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902Signed-off-by: NThomas Richter <thor@math.tu-berlin.de>
[danvet: fixup whitespace fail.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>