- 28 Mar, 2017 2 commits
-
-
Shashank Sharma authored
Geminilake has a native HDMI 2.0 controller, which is capable of driving clocks upto 594Mhz. This patch updates the max tmds clock limit for the same. V2: rebase V3: rebase V4: added r-b from Ander V5: rebase V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-7-git-send-email-shashank.sharma@intel.com
-
Shashank Sharma authored
Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset. V2: Addressed review comments from Ville: - Do not track scrambling status in DRM layer, track somewhere in driver like in intel_crtc_state. - Don't talk to monitor at such a low layer, set monitor scrambling in intel_enable_ddi() before enabling the port. V3: Addressed review comments from Jani - In comments, function names, use "sink" instead of "monitor", so that the implementation could be close to the language of HDMI spec. V4: Addressed review comment from Maarten - scrambling -> hdmi_scrambling - high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio V5: Addressed review comments from Ville and Ander - Do not modifiy the crtc_state after compute_config. Move all scrambling and tmds_clock_ratio calcutations to compute_config. - While setting scrambling for source/sink, do not check the conditions again, just go by the crtc_state flags. This will simplyfy the condition checks. V6: Addressed review comments from Ville - Do not add IS_GLK check in disable/enable function, instead add it in compute_config, while setting state flags. - Remove unnecessary paranthesis. - Simplyfy handle_sink_scrambling function as suggested. - Add readout code for scrambling status in get_ddi_config and add a check for the same in pipe_config_compare. V7: Addressed review comments from Ander/Ville - No separate function for source scrambling, make it inline - Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK - Do not add platform check while setting source scrambling - Use pipe_config instead of crtc->config to set sink scrambling - To readout scrambling status, Compare with SCRAMBLING_MASK not any of its bits - Remove platform check in intel_pipe_config_compare while checking scrambling status V8: Fixed mege conflict, Addressed review comments from Ander - Remove the desciption/comment about scrambling fom the caller, move it to the function - Move the IS_GLK check into scrambling function - Fix alignment V9: Fixed review comments from Ville, Ander - Pass the scrambling state variables as bool input to the sink_scrambling function and let the disable call be unconditional. - Fix alignments in function calls and debug messages. - Add kernel doc for function intel_hdmi_handle_sink_scrambling V10: Rebase Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
- 27 Mar, 2017 19 commits
-
-
Paulo Zanoni authored
All it does is pick the encoder and call intel_get_shared_dpll(). We can just do this in the caller. One less indirection level during code reading. As another plus, now the two callers of intel_get_shared_dpll() are {ironlake,haswell}_crtc_compute_clock(). Reported-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Chris Wilson authored
Use the incoming value from debugfs/i915_wedged to select which engines to marked as guilty in order to force us to reset those requests (required to quickly bypass simulated hangs). Testcase: igt/gem_exec_capture Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170325134735.30581-1-chris@chris-wilson.co.ukReviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Whilst I like having the assertions clearly visible in the code, they are quite repetitious! As we find new limits we want to incorporate into the set of assertions, it make sense to refactor them to a common routine. v2: Add a guc holdout. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170327131412.20293-1-chris@chris-wilson.co.ukReviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
In addition to being qword-aligned, the RING_TAIL offset must be within the ring! Signed-off-by:
-
Chris Wilson authored
If the request->wa_tail is 0 (because it landed exactly on the end of the ringbuffer), when we reconstruct request->tail following a reset we fill in an illegal value (-8 or 0x001ffff8). As a result, RING_HEAD is never able to catch up with RING_TAIL and the GPU spins endlessly. If the ring contains a couple of breadcrumbs, even our hangcheck is unable to catch the busy-looping as the ACTHD and seqno continually advance. v2: Move the wrap into a common intel_ring_wrap(). Fixes: a3aabe86 ("drm/i915/execlists: Reinitialise context image after GPU hang") Signed-off-by:
-
Ville Syrjälä authored
All the pre-SKL sprite planes compute the x/y/tile offsets in a similar way. There are a couple of minor differences but the primary planes have those as well. Thus i9xx_check_plane_surface() already does what we need, so let's use it. Signed-off-by:
-
Ville Syrjälä authored
The effective difference between i9xx_update_primary_plane() and ironlake_update_primary_plane() is only the HSW/BDW DSPOFFSET special case. So bring that over into i9xx_update_primary_plane() and eliminate the duplicated code. Signed-off-by:
-
Ville Syrjälä authored
Extract the primary plane surfae offset/x/y calculations for pre-SKL platforms into a common function, and call it during the atomic check phase to reduce the amount of stuff we have to do during the commit phase. SKL is already doing this. v2: Update the comment about the rotation adjustments to match the code better (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Computing the plane control register value is branchy so moving it out from the plane commit hook seems prudent. Let's pre-compute it during the atomic check phase and store the result in the plane state. Signed-off-by:
-
Ville Syrjälä authored
Share the code to compute the primary plane control register value between the i9xx and ilk codepaths as the differences are minimal. Actually there are no differences between g4x and ilk, so the current split doesn't really make any sense. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the pre-SKL primary plane control register value into separate functions. Allows us to pre-compute it in the future. v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Since the engine's flag is just the bit of its id, use BIT(). Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
intel_flush_status_page() is defunct since commit f8dd2934 ("drm/i915: Remove BXT incoherent seqno write workaround"), time to remove it. Signed-off-by:
-
Chris Wilson authored
Not all of our target platforms have clflush. For those without, just assume the status page is sufficiently coherent that we do not need our paranoia. Reported-by:
-
Chris Wilson authored
Old devices have quite severe restrictions for using fences, and unlike more recent device (anything from Pineview onwards) we need to enforce those restrictions even for unfenced tiled access from the render pipeline. Fixes: 944397f0 ("drm/i915: Store required fence size/alignment for GGTT vma") Reported-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Chris Wilson authored
We have only 8bits of precise timestamps in which to complete our upper/load reads, along with the switch between precision. This is not always enough time to read the upper counter twice within the same time slice, leading to hard lockups. Limit the number of times to prevent an inifite loop (my fault for assuming we would have no trouble doing the write + reads fast enough). Fixes: 47c21d9a ("drm/i915: Extend vlv/chv residency resolution") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100377Signed-off-by:
-
Chris Wilson authored
We can assume that if the device is asleep then all pending GTT writes will have been posted, and so we can defer the flush from i915_gem_object_flush_gtt_write_domain() [ 1957.462568] WARNING: CPU: 0 PID: 6132 at drivers/gpu/drm/i915/intel_drv.h:1742 fwtable_read32+0x123/0x150 [i915] [ 1957.462582] RPM wakelock ref not held during HW access [ 1957.462583] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers [ 1957.462607] CPU: 0 PID: 6132 Comm: gem_concurrent_ Tainted: G U 4.11.0-rc1+ #464 [ 1957.462619] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 1957.462630] Call Trace: [ 1957.462646] dump_stack+0x4d/0x6f [ 1957.462657] __warn+0xc1/0xe0 [ 1957.462667] warn_slowpath_fmt+0x4a/0x50 [ 1957.462709] fwtable_read32+0x123/0x150 [i915] [ 1957.462750] i915_gem_object_flush_gtt_write_domain+0x43/0x70 [i915] [ 1957.462791] i915_gem_object_set_to_cpu_domain+0x46/0xa0 [i915] [ 1957.462831] i915_gem_set_domain_ioctl+0x15d/0x220 [i915] [ 1957.462843] drm_ioctl+0x1d7/0x440 [ 1957.462885] ? i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0 [i915] [ 1957.462896] ? pick_next_task_fair+0x436/0x440 [ 1957.462906] ? mntput+0x1f/0x30 [ 1957.462915] do_vfs_ioctl+0x8f/0x5c0 [ 1957.462925] ? __schedule+0x16f/0x5f0 [ 1957.462935] ? ____fput+0x9/0x10 [ 1957.462943] SyS_ioctl+0x3c/0x70 [ 1957.462952] entry_SYSCALL_64_fastpath+0x17/0x98 [ 1957.462961] RIP: 0033:0x7fc542179ca7 [ 1957.462968] RSP: 002b:00007ffeef12ff98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1957.462982] RAX: ffffffffffffffda RBX: 00007ffeef1301d0 RCX: 00007fc542179ca7 [ 1957.462990] RDX: 00007ffeef12ffd0 RSI: 00000000400c645f RDI: 0000000000000003 [ 1957.462999] RBP: 0000000000000003 R08: 000055f433bc7c40 R09: 000000000000002c [ 1957.463006] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000018 [ 1957.463015] R13: 000055f432c89d20 R14: 000055f432c87690 R15: 0000000000000000 Fixes: 3b5724d7 ("drm/i915: Wait for writes through the GTT to land before reading back") Signed-off-by:
-
Chris Wilson authored
I noticed that gcc was spilling the CSB to the stack, so rearrange the code to be more compact. Spilling in this function is slightly more interesting due to the mmio reads acting as memory barriers and so end up flushing the stack spills. Still miniscule to having to do at least the pair of uncached reads :( function old new delta intel_lrc_irq_handler 1039 878 -161 Signed-off-by:
-
Michal Wajdeczko authored
There is no need to expose this function as it is called from one function only. Also move it up to avoid forward declaration. v2: drop intel_ prefix (Oscar) and rename to fetch_uc_fw (Michal) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170327094510.167400-1-michal.wajdeczko@intel.comReviewed-by:
-
- 24 Mar, 2017 4 commits
-
-
Chris Wilson authored
The required number of dwords for semaphore emission on BDW RCS is 8, not 6 - leading to ring buffer corruption and immediate GPU hangs when using ringbuffer submission. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com>
-
Chris Wilson authored
The current w/a for the gen7 psmi related hangs doesn't apply to bdw, so disable it if using bdw ringbuffer submission. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The forcewake_get call in the guc_send_mmio function was added to avoid getting and releasing forcewake on each register access. While this makes sense, all GuC registers are in the blitter range so no need to wake all the wells. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490366919-34715-1-git-send-email-daniele.ceraolospurio@intel.comReviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Chris Wilson authored
Move the common "client->vaddr + client->proc_desc_offset" to its own function, __get_process_desc() to match the newly established pattern. Signed-off-by:
-
- 23 Mar, 2017 15 commits
-
-
Chris Wilson authored
We only need to care about the ordering of the clearing of the bit with the uncached CSB read in order to correctly detect a new interrupt before the read completes. The uncached read itself acts as a full memory barrier, so we do not need to enforce another in the form of a locked clear_bit. v2: Clarify why the split and unlocked test/clear is harmless. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the cursor control register value into separate functions. Allows us to pre-compute them in the future. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the ILK-SNB sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the IVB-BDW sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the VLV/CHV sprite control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by:
-
Ville Syrjälä authored
On SKL the planes are uniform so the "sprites" can use the primary plane code perfectly fine. The only difference we have is the color key handling, but since we never enable that for the primary plane the same code works just fine. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to calculate the SKL plane control register value into a separate function. Allows us to pre-compute it in the future. Signed-off-by:
-
Oscar Mateo authored
They go better together. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Oscar Mateo authored
We are going to need it for future platforms. Signed-off-by:
-
Oscar Mateo authored
A GuC context and a HW context are in no way related, so the name "GuC context descriptor" is very unfortunate, because a new reader of the code gets overwhelmed very quickly with a lot of things called "context" that refer to different things. We can improve legibility a lot by simply renaming a few objects in the GuC code. v2: - Rebased - s/ctx_desc_pool/stage_desc_pool - Move some explanations to the definition of the guc_stage_desc struct (Chris) v3: - Calculate gemsize with less intermediate steps (Joonas) - Use BIT() macro (Joonas) Signed-off-by:
-
Oscar Mateo authored
Some recent refactoring patches have left the doorbell creation outside the GuC client allocation, which does not make a lot of sense (a client without a doorbell is something useless). Move it back there, and refactor the init_doorbell_hw consequently. Thanks to this, we can do some other improvements, like hoisting the check for GuC submission enabled out of the enable function. v2: Rebased. Signed-off-by:
-
Oscar Mateo authored
Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the doorbell. Kudos to Daniele for finding this out. v2: WARN instead of DRM_ERROR (Joonas) Signed-off-by:
-
Oscar Mateo authored
While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one firware interface field (s/ring_tail/submit_element_info, since it can contain more than just the ring tail). No change in functionality. v2: - Remove reference to "unique user" of the GuC (Daniele) - Keep mention to renaming from "GuC context" to "client" (Daniele) Signed-off-by:
-
Oscar Mateo authored
Prepare for an alternate GuC communication interface. v2: Make a few functions static and name them correctly while we are at it (Oscar), but leave an intel_guc_send_mmio interface for users that require old-style communication. v3: Send intel_uc_init_early back to the top (Michal). Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Oscar Mateo authored
When initializing the GuC log struct, there is an object we need to allocate always, since the GuC needs its address at fw load time. The rest is only needed during runtime, in the sense that we only create if we actually enable GuC logging. Make that distinction explicit by subdividing further the intel_guc_log struct. v2: Call the new struct "runtime", instead of "extras" (Joonas) v3: Check indent (Joonas) Signed-off-by:
-
