Matthew Auld [Mon, 29 Oct 2018 20:37:34 +0000 (20:37 +0000)]
drm/i915/selftest: test aligned offsets for 64K
When using softpin it's not enough to just pad the vma size, we also
need to ensure the vma offset is at the start of the pt boundary, if we
plan to utilize 64K pages. Therefore to improve test coverage we should
use both aligned and unaligned gtt offsets in igt_write_huge.
Checked GVT codes that guest PPGTT PTE flag bits are propagated
to shadow PTE. Read/write bit is not changed. Further tested by
i915 self-test case "igt_ctx_readonly". No error or GPU hang was
detected. So enable read-only support under GVT.
Animesh Manna [Mon, 29 Oct 2018 22:14:10 +0000 (15:14 -0700)]
drm/i915/icl: Enable DC9 as lowest possible state during screen-off
ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable
DC5/6 when appropriate.
v2: (James Ausmus)
- Also handle ICL as GEN9_LP in i915_drm_suspend_late and
i915_drm_suspend_early
- Add DC9 to gen9_dc_mask for ICL
- Re-order GEN checks for newest platform first
- Use INTEL_GEN instead of INTEL_INFO->gen
- Use INTEL_GEN >= 11 instead of IS_ICELAKE
- Consolidate GEN checks
v3: (James Ausmus)
- Also allow DC6 for ICL (Imre, Art)
- Simplify !(GEN >= 11) to GEN < 11 (Imre)
v4: (James Ausmus)
- Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
PPS regs are Always On
- Rebase against upstream changes
v5: (Anusha Srivatsa)
- rebased against the latest upstream changes.
Chris Wilson [Tue, 30 Oct 2018 11:05:54 +0000 (11:05 +0000)]
drm/i915: Stop calling intel_opregion unregister/register in suspend/resume
If we reduce the suspend function for intel_opregion to do the minimum
required, the resume function can also do the simple task of notifier
the ACPI bios that we are back. This avoid some nasty restrictions on
the likes of register_acpi_notifier() that are not allowed during the
early phase of resume.
v2: Keep the order of acpi notify vs turning off ardy/drdy the same.
Chris Wilson [Mon, 29 Oct 2018 18:27:21 +0000 (18:27 +0000)]
drm/i915/gtt: Reuse the read-only 64KiB scratch page and directories
If we can prevent stray writes from landing in the scratch page, we can
reuse the same page and same scratch PT for all contexts without fear of
information leaks and side-channels.
Chris Wilson [Mon, 29 Oct 2018 18:27:20 +0000 (18:27 +0000)]
drm/i915/gtt: Record the scratch pte
Record the scratch PTE encoding upon creation rather than recomputing
the bits everytime. This is important for the next patch where we forgo
having a valid scratch page with which we may compute the bits and so
require keeping the PTE value instead.
intel_fb_pitch_limit() has the parameters pixel_format and fb_modifier
switched in their positions. The parameters are however used correctly,
but change the order for consistency.
drm/i915: Add function to check for linear surfaces
A framebuffer can comprise surfaces with distinct tiling formats,
making checks against modifier alone insufficient. Make use of a
function to identify a linear surface based on both modifier and color
plane.
v2: Typo fix
v3: remove 'inline' from function definition (Ville)
Rodrigo Vivi [Fri, 26 Oct 2018 20:03:17 +0000 (13:03 -0700)]
drm/i915: Simplify has_sagv function
The specially case for SKL for not controlled sagv
is already taken care inside intel_enable_sagv, so there's
no need to duplicate the check here.
v2: Go one step further and remove skl special case. (Jani)
v3: Separate runtime status handle from has_sagv flag.
v4: Go back and accept simple Jani proposed solution.
Chris Wilson [Mon, 29 Oct 2018 17:29:25 +0000 (17:29 +0000)]
drm/i915/selftests: Test vm isolation
The vm of two contexts are supposed to be independent, such that a stray
write by one cannot be detected by another. Normally the GTT is filled
explicitly by userspace, but the space in between objects is filled with
a scratch page -- and that scratch page should not be able to form an
inter-context backchannel.
Rodrigo Vivi [Fri, 26 Oct 2018 19:51:43 +0000 (12:51 -0700)]
drm/i915: Kill GEN_FOREVER
commit ac657f6461e5 ("drm/i915: Introduce IS_GEN macro") introduced
GEN_FOREVER that was never used.
My first attempt was to rename it to FOREVER since GEN is
already part of the macro. Then I used coccinelle to change all
-INTEL_GEN(e1) >= e2
+INTEL_GEN_RANGE(e1, e2, FOREVER)
-INTEL_GEN(e1) <= e2
+INTEL_GEN_RANGE(e1, 0, e2)
and I liked it.
However I didn't like very much the remaining
INTEL_GEN(dev_priv) < n
and:
INTEL_GEN(e1) < n
INTEL_GEN_RANGE(e1, 0, n - 1)
didn't make much sense either.
So INTEL_GEN use for > or < seems a better unified way for unlimited
bounds. So, no reason to keep GEN_FOREVER here.
Let's kill before someone start using it.
v2: Remove remaining GEN_FOREVER forgotten in a comment. (Daniel)
Ramalingam C [Mon, 29 Oct 2018 09:45:51 +0000 (15:15 +0530)]
drm/i915: Define Intel HDCP2.2 registers
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
v3:
No changes.
v4:
%s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
v5:
Added parentheses for the parameters of macro.
v6:
No changes
v7:
No changes
Ramalingam C [Mon, 29 Oct 2018 09:45:50 +0000 (15:15 +0530)]
drm: HDMI and DP specific HDCP2.2 defines
This patch adds HDCP register definitions for HDMI and DP HDCP
adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where as HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field definitions are replaced by macros. [Tomas and Jani]
v3:
No Changes.
v4:
Comments style and typos are fixed [Uma]
v5:
Fix for macros.
v6:
Adds _MS to the timeouts to represent units [Sean Paul]
v7:
Macro DP_HDCP_2_2_REG_EKH_KM_OFFSET renamed [Uma]
Redundant macro is removed [Uma]
Ramalingam C [Mon, 29 Oct 2018 09:45:49 +0000 (15:15 +0530)]
drm: hdcp2.2 authentication msg definitions
This patch defines the hdcp2.2 protocol messages for authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
No Changes.
v4:
Style and spellings are fixed [Uma]
v5:
Fix for macros.
v6:
comment for Type is improved [Sean Paul]
v7:
%s/HDCP_2_2_LPRIME_HALF_LEN/HDCP_2_2_V_PRIME_HALF_LEN [Uma]
%s/uintxx_t/uxx
v8:
%s/eceiver_id/receiver_id
Ramalingam C [Mon, 29 Oct 2018 09:45:47 +0000 (15:15 +0530)]
drm/i915: Reassigning log level for HDCP failures
As a policy, this change considers all I915 programming failures and
HW failures as ERRORS. Where as all HDCP failures due to the sink is
considered as DEBUG logs.
Ramalingam C [Mon, 29 Oct 2018 09:45:46 +0000 (15:15 +0530)]
drm/i915: wrapping all hdcp var into intel_hdcp
Considering significant number of HDCP specific variables, it will
be clean to have separate struct for HDCP.
New structure called intel_hdcp is added within intel_connector.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
v3:
No Changes.
v4:
Commit msg is rephrased [Uma]
v5:
Comment for mutex definition.
v6:
hdcp_ prefix from all intel_hdcp members are removed [Sean Paul]
inline function intel_hdcp_to_connector is defined [Sean Paul]
v7:
%s/uint64_t/u64
v8:
Rebased
Chris Wilson [Wed, 24 Oct 2018 10:49:39 +0000 (11:49 +0100)]
drm/i915: Park signaling thread while wrapping the seqno
A danger encountered when resetting the seqno (using
debugfs/i915_next_seqno) is that as we change the breadcrumb stored in
the HWSP, it may be inspected by the signaler thread leading to
confusion in our sanity checks.
Chris Wilson [Fri, 12 Oct 2018 12:24:04 +0000 (13:24 +0100)]
drm/i915/selftests: Check for hangs mid context execution tests
Use the live_test struct to record the reset count before and compare it
at the end of the test to assert that no mystery hang occurred during the
test.
Chris Wilson [Thu, 25 Oct 2018 09:18:22 +0000 (10:18 +0100)]
drm/i915: Mark up GTT sizes as u64
Since we use a 64b virtual GTT irrespective of the system, we want to
ensure that the GTT computations remains 64b even on 32b systems,
including treatment of huge virtual pages.
No code generation changes on 64b:
Reported-by: Sergii Romantsov <sergii.romantsov@globallogic.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108282 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181025091823.20571-1-chris@chris-wilson.co.uk
Imre Deak [Tue, 23 Oct 2018 14:43:10 +0000 (17:43 +0300)]
drm/i915: Ensure proper HDA suspend/resume ordering with a device link
In order to ensure that our system suspend and resume callbacks are
called in the correct order wrt. those of the HDA driver add a device
link to the HDA driver during audio component binding time. With i915 as
the supplier and HDA as the consumer the PM framework will guarantee
the HDA->i915 suspend (and shutdown) and i915->HDA resume order.
Atm, the lack of this ordering is not a problem, since all the i915
suspend/resume steps that need to be ordered wrt. the HDA driver's
suspend/resume steps are separated out to the i915
suspend_late/resume_early hooks. That will change in a follow-up
patchset where we'll need this ordering guarantee for steps that are in
the i915 suspend/resume hooks (and which can't be moved to
suspend_late/resume_early for other reasons). So this patch is a
preparation for that follow-up patchset.
The change also allows us to move towards removing the i915
suspend_late/resume_early hooks alltogether.
Since we only need to ensure the ordering during suspend/resume and not
during driver probing create the link with DL_FLAG_STATELESS. Since the
probe time ordering has to be optional we use the component framework
for that.
Similarly for runtime PM we depend on the audio driver getting/putting
an i915 runtime PM reference whenever it needs it (along with the proper
i915 display power domain) via the audio component ops get_power /
put_power hooks. So we create the device link without
DL_FLAG_PM_RUNTIME.
v2: (Ville)
- Add a note to the commit message about not using the device link
runtime PM ordering.
- Handle the error return from device_link_add().
Chris Wilson [Wed, 24 Oct 2018 10:54:02 +0000 (11:54 +0100)]
drm/i915: Mark skl_update_plane and skl_disable_plane as static
make W=1 caught the implicit prototypes (as would sparse):
drivers/gpu/drm/i915/intel_sprite.c:462:1: error: no previous prototype for ‘skl_update_plane’ [-Werror=missing-prototypes]
skl_update_plane(struct intel_plane *plane,
^~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/intel_sprite.c:487:1: error: no previous prototype for ‘skl_disable_plane’ [-Werror=missing-prototypes]
skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc)
^~~~~~~~~~~~~~~~~
Fixes: 1e364f9008a7 ("drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181024105402.18915-1-chris@chris-wilson.co.uk
Ville Syrjälä [Tue, 23 Oct 2018 18:21:02 +0000 (21:21 +0300)]
drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLK
The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to
the appropriate platforms.
This was especially harsh on GLK since we don't even try to read
the DIMM information on that platforms, hence valid_dimm was
always false and thus we always tried to apply the w/a.
Furthermore the w/a pushed the level 0 latency above the
level 1 latency, which doesn't really make sense.
v2: Do the check when populating is_16gb_dimm (Mahesh)
drm/i915/gen11: Program the Y and UV plane for planar mode correctly, v3.
The UV plane is the master plane that does all color correction etc.
It needs to be programmed with the dimensions for color plane 1 (UV).
The Y plane just feeds the Y pixels to it. Program the scaler from the
master only, and set PLANE_CTL_YUV420_Y_PLANE on the slave plane.
Changes since v1:
- Make a common skl_program_plane, and use it for both plane updates.
Changes since v2:
- Make color_plane explicit, to clarify skl_update_plane(). (Ville)
drm/i915/gen11: Program the chroma upsampler for HDR planes.
We configure the chroma upsampler with the same chroma siting as
used by the scaler for consistency, the chroma upsampler is used
instead of the scaler for YUV 4:2:0 on ICL's HDR planes.
drm/i915/gen11: Program the scalers correctly for planar formats, v3.
The first 3 planes (primary, sprite 0 and 1) have a dedicated chroma
upsampler to upscale YUV420 to YUV444 and the scaler should only be
used for upscaling. Because of this we shouldn't program the scalers
in planar mode if NV12 and the chroma upsampler are used. Instead
program the scalers like on normal planes.
Sprite 2 and 3 have no dedicated scaler, and need to program the
selected Y plane in the scaler mode.
Changes since v1:
- Make the comment less confusing.
Changes since v2:
- Fix checkpatch warning (Matt)
- gen10- -> Pre-gen11 (Ville)
- PS_SCALER_MODE_PACKED -> PS_SCALER_MODE_NORMAL. (Matt)
- Add comment about scaler mode in intel_atomic_setup_scaler(). (Matt)
- Rename need_scaling to need_scaler. (Matt)
- Move the crtc need_scaling check to skl_update_scaler_crtc().
drm/i915/gen11: Handle watermarks correctly for separate Y/UV planes, v2.
Skylake style watermarks program the UV parameters into wm->uv_wm,
and have a separate DDB allocation for UV blocks into the same plane.
Gen11 watermarks have a separate plane for Y and UV, with separate
mechanisms. The simplest way to make it work is to keep the current
way of programming watermarks and calculate the Y and UV plane
watermarks from the master plane.
Changes since v1:
- Constify crtc_state where possible.
- Make separate paths for planar formats in skl_build_pipe_wm() (Matt)
- Make separate paths for calculating total data rate. (Matt)
- Make sure UV watermarks are unused on gen11+ by adding a WARN. (Matt)
drm/i915/gen11: Link nv12 Y and UV planes in the atomic state, v5.
To make NV12 working on icl, we need to update 2 planes simultaneously.
I've chosen to do this in the CRTC step after plane validation is done,
so we know what planes are (in)visible. The linked Y plane will get
updated in intel_plane_update_planes_on_crtc(), by the call to
update_slave, which gets the master's plane_state as argument.
The link requires both planes for atomic_update to work,
so make sure skl_ddb_add_affected_planes() adds both states.
Changes since v1:
- Introduce icl_is_nv12_y_plane(), instead of hardcoding sprite numbers.
- Put all the state updating login in intel_plane_atomic_check_with_state().
- Clean up changes in intel_plane_atomic_check().
Changes since v2:
- Fix intel_atomic_get_old_plane_state() to actually return old state.
- Move visibility changes to preparation patch.
- Only try to find a Y plane on gen11, earlier platforms only require
a single plane.
Changes since v3:
- Fix checkpatch warning about to_intel_crtc() usage.
- Add affected planes from icl_add_linked_planes() before check_planes(),
it's a cleaner way to do this. (Ville)
Changes since v4:
- Clear plane links in icl_check_nv12_planes() for clarity.
- Only pass crtc_state to icl_check_nv12_planes().
- Use for_each_new_intel_plane_in_state() in icl_check_nv12_planes.
- Rename aux to linked. (Ville)
Ville Syrjälä [Thu, 18 Oct 2018 19:59:21 +0000 (22:59 +0300)]
drm/i915: Move the SKL+ zero constant alpha handling
Let's run through the entire plane check even when the plane
is invisible due to zero constant alpha. This makes for more
consistent behaviour since we check the src/dst coordinates,
stride etc. against the hardware limits.
Ville Syrjälä [Thu, 18 Oct 2018 19:59:20 +0000 (22:59 +0300)]
drm/i915: Relocate SKL+ NV12 src width w/a
The SKL+ NV12 src width alignment w/a is still living in an odd place.
Everything else was already relocated closer to the main plane check
function. Move this workaround as well.
As a bonus we avoid the funky rotated vs. not mess with the src
coordinates as this now gets checked before we rotate the coordinates.
drm/i915/perf: add a parameter to control the size of OA buffer
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.
v2: Simplify oa buffer size exponent selection (Chris)
Reuse vma size field (Lionel)
v3: Restrict size opening parameter to values supported by HW (Chris)
v4: Drop out of date comment (Matt)
Add debug message when buffer size is rejected (Matt)
drm/i915/perf: remove redundant oa buffer initialization
We initialize the OA buffer everytime we enable the OA unit (first call in
gen[78]_oa_enable), so we don't need to initialize when preparing the metric
set.
commit e346a991f42c ("drm/i915/guc: drop negative doorbell alloc
selftest") removed the negative case from the selftest and left no
code between the goto from the positive case of the test and the label
itself, so we can get rid of it.
Reported-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181022230427.5616-5-daniele.ceraolospurio@intel.com
drm/i915/guc: fix comment about fallback to execlists
We stopped supporting fallback to execlists in commit 121981fafe69
(drm/i915/guc: Combine enable_guc_loading|submission modparams). We
do instead reset and retry in some cases, depending on the workarounds
required by the platform.
A collection of very small cleanups/improvements around doorbell checking
that do not deserve their own patch:
- Move doorbell-related HW defs to intel_guc_reg.h
- use GUC_NUM_DOORBELLS instead of GUC_DOORBELL_INVALID where
appropriate
- do not stop on error in guc_verify_doorbells
- do not print drbreg on error: the only content of the register
apart from the valid bit is the lower part of the physical memory
address, which we can't use even if valid because we don't know
which descriptor it came from (since the doorbell is in an unexpected
state)
- Move the checking of doorbell valid bit to a common helper.
v2: add more cleanups (move defs, use GUC_NUM_DOORBELLS, don't stop in
guc_verify_doorbells) (Michal)
v3: move more things to intel_guc_reg, redefine
GUC_DOORBELL_INVALID (Michal), drop guc_doorbell_qw since it just
duplicates guc_doorbell_info
Just sorting this "if" block from newer to older platform.
The main difference here is the addition of a
missing case with return false that should never occur.
And if it occurs it is better than to raise a warn
than use the icl one.
The gen >= 11 was already present in the previous logic,
although hidden.
Madhav Chauhan [Mon, 15 Oct 2018 14:28:04 +0000 (17:28 +0300)]
drm/i915/icl: Define TRANS_CONF register for DSI
This patch defines TRANS_CONF registers for DSI ports
0 and 1. Bitfields of these registers used for enabling
and reading the current state of transcoder.
v2: Add blank line before comment
v3 by Jani:
- Move DSI specific .pipe_offsets to GEN11_FEATURES
- Macro placement and comment juggling
Madhav Chauhan [Mon, 15 Oct 2018 14:28:03 +0000 (17:28 +0300)]
drm/i915/icl: Configure DSI transcoder timings
As part of DSI enable sequence, transcoder timings
(horizontal & vertical) need to be set so that transcoder
will generate the stream output as per those timings.
This patch set required transcoder timings as per BSPEC.
v2: Remove TRANS_TIMING_SHIFT usage
v3 by Jani:
- Rebase
- Reduce temp variable use
- Checkpatch fix
This patch defines TRANS_DDI_FUNC_CTL and TRANS_DDI_FUNC_CTL2
registers and their bitfields for DSI. These registers are used
for enabling port sync mode, input pipe select, data lane width
configuration etc.
v2: Changes:
- Remove redundant extra line
- Correct some of bitfield definition
v3 by Jani:
- Move DSI transcoder offsets to GEN11_FEATURES
Michal Wajdeczko [Fri, 19 Oct 2018 10:17:24 +0000 (10:17 +0000)]
drm/i915/guc: Limit number of scratch registers used for H2G
We wrongly assumed that GuC is only using last scratch register
for G2H messages, but in fact it is also using register [14] to
report sleep state status. Remove that register from our H2G
send registers pool.
v2: No message from host to GuC uses more than 8 registers and
the GuC FW itself uses an 8-element array to store the H2G message,
so we may reduce our send array to just 8 registers (Daniele)
v3: use explicit define (Daniele)
v4: and explicit comment (Daniele)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181019101725.14024-1-michal.wajdeczko@intel.com
Madhav Chauhan [Mon, 15 Oct 2018 14:27:59 +0000 (17:27 +0300)]
drm/i915/icl: Configure DSI transcoders
This patch programs DSI operation mode, pixel format,
BGR info, link calibration etc for the DSI transcoder.
This patch also extract BGR info of the DSI panel from
VBT and save it inside struct intel_dsi which used for
configuring DSI transcoder.
v2: Rebase
v3: Use newly defined bitfields.
v4 by Jani:
- Use intel_dsi_bitrate()
- Make bgr_enabled bool
- Use 0 instead of 0x0
- Replace DRM_ERROR() with MISSING_CASE() on pixel format and video mode
- Use is_vid_mode()
Madhav Chauhan [Mon, 15 Oct 2018 14:27:55 +0000 (17:27 +0300)]
drm/i915/icl: Program TA_TIMING_PARAM registers
This patch programs D-PHY timing parameters for the
bus turn around flow(in escape clocks) only if dsi link
frequency <=800 MHz using DPHY_TA_TIMING_PARAM and its
identical register DSI_TA_TIMING_PARAM (inside DSI
Controller within the Display Core).
v2: Changes
- Don't use KHz() macro (Ville/Jani N)
- Use newly defined bitfields
v3 by Jani:
- Use intel_dsi_bitrate() in favor of a new field
- Remove redundant parens
Madhav Chauhan [Mon, 15 Oct 2018 14:27:54 +0000 (17:27 +0300)]
drm/i915/icl: Program DSI clock and data lane timing params
This patch programs D-PHY timing parameters for the
clock and data lane (in escape clocks) of DSI
controller (DSI port 0 and 1).
These programmed timings would be used by DSI Controller
to calculate link transition latencies of the data and
clock lanes.
v2: Use newly defined bitfields for data and clock lane
v3 by Jani:
- Rebase on dphy abstraction
- Reduce local variables
- Remove unrelated comment changes (Ville)
- Use the same style for range checks as VLV (Ville)
- Assign, don't OR dphy_reg contents
Xiong Zhang [Thu, 18 Oct 2018 05:40:31 +0000 (13:40 +0800)]
drm/i915: Add ppgtt to GVT GEM context
Currently the guest couldn't boot up under GVT-g environment as the
following call trace exists:
[ 272.504762] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
[ 272.504834] Call Trace:
[ 272.504852] execlists_context_pin+0x2b2/0x520 [i915]
[ 272.504869] intel_gvt_scan_and_shadow_workload+0x50/0x4d0 [i915]
[ 272.504887] intel_vgpu_create_workload+0x3e2/0x570 [i915]
[ 272.504901] intel_vgpu_submit_execlist+0xc0/0x2a0 [i915]
[ 272.504916] elsp_mmio_write+0xc7/0x130 [i915]
[ 272.504930] intel_vgpu_mmio_reg_rw+0x24a/0x4c0 [i915]
[ 272.504944] intel_vgpu_emulate_mmio_write+0xac/0x240 [i915]
[ 272.504947] intel_vgpu_rw+0x22d/0x270 [kvmgt]
[ 272.504949] intel_vgpu_write+0x164/0x1f0 [kvmgt]
GVT GEM context is created by i915_gem_context_create_gvt() which
doesn't allocate ppgtt. So GVT GEM context structure doesn't have
a valid i915_hw_ppgtt.
This patch create ppgtt table at GVT GEM context creation, then assign
shadow ppgtt's root table address to this ppgtt when shadow ppgtt will
be used on GPU. So GVT GEM context has valid ppgtt address. But note
that this ppgtt only contain valid ppgtt root table address, the table
entry in this ppgtt structure are invalid.
Fixes:4a3d3f6785be("drm/i915: Match code to comment and enforce ppgtt for execlists")
Ville Syrjälä [Tue, 16 Oct 2018 15:04:13 +0000 (18:04 +0300)]
drm/i915: Use i915_gem_object_get_dma_address() to populate rotated vmas
Replace the kvmalloc_array() with i915_gem_object_get_dma_address() when
populating rotated vmas. One random access mechanism ought to be enough
for everyone?
To calculate the size of the radix tree I think we can do
something like this (assuming 64bit pointers):
num_pages = obj_size / 4096
tree_height = ceil(log64(num_pages))
num_nodes = sum(64^n, n, 0, tree_height-1)
tree_size = num_nodes * 576
If we compare that with the object size we should get a relative
overhead of around .2% to 1% for reasonable sized objects,
which framebuffers tend to be.
Joonas Lahtinen [Thu, 18 Oct 2018 09:20:25 +0000 (12:20 +0300)]
drm/i915: Drop rpm wakeref on error in debugfs/i915_drop_caches_set
Use single exit point to drop rpm wakeref in case of an error.
Fixes: 9d3eb2c33f03 ("drm/i915: Hold rpm wakeref for debugfs/i915_drop_caches_set") Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181018092025.24076-1-joonas.lahtinen@linux.intel.com
drm/i915/guc: drop negative doorbell alloc selftest
The test requires driver tweaks to avoid causing error messages
on intentionally-triggered errors and to stop accessing non
existing register. However, this is a pure GuC FW interface test
and should be covered by FW validation, so it isn't really worth
tweaking the driver for it and we're better off dropping it instead.
Testing the driver running out of doorbells is already covered by
igt_guc_doorbells
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181018004610.22895-1-daniele.ceraolospurio@intel.com
Jani Nikula [Mon, 15 Oct 2018 14:27:51 +0000 (17:27 +0300)]
drm/i915/dsi: abstract dphy parameter init
intel_dsi_vbt_init() has grown too unwieldy, and it's about to be
modified due to ICL DSI. Abstract out the VLV specific dphy param
init. No functional changes. Intentionally no stylistic changes during
code movement.
Michal Wajdeczko [Wed, 17 Oct 2018 19:52:45 +0000 (19:52 +0000)]
drm/i915/huc: Normalize HuC status returned by I915_PARAM_HAS_HUC
In response for I915_PARAM_HAS_HUC we are returning value that
indicates if HuC firmware was loaded and verified. However, our
previously used positive value was based on specific register bit
which is about to change on future platform. Let's normalize our
return values to 0 and 1 before clients will start to use Gen9 value.
v2: use bool for implicit conversion (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Haihao Xiang <haihao.xiang@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> #1 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/20181017195245.39644-1-michal.wajdeczko@intel.com
Tvrtko Ursulin [Fri, 12 Oct 2018 06:31:42 +0000 (07:31 +0100)]
drm/i915: GEM_WARN_ON considered harmful
GEM_WARN_ON currently has dangerous semantics where it is completely
compiled out on !GEM_DEBUG builds. This can leave users who expect it to
be more like a WARN_ON, just without a warning in non-debug builds, in
complete ignorance.
Another gotcha with it is that it cannot be used as a statement. Which is
again different from a standard kernel WARN_ON.
This patch fixes both problems by making it behave as one would expect.
It can now be used both as an expression and as statement, and also the
condition evaluates properly in all builds - code under the conditional
will therefore not unexpectedly disappear.
To satisfy call sites which really want the code under the conditional to
completely disappear, we add GEM_DEBUG_WARN_ON and convert some of the
callers to it. This one can also be used as both expression and statement.
>From the above it follows GEM_DEBUG_WARN_ON should be used in situations
where we are certain the condition will be hit during development, but at
a place in code where error can be handled to the benefit of not crashing
the machine.
GEM_WARN_ON on the other hand should be used where condition may happen in
production and we just want to distinguish the level of debugging output
emitted between the production and debug build.
v2:
* Dropped BUG_ON hunk.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181012063142.16080-1-tvrtko.ursulin@linux.intel.com
Lyude Paul [Tue, 16 Oct 2018 20:39:46 +0000 (16:39 -0400)]
drm/atomic_helper: Stop modesets on unregistered connectors harder
Unfortunately, it appears our fix in:
commit b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes
for unregistered connectors")
Which attempted to work around the problems introduced by:
commit 4d80273976bf ("drm/atomic_helper: Disallow new modesets on
unregistered connectors")
Is still not the right solution, as modesets can still be triggered
outside of drm_atomic_set_crtc_for_connector().
So in order to fix this, while still being careful that we don't break
modesets that a driver may perform before being registered with
userspace, we replace connector->registered with a tristate member,
connector->registration_state. This allows us to keep track of whether
or not a connector is still initializing and hasn't been exposed to
userspace, is currently registered and exposed to userspace, or has been
legitimately removed from the system after having once been present.
Using this info, we can prevent userspace from performing new modesets
on unregistered connectors while still allowing the driver to perform
modesets on unregistered connectors before the driver has finished being
registered.
Changes since v1:
- Fix WARN_ON() in drm_connector_cleanup() that CI caught with this
patchset in igt@drv_module_reload@basic-reload-inject and
igt@drv_module_reload@basic-reload by checking if the connector is
registered instead of unregistered, as calling drm_connector_cleanup()
on a connector that hasn't been registered with userspace yet should
stay valid.
- Remove unregistered_connector_check(), and just go back to what we
were doing before in commit 4d80273976bf ("drm/atomic_helper: Disallow
new modesets on unregistered connectors") except replacing
READ_ONCE(connector->registered) with drm_connector_is_unregistered().
This gets rid of the behavior of allowing DPMS On<->Off, but that should
be fine as it's more consistent with the UAPI we had before - danvet
- s/drm_connector_unregistered/drm_connector_is_unregistered/ - danvet
- Update documentation, fix some typos.
Fixes: b5d29843d8ef ("drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Cc: David Airlie <airlied@linux.ie> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181016203946.9601-1-lyude@redhat.com
The ENTER/EXIT_S_STATE actions queue the save/restore operation in GuC
FW and then return, so waiting on the H2G is not enough to guarantee
GuC is done.
When all the processing is done, GuC writes 0 to scratch register 14,
so we can poll on that. Note that GuC does not ensure that the value
in the register is different from 0 while the action is in progress
so we need to take care of that ourselves as well.
v2: improve comment, return early on GuC error and improve error
message (Michal)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181016224648.2326-1-daniele.ceraolospurio@intel.com
drm/i915: Remove crtc->config dereference from drrs_ctl
Wait for idle, and iterate over connectors instead of encoders.
With this information we know crtc->state is the actual state,
and we can enable/disable drrs safely.
Imre Deak [Tue, 16 Oct 2018 16:00:11 +0000 (19:00 +0300)]
drm/i915/gen9+: Fix initial readout for Y tiled framebuffers
If BIOS configured a Y tiled FB we failed to set up the backing object
tiling accordingly, leading to a lack of GT fence installed and a
garbled console.
The problem was bisected to
commit 011f22eb545a ("drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2")
but it just revealed a pre-existing issue.
Kudos to Ville who suspected a missing fence looking at the corruption
on the screen.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: <ronald@innovation.ch> Cc: <stable@vger.kernel.org> Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: <ronald@innovation.ch> Tested-by: <ronald@innovation.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108264 Fixes: bc8d7dffacb1 ("drm/i915/skl: Provide a Skylake version of get_plane_config()") 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/20181016160011.28347-1-imre.deak@intel.com
Michal Wajdeczko [Tue, 16 Oct 2018 08:59:30 +0000 (08:59 +0000)]
drm/i915/guc: Fix Gen9 GuC loading workarounds
In commit 4502e9ec820d ("drm/i915/uc: Unify firmware loading") we
stopped converting errors detected during firmware transfer into
-EAGAIN and this indirectly killed our workarounds for Gen9 GuC.
Reactivate those workarounds by looking for actual -ETIMEDOUT error.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181016085931.23532-1-michal.wajdeczko@intel.com
Jani Nikula [Tue, 16 Oct 2018 12:29:38 +0000 (15:29 +0300)]
drm/i915: Ensure intel_engine_init_execlist() builds with Clang
Clang build with UBSAN enabled leads to the following build error:
drivers/gpu/drm/i915/intel_engine_cs.o: In function `intel_engine_init_execlist':
drivers/gpu/drm/i915/intel_engine_cs.c:411: undefined reference to `__compiletime_assert_411'
Again, for this to work the code would first need to be inlined and then
constant folded, which doesn't work for Clang because semantic analysis
happens before optimization/inlining.
Use GEM_BUG_ON() instead of BUILD_BUG_ON().
v2: Use is_power_of_2() from log2.h (Chris)
References: http://mid.mail-archive.com/20181015203410.155997-1-swboyd@chromium.org Reported-by: Stephen Boyd <swboyd@chromium.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016122938.18757-2-jani.nikula@intel.com
Jani Nikula [Tue, 16 Oct 2018 12:29:37 +0000 (15:29 +0300)]
drm/i915: Ensure _print_param() builds with Clang
When building the kernel with Clang with defconfig and CONFIG_64BIT
disabled, vmlinux fails to link because of the BUILD_BUG in
_print_param.
ld: drivers/gpu/drm/i915/i915_params.o: in function `i915_params_dump':
i915_params.c:(.text+0x56): undefined reference to
`__compiletime_assert_191'
This function is semantically invalid unless the code is first inlined
then constant folded, which doesn't work for Clang because semantic
analysis happens before optimization/inlining.
[The above written by Nathan Chancellor <natechancellor@gmail.com>]
Use WARN_ONCE() instead of BUILD_BUG() to avoid the problem. The
WARN_ONCE() should get optimized away unless there's a type that's not
handled by _print_param().
References: https://github.com/ClangBuiltLinux/linux/issues/191
References: http://mid.mail-archive.com/20181009171401.14980-1-natechancellor@gmail.com Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nathan Chancellor <natechancellor@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Nick Desaulniers <ndesaulniers@google.com> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016122938.18757-1-jani.nikula@intel.com
Jani Nikula [Tue, 16 Oct 2018 14:50:44 +0000 (17:50 +0300)]
drm/i915: rename and move intel_get_pipe_from_connector()
Rename intel_get_pipe_from_connector() to intel_connector_get_pipe() and
move it near its connector function friends in intel_connector.c. No
functional changes.
Mahesh Kumar [Fri, 12 Oct 2018 23:47:17 +0000 (16:47 -0700)]
drm/i915/icl: Combine all port/combophy macros at one place
This patch combines CNL/ICL specific port/combophy macros together
at one location. This is prework for patches later in series where
new macros to find port/combophy register will be introduced.
projects / mirror_ubuntu-hirsute-kernel.git / log