summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2018-03-02drm/i915/execlists: Move irq state manipulation inside irq disabled regionChris Wilson
Although this state (execlists->active and engine->irq_posted) itself is not protected by the engine->timeline spinlock, it does conveniently ensure that irqs are disabled. We can use this to protect our manipulation of the state and so ensure that the next IRQ to arrive sees consistent state and (hopefully) ignores the reset engine. Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-chris@chris-wilson.co.uk
2018-03-02drm/i915: Suspend submission tasklets around wedgingChris Wilson
After staring hard at sequences like [ 28.199013] systemd-1 2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?] [ 28.199095] systemd-1 2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1 [ 28.199177] systemd-1 2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024 [ 28.199258] systemd-1 2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0 [ 28.199340] gem_eio-829 1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0 [ 28.199421] <idle>-0 2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?] [ 28.199503] <idle>-0 2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1 [ 28.199585] gem_eio-829 1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0 [ 28.199667] gem_eio-829 1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0 [ 28.199749] <idle>-0 2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?] [ 28.199830] <idle>-0 2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1 [ 28.199912] <idle>-0 2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0 [ 28.199994] gem_eio-829 2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?] [ 28.200096] gem_eio-829 2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5 [ 28.200178] gem_eio-829 2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0 [ 28.200260] gem_eio-829 2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id) the conclusion is that the only place where the ports are reset to zero, is from engine->cancel_requests called during i915_gem_set_wedged(). The race is horrible as it results from calling set-wedged on active HW (the GPU reset failed) and as such we need to be careful as the HW state changes beneath us. Fortunately, it's the same scary conditions as affect normal reset, so we can reuse the same machinery to disable state tracking as we clobber it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged") Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
2018-03-02drm/i915: Deduplicate the code to fill the aux message headerVille Syrjälä
We have two instances of the code to fill out the header for the aux message. Pull it into a small helper. v2: Rebase due to txbuf[] changes Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222212802.4826-1-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2018-03-02drm/i915: Keep the AKSV details in intel_dp_hdcp_write_an_aksv()Ville Syrjälä
Let's try to keep the details on the AKSV stuff concentrated in one place. So move the control bit and +5 data size handling there. v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer() will still load into the registers even though the hardware will ignore it Cc: Sean Paul <seanpaul@chromium.org> Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222212732.4665-1-ville.syrjala@linux.intel.com Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
2018-03-02drm/i915: s/intel_dp_aux_ch/intel_dp_aux_xfer/Ville Syrjälä
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey what it actually does. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222181036.15251-6-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #irc
2018-03-02drm/i915/gen9, gen10: Disable FBC on planes with a misaligned Y-offsetImre Deak
Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may cause pipe FIFO underruns and flickers, so disable FBC on such a config. I tried the followings to work around the issue: - enable each HW work around in ILK_DPFC_CHICKEN - disable each compression algorithm in ILK_DPFC_CONTROL - disable low-power watermarks None of the above got rid of the problem. I haven't found this issue in the Bspec/WA database either. Besides the igt testcase below (yet to be merged) an easy way to reproduce the issue is to enable a plane with FBC and a plane Y-offset not aligned to 4 and then just enable/disable FBC in a loop, keeping the plane enabled. I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's only present on GEN9 and GEN10. v2: (Ville) - Run the test/apply the WA on CNL as well. - Use IS_GEN() instead of INTEL_GEN(). - Fix spelling. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Testcase: igt/kms_plane/plane-clipping-pipe-A-planes 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/20180301134457.13974-1-imre.deak@intel.com
2018-03-02drm/i915: Add support for the YCbCr COLOR_RANGE propertyVille Syrjälä
Add support for the COLOR_RANGE property on planes. This property selects whether the input YCbCr data is to treated as limited range or full range. On most platforms this is a matter of setting the "YUV range correction disable" bit, and on VLV/CHV we'll just have to program the color correction logic to pass the data through unmodified. v2: Rebase Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Change the COLOR_ENCODING prop default value to BT.709Ville Syrjälä
Bring us forward from the stone age and switch our default YCbCr->RGB conversion matrix to BT.709 from BT.601. I would expect most matrial to be BT.709 these days. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Acked-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Add support for the YCbCr COLOR_ENCODING propertyVille Syrjälä
Add support for the COLOR_ENCODING plane property which selects the matrix coefficients used for the YCbCr->RGB conversion. Our hardware can generally handle BT.601 and BT.709. CHV pipe B sprites have a fully programmable matrix, so in theory we could handle anything, but it doesn't seem all that useful to expose anything beyond BT.601 and BT.709 at this time. GLK can supposedly do BT.2020, but let's leave enabling that for the future as well. v2: Rename bit defines to match the spec more closely (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-7-ville.syrjala@linux.intel.com
2018-03-02drm/i915: Fix plane YCbCr->RGB conversion for GLKVille Syrjälä
On GLK the plane CSC controls moved into the COLOR_CTL register. Update the code to progam the YCbCr->RGB CSC mode correctly when faced with an YCbCr framebuffer. The spec is rather confusing as it calls the mode "YUV601 to RGB709". I'm going to assume that just means it's going to use the YCbCr->RGB matrix as specified in BT.601 and doesn't actually change the gamut. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-6-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-03-02drm/i915: Correctly handle limited range YCbCr data on VLV/CHVVille Syrjälä
Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and saturation). On CHV pipe B we were actually doing the right thing already because we progammed the custom CSC matrix to do expect limited range input. Now that well pre-expand the data out with the color correction unit, we need to change the CSC matrix to operate with full range input instead. This should make the sprite output of the other pipes match the sprite output of pipe B reasonably well. Looking at the resulting pipe CRCs, there can be a slight difference in the output, but as I don't know the formula used by the fixed function CSC of the other pipes, I don't think it's worth the effort to try to match the output exactly. It might not even be possible due to difference in internal precision etc. One slight caveat here is that the color correction registers are single bufferred, so we should really be updating them during vblank, but we still don't have a mechanism for that, so just toss in another FIXME. v2: Rebase v3: s/bri/brightness/ s/con/contrast/ (Shashank) v4: Clarify the constants and math (Shashank) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Tang, Jun" <jun.tang@intel.com> Reported-by: "Tang, Jun" <jun.tang@intel.com> Cc: stable@vger.kernel.org Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4") Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
2018-03-02drm/atomic: Include color encoding/range in plane state dumpVille Syrjälä
Include color_enconding and color_range in the plane state dump. v2: Add kerneldoc (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219202846.10628-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Harry Wentland <harry.wentland@amd.com>
2018-03-02drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_planeJyri Sarha
Add a standard optional properties to support different non RGB color encodings in DRM planes. COLOR_ENCODING select the supported non RGB color encoding, for instance ITU-R BT.709 YCbCr. COLOR_RANGE selects the value ranges within the selected color encoding. The properties are stored to drm_plane object to allow different set of supported encoding for different planes on the device. v2: Add/fix kerneldocs, verify bitmasks (danvet) Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> [vsyrjala v2: Add/fix kerneldocs, verify bitmasks] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219202823.10508-1-ville.syrjala@linux.intel.com Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2018-03-02drm/i915: Wedged engine mask makes more sense in hexTvrtko Ursulin
In decimal its just a weird big number, while in hex can actually log which engines were requested to be wedged. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180228171844.20006-1-tvrtko.ursulin@linux.intel.com
2018-03-02drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure ↵Sagar Arun Kamble
symmetric GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw loading functions and declarations to separate files intel_huc_fw.c|h like GuC. While at this, do below changes 1. Update kernel-doc comment for intel_*_fw_upload() functions 2. s/huc_ucode_xfer/huc_fw_xfer 3. Introduce intel_huc_fw_init_early() v2: Changed patch to update HuC functions instead of changing guc_fw_upload and update file structure. (Michal Wajdeczko) v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Anusha Srivatsa <anusha.srivatsa@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/1519922745-25441-1-git-send-email-sagar.a.kamble@intel.com
2018-03-02drm/sun4i: Allow building on arm64Jernej Skrabec
64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which is compatible to 32-bit SoCs, so allow building DRM driver for arm64 architecture. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-14-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Add support for H3 HDMI PHY variantJernej Skrabec
While A83T HDMI PHY seems to be just customized Synopsys HDMI PHY, H3 HDMI PHY is completely custom PHY. However, they still have many things in common like clock and reset setup, setting sync polarity and more. Add support for H3 HDMI PHY variant. While documentation exists for this PHY variant, it doesn't go in great details. Because of that, almost all settings are copied from BSP linux 4.4. Interestingly, those settings are slightly different to those found in a older BSP with Linux 3.4. For now, no user visible difference was found between them. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-13-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Move and expand DW HDMI PHY register macrosJernej Skrabec
DW HDMI PHY macros are moved to header file and expanded with the registers present on newer SoCs like H3 and H5. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-12-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Add support for variants to DW HDMI PHYJernej Skrabec
There are multiple variants of DW HDMI PHYs in Allwinner SoCs. While some things like clock and reset setup are the same, PHY configuration differs a lot. Split out code which is PHY specific to separate functions and create a structure which holds pointers to those functions. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-11-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Fix polarity configuration for DW HDMI PHYJernej Skrabec
Current polarity configuration code is cleary wrong since it compares same flag two times. However, even if flag name is fixed, it won't work well for resolutions which have one polarity positive and another negative. Fix that by properly set each bit according to each polarity. Since those two bits are not described in any documentation, relationships were obtained by experimentation. Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-10-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Add support for H3 mixer 0Jernej Skrabec
This mixer supports 1 VI plane, 3 UI plane and HW scaling on all planes. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-9-jernej.skrabec@siol.net
2018-03-02drm/sun4i: Add support for H3 display engineJernej Skrabec
H3 display engine has two mixers which are connected to HDMI and TV output. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-8-jernej.skrabec@siol.net
2018-03-02dt-bindings: display: sun4i-drm: Add compatibles for H3 HDMI pipelineJernej Skrabec
Add missing compatibles for H3 HDMI pipeline. These compatibles can also be used with H5 SoC. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301213442.16677-6-jernej.skrabec@siol.net
2018-03-01drm/i915: Check for I915_MODE_FLAG_INHERITED before ↵Maarten Lankhorst
drm_atomic_helper_check_modeset Moving the check upwards will mean we we no longer have to add planes and connectors manually, because everything is handled correctly by drm_atomic_helper_check_modeset() as intended. [applied with whitespace changes to make sparse happy] Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221092808.30060-1-maarten.lankhorst@linux.intel.com
2018-03-01drm/i915: Replace open-coded wait-for loopChris Wilson
Now that we can pass arbitrary commands into the base __wait_for() macro, we can reimplement the open-coded wait-for inside i915_gem_idle_work_handler() using the new macro. This means that instead of using ktime, we now use jiffies, and benefit from the exponential sleep backoff that allows a fast response if the HW settles quickly. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301103338.5380-1-chris@chris-wilson.co.uk
2018-03-01drm/amd/amdgpu: Mask rptr as well in ring debugfsTom St Denis
The read/write pointers on sdma4 devices increment beyond the ring size and should be masked. Tested on my Ryzen 2400G. Signed-off-by: Tom St Denis <tom.stdenis@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01drm/amdgpu: try again kiq access if not in IRQ(v4)Monk Liu
sometimes GPU is switched to other VFs and won't swich back soon, so the kiq reg access will not signal within a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT) and returning TMO we can istead sleep 5ms and try again later (non irq context) And since the waiting in kiq_r/weg is busy wait, so MAX_KIQ_REG_WAIT shouldn't set to a long time, set it to 10ms is more appropriate. if gpu already in reset state, don't retry the KIQ reg access otherwise it would always hang because KIQ was already die usually. v2: replace schedule() with msleep() for the wait v3: use while loop for the wait repeating use macros for the sleep period more description for it v4: drop unused variable Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com Reviewed-by: Pixel Ding <Pixel.Ding@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01drm/amdgpu: cleanups for vram lost handlingMonk Liu
1)create a routine "handle_vram_lost" to do the vram recovery, and put it into amdgpu_device_reset/reset_sriov, this way no need of the extra paramter to hold the VRAM LOST information and the related macros can be removed. 3)show vram_recover failure if time out, and set TMO equal to lockup_timeout if vram_recover is under SRIOV runtime mode. 4)report error if any ip reset failed for SR-IOV Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01drm/amdgpu: stop all rings before doing gpu recoverMonk Liu
found recover_vram_from_shadow sometimes get executed in paralle with SDMA scheduler, should stop all schedulers before doing gpu reset/recover Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Tested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-03-01drm/rockchip: analogix_dp: reorder psr_unregister call in unbindJeffy Chen
In bind the psr handler gets registered first before the core analogix_dp_bind() gets called. So it should be the other way around in unbind, first unbind the analogix_dp and then unregister the psr. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/76025075.yWNtk1v57f@phil
2018-03-01drm/rockchip: analogix_dp: Add a sanity check for rockchip_drm_psr_register()Jeffy Chen
The rockchip_drm_psr_register() can fail, so add a sanity check for that. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> [moved psr_unregister reordering in unbind to separate patch] Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180110162348.22765-4-thierry.escande@collabora.com
2018-03-01drm/bridge: analogix_dp: Fix connector and encoder cleanupJeffy Chen
Since we are initing connector in the core driver and encoder in the plat driver, let's clean them up in the right places. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180110162348.22765-3-thierry.escande@collabora.com
2018-03-01drm/bridge: analogix: Do not use device's drvdataJeffy Chen
The driver that instantiates the bridge should own the drvdata, as all driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also owned by its driver struct. Moreover, storing two different pointer types in driver data depending on driver initialization status is barely a good practice and in fact has led to many bugs in this driver. Let's clean up this mess and change Analogix entry points to simply accept some opaque struct pointer, adjusting their users at the same time to avoid breaking the compilation. Signed-off-by: Tomasz Figa <tfiga@chromium.org> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Thierry Escande <thierry.escande@collabora.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Jingoo Han <jingoohan1@gmail.com> Acked-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180110162348.22765-2-thierry.escande@collabora.com
2018-03-01drm/i915/perf: fix perf stream opening lockLionel Landwerlin
We're seeing on CI that some contexts don't have the programmed OA period timer that directs the OA unit on how often to write reports. The issue is that we're not holding the drm lock from when we edit the context images down to when we set the exclusive_stream variable. This leaves a window for the deferred context allocation to call i915_oa_init_reg_state() that will not program the expected OA timer value, because we haven't set the exclusive_stream yet. v2: Drop need_lock from gen8_configure_all_contexts() (Matt) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 701f8231a2f ("drm/i915/perf: prune OA configs") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755 Link: https://patchwork.freedesktop.org/patch/msgid/20180301110613.1737-1-lionel.g.landwerlin@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 Cc: <stable@vger.kernel.org> # v4.14+
2018-03-01drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()Jeffy Chen
Currently we are calling scl_vop_cal_scale() to get vskiplines for yrgb and cbcr. So the cbcr's vskiplines might be an unexpected value if the second scl_vop_cal_scale() didn't update it. Init vskiplines in scl_vop_cal_scale() to avoid that. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180223062250.10470-1-jeffy.chen@rock-chips.com
2018-03-01drm/rockchip: Add device links for master and componentsJeffy Chen
Since we are trying to access components' resources in the master's suspend/resume PM callbacks(e.g. panel), add device links to correct the suspend/resume and shutdown ordering. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180207175309.21095-1-enric.balletbo@collabora.com
2018-03-01drm/i915/icl: Interrupt handlingMika Kuoppala
v2: Rebase. v3: * Remove DPF, it has been removed from SKL+. * Fix -internal rebase wrt. execlists interrupt handling. v4: Rebase. v5: * Updated for POR changes. (Daniele Ceraolo Spurio) * Merged with irq handling fixes by Daniele Ceraolo Spurio: * Simplify the code by using gen8_cs_irq_handler. * Fix interrupt handling for the upstream kernel. v6: * Remove early bringup debug messages (Tvrtko) * Add NB about arbitrary spin wait timeout (Tvrtko) v7 (from Paulo): * Don't try to write RO bits to registers. * Don't check for PCH types that don't exist. PCH interrupts are not here yet. v9: * squashed in selector and shared register handling (Daniele) * skip writing of irq if data is not valid (Daniele) * use time_after32 (Chris) * use I915_MAX_VCS and I915_MAX_VECS (Daniele) * remove fake pm interrupt handling for later patch (Mika) v10: * Direct processing of banks. clear banks early (Chris) * remove poll on valid bit, only clear valid bit (Mika) * use raw accessors, better naming (Chris) v11: * adapt to raw_reg_[read|write] * bring back polling the valid bit (Daniele) v12: * continue if unset intr_dw (Daniele) * comment the usage of gen8_de_irq_handler bits (Daniele) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180228101153.7224-2-mika.kuoppala@linux.intel.com
2018-03-01drm/i915/icl: Prepare for more ringsTvrtko Ursulin
Gen11 will add more VCS and VECS rings so prepare the infrastructure to support that. Bspec: 7021 v2: Rebase. v3: Rebase. v4: Rebase. v5: Rebase. v6: - Update for POR changes. (Daniele Ceraolo Spurio) - Add provisional guc engine ids - to be checked and confirmed. v7: - Rebased. - Added the new ring masks. - Added the new HW ids. v8: - Introduce I915_MAX_VCS/VECS to avoid magic numbers (Michal) v9: increase MAX_ENGINE_INSTANCE to 3 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20180228101153.7224-1-mika.kuoppala@linux.intel.com
2018-03-01Merge drm-next into drm-intel-next-queued (this time for real)Joonas Lahtinen
To pull in the HDCP changes, especially wait_for changes to drm/i915 that Chris wants to build on top of. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-03-01drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates arrayManasi Navare
dp_rates[] array is a superset of all the link rates supported by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate to the set of link rates supported by sink. This patch adds this rate to dp_rates[] array that gets used to populate the sink_rates[] array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register. v2: * Rebased on top of Jani's localized rates patch Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1519857110-26916-1-git-send-email-manasi.d.navare@intel.com
2018-03-01Merge tag 'drm-intel-next-2018-02-21' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Lift alpha_support protection from Cannonlake (Rodrigo) * Meaning the driver should mostly work for the hardware we had at our disposal when testing * Used to be preliminary_hw_support - Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo) - Cannonlake port register fix (Mahesh) - Fix Dell Venue 8 Pro black screen after modeset (Hans) - Fix for always returning zero out-fence from execbuf (Daniele) - Fix HDMI audio when no no relevant video output is active (Jani) - Fix memleak of VBT data on driver_unload (Hans) - Fix for KASAN found locking issue (Maarten) - RCU barrier consolidation to improve igt/gem_sync/idle (Chris) - Optimizations to IRQ handlers (Chris) - vblank tracking improvements (64-bit resolution, PM) (Dhinakaran) - Pipe select bit corrections (Ville) - Reduce runtime computed device_info fields (Chris) - Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris) - A bunch of kerneldoc warning fixes (Chris) * tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20180221 drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning drm/i915: Move the policy for placement of the GGTT vma into the caller drm/i915: Also check view->type for a normal GGTT view drm/i915: Drop WaDoubleCursorLP3Latency:ivb drm/i915: Set the primary plane pipe select bits on gen4 drm/i915: Don't set cursor pipe select bits on g4x+ drm/i915: Assert that we don't overflow frontbuffer tracking bits drm/i915: Track number of pending freed objects drm/i915/: Initialise trans_min for skl_compute_transition_wm() drm/i915: Clear the in-use marker on execbuf failure drm/i915: Prune gen8_gt_irq_handler drm/i915: Track GT interrupt handling using the master iir drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use drm: intel_dpio_phy: fix kernel-doc comments at nested struct drm/i915: Release connector iterator on a digital port conflict. drm/i915/execlists: Remove too early assert drm/i915: Assert that we always complete a submission to guc/execlists drm: move read_domains and write_domain into i915 ...
2018-03-01Merge tag 'tilcdc-4.17' of https://github.com/jsarha/linux into drm-nextDave Airlie
drm/tilcdc changes to v4.17 * tag 'tilcdc-4.17' of https://github.com/jsarha/linux: drm/tilcdc: tilcdc_panel: Rename device from "panel" to "tilcdc-panel" drm/tilcdc: Add support for drm panels drm/tilcdc: panel: Use common error handling code in of_get_panel_info() drm/tilcdc: Delete an error message for a failed memory allocation in seven functions
2018-02-28drm/i915/dp: move link rate arrays where they're usedJani Nikula
Localize link rate arrays by moving them to the functions where they're used. Further clarify the distinction between source and sink capabilities. Split pre and post Haswell arrays, and get rid of the array size arithmetics. Use a direct rate value in the paranoia case of no common rates find. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180227105911.4485-1-jani.nikula@intel.com
2018-02-28drm/amdgpu: fix module parameter descriptionsAlex Deucher
Some were missing the close parens around options. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-02-28drm/amdgpu: Map all visible VRAM at startupAmber Lin
When using CPU to update page table, we need to kmap all the PDs/PTs after they are allocated and that requires a TLB shot down on each CPU, which is quite heavy. Instead, we map the whole visible VRAM to a kernel address at once. Pages can be obtained from the offset. v2: move the mapping base from gmc to amdgpu_mman structure, and the implementation in amdgpu_ttm_* functions Signed-off-by: Amber Lin <Amber.Lin@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-02-28drm/amd/display: check for ipp before calling cursor operationsShirish S
Currently all cursor related functions are made to all pipes that are attached to a particular stream. This is not applicable to pipes that do not have cursor plane initialised like underlay. Hence this patch allows cursor related operations on a pipe only if ipp in available on that particular pipe. The check is added to set_cursor_position & set_cursor_attribute. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-02-28drm/amd/display: make dm_dp_aux_transfer return payload bytes instead of sizeShirish S
The drm layer expects aux->transfer() to return the payload bytes read. Currently dm_dp_aux_transfer() returns the payload size which does not gets updated during the read, hence not giving the right data for the drm layer to pars edid. This leads to the drm layer to conclude as the edid is BAD and hence some monitors/devices dont get detected properly. This patch changes the return type of dm_dp_aux_transfer() to actual bytes read during DP_AUX_NATIVE_READ & DP_AUX_I2C_READ. Signed-off-by: Shirish S <shirish.s@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-02-28tinydrm: add backlight dependencyArnd Bergmann
Calling devm_of_find_backlight directly means we get a link failure without CONFIG_BACKLIGHT_CLASS_DEVICE: drivers/gpu/drm/tinydrm/mi0283qt.o: In function `mi0283qt_probe': mi0283qt.c:(.text+0x684): undefined reference to `devm_of_find_backlight' This adds an explicit Kconfig dependency for it. While I did not observe that failure for st7735r, I assume the same change is needed there for the same reason. Fixes: d1a2e7004b5e ("drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180228134111.2042877-1-arnd@arndb.de
2018-02-28drm/amdgpu: disable GFX ring and disable PQ wptr in hw_finiMonk Liu
otherwise there will be DMAR reading error comes out from CP since GFX is still alive and CPC's WPTR_POLL is still enabled, which would lead to DMAR read error. fix: we can hault CPG after hw_fini, but cannot halt CPC becaues KIQ stil need to be alive to let RLCV invoke, but its WPTR_POLL could be disabled. Signed-off-by: Monk Liu <Monk.Liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-02-28drm/amdgpu: cleanup SA inti and fini(v2)Monk Liu
should use bo_create_kernel instead of split to two function that create and pin the SA bo issue: before this patch, there are DMAR read error in host side when running SRIOV test, the DMAR address dropped in the range of SA bo. fix: after this cleanups of SA init and fini, above DMAR eror gone. v2: keep sa_bo's fini instead of suspend, to keep reporting error Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-06 04:39:44 +0000