Commit Graph

62117 Commits

Author SHA1 Message Date
Pankaj Bharadiya a9f236d1fc drm/i915: Make WARN* drm specific where uncore or stream ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where intel_uncore/i915_perf_stream  struct
pointer is readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@@
identifier func, T;
@@
func(...) {
...
struct intel_uncore *T = ...;
<...
(
-WARN(
+drm_WARN(&T->i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->i915->drm,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct intel_uncore *T,...) {
<...
(
-WARN(
+drm_WARN(&T->i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->i915->drm,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct i915_perf_stream *T,...) {
+struct drm_i915_private *i915 = T->perf->i915;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}

command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file <script> \
					--linux-spacing --in-place

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-11-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22 17:57:39 +02:00
Pankaj Bharadiya 48a1b8d4af drm/i915: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \
			<script> --linux-spacing --in-place

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22 17:54:33 +02:00
Pankaj Bharadiya 0d4c351a0f drm/i915/gt: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/gt \
					--linux-spacing --in-place

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-7-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22 17:53:37 +02:00
Pankaj Bharadiya 85c823ac9a drm/i915/gem: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/gem \
					--linux-spacing --in-place

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-6-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22 17:52:39 +02:00
Pankaj Bharadiya 3a47ae201e drm/i915/display: Make WARN* drm specific where encoder ptr is available
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where intel_encoder struct pointer is available.

The conversion was done automatically with below coccinelle semantic
patch.

@@
identifier func, T;
@@
func(...) {
...
struct intel_encoder *T = ...;
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct intel_encoder *T,...) {
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/display \
					--linux-spacing --in-place

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-5-pankaj.laxminarayan.bharadiya@intel.com
2020-01-22 17:51:53 +02:00
Chris Wilson 5424f5d794 drm/i915: Clear the GGTT_WRITE bit on unbinding the vma
While we do flush writes to the vma before unbinding (to make sure they
go through the right detiling register), we may also be concurrently
poking at the GGTT_WRITE bit from set-domain, as we mark all GGTT vma
associated with an object. We know this is for another vma, as we
are currently unbinding this one -- so if this vma will be reused, it
will be refaulted and have its dirty bit set before the next write.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/999
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121222447.419489-1-chris@chris-wilson.co.uk
2020-01-22 13:21:16 +00:00
Lyude Paul d2a4bb6f8b drm/i915: Don't use VBT for detecting DPCD backlight controls
Despite the fact that the VBT appears to have a field for specifying
that a system is equipped with a panel that supports standard VESA
backlight controls over the DP AUX channel, so far every system we've
spotted DPCD backlight control support on doesn't actually set this
field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.

While we don't know the exact reason for this VBT misuse, talking with
some vendors indicated that there's a good number of laptop panels out
there that supposedly support both PWM backlight controls and DPCD
backlight controls as a workaround until Intel supports DPCD backlight
controls across platforms universally. This being said, the X1 Extreme
2nd Gen that I have here (note that Lenovo is not the hardware vendor
that informed us of this) PWM backlight controls are advertised, but
only DPCD controls actually function. I'm going to make an educated
guess here and say that on systems like this one, it's likely that PWM
backlight controls might have been intended to work but were never
really tested by QA.

Since we really need backlights to work without any extra module
parameters, let's take the risk here and rely on the standard DPCD caps
to tell us whether AUX backlight controls are supported or not. We still
check the VBT, just so we can print a debugging message on systems that
advertise DPCD backlight support on the panel but not in the VBT.

Changes since v3:
* Print a debugging message if we enable DPCD backlight control on a
  device which doesn't report DPCD backlight controls in it's VBT,
  instead of warning on custom panel backlight interfaces.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Perry Yuan <pyuan@redhat.com>
Cc: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117232155.135579-1-lyude@redhat.com
2020-01-22 11:15:38 +02:00
Jani Nikula eea4262a4b drm/i915: drop alpha_support for good in favour of force_probe
It's been a long enough transition period since the DRM_I915_FORCE_PROBE
config and i915.force_probe module parameter were introduced in commit
7ef5ef5cde ("drm/i915: add force_probe module parameter to replace
alpha_support"). Remove alpha support.

Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121103020.26494-1-jani.nikula@intel.com
2020-01-22 10:51:32 +02:00
Chris Wilson 29baf3ae8d drm/i915: Don't show the blank process name for internal/simulated errors
For a simulated preemption reset, we don't populate the request and so
do not fill in the guilty context name.

[   79.991294] i915 0000:00:02.0: GPU HANG: ecode 9:1:e757fefe, in  [0]

Just don't mention the empty string in the logs!

Fixes: 742379c0c4 ("drm/i915: Start chopping up the GPU error capture")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121132107.267709-1-chris@chris-wilson.co.uk
2020-01-21 22:27:26 +00:00
Ville Syrjälä 486bba4524 drm/i915/hdcp: Clean up local variables
Eliminate the inconsistencies in the hdcp code local variables:
- use dev_priv over dev
- use to_i915() instead of dev->dev_private
- initialize variables when declaring them
- a bit of declaration suffling to appease ocd

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-10-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2020-01-21 18:27:41 +02:00
Ville Syrjälä 5d1db3f61a drm/i915: Rename conn_to_dig_port() to intel_attached_dig_port()
Use the standard naming convention and rename conn_to_dig_port()
to intel_attached_dig_port().

@@
@@
- conn_to_dig_port
+ intel_attached_dig_port
	(...)
{
...
}

@@
expression C;
@@
- conn_to_dig_port(C)
+ intel_attached_dig_port(C)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-9-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21 18:20:46 +02:00
Ville Syrjälä 490eda588c drm/i915: Use intel_attached_dp() instead of hand rolling it
Replace the hand rolled intel_attached_dp() with the real thing.

@@
identifier F !~ "^intel_attached_dp$";
expression C;
@@
F(...)
{
<...
- enc_to_intel_dp(intel_attached_encoder(C))
+ intel_attached_dp(C)
...>
}

v2: Regenerated

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-8-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21 18:17:06 +02:00
Ville Syrjälä ecdfd84f32 drm/i915: Relocate intel_attached_dp()
We have uses for intel_attached_dp() outside of intel_dp.c. Move
it to a header.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2020-01-21 18:16:42 +02:00
Ville Syrjälä fa7edcd25c drm/i915: Use intel_attached_encoder()
It's easy to confuse the drm_connector->encoder (legacy state
adjusted during modeset) and intel_connector->encoder (the statically
(sans. MST) attached encoder of the connector). For the latter
let's use intel_attached_encoder() consistently.

@@
identifier F !~ "^intel_attached_encoder$";
struct intel_connector *C;
expression E;
@@
F(...)
{
<...
(
  C->encoder = E
|
- C->encoder
+ intel_attached_encoder(C)
)
...>
}

@@
identifier F !~ "^intel_attached_encoder$";
struct drm_connector *C;
expression E;
@@
F(...)
{
<...
(
  to_intel_connector(C)->encoder = E
|
- to_intel_connector(C)->encoder
+ intel_attached_encoder(to_intel_connector(C))
)
...>
}

v2: Regenerated

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-6-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2020-01-21 18:16:34 +02:00
Jani Nikula 6fe20299b3 drm/i915/dp: debug log max vswing and pre-emphasis
Provide slightly more debugging help.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117150235.22471-1-jani.nikula@intel.com
2020-01-21 16:54:24 +02:00
Jani Nikula 08b90a717f drm/i915: use intel_bios_is_port_present()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/42544944ce505826335bab30cc76e135581229be.1579270868.git.jani.nikula@intel.com
2020-01-21 11:11:18 +02:00
Jani Nikula 85d8ec20db drm/i915/bios: check DDI port presence based on child device
Report port presence based on port presence in VBT alone, relaxing the
requirements on supported encoders (DP, DVI, or HDMI). The goal is to
make future changes easier, however there is a small risk of reporting
more ports present than before in case of dubious VBT.

Regarding the current callers of intel_bios_is_port_present(), the
potential issue might be caused by DVO_PORT_CRT being identified as port
E in dvo_port_to_port(). Hopefully no VBT has that on SKL+ which support
DP/DVI/HDMI on port E; the current CRT init code on HSW/BDW does not
care.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4338a29e4ed49e69f859dff1490fd85f6ae6177e.1579270868.git.jani.nikula@intel.com
2020-01-21 10:55:24 +02:00
Jani Nikula c5faae5a45 drm/i915/bios: add intel_bios_port_supports_*()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/21549ff74e8e5746917b0e2be4afbfb141e26657.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:44 +02:00
Jani Nikula 17004bfb53 drm/i915/bios: add intel_bios_alternate_ddc_pin()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9e4fcb625cec26ee88245aad7ae80bfe93b14e59.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:31 +02:00
Jani Nikula f83acdab82 drm/i915/bios: add intel_bios_dp_max_link_rate()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c30e1183afdd469c95b01f64ca0458b9e832404.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:28 +02:00
Jani Nikula 01a60883af drm/i915/bios: intel_bios_hdmi_boost_level()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6d61a5bc60c995d2ee812ef61d3c5c93b61453e7.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:25 +02:00
Jani Nikula 605a18722c drm/i915/bios: intel_bios_dp_boost_level()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fb8645cecadbc4ebeea1c0de94cb3116a769d9bf.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:22 +02:00
Jani Nikula 0aed3bdede drm/i915/bios: add intel_bios_hdmi_level_shift()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/da8ca144020fe165af33992661568d0586a2fdeb.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:18 +02:00
Jani Nikula d9ee21111b drm/i915/bios: add intel_bios_max_tmds_encoder()
Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c52c39df43374b51f56439daf8047079afae7749.1579270868.git.jani.nikula@intel.com
2020-01-21 10:51:03 +02:00
Chris Wilson 7865559872 drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list
Currently we create a new mmap_offset for every call to
mmap_offset_ioctl. This exposes ourselves to an abusive client that may
simply create new mmap_offsets ad infinitum, which will exhaust physical
memory and the virtual address space. In addition to the exhaustion, a
very long linear list of mmap_offsets causes other clients using the
object to incur long list walks -- these long lists can also be
generated by simply having many clients generate their own mmap_offset.

However, we can simply use the drm_vma_node itself to manage the file
association (allow/revoke) dropping our need to keep an mmo per-file.
Then if we keep a small rbtree of per-type mmap_offsets, we can lookup
duplicate requests quickly.

Fixes: cc662126b4 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120104924.4000706-3-chris@chris-wilson.co.uk
2020-01-20 15:38:37 +00:00
Ville Syrjälä 814df0ce5e drm/i915/sdvo: Consolidate SDVO HDMI force_dvi handling
Move the force_dvi check to a single function that can be called from
both mode validation and compute_config(). Note that currently we
don't call it from mode validation, but that will change soon.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20 17:17:31 +02:00
Ville Syrjälä b1040461e6 drm/i915: Consolidate HDMI force_dvi handling
Move the force_dvi check to a single function that can be called from
both mode validation and compute_config().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20 17:16:24 +02:00
Ville Syrjälä cb70b713a8 drm/i915/sdvo: Reduce the size of the on stack buffers
The strings we want to print to the on stack buffers should
be no more than
8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61
bytes. So let's shrink the buffers down to 64 bytes.

Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in
my arithmentic.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-01-20 17:13:32 +02:00
Ville Syrjälä 691313ea62 drm/i915: Move encoder variable to tighter scope
Let's not pollute the function scope with variables when they're
only needed inside some loops.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20 17:04:33 +02:00
Ville Syrjälä b33950dd3f drm/i915: Use PIPE_CONF_CHECK_X() for sync_mode_slaves_mask
sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it
so we get the mismatch printed in hex instead of decimal.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Tested-by: Manasi Navare <manasi.d.navare@intel.com>
2020-01-20 17:03:08 +02:00
Ville Syrjälä ee34801cc0 drm/i915: Prefer to use the pipe to index the ddb entries
Let's use the pipe rather than the silly 'i' iterator from
for_each_oldnew_intel_crtc_in_state() for indexing the ddb
entries array. Maybe one day we can assume c99 and hide the
'i' entirely from sight.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20 16:54:25 +02:00
Ville Syrjälä fff13e63a1 drm/i915: Clear most of crtc state when disabling the crtc
Currently we don't call intel_crtc_prepare_cleared_state() for crtcs
that are going to be entirely disabled (uapi.enable==false). That
means such crtcs will leave stale junk lying around in their states
and we have to sprinkle hw.enable checks all over before we can
look at the states. Let's change that a bit so that we aways do
the state clearing, even for fully disabled crtcs.

Note that we still keep some parts of the old state (see
intel_crtc_prepare_cleared_state() for the details) so probably
can't trust things 100% when hw.enable==false. But at least there's
less chance now that we end up looking at stale junk.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20 16:52:29 +02:00
Ville Syrjälä d0eed1545f drm/i915: Fix post-fastset modeset check for port sync
The post-fastset "does anyone still need a full modeset?" for
port sync looks busted. The outer loop bails out of a full modeset
is still needed by the current crtc, and then we skip forcing
a full modeset on the related crtcs. That's totally the opposite
of what we want.

The MST path has the logic mostly the other way around so it
looks correct. To fix the port sync case let's follow the MST
logic for both. So, if the current crtc already needs a modeset
we do nothing. otherwise we check if any of the related crtcs
needs a modeset, and if so we force a full modeset for the
current crtc.

And while at let's change the else if to a plain if to so
we don't have needless coupling between the MST and port sync
checks.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 05a8e45136 ("drm/i915/display: Use external dependency loop for port sync")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2020-01-20 16:49:18 +02:00
Tvrtko Ursulin 0b3bd0cdc3 drm/i915: Align engine->uabi_class/instance with i915_drm.h
In our ABI we have defined I915_ENGINE_CLASS_INVALID_NONE and
I915_ENGINE_CLASS_INVALID_VIRTUAL as negative values which creates
implicit coupling with type widths used in, also ABI, struct
i915_engine_class_instance.

One place where we export engine->uabi_class
I915_ENGINE_CLASS_INVALID_VIRTUAL is from our our tracepoints. Because the
type of the former is u8 in contrast to u16 defined in the ABI, 254 will
be returned instead of 65534 which userspace would legitimately expect.

Another place is I915_CONTEXT_PARAM_ENGINES.

Therefore we need to align the type used to store engine ABI class and
instance.

v2:
 * Update the commit message mentioning get_engines and cc stable.
   (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 6d06779e86 ("drm/i915: Load balancing across a virtual engine")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v5.3+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116134508.25211-1-tvrtko.ursulin@linux.intel.com
2020-01-20 09:13:01 +00:00
Chris Wilson cd69952778 drm/i915/gt: Be paranoid and reset the GPU before release
Just in the very unlikely case we have not stopped the GPU before we
return the pages being used by the GPU to the system, force a reset.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117180309.3249427-1-chris@chris-wilson.co.uk
2020-01-18 08:53:53 +00:00
Matthew Auld 8e78871bc1 drm/i915/userptr: fix size calculation
If we create a rather large userptr object(e.g 1ULL << 32) we might
shift past the type-width of num_pages: (int)num_pages << PAGE_SHIFT,
resulting in a totally bogus sg_table, which fortunately will eventually
manifest as:

gen8_ppgtt_insert_huge:463 GEM_BUG_ON(iter->sg->length < page_size)
kernel BUG at drivers/gpu/drm/i915/gt/gen8_ppgtt.c:463!

v2: more unsigned long
    prefer I915_GTT_PAGE_SIZE

Fixes: 5cc9ed4b9a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-2-matthew.auld@intel.com
2020-01-17 19:14:03 +00:00
Matthew Auld 24860ad748 drm/i915/userptr: add user_size limit check
Don't allow a mismatch between obj->base.size/vma->size and the actual
number of pages for the backing store, which is limited to INT_MAX
pages.

v2: document what are missing before we can safely drop the limit check

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117132413.1170563-1-matthew.auld@intel.com
2020-01-17 19:14:03 +00:00
Chris Wilson 9452302436 drm/i915/gt: Report the currently active execlists request
Since commit 22b7a426bb ("drm/i915/execlists: Preempt-to-busy"), we
prune the engine->active.requests list prior to preemption, thus
removing the trace of the currently executing request. If that request
hangs rather than be preempted, we conclude that no active request was
on the GPU. Fortunately, this only impacts our debugging, and not our
means of hang detection or recovery.

v2: Use from to check the current iterator before continuing, and report
active as NULL if the current request is already completed.

References: 22b7a426bb ("drm/i915/execlists: Preempt-to-busy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117113259.3023890-1-chris@chris-wilson.co.uk
2020-01-17 16:09:42 +00:00
Wambui Karuga 89c02493de drm/i915: convert to new logging macros in i915/intel_memory_region.c
Replace the use of printk based logging macros with the new struct
drm_device based logging macro in i915/intel_memory_region.c.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1bf4d362e72c619843d44aac96c3561f54e4b23a.1578560355.git.wambui.karugax@gmail.com
2020-01-17 17:44:19 +02:00
Wambui Karuga fd6735fc63 drm/i915: convert to new logging macros in i915/intel_gvt.c
This converts the use of printk based logging macros in i915/intel_gvt.c
with the new struct drm_device based logging macros.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44f3839820a32ed03d73dc56a6ef3581994802c9.1578560355.git.wambui.karugax@gmail.com
2020-01-17 17:44:19 +02:00
Wambui Karuga 68b3271729 drm/i915: conversion to new logging macros in i915/intel_device_info.c
This replaces the printk and struct device based logging macros with the
new struct drm_device style based logging macros i915/intel_device_info.c.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e404429ff2a5e5080867f577beccd7b578a671cd.1578560355.git.wambui.karugax@gmail.com
2020-01-17 17:41:33 +02:00
Wambui Karuga 5e04eb0147 drm/i915: conversion to new logging macros in i915/intel_csr.c
Replace the use of printk and struct device based logging macros with
the new struct drm_device based logging macros in i915/intel_csr.c

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0ea8e0f39013a73ed66052893a8f8abf8cc23ba6.1578560355.git.wambui.karugax@gmail.com
2020-01-17 17:41:33 +02:00
Wambui Karuga aee2eeeb18 drm/i915: conversion to new logging macros in i915/i915_vgpu.c
Replace the use of printk based logging macros with the struct
drm_device based macros in i915/i915_vgpu.c

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/45e8bffff8cbffd72ed41901c3db9f7f6dbe79f3.1578560355.git.wambui.karugax@gmail.com
2020-01-17 17:41:33 +02:00
Michal Wajdeczko 77b20896d5 drm/i915/guc: Introduce CT_DEBUG
As we now have "ct" available almost in all functions we can
start using dev variants of logs also for debug.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-6-michal.wajdeczko@intel.com
2020-01-17 14:02:05 +00:00
Michal Wajdeczko d624d40177 drm/i915/guc: Switch to CT_ERROR in ct_read
As we now have "ct" available in ct_read function we can switch
from generic DRM_ERROR to our custom CT_ERROR.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-5-michal.wajdeczko@intel.com
2020-01-17 14:02:05 +00:00
Michal Wajdeczko 235198d7c9 drm/i915/guc: Don't pass CTB while reading
Since we only have one RECV buffer we don't need to explicitly pass
it to the read function.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-4-michal.wajdeczko@intel.com
2020-01-17 14:02:05 +00:00
Michal Wajdeczko 6a327cb186 drm/i915/guc: Don't pass CTB while writing
Since we only have one SEND buffer we don't need to explicitly pass
it to the write function.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-3-michal.wajdeczko@intel.com
2020-01-17 14:02:05 +00:00
Michal Wajdeczko 1b9fc94a77 drm/i915/guc: Don't GEM_BUG_ON on corrupted G2H CTB
We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indicate that we will not process
any further messages over this CTB (until reset). While here
move descriptor error reporting to the function that actually
touches that descriptor.

Note that unexpected content of the specific CT messages, that
still complies with generic CT message format, shall not trigger
disabling whole CTB, as that might just indicate new unsupported
message types.

v2: drop redundant message (Daniele)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-2-michal.wajdeczko@intel.com
2020-01-17 14:00:45 +00:00
Chris Wilson 416d3838f7 drm/i915: Satisfy smatch that a loop has at least one iteration
Smatch worries that the engine->mask may be 0 leading to the loop being
shortcircuited leaving the next pointer unset,

drivers/gpu/drm/i915/i915_active.c:667 i915_active_acquire_preallocate_barrier() error: uninitialized symbol 'next'.

Assert that mask is not 0 and smatch can then verify that next must be
initialised before use.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117110603.2982286-1-chris@chris-wilson.co.uk
2020-01-17 13:27:10 +00:00
Chris Wilson f1766e3a78 drm/i915: Fix typo in kerneldoc function name
A forgetful copy'n'paste left the name of the old function intact, and
did not introduce the new function 'i915_request_is_ready'

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117101639.2908469-1-chris@chris-wilson.co.uk
2020-01-17 13:20:18 +00:00