SOFT_SCRATCH(15) is used by GuC for sending MMIO GuC events to host and
those events are now handled by intel_guc_to_host_event_handler_mmio().
We should not try to read it on MMIO action error as 1) we may be using
different set of registers for GuC MMIO communication, and 2) GuC may
use CTB mechanism for sending events to host.
While here, upgrade error message to DRM_ERROR.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180528171618.10436-1-michal.wajdeczko@intel.com
Normally this is called on a modeset, but the call is missing when
we inherit the mode from the BIOS, so make sure it's called somewhere
in hardware readout.
Changes since v1:
- Unconditionally call intel_opregion_notify_encoder. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516085038.36785-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since we use i915_gem_find_active_request() from inside
intel_engine_dump() and may call that at any time, we do not guarantee
that the engine is paused nor that the signal kthreads and irq handler
are suspended, so we cannot assert that the breadcrumb doesn't advance
and that the irq hasn't happened on another CPU signaling the request we
believe to be idle.
The second assert removed (that request->engine == engine) remains
valid, but is now more rigorously checked during retirement.
Fixes: f636edb214 ("drm/i915: Make i915_engine_info pretty printer to standalone")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180529132922.6831-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
DPCD 2009h "Synchronization latency in sink" has bits that tell us the
maximum number of frames sink can take to resynchronize to source timing
when exiting PSR. More importantly, as per eDP 1.4b, this is the "Minimum
number of frames following PSR exit that the Source device needs to
wait for PSR entry."
We currently use this value only to setup the number frames to wait before
PSR2 selective update. But, based on the above description it makes more
sense to use this to configure idle frames for both PSR1 and and PSR2. This
will ensure we wait the required number of frames before
activation whether it is PSR1 or PSR2.
The minimum number of idle frames remains 6, while allowing sink
synchronization latency and VBT to increase this value.
This also solves the flip-flop between sink and source frames that I
noticed on my Thinkpad X260 during PSR exit. This specific panel has a
value of 8h, which according to the spec means the "Source device must
wait for more than eight active frames after PSR exit before initiating PSR
entry. (In this case, should be provided by the panel supplier.)" VBT
however has a value of 0.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525033047.7596-1-dhinakaran.pandiyan@intel.com
Enables blend optimization for floating point RTs
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
References: HSDES#1406393558
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527285939-20113-5-git-send-email-oscar.mateo@intel.com
Disable blend embellishment in RCC.
Also, some other registers style fixed in passing.
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
- Fixed in B0
- Mentioned style fixes in commit message
References: HSDES#2006665173
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527285939-20113-4-git-send-email-oscar.mateo@intel.com
Redirects the state cache to the CS Command buffer section for
performance reasons.
v2: Rebased
v3: Rebased on top of the WA refactoring
v3: Added References (Mika)
References: HSDES#1604325460
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527285939-20113-3-git-send-email-oscar.mateo@intel.com
Revert to the legacy implementation.
v2: GEN7_ROW_CHICKEN2 is masked
v3:
- Rebased
- Renamed to Wa_2006611047
- A0 and B0 only
v4:
- Add spaces around '<<' (and fix the surrounding code as well)
- Mark the WA as pre-prod
v5: Rebased on top of the WA refactoring
v6: Added References (Mika)
v7: Fixed in B0
References: HSDES#2006611047
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527285939-20113-2-git-send-email-oscar.mateo@intel.com
Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.
v2: don't forget about function descriptions (Sagar)
v3: rebased
v4: rebased
v5: rebased, pulled out from the series
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525121858.53928-1-michal.wajdeczko@intel.com
Let's suppress the underruns around every modeset sequence instead
of trying to avoid it. Planes are disabled at this point anyway so
we don't really gain anything from keeping the underrun reporting
enabled. Also for PCH ports we already suppress all underruns here
anyway so trying avoid it for the CPU eDP doesn't seem all that
important.
Maybe this gets rid of some lingering spurious underruns?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524190406.2973-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
VBT seems to have some bits to tell us whether the internal LVDS port
has something hooked up. In theory one might expect the VBT to not have
a child device for the LVDS port if there's no panel hooked up, but
in practice many VBTs still add the child device. The "LVDS config" bits
seem more reliable though, so let's check those.
So far we've used the "LVDS config" bits to check for eDP support on
ILK+, and disable the internal LVDS when the value is 3. That value
is actually documented as "Both internal LVDS and SDVO LVDS", but in
practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's
keep that interpretation, but for pre-ILK we will consider the value
3 to also indicate the presence of the internal LVDS.
Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an
effort to reduce that let's toss in a WARN when the DMI match and VBT
both tell us that the internal LVDS is not present. The hope is that
people will report a bug, and then we can just nuke the corresponding
entry from the DMI quirk list. Credits to Jani for this idea.
v2: Split the basic int_lvds_support thing to a separate patch (Jani)
v3: Rebase
v4: Limit this to VBT version >= 134
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518150138.18361-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
My ILK seems to generate a spurious PCH underrun with most interlaced
HDMI modes. Add a second vblank wait to avoid it.
We have seen some spurious PCH underruns still in CI as well, some
of which seem to be progressive DP. The logs also point towards some
spurious underrins with progressive HDMI on SNB. While I don't have
a solid explanation for those let's try to kill all the birds with one
stone and always do the double wait.
Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106387
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524190406.2973-1-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
We can always figure out which pipe is affected by the panel power
sequencer lockout mechanism. So no need for the pipe A fallback
anymore. The only case we may have to worry about is an invalid
port select in the power sequencer, but INVALID_PIPE is just fine
in that case. We'll get the WARN about the bogus pps port select
anyway.
Cc: Jani Nikula <jani.nikula@intel.com>
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523145718.22932-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
In order to prepare the GPU for sleeping, we may want to submit commands
to it. This is a complicated process that may even require some swapping
in from shmemfs, if the GPU was in the wrong state. As such, we need to
do this preparation step synchronously before the rest of the system has
started to turn off (e.g. swapin fails if scsi is suspended).
Fortunately, we are provided with a such a hook, pm_ops.prepare().
v2: Compile cleanup
v3: Fewer asserts, fewer problems?
v4: Ville pointed out that in some circumstances (such as switching off
the overlay) the display code may issue a GPU request. This is
unexpected, and will result in us going to sleep with us believing the
GPU is still awake (though all user work has been saved). Add a comment
to remind our future selves of what trouble brews.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Testcase: igt/drv_suspend after igt/gem_tiled_swapping
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525092629.1456-1-chris@chris-wilson.co.uk
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
After a reset, we will ensure that there is at least one request
submitted to HW to ensure that a context is loaded for powersaving.
Let's wait for this submission via a tasklet to complete before we drop
our forcewake, ensuring the system is ready for rc6 before we let it
possibly sleep.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522101937.7738-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
We were not very carefully checking to see if an older request on the
engine was an earlier switch-to-kernel-context before deciding to emit a
new switch. The end result would be that we could get into a permanent
loop of trying to emit a new request to perform the switch simply to
flush the existing switch.
What we need is a means of tracking the completion of each timeline
versus the kernel context, that is to detect if a more recent request
has been submitted that would result in a switch away from the kernel
context. To realise this, we need only to look in our syncmap on the
kernel context and check that we have synchronized against all active
rings.
v2: Since all ringbuffer clients currently share the same timeline, we do
have to use the gem_context to distinguish clients.
As a bonus, include all the tracing used to debug the death inside
suspend.
v3: Test, test, test. Construct a selftest to exercise and assert the
expected behaviour that multiple switch-to-contexts do not emit
redundant requests.
Reported-by: Mika Kuoppala <mika.kuoppala@intel.com>
Fixes: a89d1f921c ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524081135.15278-1-chris@chris-wilson.co.uk
While touching the code around this, I noticed that absence of ALPM
capability does not stop us from enabling PSR2. But, the spec
unambiguously states that ALPM is required for PSR2 and so does this
commit that introduced this code
drm/i915/psr: enable ALPM for psr2
As per edp1.4 spec , alpm is required for psr2 operation as it's
used for all psr2 main link power down management and alpm enable
bit must be set for psr2 operation.
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Tarun Vyas <tarun.vyas@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-6-dhinakaran.pandiyan@intel.com
Noticed that we assume the best case of 0 latency when the DPCD read
fails, reasonable pessimism is safer.
eDP spec does say that if latency is greater than 8, the panel
supplier needs to provide it. I didn't see anything specific in the VBT
for this, so let's go with 8 frames as a fallback.
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-5-dhinakaran.pandiyan@intel.com
By moving the check from psr_compute_config() to psr_init_dpcd(), we get
to set the dev_priv->psr.sink_support flag only when the panel is
capable of changing power state. An additional benefit is that the check
will be performed only at init time instead of every atomic_check.
This should change the psr_basic IGT failures on HSW to skips.
v2: Return early when SET_POWER_CAPABLE bit is 0 (Jose)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106217
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106346
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-2-dhinakaran.pandiyan@intel.com
Ville noticed that we are unncessarily reading DPCD's after knowing
panel did not support PSR. Looks like this check that was present
earlier got removed unintentionally, let's put it back.
While we do this, add the PSR version number in the debug print.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Tarun Vyas <tarun.vyas@intel.com>
Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-1-dhinakaran.pandiyan@intel.com
PSR hardware and hence the driver code for VLV and CHV deviates a lot from
their DDI counterparts. While the feature has been disabled for a long time
now, retaining support for these platforms is a maintenance burden. There
have been multiple refactoring commits to just keep the existing code for
these platforms in line with the rest. There are known issues that need to
be fixed to enable PSR on these platforms, and there is no PSR capable
platform in CI to ensure the code does not break again if we get around to
fixing the existing issues. On account of all these reasons, let's nuke
this code for now and bring it back if a need arises in the future.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511230059.19387-1-dhinakaran.pandiyan@intel.com
For psr block #9, the vbt description has moved to options [0-3] for
TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
structure. Since spec does not mention from which VBT version this
change was added to vbt.bsf file, we cannot depend on bdb->version check
to change for all the platforms.
There is RCR inplace for GOP team to provide the version number
to make generic change. Since Kabylake with bdb version 209 is having this
change, limiting this change to gen9_bc and version 209+ to unblock google.
Tested on skl(bdb version 203,without options) and
kabylake(bdb version 209,212) having new options.
bspec 20131
v2: (Jani and Rodrigo)
move the 165 version check to intel_bios.c
v3: Jani
Move the abstraction to intel_bios.
v4: Jani
Rename tp*_wakeup_time to have "us" suffix.
For values outside range[0-3],default to max 2500us.
Old decimal value was wake up time in multiples of 100us.
v5: Jani and Rodrigo
Handle option 2 in default condition.
Print oustide range value.
For negetive values default to 2500us.
v6: Jani
Handle default first and then fall through for case 2.
v7: Rodrigo
Apply this change for IS_GEN9_BC and vbt version > 209
v8: Puthik
Add new function vbt_psr_to_us.
v9: Jani
Change to v7 version as it's more readable.
DK
add comment /*fall through*/ after case2.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Puthikorn Voravootivat <puthik@chromium.org>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526981243-2745-1-git-send-email-vathsala.nagaraju@intel.com
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 instead of correct values.
However, this is not going to be the case in any production silicon.
Therefore, we only check at initialization and issue a warning should
this really happen.
References: HSDES#1405586840
v2:
- use fls instead of find_last_bit (Chris)
- use is_power_of_2() instead of counting bit set (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Move local variable into scope where they are used (Ursulin)
- use a new local variable to reduce long line of code (Ursulin)
v6:
- Some coding style and use more local variables for clearer
logic (Ursulin)
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683285-24861-1-git-send-email-yunwei.zhang@intel.com
WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Icelake as
well.
References: HSD#1405586840, BSID#0575
v2:
- GEN11 mask is different from its predecessors. (Oscar)
- Better separate GEN10 and GEN11. (Oscar)
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683232-24753-1-git-send-email-yunwei.zhang@intel.com
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice/subslice pair. Otherwise, incorrect value will be returned.
However, that means each subsequent MMIO read will be forwarded to a
specific slice/subslice combination as read is unicast. This is OK since
slice/subslice specific register values are consistent in almost all cases
across slice/subslice. There are rare occasions such as INSTDONE that this
value will be dependent on slice/subslice combo, in such cases, we need to
program 0xFDC and recover this after. This is already covered by
read_subslice_reg.
Also, 0xFDC will lose its information after TDR/engine reset/power state
change.
References: HSD#1405586840, BSID#0575
v2:
- use fls() instead of find_last_bit() (Chris)
- added INTEL_SSEU to extract sseu from device info. (Chris)
v3:
- rebase on latest tip
v5:
- Added references (Mika)
- Change the ordered of passing arguments and etc. (Ursulin)
v7:
- Moved WA explanation Comments(Oscar)
- Rebased.
v8:
- Renamed sanitize_mcr to calculate_s_ss_select. (Oscar)
- calculate s/ss selector instead of whole mcr. (Oscar)
v9:
- Updated function name (Oscar)
- Remove redundant variables (Oscar)
v10:
- Separate pre-GEN10 and GEN11 mask. (Oscar)
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526683197-24656-1-git-send-email-yunwei.zhang@intel.com
'Pipe CSC enable' bit is more than just deprecated in ICL+, it was
disabled in commit 077ef1f09c ("drm/i915/icl: Don't set pipe
CSC/Gamma in PLANE_COLOR_CTL") for primary and sprite planes as it was
causing those planes to be rendered as always black but it was not
disabled in cursor plane, also causing it to be rendered as black.
As mentioned in the commit referenced above, this is a workaround
too and the CSC and gamma per plane values needs to be setup before
enable CSC and gamma again.
BSpec: 4278 and 7635
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518201547.15793-1-jose.souza@intel.com
The power sequencer has bits to allow DP C to be used for eDP.
Currently we assume this will never happen, but I guess it could
theoretically be a thing. Make the code do the right thing in that
case, and toss in a MISSING_CASE() for any other port.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Clean up the DP pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state(),
the port state asserts, and the VLV power sequencer code.
v2: Return PIPE_A for cpt/ppt when the port isn't selected by
any transcoder. Returning INVALID_PIPE explodes *somewhere*
on some machines (can't immediately see where though). This
now matches the old behaviour.
v3: Order the defines shift,mask,value (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic
drivers. Let's throw out intel_trans_dp_port_sel() and replace it
with intel_get_crtc_new_encoder() which looks the atomic state instead.
Since we now have to call intel_get_crtc_new_encoder() during the commit
phase we'll need to plumb in the top level atomic state. The
crtc_state->state pointers are no longer valid at that point.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
nospec quite reasonably asserts that it will never be used with an index
larger than unsigned long (that being the largest possibly index into an
C array). However, our ubi uses the convention of u64 for any large
integer, running afoul of the assertion on 32b. Reduce our index to an
unsigned long, checking for type overflow first.
drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
Reported-by: kbuild-all@01.org
Fixes: 84b510e22d ("drm/i915/query: Protect tainted function pointer lookup")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522121018.15199-1-chris@chris-wilson.co.uk
Replace dev_priv->vbt.edp.support with
dev_priv->vbt.int_lvds_support. We'll want to extend its
use beyond the LVDS vs. eDP case in the future.
v2: Nuke the edp.support from parse_edp() (Jani)
Only clear int_lvds_support for gen5+ to preserve
the current behaviour (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508140814.20105-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
As we handle the allocation failure of the page directory and tables by
propagating the failure back to userspace, allow it to fail if direct
reclaim is unable to satisfy the request (i.e. disable the oomkiller).
The premise being that if we are unable to allocate a single page for
the pagetable, we will not be able to handle the multitude of pages
required for the gfx operation and we should back off to allow the
system to recover.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106609
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522083643.29601-1-chris@chris-wilson.co.uk
Smatch identifies i915_query_ioctl() as being a potential victim of
Spectre due to its use of a tainted user index into a function pointer
array. Use array_index_nospec() to defang the user index before using it
to lookup the function pointer.
Fixes: a446ae2c6e ("drm/i915: add query uAPI")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521210530.26008-1-chris@chris-wilson.co.uk
This reverts commit dc911f5bd8.
Per the report, no matter what display mode you select with xrandr, the
i915 driver will always select the alternate fixed mode. For the
reporter this means that the display will always run at 40Hz which is
quite annoying. This may be due to the mode comparison.
But there are some other potential issues. The choice of alt_fixed_mode
seems dubious. It's the first non-preferred mode, but there are no
guarantees that the only difference would be refresh rate. Similarly,
there may be more than one preferred mode in the probed modes list, and
the commit changes the preferred mode selection to choose the last one
on the list instead of the first.
(Note that the probed modes list is the raw, unfiltered, unsorted list
of modes from drm_add_edid_modes(), not the pretty result after a
drm_helper_probe_single_connector_modes() call.)
Finally, we already have eerily similar code in place to find the
downclock mode for DRRS that seems like could be reused here.
Back to the drawing board.
Note: This is a hand-crafted revert due to conflicts. If it fails to
backport, please just try reverting the original commit directly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469
Reported-by: Rune Petersen <rune@megahurts.dk>
Reported-by: Mark Spencer <n7u4722r35@ynzlx.anonbox.net>
Fixes: dc911f5bd8 ("drm/i915/edp: Allow alternate fixed mode for eDP if available.")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nikula@intel.com
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@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
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-2-daniels@collabora.com
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@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
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-1-daniels@collabora.com
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.
v2: Move request alloc earlier as already try to track shadow status
depending on request state, which also facilitate to use request->hw_context
for target engine context reference.
Fixes: 1fc44d9b1a ("drm/i915: Store a pointer to intel_context in i915_request")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.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/20180521081752.31056-1-zhenyuw@linux.intel.com
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active timeouts are the same, it is hard to distinguish
which caused the timeout. Bump the active thread timeouts to 5s,
compared to the 1s timeout for the hang, so that we preferentially
report the hang timing out, while hopefully ensuring that we do at least
wake up the hang thread first before declaring the background active
timeout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517142442.16979-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
