Hans de Goede [Thu, 3 Sep 2020 11:23:27 +0000 (13:23 +0200)]
pwm: lpss: Remove suspend/resume handlers
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.
The only in kernel consumers of the pwm-lpss code, the i915 driver
and the pwm-class sysfs interface code both correctly restore the
state on resume, so there is no need to do this in the pwm-lpss code.
More-over the removed resume handler is buggy, since it blindly
restores the ctrl-register contents without setting the update
bit, which is necessary to get the controller to actually use/apply
the restored base-unit and on-time-div values.
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.
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.
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).
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
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.
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.
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.
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.
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.]
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
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.
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.
Sean Paul [Tue, 18 Aug 2020 15:38:59 +0000 (11:38 -0400)]
drm/i915: Use ddi_update_pipe in intel_dp_mst
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
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.
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.
Sean Paul [Tue, 18 Aug 2020 15:38:54 +0000 (11:38 -0400)]
drm/i915: Factor out hdcp->value assignments
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
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.
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.
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!
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.
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: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.
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.
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.
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).
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.
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>
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.
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.
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.
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.
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.
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.
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>
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.
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.
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)
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.
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.
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).
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.
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
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.
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>
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().
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.
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>
projects / users / jedix / linux-maple.git / log