summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_debugfs.c
AgeCommit message (Collapse)Author
2015-03-20drm/i915: Relax RPS contraints to allows setting minfreq on idleChris Wilson
When we idle, we set the GPU frequency to the hardware minimum (not user minimum). We introduce a new variable to distinguish between the different roles, and to allow easy tuning of the idle frequency without impacting over aspects of RPS. Setting the minimum frequency should be a safety blanket as the pcu on the GPU should be power gating itself anyway. However, in order for us to do set the absolute minimum frequency, we need to relax a few of our assertions that we do not exceed the user limits. v2: Add idle_freq v3: Init idle_freq for vlv and add a bunch of WARNs Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-20drm/i915: Fix sink crc connector iterationRodrigo Vivi
Regressed by this commit: commit 3455454e18ca3f92c565700539e744c620d8276b Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Mar 3 15:21:56 2015 +0200 drm/i915: Add a for_each_intel_connector macro Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/skl: Updated the i915_frequency_info debugfs functionAkash Goel
Added support for SKL in the i915_frequency_info debugfs function v2: - corrected the handling of reqf (Damien) - Reorderd the platform check for cagf (Ville) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Exit early from psr_status if PSR is not supported by the deviceDamien Lespiau
Static analysis was complaining that a path existed where we could use stat[] uninitialized. Fix this by simplifying the logic to exit early if PSR isn't supported. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915/chv: Add CHV HW status to SSEU statusJeff McGee
Collect the currently enabled counts of slice, subslice, and execution units using the power gate control ack message registers specific to Cherryview. Slice/subslice/EU info and hardware status can now be determined for CHV, so allow the debugfs SSEU status dump to proceed for CHV devices. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Remove ironlake rc6 supportJohn Harrison
Apparently, this has never worked reliably and is currently disabled. Also, the gains are not particularly impressive. Thus rather than try to keep unused code from decaying and having to update it for other driver changes, it was decided to simply remove it. For: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Add debugfs entry for DRRSVandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not V2: [By Ram]: Following details about the active crtc will be filled in seq-file of the debugfs 1. Encoder output type 2. DRRS Support on this CRTC 3. DRRS current state 4. Current Vrefresh Format is as follows: CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_HIGH_RR, Vrefresh: 60 CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_LOW_RR, Vrefresh: 40 CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless V3: [By Ram]: Readability is improved. Another error case is covered [Daniel] V4: [By Ram]: Current status of the Idleness DRRS along with the Front buffer bits are added to the debugfs. [Rodrigo] V5: [By Ram]: Rephrased to make it easy to understand. And format is modified. [Rodrigo] V6: [By Ram]: Modeset mutex are acquired for each crtc along with renaming the Idleness detection states [Daniel] Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: dump full busy_frontbuffer_bits and remove the dubios computed logical state of DRRS - debugfs is about what is fact, developers should reach their own conclusion when debugging issues.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Add a for_each_intel_connector macroAnder Conselvan de Oliveira
We have similar macros for crtcs and encoders, and the pattern happens often enough to justify the macro. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Make for_each_plane() take dev_priv as argumentDamien Lespiau
Implicit usage of local variables in macros isn't exactly the greatest thing in the world, especially when that variable is the drm device and we want to move towards a broader use of the i915 device structure. Let's make for_each_plane() take dev_priv as its first argument then. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Kill intel_crtc->cursor_{width, height} (v2)Matt Roper
The cursor size fields in intel_crtc just duplicate the data from cursor->state.crtc_{w,h} so we don't need them any more. Worse, their use in the watermark code actually introduces a subtle bug since they don't get updated to mirror the state values until the plane commit stage, which is *after* we've already used them to calculate new watermark values. This happens because we had to move watermark updates slightly earlier (outside vblank evasion) in commit commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68 Author: Matt Roper <matthew.d.roper@intel.com> Date: Wed Dec 24 07:59:06 2014 -0800 drm/i915: Refactor work that can sleep out of commit (v7) Dropping the intel_crtc fields and just using the state values (which are properly updated by the time watermark updates happen) should solve the problem. Aside from the actual removal of the struct fields (which are formatted in a way that I couldn't figure out how to match in Coccinelle), the rest of this patch was generated via the following semantic patch: // Drop assignment @@ struct intel_crtc *C; struct drm_plane_state S; @@ ( - C->cursor_width = S.crtc_w; | - C->cursor_height = S.crtc_h; ) // Replace usage @@ struct intel_crtc *C; expression E; @@ ( - C->cursor_width + C->base.cursor->state->crtc_w | - C->cursor_height + C->base.cursor->state->crtc_h | - to_intel_crtc(E)->cursor_width + E->cursor->state->crtc_w | - to_intel_crtc(E)->cursor_height + E->cursor->state->crtc_h ) v2: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joe Konno <joe.konno@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-09Merge tag 'v4.0-rc3' into drm-nextDave Airlie
Linux 4.0-rc3 backmerge to fix two i915 conflicts, and get some mainline bug fixes needed for my testing box Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/intel_display.c
2015-03-09Merge tag 'drm-intel-next-2015-02-27' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next - Y tiling support for scanout from Tvrtko&Damien - Remove more UMS support - some small prep patches for OLR removal from John Harrison - first few patches for dynamic pagetable allocation from Ben Widawsky, rebased by tons of other people - DRRS support patches (Sonika&Vandana) - fbc patches from Paulo - make sure our vblank callbacks aren't called when the pipes are off - various patches all over * tag 'drm-intel-next-2015-02-27' of git://anongit.freedesktop.org/drm-intel: (61 commits) drm/i915: Update DRIVER_DATE to 20150227 drm/i915: Clarify obj->map_and_fenceable drm/i915/skl: Allow Y (and Yf) frame buffer creation drm/i915/skl: Update watermarks for Y tiling drm/i915/skl: Updated watermark programming drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling drm/i915/skl: Allow scanning out Y and Yf fbs drm/i915/skl: Add new displayable tiling formats drm/i915: Remove DRIVER_MODESET checks from modeset code drm/i915: Remove regfile code&data for UMS suspend/resume drm/i915: Remove DRIVER_MODESET checks from gem code drm/i915: Remove DRIVER_MODESET checks in the gpu reset code drm/i915: Remove DRIVER_MODESET checks from suspend/resume code drm/i915: Remove DRIVER_MODESET checks in load/unload/close code drm/i915: fix a printk format drm/i915: Add media rc6 residency file to sysfs drm/i915: Add missing description to parameter in alloc_pt_range drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions ...
2015-03-05Merge tag 'drm-intel-next-2015-02-14' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next - use the atomic helpers for plane_upate/disable hooks (Matt Roper) - refactor the initial plane config code (Damien) - ppgtt prep patches for dynamic pagetable alloc (Ben Widawsky, reworked and rebased by a lot of other people) - framebuffer modifier support from Tvrtko Ursulin, drm core code from Rob Clark - piles of workaround patches for skl from Damien and Nick Hoath - vGPU support for xengt on the client side (Yu Zhang) - and the usual smaller things all over * tag 'drm-intel-next-2015-02-14' of git://anongit.freedesktop.org/drm-intel: (88 commits) drm/i915: Update DRIVER_DATE to 20150214 drm/i915: Remove references to previously removed UMS config option drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5 drm/i915/skl: Fix always true comparison in a revision id check drm/i915/skl: Implement WaEnableLbsSlaRetryTimerDecrement drm/i915/skl: Implement WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken drm/i915: Add process identifier to requests drm/i915/skl: Implement WaBarrierPerformanceFixDisable drm/i915/skl: Implement WaCcsTlbPrefetchDisable:skl drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS drm/i915/skl: Implement WaDisableHDCInvalidation drm/i915/skl: Implement WaDisableLSQCROPERFforOCL drm/i915/skl: Implement WaDisablePartialResolveInVc drm/i915/skl: Introduce a SKL specific init_workarounds() drm/i915/skl: Document that we implement WaRsClearFWBitsAtReset drm/i915/skl: Implement WaSetGAPSunitClckGateDisable drm/i915/skl: Make the init clock gating function skylake specific drm/i915/skl: Provide a gen9 specific init_render_ring() drm/i915/skl: Document the WM read latency W/A with its name drm/i915/skl: Also detect eDRAM on SKL ...
2015-03-05drm/mm: Support 4 GiB and larger rangesThierry Reding
The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. [airlied: fix i915 warnings and coloring callback] Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> fixupo
2015-02-26drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functionsAkash Goel
The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register are stored, initially by the Driver, inside the dev_priv->rps structure. Since these values are expected to remain same throughout, there is no real need to read this register, on dynamic basis, from certain debugfs/sysfs functions and the values can be instead retrieved from the dev_priv->rps structure when needed. For the i915_frequency_info debugfs interface, the frequency values from the RP_STATE_CAP register only should be used, to indicate the actual Hw state, since it is principally used for the debugging purpose. v2: Reverted the changes in i915_frequency_info function, to continue report back the frequency values, as per the actual Hw state (Chris) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-25drm/i915: Complete page table structuresBen Widawsky
Move the remaining members over to the new page table structures. This can be squashed with the previous commit if desire. The reasoning is the same as that patch. I simply felt it is easier to review if split. v2: In lrc: s/ppgtt->pd_dma_addr[i]/ppgtt->pdp.page_directory[i].daddr/ v3: Rebase. v4: Rebased after s/page_tables/page_table/. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-25drm/i915: cleanup some indentingDan Carpenter
Static checkers complain that we should probably add curly braces because, from the indenting, it looks like seq_printf() should be inside the list_for_each_entry() loop. But the code is actually correct, it's just the indenting which is off. Besides fixing the indenting on seq_printf(), I did add curly braces, because generally mult-line indents should have curly braces to make them more readable. The unintended indent was left behind and not unindented in commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-23drm/i915/skl: Add SKL HW status to SSEU statusJeff McGee
Add a new section to the 'i915_sseu_status' debugfs entry to report the currently enabled counts of slice, subslice, and execution units on the device. The count of enabled subslice per slice represents the most enabled subslice on any one slice for devices where imbalances may exist. Similarly, the count of enabled EU per subslice represents the most enabled EU on any one subslice. Collect this device status for Skylake by reading the Gen9 power gate control ack message registers. Power gate control operates on EU in pairs, therefore our reported counts of enabled EU can be overestimated by one for each pair in which one EU is fused-off. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-23drm/i915/skl: Determine SKL slice/subslice/EU infoJeff McGee
Read fuse registers to determine the available slice total, subslice total, subslice per slice, EU total, and EU per subslice counts of the SKL device. The EU per subslice attribute is more precisely defined as the maximum EU available on any one subslice, since available EU counts may vary across subslices due to fusing. Set flags indicating the SKL device's slice/subslice/EU (SSEU) power gating capability. Make all values available via debugfs entry 'i915_sseu_status'. v2: Several small clean-ups suggested by Damien. Most notably, used smaller types for the new device info fields to reduce memory usage and improved the clarity/readability of the method used to extract attribute values from the fuse registers. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-23drm/i915: Switch to drm_crtc variants of vblank functionsDaniel Vetter
Where possible right now. Just a small step towards nirvana ... v2: git add. Uggh. Noticed by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-02-13drm/i915: Show frame buffer modifier in debug infoTvrtko Ursulin
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-13drm/i915: Introduce intel_set_rps()Ville Syrjälä
Replace the valleyview_set_rps() and gen6_set_rps() calls with intel_set_rps() which itself does the IS_VALLEYVIEW() check. The code becomes simpler since the callers don't have to do this check themselves. Most of the change was performe with the following semantic patch: @@ expression E1, E2, E3; @@ - if (IS_VALLEYVIEW(E1)) { - valleyview_set_rps(E2, E3); - } else { - gen6_set_rps(E2, E3); - } + intel_set_rps(E2, E3); Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps() static was done manually. Also valleyview_set_rps() had to be moved a bit avoid a forward declaration. v2: Use a less greedy semantic patch Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-09drm/i915: Take runtime pm reference on hangcheck_infoMika Kuoppala
We read the coherent current seqno and actual head from ring. For hardware access we need to take runtime_pm reference. Get hardware specific values with runtime reference held and print them first to emphasize hw state vs bookkeepping. v2: Reorder output according to hw access (Chris) remove superfluous locking (Daniel) Testcase: igt/pm_rpm/debugfs-read Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88910 Tested-by: Ding Heng <hengx.ding@intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-01-29drm/i915: Remove nested work in gpu error handlingMika Kuoppala
Now when we declare gpu errors only through our own dedicated hangcheck workqueue there is no need to have a separate workqueue for handling the resetting and waking up the clients as the deadlock concerns are no more. The only exception is i915_debugfs::i915_set_wedged, which triggers error handling through process context. However as this is only used through test harness it is responsibility for test harness not to introduce hangs through both debug interface and through hangcheck mechanism at the same time. Remove gpu_error.work and let the hangcheck work do the tasks it used to. v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-28drm/i915: Be consistent on printing seqnosMika Kuoppala
We have had %x and %u intermixed. Bring everything in line and use %x Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-28drm/i915: Display current hangcheck status in debugfsChris Wilson
For example, /sys/kernel/debug/dri/0/i915_hangcheck_info: Hangcheck active, fires in 15887800ms render ring: seqno = -4059 [current -583] action = 2 score = 0 ACTHD = 1ee8 [current 21f980] max ACTHD = 0 v2: Include expiration ETA. Can anyone spot a problem? v3: Convert for workqueued hangcheck (Mika) v4: Print seqnos as unsigned ints (Ville) v5: Print seqnos as hex (Chris) Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Use intel_gpu_freq() and intel_freq_opcode()Ville Syrjälä
Replace all the vlv_gpu_freq(), vlv_freq_opcode(), *GT_FREQUENCY_MULTIPLIER, and /GT_FREQUENCY_MULTIPLIER instances with intel_gpu_freq() and intel_freq_opcode() calls. Most of the change was performed with the following semantic patch: @@ expression E; @@ ( - E * GT_FREQUENCY_MULTIPLIER + intel_gpu_freq(dev_priv, E) | - E *= GT_FREQUENCY_MULTIPLIER + E = intel_gpu_freq(dev_priv, E) | - E /= GT_FREQUENCY_MULTIPLIER + E = intel_freq_opcode(dev_priv, E) | - do_div(E, GT_FREQUENCY_MULTIPLIER) + E = intel_freq_opcode(dev_priv, E) ) @@ expression E1, E2; @@ ( - vlv_gpu_freq(E1, E2) + intel_gpu_freq(E1, E2) | - vlv_freq_opcode(E1, E2) + intel_freq_opcode(E1, E2) ) @@ expression E1, E2, E3, E4; @@ ( - if (IS_VALLEYVIEW(E1)) { - E2 = intel_gpu_freq(E3, E4); - } else { - E2 = intel_gpu_freq(E3, E4); - } + E2 = intel_gpu_freq(E3, E4); | - if (IS_VALLEYVIEW(E1)) { - E2 = intel_freq_opcode(E3, E4); - } else { - E2 = intel_freq_opcode(E3, E4); - } + E2 = intel_freq_opcode(E3, E4); ) One hunk was manually undone as intel_gpu_freq() ended up calling itself. Supposedly it would be possible to exclude certain functions via !=~, but I couldn't get that to work. Also the removal of vlv_gpu_freq() and vlv_opcode_freq() compat wrappers was done manually. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915/skl: Adding power domains for AUX controllersSatheeshakrishna M
Adding new power doamins for AUX controllers v2: Added new power domains in power_domain_str per Imre's comment v3: Added AUX power domains to older platforms v4: Rebase on top of POWER_DOMAIN_PLLS. v5: Modified to address review comments from Imre Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Rename i915_gen6_forcewake_count_infoMika Kuoppala
There are multiple forcewake domains in newer architectures. Rename 'i915_gen6_forcewake_count_info' debugfs entry to 'i915_forcewake_domains' to reflect this. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Rename the forcewake get/put functionsMika Kuoppala
We have multiple forcewake domains now on recent gens. Change the function naming to reflect this. v2: More verbose names (Chris) v3: Rebase v4: Rebase v5: Add documentation for forcewake_get/put Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Consolidate forcewake codeMika Kuoppala
As we now have forcewake domains, take advantage of it by putting the differences in gen fw handling in data rather than in code. In past we have opencoded this quite extensively as the fw handling is in the fast path. There has also been a lot of cargo-culted copy'n'pasting from older gens to newer ones. Now when the releasing of the forcewake is done by deferred timer, it gives chance to consolidate more. Due to the frequency of actual hw access being significantly less. Take advantage of this and generalize the fw handling code as much as possible. But we still aim to keep the forcewake sequence particularities for each gen intact. So the access pattern to fw engines should remain the same. v2: - s/old_ack/clear_ack (Chris) - s/post_read/posting_read (Chris) - less polite commit msg (Chris) v3: - rebase - check and clear wake_count in init v4: - fix posting reads for gen8 (PRTS) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Reduce duplicated forcewake logicChris Wilson
Introduce a structure to track the individual forcewake domains and use that to eliminate duplicate logic. v2: - Rebase on latest dinq (Mika) - for_each_fw_domain macro (Mika) - Handle reset atomically, keeping the timer running (Mika) - for_each_fw_domain parameter ordering (Chris) - defer timer on new register access (Mika) v3: - Fix forcewake_reset/get race by waiting pending timers v4: - cond_resched and verbose warning on timer deletion (Chris) - need to run pending timers manually on reset Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Assert that runtime pm is active on user fw accessChris Wilson
On user forcewake access, assert that runtime pm reference is held. Fix and cleanup the callsites accordingly. v2: Remove intel_runtime_pm_get() rebasehap (Deepak) v3: use drivers own runtime state tracking as pm_runtime_active() will return wrong results when we are in resume callchain (Mika) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_requestNick Hoath
Move all remaining elements that were unique to execlists queue items in to the associated request. Issue: VIZ-4274 v2: Rebase. Fixed issue of overzealous freeing of request. v3: Removed re-addition of cleanup work queue (found by Daniel Vetter) v4: Rebase. v5: Actual removal of intel_ctx_submit_request. Update both tail and postfix pointer in __i915_add_request (found by Thomas Daniel) v6: Removed unrelated changes Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Reviewed-by: Thomas Daniel <thomas.daniel@intel.com> [danvet: Reformat comment with strange linebreaks.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Removed duplicate members from submit_requestNick Hoath
Where there were duplicate variables for the tail, context and ring (engine) in the gem request and the execlist queue item, use the one from the request and remove the duplicate from the execlist queue item. Issue: VIZ-4274 v1: Rebase v2: Fixed build issues. Keep separate postfix & tail pointers as these are used in different ways. Reinserted missing full tail pointer update. Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Reviewed-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira
To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: PSR link standby at debugfsRodrigo Vivi
It is useful to know at debug time if we are keeping main link on. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Implement a framework for batch buffer poolsBrad Volkin
This adds a small module for managing a pool of batch buffers. The only current use case is for the command parser, as described in the kerneldoc in the patch. The code is simple, but separating it out makes it easier to change the underlying algorithms and to extend to future use cases should they arise. The interface is simple: init to create an empty pool, fini to clean it up, get to obtain a new buffer. Note that all buffers are expected to be inactive before cleaning up the pool. Locking is currently based on the caller holding the struct_mutex. We already do that in the places where we will use the batch pool for the command parser. v2: - s/BUG_ON/WARN_ON/ for locking assertions - Remove the cap on pool size - Switch from alloc/free to init/fini v3: - Idiomatic looping structure in _fini - Correct handling of purged objects - Don't return a buffer that's too much larger than needed v4: - Rebased to latest -nightly v5: - Remove _put() function and clean up comments to match v6: - Move purged check inside the loop (danvet, from v4 1/7 feedback) v7: - Use single list instead of two. (Chris W) - s/active_list/cache_list - Squashed in debug patches (Chris W) drm/i915: Add a batch pool debugfs file It provides some useful information about the buffers in the global command parser batch pool. v2: rebase on global pool instead of per-ring pools v3: rebase drm/i915: Add batch pool details to i915_gem_objects debugfs To better account for the potentially large memory consumption of the batch pool. v8: - Keep cache in LRU order (danvet, from v6 1/5 feedback) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-15drm/i915: Infrastructure for supporting different GGTT views per objectTvrtko Ursulin
Things like reliable GGTT mappings and mirrored 2d-on-3d display will need to map objects into the same address space multiple times. Added a GGTT view concept and linked it with the VMA to distinguish between multiple instances per address space. New objects and GEM functions which do not take this new view as a parameter assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the previous behaviour. This now means that objects can have multiple VMA entries so the code which assumed there will only be one also had to be modified. Alternative GGTT views are supposed to borrow DMA addresses from obj->pages which is DMA mapped on first VMA instantiation and unmapped on the last one going away. v2: * Removed per view special casing in i915_gem_ggtt_prepare / finish_object in favour of creating and destroying DMA mappings on first VMA instantiation and last VMA destruction. (Daniel Vetter) * Simplified i915_vma_unbind which does not need to count the GGTT views. (Daniel Vetter) * Also moved obj->map_and_fenceable reset under the same check. * Checkpatch cleanups. v3: * Only retire objects once the last VMA is unbound. v4: * Keep scatter-gather table for alternative views persistent for the lifetime of the VMA. * Propagate binding errors to callers and handle appropriately. v5: * Explicitly look for normal GGTT view in i915_gem_obj_bound to align usage in i915_gem_object_ggtt_unpin. (Michel Thierry) * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry) * Removed stray semi-colon in i915_gem_object_set_cache_level. For: VIZ-4544 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Michel Thierry <michel.thierry@intel.com> [danvet: Drop hunk from i915_gem_shrink since it's just prettification but upsets a __must_check warning.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-15drm/i915: Use BUILD_BUG if possible in the i915 WARN_ONDaniel Vetter
Faster feedback to errors is always better. This is inspired by the addition to WARN_ONs to mask/enable helpers for registers to make sure callers have the arguments ordered correctly: Pretty much always the arguments are static. We use WARN_ON(1) a lot in default switch statements though where we should always handle all cases. So add a new macro specifically for that. The idea to use __builtin_constant_p is from Chris Wilson. v2: Use the ({}) gcc-ism to avoid the static inline, suggested by Dave. My first attempt used __cond as the temp var, which is the same used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so sprinkle i915 into the name. Also use a temporary variable to only evaluate the condition once, suggested by Damien. v3: It's crazy but apparently 32bit gcc can't compile out the BUILD_BUG_ON in a lot of cases and just falls over. I have no idea why, but until clue grows just disable this nifty idea on 32bit builds. Reported by 0-day builder. v4: Got it all wrong, apparently its the gcc version. We need 4.9+. Now reported by Imre. v5: Chris suggested to add the case to MISSING_CASE for speedier debug. v6: Even some gcc 4.9 versions don't see through the maze, so give up for now. Keep the skeleton and MISSING_CASE stuff though. Cc: Imre Deak <imre.deak@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-10drm/i915: Protect against leaks in pipe_crc_set_sourceDaniel Vetter
Stupid userspace (there is no evil userspace in debugfs by assumption) might provoke a leak since we allocate the new array without holding any locks. Drop in an unconditional kfree to deal with this - kfree can handle NULL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-10drm/i915: Make i915_pipe_crc_read() oops proofVille Syrjälä
Currently i915_pipe_crc_read() will drop pipe_crc->lock for the entire duration of the copy_to_user() loop, which means it'll access pipe_crc->entries without any protection. If another thread sneaks in and frees pipe_crc->entries the code will oops. Reorganize the code to hold the lock around everything except copy_to_user(). After the copy the lock is reacquired and the the number of available entries is rechecked. Since this is a debug feature simplify the error handling a bit by consuming the crc entry even if copy_to_user() would fail. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-10drm/i915: Allocate the pipe_crc->entires with kcalloc()Ville Syrjälä
pipe_crc->entries[] is an array so allocate with kcalloc() instead of kzalloc(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-10drm/i915: Protect pipe_crc->entries updateVille Syrjälä
Set the pipe_crc->entries pointer while holding the relevant spinlock. Doesn't matter too much since a spurious pipe crc interrupt would then just update one entry but later that entry would get cleared when head and tail are both set to 0. But being a bit more paranoid doesn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-10drm/i915: Fix CRC support for DP port D on CHVVille Syrjälä
Add the missing CRC control register value for DP port D on CHV. Untested as I don't have a CHV machine with DP on port D. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Add a check to only allow DP D on chv, not vlv.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-10drm/i915: Engage the DP scramble reset for pipe C on CHVVille Syrjälä
To get stable CRCs from the DP CRC source we need to reset the scrambler for each frame. Enable the reset feature when grabbing CRCs for pipe C on CHV. Pipes A and B were already covered due sharing the code with VLV. We can safely extend PIPE_SCRAMBLE_RESET_MASK to deal with CHV since the extra bit was MBZ on the older platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-04drm/i915: Don't display nonsensical values in i915_ddb_info on gen < 9Damien Lespiau
When playing around with debugfs and a HSW machine I noticed that we were displaying some garbled value in i915_ddb_info. This debugfs file is only meaningful for gen9+, so don't display anything on earlier platforms. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Remove redundant flip_work->flip_queued_ringDaniel Vetter
Similar to the patch from John which removed obj->ring. Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Thomas Daniel <Thomas.Daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-03drm/i915: Remove the now redundant 'obj->ring'John Harrison
The ring member of the object structure was always updated with the last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is now a direct copy of obj->last_read_req->ring. This makes it somewhat redundant and potentially misleading (especially as there was no comment to explain its purpose). This checkin removes the redundant field. Many uses were simply testing for non-null to see if the object is active on the GPU. Some of these have been converted to check 'obj->active' instead. Others (where the last_read_req is about to be used anyway) have been changed to check obj->last_read_req. The rest simply pull the ring out from the request structure and proceed as before. For: VIZ-4377 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed'John Harrison
Almost everywhere that caled i915_seqno_passed() was really asking 'has the given seqno popped out of the hardware yet?'. Thus it had to query the current hardware seqno and then do a signed delta comparison (which copes with wrapping around zero but not with seqno values more than 2GB apart, although the latter is unlikely!). Now that the majority of seqno instances have been replaced with request structures, it is possible to convert this test to be request based as well. There is now a 'i915_gem_request_completed()' function which takes a request and returns true or false as appropriate. Note that this currently just wraps up the original _passed() test but a later patch in the series will reduce this to simply returning a cached internal value, i.e.: _completed(req) { return req->completed; }' This checkin converts almost all _seqno_passed() calls. The only one left is in the semaphore code which still requires seqnos not request structures. For: VIZ-4377 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com> [danvet: Drop hunk touching the trace_irq code since I've dropped the patch which converts that, and resolve resulting conflict.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>