Hans de Goede [Thu, 3 Sep 2020 11:23:26 +0000 (13:23 +0200)]
pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:
1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired values.
2. That the controller is enabled when the cached
pwm_state.enabled says that the controller is enabled.
As the long history of fixes for subtle (often suspend/resume)
lpss-pwm issues shows, these assumptions are not necessary
always true.
1. Specifically is not true on some (*) Cherry Trail devices
with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
b. sets the base-unit to 0 and writes the update bit to apply/commit
c. restores the original ctrl value without setting the update bit,
so that the 0 base-unit value is still in use.
2. Assumption 2. currently is true, but only because of the code which
saves/restores the state on suspend/resume. By convention restoring the
PWM state should be done by the PWM consumer and the presence of this
code in the pmw-lpss driver is a bug. Therefor the save/restore code will
be dropped in the next patch in this series, after which this assumption
also is no longer true.
This commit changes the pwm_lpss_apply() to not make any assumptions about
the state the hardware is in. Instead it makes pwm_lpss_apply() always
fully program the PWM controller, making it much less fragile.
*) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
and various Medion models.
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-7-hdegoede@redhat.com
Hans de Goede [Thu, 3 Sep 2020 11:23:25 +0000 (13:23 +0200)]
pwm: lpss: Add pwm_lpss_prepare_enable() helper
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enabled -> enabled transition there, so that we can error check
the entire transition in a single place and only have one pm_runtime_put()
on failure call site.
While working on this I noticed that the enabled -> enabled (update
settings) path was quite similar, so I've added an enable parameter to
the new pwm_lpss_prepare_enable() helper, which allows using it in that
path too.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-6-hdegoede@redhat.com
Hans de Goede [Thu, 3 Sep 2020 11:23:24 +0000 (13:23 +0200)]
pwm: lpss: Add range limit check for the base_unit register value
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Fixes:
684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-5-hdegoede@redhat.com
Hans de Goede [Thu, 3 Sep 2020 11:23:23 +0000 (13:23 +0200)]
pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input clock-cycles the counter has been increased from 0 to
65535 and it will overflow on the next cycle, so it will overflow after
every 65536 clock cycles and thus the calculations done in
pwm_lpss_prepare() should use 65536 and not 65535.
This commit fixes this. Note this also aligns the calculations in
pwm_lpss_prepare() with those in pwm_lpss_get_state().
Note this effectively reverts commit
684309e5043e ("pwm: lpss: Avoid
potential overflow of base_unit"). The next patch in this series really
fixes the potential overflow of the base_unit value.
Fixes:
684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-4-hdegoede@redhat.com
Hans de Goede [Thu, 3 Sep 2020 11:23:22 +0000 (13:23 +0200)]
ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation)
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI0.GFX0.PWMC */
PSAT |= 0x03
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
...
}
Where PSAT is the power-status register of the PWM controller.
Since the i915 driver will do a pwm_get on the pwm device as it uses it to
control the LCD panel backlight, there is a device-link marking the i915
device as a consumer of the pwm device. So that the PWM controller will
always be suspended after the i915 driver suspends (which is the right
thing to do). This causes the above GFX0 PS3 AML code to run before
acpi_lpss.c calls acpi_lpss_save_ctx().
So on these devices the PWM controller will already be off when
acpi_lpss_save_ctx() runs. This causes it to read/save all 1-s (0xffffffff)
as ctx register values.
When these bogus values get restored on resume the PWM controller actually
keeps working, since most bits are reserved, but this does set bit 3 of
the LPSS General purpose register, which for the PWM controller has the
following function: "This bit is re-used to support 32kHz slow mode.
Default is 19.2MHz as PWM source clock".
This causes the clock of the PWM controller to switch from 19.2MHz to
32KHz, which is a slow-down of a factor 600. Surprisingly enough so far
there have been few bug reports about this. This is likely because the
i915 driver was hardcoding the PWM frequency to 46 KHz, which divided
by 600 would result in a PWM frequency of approx. 78 Hz, which mostly
still works fine. There are some bug reports about the LCD backlight
flickering after suspend/resume which are likely caused by this issue.
But with the upcoming patch-series to finally switch the i915 drivers
code for external PWM controllers to use the atomic API and to honor
the PWM frequency specified in the video BIOS (VBT), this becomes a much
bigger problem. On most cases the VBT specifies either 200 Hz or 20
KHz as PWM frequency, which with the mentioned issue ends up being either
1/3 Hz, where the backlight actually visible blinks on and off every 3s,
or in 33 Hz and horrible flickering of the backlight.
There are a number of possible solutions to this problem:
1. Make acpi_lpss_save_ctx() run before GFX0._PS3
Pro: Clean solution from pov of not medling with save/restore ctx code
Con: As mentioned the current ordering is the right thing to do
Con: Requires assymmetry in at what suspend/resume phase we do the save vs
restore, requiring more suspend/resume ordering hacks in already
convoluted acpi_lpss.c suspend/resume code.
2. Do some sort of save once mode for the LPSS ctx
Pro: Reasonably clean
Con: Needs a new LPSS flag + code changes to handle the flag
3. Detect we have failed to save the ctx registers and do not restore them
Pro: Not PWM specific, might help with issues on other LPSS devices too
Con: If we can get away with not restoring the ctx why bother with it at
all?
4. Do not save the ctx for CHT PWM controllers
Pro: Clean, as simple as dropping a flag?
Con: Not so simple as dropping a flag, needs a new flag to ensure that
we still do lpss_deassert_reset() on device activation.
5. Make the pwm-lpss code fixup the LPSS-context registers
Pro: Keeps acpi_lpss.c code clean
Con: Moves knowledge of LPSS-context into the pwm-lpss.c code
1 and 5 both do not seem to be a desirable way forward.
3 and 4 seem ok, but they both assume that restoring the LPSS-context
registers is not necessary. I have done a couple of test and those do
show that restoring the LPSS-context indeed does not seem to be necessary
on devices using s2idle suspend (and successfully reaching S0i3). But I
have no hardware to test deep / S3 suspend. So I'm not sure that not
restoring the context is safe.
That leaves solution 2, which is about as simple / clean as 3 and 4,
so this commit fixes the described problem by implementing a new
LPSS_SAVE_CTX_ONCE flag and setting that for the CHT PWM controllers.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-3-hdegoede@redhat.com
Hans de Goede [Thu, 3 Sep 2020 11:23:21 +0000 (13:23 +0200)]
ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFFFFFC
Local1 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
RSTA = Zero
RSTF = Zero
RSTA = One
RSTF = One
PWMB |= 0xC0000000
PWMC = PWMB /* \_SB_.PCI0.GFX0.PWMB */
}
Where PSAT is the power-status register of the PWM controller, so if it
is in D3 when the GFX0 device's PS0 method runs then it will turn it on
and restore the PWM ctrl register value it saved from its PS3 handler.
Note not only does it restore it, it ors it with 0xC0000000 turning it
on at a time where we may not want it to get turned on at all.
The pwm_get call which the i915 driver does to get a reference to the
PWM controller, already adds a device-link making the GFX0 device a
consumer of the PWM device. So it should already have been resumed when
the above AML runs and the AML should thus not do its undesirable poking
of the PWM controller register.
But the PCI core powers on PCI devices in the no-irq resume phase and
thus calls the troublesome PS0 method in the no-irq resume phase.
Where as LPSS devices by default are resumed in the early resume phase.
This commit sets the resume_from_noirq flag in the bsw_pwm_dev_desc
struct, so that Cherry Trail PWM controllers will be resumed in the
no-irq phase. Together with the device-link added by the pwm-get this
ensures that the PWM controller will be on when the troublesome PS0
method runs, which stops it from poking the PWM controller.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200903112337.4113-2-hdegoede@redhat.com
Jani Nikula [Wed, 2 Sep 2020 14:30:23 +0000 (17:30 +0300)]
drm/i915: remove the extra modeset init layer
Streamline the modeset init by removing the extra init layer.
No functional changes, which means the cleanup path looks hideous.
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/62c32c35683b843ecdc2eca2bd2d3e62cb705e96.1599056955.git.jani.nikula@intel.com
Jani Nikula [Wed, 2 Sep 2020 14:30:22 +0000 (17:30 +0300)]
drm/i915: split out intel_modeset_driver_remove_nogem() and simplify
Split out a separate display function for driver remove after gem
deinitialization. Note that the sequence is not symmetric with
init. However use similar naming as that reflects the deinit sequence.
No functional changes.
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/197fa7e488b412e147ff0fe9440c48811888f1a6.1599056955.git.jani.nikula@intel.com
Jani Nikula [Wed, 2 Sep 2020 14:30:21 +0000 (17:30 +0300)]
drm/i915: move more display related probe to intel_modeset_init_noirq()
With the intel_modeset_* probe functions clarified, we can continue with
moving more related calls to the right layer:
- drm_vblank_init()
- intel_bios_init()
- intel_vga_register()
- intel_csr_ucode_init()
Unfortunately, for the time being, we also need to move a call to the
*wrong* layer: the power domain init.
No functional changes.
v2: move probe failure while at it, power domain init
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/da229ffbed64983f002605074533c8b2878d17ee.1599056955.git.jani.nikula@intel.com
Jani Nikula [Wed, 2 Sep 2020 14:30:20 +0000 (17:30 +0300)]
drm/i915: split intel_modeset_init() pre/post gem init
Turn current intel_modeset_init() to a pre-gem init function, and add a
new intel_modeset_init() function and move all post-gem modeset init
there, in the correct layer. No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/5f4603f2c0216dba980338f00e0bfa791b526231.1599056955.git.jani.nikula@intel.com
Kai Vehmanen [Tue, 1 Sep 2020 15:10:36 +0000 (18:10 +0300)]
drm/i915: fix regression leading to display audio probe failure on GLK
In commit
4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
to separate function") the order of force_min_cdclk_changed check and
intel_modeset_checks(), was reversed. This broke the mechanism to
immediately force a new CDCLK minimum, and lead to driver probe
errors for display audio on GLK platform with 5.9-rc1 kernel. Fix
the issue by moving intel_modeset_checks() call later.
[vsyrjala: It also broke the ability of planes to bump up the cdclk
and thus could lead to underruns when eg. flipping from 32bpp to
64bpp framebuffer. To be clear, we still compute the new cdclk
correctly but fail to actually program it to the hardware due to
intel_set_cdclk_{pre,post}_plane_update() not getting called on
account of state->modeset==false.]
Fixes:
4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking to separate function")
BugLink: https://github.com/thesofproject/linux/issues/2410
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200901151036.1312357-1-kai.vehmanen@linux.intel.com
Sean Paul [Tue, 18 Aug 2020 15:39:05 +0000 (11:39 -0400)]
drm/i915: Add HDCP 1.4 support for MST connectors
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li <juston.li@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-18-sean@poorly.run
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
Changes in v6:
-Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
don't have hardware to test it
Changes in v7:
-Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-18-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:39:04 +0000 (11:39 -0400)]
drm/i915: Print HDCP version info for all connectors
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li <juston.li@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Juston Li <juston.li@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-16-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-16-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-17-sean@poorly.run
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-17-sean@poorly.run
Sean Paul [Wed, 19 Aug 2020 14:31:24 +0000 (10:31 -0400)]
drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
Used to query whether an MST stream is encrypted or not.
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-16-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-16-sean@poorly.run
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-Use FIELD_PREP to generate request buffer bitfields (Lyude)
-Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
Changes in v7:
-None
Changes in v8:
-Reverse the parsing on the hdcp_*x_device_present bits and leave
breadcrumb in case this is incorrect (Anshuman)
Changes in v8.5:
-s/DRM_DEBUG_KMS/drm_dbg_kms/ (Lyude)
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200819143133.46232-1-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:39:02 +0000 (11:39 -0400)]
drm/i915: Add connector to hdcp_shim->check_link()
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-15-sean@poorly.run
Changes in v4:
-Added to the set
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-15-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:39:01 +0000 (11:39 -0400)]
drm/i915: Plumb port through hdcp init
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-14-sean@poorly.run
Changes in v5:
-Added to the set
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-14-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:39:00 +0000 (11:39 -0400)]
Sean Paul [Tue, 18 Aug 2020 15:38:59 +0000 (11:38 -0400)]
Sean Paul [Tue, 18 Aug 2020 15:38:58 +0000 (11:38 -0400)]
Sean Paul [Tue, 18 Aug 2020 15:38:57 +0000 (11:38 -0400)]
drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-10-sean@poorly.run
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Split minor intel_hdcp_disable refactor into separate patch (Ramalingam)
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-10-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:56 +0000 (11:38 -0400)]
drm/i915: Clean up intel_hdcp_disable
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-9-sean@poorly.run
Changes in v7:
-Split into separate patch (Ramalingam)
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-9-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:55 +0000 (11:38 -0400)]
drm/i915: Protect workers against disappearing connectors
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-8-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-8-sean@poorly.run
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-8-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:54 +0000 (11:38 -0400)]
Sean Paul [Tue, 18 Aug 2020 15:38:53 +0000 (11:38 -0400)]
drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-6-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-6-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-6-sean@poorly.run
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-6-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:52 +0000 (11:38 -0400)]
drm/i915: Intercept Aksv writes in the aux hooks
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-5-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-5-sean@poorly.run
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-5-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:51 +0000 (11:38 -0400)]
drm/i915: WARN if HDCP signalling is enabled upon disable
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-4-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-4-sean@poorly.run
Changes in v2:
-Added to the set in lieu of just clearing the bit
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
Changes in v6:
-None
Changes in v7:
-Rebased, variable name changed from 'ctl' to 'val'
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-4-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:50 +0000 (11:38 -0400)]
drm/i915: Clear the repeater bit on HDCP disable
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes:
ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-3-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-3-sean@poorly.run
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-3-sean@poorly.run
Sean Paul [Tue, 18 Aug 2020 15:38:49 +0000 (11:38 -0400)]
drm/i915: Fix sha_text population code
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes:
ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base implementation")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.17+
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-2-sean@poorly.run
Link: https://patchwork.freedesktop.org/patch/msgid/20200623155907.22961-2-sean@poorly.run
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
Changes in v6:
-None
Changes in v7:
-None
Changes in v8:
-None
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200818153910.27894-2-sean@poorly.run
Lionel Landwerlin [Fri, 28 Aug 2020 13:31:25 +0000 (16:31 +0300)]
drm/i915: break TGL pci-ids in GT 1 & 2
I'll need this in IGT to identify the different kind of GTs and apply
the right performance query configuration.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200828133125.157171-1-lionel.g.landwerlin@intel.com
Nathan Chancellor [Fri, 28 Aug 2020 20:28:30 +0000 (13:28 -0700)]
drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state
Clang warns:
drivers/gpu/drm/i915/display/intel_combo_phy.c:268:3: warning: variable
'ret' is uninitialized when used here [-Wuninitialized]
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
^~~
drivers/gpu/drm/i915/display/intel_combo_phy.c:261:10: note: initialize
the variable 'ret' to silence this warning
bool ret;
^
= 0
1 warning generated.
In practice, the bug this warning appears to be concerned with would not
actually matter because ret gets initialized to the return value of
cnl_verify_procmon_ref_values. However, that does appear to be a bug
since it means the first hunk of the patch this fixes won't actually do
anything (since the values of check_phy_reg won't factor into the final
ret value). Initialize ret to true then make all of the assignments a
bitwise AND with itself so that the function always does what it should
do.
Fixes:
239bef676d8e ("drm/i915/display: Implement new combo phy initialization step")
Link: https://github.com/ClangBuiltLinux/linux/issues/1094
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200828202830.7165-1-jose.souza@intel.com
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
José Roberto de Souza [Wed, 26 Aug 2020 20:15:49 +0000 (13:15 -0700)]
drm/i915/ehl: Update voltage swing table
Update with latest tuning in the table.
v3: Fix values of to last columns.
BSpec: 21257
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826201549.83658-3-jose.souza@intel.com
José Roberto de Souza [Wed, 26 Aug 2020 20:15:48 +0000 (13:15 -0700)]
drm/i915/display/ehl: Use EHL DP tables for eDP ports without low power support
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
set as EHL combo phy supports HBR3 (Matt R)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826201549.83658-2-jose.souza@intel.com
José Roberto de Souza [Wed, 26 Aug 2020 20:15:47 +0000 (13:15 -0700)]
drm/i915/display/tgl: Use TGL DP tables for eDP ports without low power support
Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
being used when the eDP port don't support low power voltage swing table.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826201549.83658-1-jose.souza@intel.com
José Roberto de Souza [Thu, 27 Aug 2020 23:39:43 +0000 (16:39 -0700)]
drm/i915/tgl: Fix stepping WA matching
TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit
96c5a15f9f39
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP stepping
mapping between SKUs and the same stepping revision of GT do not match
the same HW between TGL U/Y and regular TGL.
So it was required to have 2 different macros to check GT WAs while
for Display we are able to use just one macro that uses the right
revids table.
All TGL workarounds checked and updated accordingly.
v2:
- removed TODO to check if WA
14010919138 applies to regular TGL.
- fixed display stepping in regular TGL (Anusha)
BSpec: 52890
BSpec: 55378
BSpec: 44455
Reviewed-by: Anusha Srivatsa <anusha.srivtsa@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Penne Lee <penne.y.lee@intel.com>
Cc: Guangyao Bai <guangyao.bai@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200827233943.400946-1-jose.souza@intel.com
José Roberto de Souza [Tue, 25 Aug 2020 17:13:31 +0000 (10:13 -0700)]
drm/i915/display: Fix DRRS debugfs
Supported and enabled are different things so printing both.
v3: using drrs->type instead of vbt.drrs_type
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Srinivas K <srinivasx.k@intel.com>
Cc: Hariom Pandey <hariom.pandey@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200825171331.17971-3-jose.souza@intel.com
José Roberto de Souza [Tue, 25 Aug 2020 17:13:30 +0000 (10:13 -0700)]
drm/i915/display: Disable DRRS when needed in fastsets
Changes in the configuration could cause PSR to be compatible and
enabled so driver must also be able to disable DRRS when doing
fastsets.
v2: Fixed name of DRRS compute function (Anshuman)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/173
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
Cc: Srinivas K <srinivasx.k@intel.com>
Cc: Hariom Pandey <hariom.pandey@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200825171331.17971-2-jose.souza@intel.com
José Roberto de Souza [Tue, 25 Aug 2020 17:13:29 +0000 (10:13 -0700)]
drm/i915/display: Compute has_drrs after compute has_psr
DRRS and PSR can't be enable together, so giving preference to PSR
as it allows more power-savings by complete shutting down display,
so to guarantee this, it should compute DRRS state after compute PSR.
Cc: Srinivas K <srinivasx.k@intel.com>
Cc: Hariom Pandey <hariom.pandey@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200825171331.17971-1-jose.souza@intel.com
Colin Ian King [Mon, 10 Aug 2020 09:59:52 +0000 (10:59 +0100)]
drm/i915/vlv_dsi_pll: fix spelling mistake "Cant" -> "Can't"
There is a spelling mistake in a drm_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200810095952.60968-1-colin.king@canonical.com
Clint Taylor [Wed, 26 Aug 2020 02:57:24 +0000 (19:57 -0700)]
drm/i915/gt: Implement WA_1406941453
Enable HW Default flip for small PL.
bspec: 52890
bspec: 53508
bspec: 53273
v2: rebase to drm-tip
v3: move from ctx to gt workarounds. Remove whitelist.
v4: move to rcs WA init
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826025724.20944-1-clinton.a.taylor@intel.com
Anshuman Gupta [Wed, 5 Aug 2020 11:45:21 +0000 (17:15 +0530)]
drm/i915/hdcp: No direct access to power_well desc
HDCP code doesn't require to access power_well internal stuff,
instead it should use the intel_display_power_well_is_enabled()
to get the status of desired power_well.
No functional change.
v2:
- used with_intel_runtime_pm instead of get/put. [Jani]
v3:
- rebased.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-3-anshuman.gupta@intel.com
Anshuman Gupta [Wed, 5 Aug 2020 11:45:20 +0000 (17:15 +0530)]
drm/i915/hdcp: Add update_pipe early return
Currently intel_hdcp_update_pipe() is also getting called for non-hdcp
connectors and get through its conditional code flow, which is completely
unnecessary for non-hdcp connectors, therefore it make sense to
have an early return. No functional change.
v2:
- rebased.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805114521.867-2-anshuman.gupta@intel.com
Rodrigo Vivi [Mon, 24 Aug 2020 18:26:38 +0000 (14:26 -0400)]
drm/i915: Update DRIVER_DATE to
20200824
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Mika Kuoppala [Mon, 17 Aug 2020 19:59:26 +0000 (22:59 +0300)]
drm/i915: Fix cmd parser desc matching with masks
Our variety of defined gpu commands have the actual
command id field and possibly length and flags applied.
We did start to apply the mask during initialization of
the cmd descriptors but forgot to also apply it on comparisons.
Fix comparisons in order to properly deny access with
associated commands.
v2: fix lri with correct mask (Chris)
References:
926abff21a8f ("drm/i915/cmdparser: Ignore Length operands during command matching")
Reported-by: Nicolai Stange <nstange@suse.de>
Cc: stable@vger.kernel.org # v5.4+
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tyler Hicks <tyhicks@canonical.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200817195926.12671-1-mika.kuoppala@linux.intel.com
Matt Atwood [Wed, 12 Aug 2020 21:07:02 +0000 (14:07 -0700)]
drm/i915: Apply Wa_14011264657:gen11+
Add minimum width to planes, variable with specific formats for gen11+
to reflect recent bspec changes.
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200812210702.7153-1-matthew.s.atwood@intel.com
José Roberto de Souza [Thu, 13 Aug 2020 20:00:29 +0000 (13:00 -0700)]
drm/i915: Update TGL and RKL HuC firmware versions
Major upgrade of HuC firmware with fixes and new features.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200813200029.25307-2-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Thu, 13 Aug 2020 20:00:28 +0000 (13:00 -0700)]
drm/i915: Update TGL and RKL DMC firmware versions
Fixes around DC5, DC6 and DC3CO in those new firmwares.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200813200029.25307-1-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Mon, 10 Aug 2020 17:41:44 +0000 (10:41 -0700)]
drm/i915/display: Implement WA
1408330847
From the 3 WAs for PSR2 man track/selective fetch this is only one
needed when doing single full frames at every flip.
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200810174144.76761-2-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Mon, 10 Aug 2020 17:41:43 +0000 (10:41 -0700)]
drm/i915: Initial implementation of PSR2 selective fetch
All GEN12 platforms supports PSR2 selective fetch but not all GEN12
platforms supports PSR2 hardware tracking(aka RKL).
This feature consists in software programming registers with the
damaged area of each plane this way hardware will only fetch from
memory those areas and sent the PSR2 selective update blocks to panel,
saving even more power.
But as initial step it is only enabling the full frame fetch at
every flip, the actual selective fetch part will come in a future
patch.
Also this is only handling the page flip side, it is still completely
missing frontbuffer modifications, that is why the
enable_psr2_sel_fetch parameter was added.
v3:
- calling intel_psr2_sel_fetch_update() during the atomic check phase
(Ville)
BSpec: 55229
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200810174144.76761-1-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Tue, 11 Aug 2020 03:21:05 +0000 (20:21 -0700)]
drm/i915/kbl: Fix revision ID checks
We usually assume that increasing PCI device revision ID's translates to
newer steppings; macros like IS_KBL_REVID() that we use rely on this
behavior. Unfortunately this turns out to not be true on KBL; the
newer device 2 revision ID's sometimes go backward to older steppings.
The situation is further complicated by different GT and display
steppings associated with each revision ID.
Let's work around this by providing a table to map the revision ID to
specific GT and display steppings, and then perform our comparisons on
the mapped values.
v2:
- Move the kbl_revids[] array to intel_workarounds.c to avoid compiler
warnings about an unused variable in files that don't call the
macros (kernel test robot).
Bspec: 18329
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200811032105.2819370-1-matthew.d.roper@intel.com
Reviewed-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Fri, 7 Aug 2020 19:26:29 +0000 (12:26 -0700)]
drm/i915/tgl: Add new voltage swing table
This new HBR2 table for TGL-U and TGL-Y is required to pass
DisplayPort compliance.
BSpec: 49291
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Khaled Almahallawy<khaled.almahallawy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200807192629.64134-2-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Fri, 7 Aug 2020 19:26:28 +0000 (12:26 -0700)]
drm/i915/tgl: Set subplatforms
There is no way to differentiate TGL-U from TGL-Y by the PCI ids as
some ids are available in both SKUs.
So here using the root device id in the PCI bus that iGPU is in
to differentiate between U and Y.
BSpec: 44455
Reviewed-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200807192629.64134-1-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Wed, 5 Aug 2020 15:00:56 +0000 (18:00 +0300)]
drm/i915/tgl: Fix TC-cold block/unblock sequence
The command register is the PCODE MBOX low register not the high one as
described by the spec. This left the system with the TC-cold power state
being blocked all the time. Fix things by using the correct register.
Also to make sure we retry a request for at least 600usec, when the
PCODE MBOX command itself succeeded, but the TC-cold block command
failed, sleep for 1msec unconditionally after any fail.
The change was tested with JTAG register read of the HW/FW's actual
TC-cold state, which reported the expected states after this change.
Tested-by: Nivedita Swaminathan <nivedita.swaminathan@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805150056.24248-1-imre.deak@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Mon, 20 Jul 2020 23:29:52 +0000 (02:29 +0300)]
drm/i915/tgl: Make sure TC-cold is blocked before enabling TC AUX power wells
The dependency between power wells is determined by the ordering of the
power well list: when enabling the power wells for a domain, this
happens walking the power well list forward, while disabling them
happens in the reverse direction. Accordingly a power well on the list
must follow any other power well it depends on.
Since the TC AUX power wells depend on TC-cold being blocked, move the
TC-cold off power well before all AUX power wells.
Fixes:
3c02934b24e3 ("drm/i915/tc/tgl: Implement TC cold sequences")
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200720232952.16228-1-imre.deak@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
George Spelvin [Wed, 25 Mar 2020 19:24:29 +0000 (19:24 +0000)]
drm/i915/selftests: Avoid passing a random 0 into ilog2
igt_mm_config() calls ilog2() on the (pseudo)random 21-bit number
s>>12. Once in 2 million seeds, this is zero and ilog2 summons
the nasal demons.
There was an attempt to handle this case with a max(), but that's
too late; ms could already be something bizarre.
Given that the low 12 bits of s and ms are always zero, it's a lot
simpler just to divide them by 4096, then everything fits into 32
bits, and we can easily generate a random number 1 <= s <= 0x1fffff.
Fixes:
14d1b9a6247c ("drm/i915: buddy allocator")
Signed-off-by: George Spelvin <lkml@sdf.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200325192429.GA8865@SDF.ORG
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lionel Landwerlin [Tue, 4 Aug 2020 08:59:54 +0000 (11:59 +0300)]
drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Rebase
v12: Allow multiple extension nodes of timeline syncobj (Chris)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Co-authored-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v11)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804085954.350343-3-lionel.g.landwerlin@intel.com
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2901
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lionel Landwerlin [Tue, 4 Aug 2020 08:59:53 +0000 (11:59 +0300)]
drm/i915: introduce a mechanism to extend execbuf2
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804085954.350343-2-lionel.g.landwerlin@intel.com
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2901
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Tue, 4 Aug 2020 04:40:24 +0000 (21:40 -0700)]
Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
The hardware team has dropped this workaround from the bspec; it is no
longer needed.
This reverts commit
111822b21be995a3a4a731066db3d820523c57f7.
Bspec: 49291
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804044024.1931170-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tianjia Zhang [Sun, 2 Aug 2020 11:15:35 +0000 (19:15 +0800)]
drm/i915: Fix wrong return value in intel_atomic_check()
In the case of calling check_digital_port_conflicts() failed, a
negative error code -EINVAL should be returned.
Fixes:
bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200802111535.5200-1-tianjia.zhang@linux.alibaba.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tianjia Zhang [Sun, 2 Aug 2020 11:56:55 +0000 (12:56 +0100)]
drm/i915: Fix wrong return value
In function i915_active_acquire_preallocate_barrier(), not all
paths have the return value set correctly, and in case of memory
allocation failure, a negative error code should be returned.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
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/20200802115655.25568-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 12 Jun 2020 20:47:34 +0000 (13:47 -0700)]
drm/i915: Update bw_buddy pagemask table
A recent bspec update removed the LPDDR4 single channel entry from the
buddy register table, but added a new four-channel entry.
Workaround
1409767108 hasn't been updated with any guidance for four
channel configurations, so we leave that alternate table unchanged for
now.
Bspec 49218
Fixes:
3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200612204734.3674650-1-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Fri, 31 Jul 2020 08:50:09 +0000 (09:50 +0100)]
drm/i915: Add a couple of missing i915_active_fini()
We use i915_active_fini() as a debug check on the i915_active state
before freeing. If we forget to call it, we may end up angering the
debugobjects contained within.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200731085015.32368-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Wed, 29 Jul 2020 13:09:12 +0000 (14:09 +0100)]
drm/i915/display: Check for an LPSP encoder before dereferencing
Avoid a GPF at
<1>[ 20.177320] BUG: kernel NULL pointer dereference, address:
000000000000007c
<1>[ 20.177322] #PF: supervisor read access in kernel mode
<1>[ 20.177323] #PF: error_code(0x0000) - not-present page
<6>[ 20.177324] PGD 0 P4D 0
<4>[ 20.177327] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[ 20.177328] CPU: 1 PID: 944 Comm: debugfs_test Not tainted 5.8.0-rc7-CI-CI_DRM_8814+ #1
<4>[ 20.177330] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018
<4>[ 20.177372] RIP: 0010:i915_lpsp_capability_show+0x44/0xc0 [i915]
<4>[ 20.177374] Code: 0f b6 81 ca 0d 00 00 3c 0b 74 77 76 19 3c 0c 75 44 83 7e 7c 01 7e 2f 48 c7 c6 d7 b9 47 a0 e8 43 df 06 e1 31 c0 c3 3c 09 72 2b <8b> 46 7c 85 c0 75 e6 8b 82 e4 00 00 00 89 c2 83 e2 fb 83 fa 0a 74
<4>[ 20.177376] RSP: 0018:
ffffc90000cebe38 EFLAGS:
00010246
<4>[ 20.177377] RAX:
0000000000000009 RBX:
ffff888267fe6a58 RCX:
ffff888252d10000
<4>[ 20.177378] RDX:
ffff88824a9a4000 RSI:
0000000000000000 RDI:
ffff888267fe6a30
<4>[ 20.177379] RBP:
0000000000000000 R08:
0000000000000000 R09:
0000000000000001
<4>[ 20.177380] R10:
0000000000000001 R11:
0000000000000000 R12:
ffffc90000cebf08
<4>[ 20.177381] R13:
00000000ffffffff R14:
0000000000000001 R15:
ffff888267fe6a30
<4>[ 20.177383] FS:
00007f6f9c6b5e40(0000) GS:
ffff888276480000(0000) knlGS:
0000000000000000
<4>[ 20.177384] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4>[ 20.177385] CR2:
000000000000007c CR3:
0000000255f04006 CR4:
00000000003606e0
<4>[ 20.177386] Call Trace:
<4>[ 20.177390] seq_read+0xcb/0x420
which is presumably from having no encoder attached at that time.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2175
Fixes:
8806211fe7b3 ("drm/i915: Add i915_lpsp_capability debugfs")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200729130912.30093-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Tue, 28 Jul 2020 15:22:19 +0000 (16:22 +0100)]
drm/i915: Remove gen check before calling intel_rps_boost
It's been a while since gen6_rps_boost() [that only worked on gen6+] was
replaced by intel_rps_boost() that understood itself when rps was
active. Since the intel_rps_boost() is gen-agnostic, just call it.
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/20200728152219.1387-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Tue, 28 Jul 2020 15:21:10 +0000 (16:21 +0100)]
drm/i915/selftests: Add compiler paranoia for checking HWSP values
Since we want to read the values from the HWSP as written to by the GPU,
warn the compiler that the values are volatile.
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/20200728152110.830-2-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Tue, 28 Jul 2020 15:06:00 +0000 (16:06 +0100)]
drm/i915: Copy default modparams to mock i915_device
Since we use the module parameters stored inside the drm_i915_device
itself, we need to ensure the mock i915_device also sets up the right
defaults.
Fixes:
8a25c4be583d ("drm/i915/params: switch to device specific parameters")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200728150600.4509-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Uma Shankar [Thu, 16 Jul 2020 14:58:57 +0000 (20:28 +0530)]
drm/i915/display/fbc: Disable fbc by default on TGL
Fbc is causing random underruns in CI execution on TGL platforms.
Disabling the same while the problem is being debugged and analyzed.
v2: Moved the check below the module param check (Ville)
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716145857.6911-1-uma.shankar@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Mon, 27 Jul 2020 16:47:29 +0000 (09:47 -0700)]
drm/i915: Implement WA
14011294188
Although the WA description targets the platforms it is a workaround
for the affected PCHs, that is why it is being checked.
v2: excluding DG1 fake PCH from WA
BSpec: 52890
BSpec: 53273
BSpec: 52888
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200727164729.28836-1-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Thu, 23 Jul 2020 15:38:05 +0000 (16:38 +0100)]
drm/i915/selftests: Downgrade severity of CS/SRM frequency scaling tests
Gracefully skip over the failures in the frequency scaling for the
moment, the results are under review.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1754
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Sundaresan, Sujaritha" <sujaritha.sundaresan@intel.com>
Cc: "Ewins, Jon" <jon.ewins@intel.com>
Reviewed-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200723153805.8076-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 16 Jul 2020 22:05:51 +0000 (15:05 -0700)]
drm/i915/rkl: Add Wa_14011224835 for PHY B initialization
After doing normal PHY-B initialization on Rocket Lake, we need to
manually copy some additional PHY-A register values into PHY-B
registers.
Note that the bspec's combo phy page doesn't specify that this
workaround is restricted to specific platform steppings (and doesn't
even do a very good job of specifying that RKL is the only platform this
is needed on), but the RKL workaround page lists this as relevant only
for A and B steppings, so I'm trusting that information for now.
v2: Make rkl_combo_phy_b_init_wa() static
v3:
- Minimize variables in WA function. (Jose)
- Fix timeout duration (usec vs msec). (Jose)
- Add verification of workaround. (Jose)
- Fix stepping bounds in comment.
Bspec: 49291
Bspec: 53273
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-6-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 16 Jul 2020 22:05:50 +0000 (15:05 -0700)]
drm/i915/rkl: Handle HTI
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
v2:
- Fix minor checkpatch warnings
v3:
- Just readout HDPORT_STATE register once during init and then parse it
later as needed.
- Add a 'has_hti' device info flag to track whether we should readout
HDPORT_STATE or not. We can skip the platform/flag tests later since
the hti_state in dev_priv will remain 0 for platforms it does not
apply to.
- Move PLL masking into icl_get_combo_phy_dpll() since at the moment
RKL is the only platform that has HTI. (Jose)
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-5-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 16 Jul 2020 22:05:49 +0000 (15:05 -0700)]
drm/i915/rkl: Add DPLL4 support
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2.
v2:
- Add new .update_ref_clks() hook.
v3:
- Renumber TBT PLL to '3' and switch _MMIO_PLL3 to _MMIO_PLL (Lucas)
v4:
- Don't drop _MMIO_PLL3; although it's now unused, we're going to need
it very soon again for upcoming DG1 patches. (Lucas)
v5:
- Don't re-number TBT PLL and beyond, just use new RKL_DPLL_CFGCR
macros to lookup the proper registers instead. Although renumbering
the PLLs might be something we want to consider down the road, it
opens a big can of worms right now since a bunch of places in the
code have an assumption that the PLL table has idx==id and no holes.
Renumbering creates a hole for TGL, so we'd either need to allow
holes in the table or break the idx==id invariant, both of which are
somewhat invasive changes to the design.
Bspec: 49202
Bspec: 49443
Bspec: 50288
Bspec: 50289
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-4-matthew.d.roper@intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 16 Jul 2020 22:05:48 +0000 (15:05 -0700)]
drm/i915/rkl: Add initial workarounds
RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.
v2:
- Add Wa_1604555607 for RKL. This makes RKL's ctx WA list identical to
TGL's, so we'll have both functions call the tgl_ function for now;
this workaround isn't listed for DG1 so we don't want to add it to
the general gen12_ function.
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-3-matthew.d.roper@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 16 Jul 2020 22:05:47 +0000 (15:05 -0700)]
drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
v2:
- Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
- Checkpatch style fixes
Bspec: 50287
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-2-matthew.d.roper@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Thu, 16 Jul 2020 19:04:25 +0000 (22:04 +0300)]
drm/i915: Move WaDisableDopClockGating:skl to skl_init_clock_gating()
It's silly to have if(SKL) checks in gen9_init_clock_gating() when
we can just move those bits into skl_init_clock_gating().
I'm not entirely convinced we even need this w/a, or if we do
then maybe we want it for kbl/cfl as well. IIRC it was only
listed in the wadb, but that is now dead so can't double check
anymore. Bspec doesn't seem to have any purely skl specific
DOP clock gating workarounds listed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716190426.17047-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
José Roberto de Souza [Wed, 15 Jul 2020 17:56:37 +0000 (10:56 -0700)]
drm/i915/display: Implement HOBL
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails it fall
back to the original table.
intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
instead of do something like is done in intel_ddi_dp_voltage_max()
because it is only called after the first entry of the voltage swing
table was loaded so the HOBL flag is valid at that point.
v3:
- removed a few parameters of icl_ddi_combo_vswing_program() that
can be taken from encoder
v4:
- using the HOBL vswing table until training fails completely (Ville)
v5:
- not reducing lane or link rate when link training fails with HOBL
active
- duplicated the HOBL voltage swing entry to match DP spec requirement
v6:
- removed the optional VS 3 & pre-emp 0 from HOBL table
- changed from u8:1 to bool to store hobl_failed/active
BSpec: 49291
BSpec: 49399
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200715175637.33763-1-jose.souza@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Alexei Podtelezhnikov [Tue, 28 Apr 2020 03:47:52 +0000 (23:47 -0400)]
drm/i915: Remove dubious Valleyview PCI IDs
0x0155 is rather Ivy Bridge PCI-E Root Port.
0x0157 from the same commit
ff049b6ce21d ("drm/i915: bind driver to ValleyView chipsets")
is likely wrong too. Nowhere is it independetly confirmed or mentioned.
Signed-off-by: Alexei Podtelezhnikov <apodtele@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428034752.3975-1-apodtele@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Thu, 16 Jul 2020 09:46:43 +0000 (10:46 +0100)]
drm/i915: Provide the perf pmu.module
Rather than manually implement our own module reference counting for perf
pmu events, finally realise that there is a module parameter to struct
pmu for this very purpose.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716094643.31410-1-chris@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Tue, 14 Jul 2020 15:31:41 +0000 (18:31 +0300)]
drm/i915/ddi: Don't rewrite DDI_BUF_CTL reg during DP link training
The value we program to DDI_BUF_CTL changes at the following places:
- At enabling/disabling the output to configure the port width etc, and
to enable/disable the DDI BUF function.
- At the beginning/end of link re-training to disable/re-enable the DDI
BUF function.
- On HSW/BDW/SKL to change the voltage swing/pre-emph levels.
Except of the above the value we program to the DDI_BUF_CTL register
(intel_dp->DP) doesn't change, so no need to reprogram the register when
changing the link training patterns (which is programmed via the
DP_TP_CTL register on DDI platforms).
v2:
- Fix the commit message wrt. voltage/pre-emph level values in
intel_dp->DP. (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714153141.10280-2-imre.deak@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Imre Deak [Tue, 14 Jul 2020 15:31:40 +0000 (18:31 +0300)]
drm/i915/ddi: Don't frob the DP link scramble disabling flag
According to BSpec this flag should not be changed while the DDI
function is enabled. On BDW+ the DP_TP_CTL register spec also states it
explicitly that the HW takes care of enabling/disabling the scrambling
for training patterns (and it must stay enabled for normal pixel
output). Assume that this HW automatic handling of scrambling is also
true for HSW.
BSpec: 8013, 7557, 50484
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714153141.10280-1-imre.deak@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 14 Jul 2020 15:26:25 +0000 (18:26 +0300)]
drm/i915: Make i830 .get_cdclk() assignment less confusing
Explicitly check for i830 when assigning the .get_cdclk() vfunc,
and then deal with the case of not having assigned the vfunc
separately. Less confusing, and gets rid of the checkpatch complaint
about using {} on one branch but not the others.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 14 Jul 2020 15:26:24 +0000 (18:26 +0300)]
drm/i915: Fix some whitespace
Some spaces have snuck in where we want tabs. Fix it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 14 Jul 2020 15:26:23 +0000 (18:26 +0300)]
drm/i915: Pack struct intel_cdclk_vals
There's a pointless hole in struct intel_cdclk_vals, get rid of it.
Fortunately we already use named initializers so the order does not
matter.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Tue, 14 Jul 2020 20:19:45 +0000 (23:19 +0300)]
drm/i915/fbc: Limit cfb to the first 256MiB of stolen on g4x+
Since g4x the CFB base only takes a 28bit offset into stolen.
Not sure if the CFB is allowed to start below that limit but
then extend beyond it. Let's assume not and just restrict the
allocation to the first 256MiB (in the unlikely case
we have more stolen than that).
v2: s/BIT/BIT_ULL/ (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714201945.18959-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Christian König [Wed, 12 Aug 2020 03:03:49 +0000 (13:03 +1000)]
drm/ttm: revert "drm/ttm: make TT creation purely optional v3"
This reverts commit
2ddef17678bc2ea1d20517dd2b4ed4aa967ffa8b.
As it turned out VMWGFX needs a much wider audit to fix this.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200811092400.188124-1-christian.koenig@amd.com
Dave Airlie [Wed, 12 Aug 2020 02:58:19 +0000 (12:58 +1000)]
Merge branch 'vmwgfx-next-5.9' of git://people.freedesktop.org/~sroland/linux into drm-next
The drm_mode_config_reset patches are very important fixing a recently
introduced kernel crash, the others fix various older issues which are
a bit less serious in practice.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Roland Scheidegger (VMware)" <rscheidegger.oss@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200812005941.19465-1-rscheidegger.oss@gmail.com
Dave Airlie [Tue, 11 Aug 2020 03:08:44 +0000 (13:08 +1000)]
Merge tag 'amd-drm-fixes-5.9-2020-08-07' of git://people.freedesktop.org/~agd5f/linux into drm-next
amd-drm-fixes-5.9-2020-08-07:
amdgpu:
- Re-add spelling typo fix
- Sienna Cichlid fixes
- Navy Flounder fixes
- DC fixes
- SMU i2c fix
- Power fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200807222843.3909-1-alexander.deucher@amd.com
Dave Airlie [Tue, 11 Aug 2020 01:59:19 +0000 (11:59 +1000)]
Merge tag 'drm-misc-fixes-2020-08-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
* backmerge from drm-fixes at v5.8-rc7
* add orientation quirk for ASUS T103HAF
* drm/omap: force runtime PM suspend on system suspend
* drm/tidss: fix modeset init for DPI panels
* re-added docs for drm_gem_flink_ioctl()
* ttm: fix page-offset calculation within TTM
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804125510.GA29670@linux-uq9g
Dave Airlie [Tue, 11 Aug 2020 01:58:31 +0000 (11:58 +1000)]
Merge tag 'v5.8' into drm-next
I need to backmerge 5.8 as I've got a bunch of fixes sitting
on an rc7 base that I want to land.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Colin Ian King [Mon, 10 Aug 2020 10:04:01 +0000 (11:04 +0100)]
drm/vmwgfx: fix spelling mistake "Cant" -> "Can't"
There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Colin Ian King [Wed, 5 Aug 2020 11:31:55 +0000 (12:31 +0100)]
drm/vmwgfx: fix spelling mistake "Cound" -> "Could"
There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Roland Scheidegger [Fri, 7 Aug 2020 20:04:33 +0000 (22:04 +0200)]
drm/vmwgfx/ldu: Use drm_mode_config_reset
Same problem as in stdu, same fix.
Fixes:
51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Roland Scheidegger [Fri, 7 Aug 2020 20:03:42 +0000 (22:03 +0200)]
drm/vmwgfx/sou: Use drm_mode_config_reset
Same problem as in stdu, same fix.
Fixes:
51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Acked-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Daniel Vetter [Thu, 6 Aug 2020 15:42:27 +0000 (17:42 +0200)]
drm/vmwgfx/stdu: Use drm_mode_config_reset
When converting to atomic the state reset was done by directly calling
the functions, and before the modeset object was fully initialized.
This means the various ->dev pointers weren't set up.
After
commit
51f644b40b4b794b28b982fdd5d0dd8ee63f9272
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jun 12 18:00:49 2020 +0200
drm/atomic-helper: reset vblank on crtc reset
this started to oops because now we're trying to derefence
drm_crtc->dev. Fix this up by entirely switching over to
drm_mode_config_reset, called once everything is set up.
Fixes:
51f644b40b4b ("drm/atomic-helper: reset vblank on crtc reset")
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Tested-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Dan Carpenter [Fri, 26 Jun 2020 10:39:59 +0000 (13:39 +0300)]
drm/vmwgfx: Fix two list_for_each loop exit tests
These if statements are supposed to be true if we ended the
list_for_each_entry() loops without hitting a break statement but they
don't work.
In the first loop, we increment "i" after the "if (i == unit)" condition
so we don't necessarily know that "i" is not equal to unit at the end of
the loop.
In the second loop we exit when mode is not pointing to a valid
drm_display_mode struct so it doesn't make sense to check "mode->type".
Fixes:
a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Dan Carpenter [Fri, 26 Jun 2020 10:34:37 +0000 (13:34 +0300)]
drm/vmwgfx: Use correct vmw_legacy_display_unit pointer
The "entry" pointer is an offset from the list head and it doesn't
point to a valid vmw_legacy_display_unit struct. Presumably the
intent was to point to the last entry.
Also the "i++" wasn't used so I have removed that as well.
Fixes:
d7e1958dbe4a ("drm/vmwgfx: Support older hardware.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Gustavo A. R. Silva [Wed, 17 Jun 2020 21:51:44 +0000 (16:51 -0500)]
drm/vmwgfx: Use struct_size() helper
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle and, audited and
fixed manually.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Dave Airlie [Tue, 11 Aug 2020 00:56:11 +0000 (10:56 +1000)]
Merge tag 'drm-misc-next-fixes-2020-08-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next-fixes for v5.9-rc1:
- Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi
- Fix a fbcon OOB read in fbdev, found by syzbot.
- Mark vga_tryget static as it's not used elsewhere.
- Small fixes to xlnx.
- Remove null check for kfree in drm_dev_release.
- Fix DRM_FORMAT_MOD_AMLOGIC_FBC definition.
- Fix mode initialization in omap_connector_mode_valid().
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b2043dad-f118-bd19-54a6-f23bf6264007@linux.intel.com
Sandeep Raghuraman [Thu, 6 Aug 2020 17:22:20 +0000 (22:52 +0530)]
drm/amdgpu: Fix bug where DPM is not enabled after hibernate and resume
Reproducing bug report here:
After hibernating and resuming, DPM is not enabled. This remains the case
even if you test hibernate using the steps here:
https://www.kernel.org/doc/html/latest/power/basic-pm-debugging.html
I debugged the problem, and figured out that in the file hardwaremanager.c,
in the function, phm_enable_dynamic_state_management(), the check
'if (!hwmgr->pp_one_vf && smum_is_dpm_running(hwmgr) && !amdgpu_passthrough(adev) && adev->in_suspend)'
returns true for the hibernate case, and false for the suspend case.
This means that for the hibernate case, the AMDGPU driver doesn't enable DPM
(even though it should) and simply returns from that function.
In the suspend case, it goes ahead and enables DPM, even though it doesn't need to.
I debugged further, and found out that in the case of suspend, for the
CIK/Hawaii GPUs, smum_is_dpm_running(hwmgr) returns false, while in the case of
hibernate, smum_is_dpm_running(hwmgr) returns true.
For CIK, the ci_is_dpm_running() function calls the ci_is_smc_ram_running() function,
which is ultimately used to determine if DPM is currently enabled or not,
and this seems to provide the wrong answer.
I've changed the ci_is_dpm_running() function to instead use the same method that
some other AMD GPU chips do (e.g Fiji), which seems to read the voltage controller.
I've tested on my R9 390 and it seems to work correctly for both suspend and
hibernate use cases, and has been stable so far.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208839
Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Evan Quan [Wed, 5 Aug 2020 09:24:41 +0000 (17:24 +0800)]
drm/amd/powerplay: put VCN/JPEG into PG ungate state before dpm table setup(V3)
As VCN related dpm table setup needs VCN be in PG ungate state. Same logics
applies to JPEG.
V2: fix paste typo
V3: code cosmetic
Signed-off-by: Evan Quan <evan.quan@amd.com>
Tested-by: Matt Coffin <mcoffin13@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Mon, 3 Aug 2020 03:15:14 +0000 (11:15 +0800)]
drm/amd/powerplay: update swSMU VCN/JPEG PG logics
Add lock protections and avoid unnecessary actions
if the PG state is already the same as required.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Tested-by: Matt Coffin <mcoffin13@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>