Make it easier to find the right blocks. No functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/56e1989940d83a670d087d531b7b6aa5dc4c0228.1559308269.git.jani.nikula@intel.com

Use the comments verbatim from the spec to help find the right block. No
functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/52c32be96bd605d7a9f94accbd4dbe7718849f93.1559308269.git.jani.nikula@intel.com

Don't use bdb_ prefixes for structs within blocks. Add a new bdb struct
for SDVO panel DTDs for completeness.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cd062ced1bbbe07e087212b42c83e5ac64a22a49.1559308269.git.jani.nikula@intel.com

We've carried this baggage for more than a decade. Time to let it go.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/00058e6507aa7a62fce1d2a6de223cbbfabb204b.1559308269.git.jani.nikula@intel.com

Change the order, add some stylistic touches, and add LSPCON.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3c9aaedcacaeaca24b2a35bf2af680dd118823d4.1559308269.git.jani.nikula@intel.com

Avoid iterating the child devices. This should be a non-functional
change, but theoretically this might enable LSPCON on some extra ports
with buggy VBTs.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4bbaff16abb3461ccb67abf1537f68bb50823390.1559308269.git.jani.nikula@intel.com

Avoid iterating the child devices.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/841c226efa424701161dd9f1793e0cf96b45a07c.1559308269.git.jani.nikula@intel.com

Add separate functions to get the port by DDC pin and AUX channel.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a8b4afc08dd03e08c1403531e7f5ab33d777b1db.1559308269.git.jani.nikula@intel.com

This allows us to avoid iterating the child devices in some cases.

Also replace the presence bit with child device being non-NULL, and set
the child device pointer last to allow us to take advantage of it in
follow-up work.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ceccb75d637af3134d0328d67cbd6623932f94db.1559308269.git.jani.nikula@intel.com

Make the child device order the priority order in sanitizing DDC pin and
AUX CH. First come, first served.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/34ab98880386a095422521ad39f4c080eeb3989a.1559308269.git.jani.nikula@intel.com

In this patch, intel_color_get_config() is enabled and support
for read_luts() will be added platform by platform incrementally
in the follow-up patches.

v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
    -Added the user early on such that support for get_color_config()
     can be added platform by platform incrementally [Jani]
v5: -Incorrect place for calling intel_color_get_config() in
     haswell_get_pipe_config() [Ville]
v6: -Renamed intel_color_read_luts() to intel_color_get_config()
     [Jani and Ville]
Signed-off-by: NSwati Sharma <swati2.sharma@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1559123462-7343-3-git-send-email-swati2.sharma@intel.com

In this patch, a vfunc read_luts() is introduced to create a hw lut
i.e. lut having values read from gamma/degamma registers which will
later be used to compare with sw lut to validate gamma/degamma lut values.

v3: -Rebase
v4: -Renamed intel_get_color_config to intel_color_get_config [Jani]
    -Wrapped get_color_config() [Jani]
v5: -Renamed intel_color_get_config() to intel_color_read_luts()
    -Renamed get_color_config to read_luts
v6: -Renamed intel_color_read_luts() back to intel_color_get_config()
     [Jani and Ville]
Signed-off-by: NSwati Sharma <swati2.sharma@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1559123462-7343-2-git-send-email-swati2.sharma@intel.com

WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2

Fixes: 112ed2d3 ("drm/i915: Move GraphicsTechnology files under gt/")
Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bd7dd29b9fb2101c954c8cfb2c3b4efc7d277045.1559656538.git.mchehab+samsung@kernel.org

Instead of relying on the caller holding struct_mutex across the
allocation, push the allocation under a tree of spinlocks stored inside
the page tables. Not only should this allow us to avoid struct_mutex
here, but it will allow multiple users to lock independent ranges for
concurrent allocations, and operate independently. This is vital for
pushing the GTT manipulation into a background thread where dependency
on struct_mutex is verboten, and for allowing other callers to avoid
struct_mutex altogether.

v2: Restore lost GEM_BUG_ON for removing too many PTE from
gen6_ppgtt_clear_range.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604153830.19096-1-chris@chris-wilson.co.uk

As the GTT is outside of the powerwell, we can simplify flushing the
GGTT writes by using an unchecked mmio write and post.

v2: s/unc/uncore/
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604120022.20472-3-chris@chris-wilson.co.uk

As the fence registers are not part of the engine powerwells, we do not
need to fiddle with forcewake in order to update a fence. Avoid using
the heavyweight debug checking normal mmio writes as the checking
dominates the selftest runtime and is superfluous!

In the process, retire the I915_WRITE() implicit macro with the new
intel_uncore_write interface.

v2: s/unc/uncore/
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604120022.20472-2-chris@chris-wilson.co.uk

We only need to flush the object once prior to starting the partial
tiling test as inside the test we explicitly maintain coherency.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604120022.20472-1-chris@chris-wilson.co.uk

Stop dumping plane->state for planes. That is the old state most of the
time and dumping stale information only serves to confuse people.
Instead dump the new state just for the planes included in the
operation. For now we'll include only the planes for the modeset/fastset
pipes in the dumps. But probably we want to dump them all eventually,
just not quite sure how to present that information nicely to the user.

And while at it let's dump a few more interesting bits from the state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-14-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Constify a bunch of the arguments of various state dumping
functions. Makes it clear they don't mutate the states.
And fix up some indent fails while at it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-13-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Currently we're only dumping the failed crtc state if
intel_modeset_pipe_config() fails. Let's do the state
dump if anything else fails afterwards. The downside
is that we lose the immediate knowledge which crtc caused
the failure (unless a lower level function indicates it
with an additional debug print) but having the full state
dumped seems like something that could be beneficial.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-12-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Currently we're not dumping out whether the crtc is actually
active or in dpms off state. Let's include that in the dumps.
And while at it compress out a few lines from the state dump.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-11-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Currently we're dumping the crtc states before they have
been fully calculated. Move the dumping to the end of
.atomic_check() so we get a fully up to date dump.

Let's also do the dump for fully disabled pipes, but we'll
limit that to just saying that the pipe is disabled since
the rest of the state is going to be nonsense in that case.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-10-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Switch to using intel_ types instead of drm_ types. Avoids
ugly casts and nasty aliasing variables with different types.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-9-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Switch to using intel_ types instead of drm_ types. Avoids
ugly casts and nasty aliasing variables with different types.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-8-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We already pass the crtc's state to intel_modeset_pipe_config()
so passing the crtc as well is redundant.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-7-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We already pass the crtc's state to intel_dump_pipe_config()
so passing the crtc as well is redundant.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-6-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-5-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-4-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Thanks to using the short names for platoforms all the cdclk
vfunc assignemtns now fit within 80 cols. Remove the extra
line wraps.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Pass around intel_atomic_state rather than drm_atomic_state.
This avoids some extra casts and annoing aliasing variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Currently, the i2c adapter is available only under DP connectors.

Add i2c symlink under hdmi connector pointing to i2c adapter in order to
make this behaviour consistent.

The initial motivation was to make igt i2c subtest
patch [1] work on all connectors.

[1]: https://patchwork.freedesktop.org/series/60357/

v2:
- Moved symlink remove to unregister (Ville)
- Clarified commit message (Jani)
- Changed WARN to DRM_ERROR (Jani)
- Minor codestyle changes proposed by Jani

v3: added blank line

Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NOleg Vasilev <oleg.vasilev@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190520150642.3477-1-oleg.vasilev@intel.com

Move over structures, enums and macros from intel_display.h and
i915_drv.h to have all the display PM defines in the same header.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531222409.9177-3-daniele.ceraolospurio@intel.com

Keep all the device-level PM management in intel_runtime_pm.h/c and move
all the display specific bits into their own file. Also add the new
header to Makefile.header-test.

Apart from the giant code move, the only difference is with the
intel_runtime_<get/put>_raw() functions, which are now exposed in the
header. The _put() version is also not conditionally compiled anymore
since it is ok to always pass the wakeref taken from the _get() to
__intel_runtime_pm_put (it is -1 if tracking is disabled).
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531222409.9177-2-daniele.ceraolospurio@intel.com

Make sure the HW state of the port A combo PHY is correct wrt. the
IREFGEN setting. This will force a reprogramming during init or a WARN
during uninit if the setting is incorrect.

On my ICL RVP I haven't seen this check failing and leading to a forced
reinit/WARN, but let's add it still for consistency.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531082626.30640-1-imre.deak@intel.com

Currently, we try to report to the shrinker the precise number of
objects (pages) that are available to be reaped at this moment. This
requires searching all objects with allocated pages to see if they
fulfill the search criteria, and this count is performed quite
frequently. (The shrinker tries to free ~128 pages on each invocation,
before which we count all the objects; counting takes longer than
unbinding the objects!) If we take the pragmatic view that with
sufficient desire, all objects are eventually reapable (they become
inactive, or no longer used as framebuffer etc), we can simply return
the count of pinned pages maintained during get_pages/put_pages rather
than walk the lists every time.

The downside is that we may (slightly) over-report the number of
objects/pages we could shrink and so penalize ourselves by shrinking
more than required. This is mitigated by keeping the order in which we
shrink objects such that we avoid penalizing active and frequently used
objects, and if memory is so tight that we need to free them we would
need to anyway.

v2: Only expose shrinkable objects to the shrinker; a small reduction in
not considering stolen and foreign objects.
v3: Restore the tracking from a "backup" copy from before the gem/ split
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190530203500.26272-2-chris@chris-wilson.co.uk

Currently the purgeable objects, I915_MADV_DONTNEED, are mixed in the
normal bound/unbound lists. Every shrinker pass starts with an attempt
to purge from this set of unneeded objects, which entails us doing a
walk over both lists looking for any candidates. If there are none, and
since we are shrinking we can reasonably assume that the lists are
full!, this becomes a very slow futile walk.

If we separate out the purgeable objects into own list, this search then
becomes its own phase that is preferentially handled during shrinking.
Instead the cost becomes that we then need to filter the purgeable list
if we want to distinguish between bound and unbound objects.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190530203500.26272-1-chris@chris-wilson.co.uk

The i915.alpha_support module parameter has caused some confusion along
the way. Add new i915.force_probe parameter to specify PCI IDs of
devices to probe, when the devices are recognized but not automatically
probed by the driver. The name is intended to reflect what the parameter
effectively does, avoiding any overloaded semantics of "alpha" and
"support".

The parameter supports "" to disable, "<pci-id>,[<pci-id>,...]" to
enable force probe for one or more devices, and "*" to enable force
probe for all known devices.

Also add new CONFIG_DRM_I915_FORCE_PROBE config option to replace the
DRM_I915_ALPHA_SUPPORT option. This defaults to "*" if
DRM_I915_ALPHA_SUPPORT=y.

Instead of replacing i915.alpha_support immediately, let the two coexist
for a while, with a deprecation message, for a transition period.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190506134801.28751-1-jani.nikula@intel.com

The assignment of err is using the incorrect pointer vaddr that has
not been initialized. Fix this by using the correct pointer obj instead.

Addresses-Coverity: ("Uninitialized pointer read")
Fixes: 6501aa4e ("drm/i915: add in-kernel blitter client")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531103201.10124-1-colin.king@canonical.com

The normal behaviour is to periodically check for a mmio access error,
and once detected enable mmio access checking. However this is useless
if the error only occurs once during module load, and so we may miss
such errors in CI. To allow ourselves to catch them, allow CI to opt into
always enabling mmio debugging.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190530121311.6794-1-chris@chris-wilson.co.uk