aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2014-07-10drm/i915: ->disable hook for WRPLLsDaniel Vetter2-14/+20
Currently still with a redudant WARN_ON in there, the common shared dpll code will take care of this in the future. Also we need to flip the switch for the transitional hack now to make sure that we disable the right pll. Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: State readout support for WRPLLsDaniel Vetter5-0/+31
Still tacked onto the side, but slowly getting there. v2: Don't forget the debugfs file. v3 (from Paulo): Don't forget to check the power domains. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: add POWER_DOMAIN_PLLSPaulo Zanoni4-0/+14
And get/put it when needed. The special thing about this commit is that it will now return false in ibx_pch_dpll_get_hw_state() in case the power domain is not enabled. This will fix some WARNs we have when we run pm_rpm on SNB. Testcase: igt/pm_rpm Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=80463 Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Document that the pll->mode_set hook is optionalDaniel Vetter1-0/+2
The WRPLLs won't use them. Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Basic shared dpll support for WRPLLsDaniel Vetter3-10/+34
Just filing in names and ids, but not yet officially registering them so that the hw state cross checker doesn't completely freak out about them. Still since we do already read out and cross check config->shared_dpll the basics are now there to flesh out the wrpll shared dpll implementation. The idea is now to roll out all the callbacks step-by-step and then at the end switch to the shared dpll framework. This way hw and sw changes are clearly separated. Signed-off-by: Daniel Vetter <[email protected]> [imre: added const to hsw_ddi_pll_names (Damien)] Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Precompute static ddi_pll_sel values in encodersDaniel Vetter3-35/+26
This way only the dynamic WRPLL selection for hdmi ddi mode is done in intel_ddi_pll_select. v2: Don't clobber the precomputed values when selecting clocks fro hdmi encoders. v3 (from Paulo): Rebase on top of the s/IS_HASWELL/HAS_DDI/ patch. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: BDW also has special-purpose DP DDI clocksPaulo Zanoni1-1/+1
Don't let it fall in the HAS_PCH_SPLIT() case. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: State readout and cross-checking for ddi_pll_selDaniel Vetter3-55/+34
To make things a bit more manageable extract a new function for reading out common ddi port state. This means a bit of duplication between encoders and the core since both look at the same registers, but doesn't seem worth to make a fuzz about. We can also remove the state readout code in intel_ddi_setup_hw_pll_state. That code is only called from the hardware take over and not the cross check code, and only after the crtc state is reconstructed. So we can rely on an accurate value of crtc->config.ddi_pll_sel already. Compared to the old code also trust the hw state more and don't special-case port A - we want to cross-check the actual-state, not bake in our own assumptions about how this is supposed to all be linked up. v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Move ddi_pll_sel into the pipe configDaniel Vetter2-19/+20
Just boring sed job for preparation. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Add a debugfs file for the shared dpll stateDaniel Vetter1-0/+26
Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Move SPLL disabling into hsw_crt_post_disableDaniel Vetter2-7/+15
Similar to how the ->crtc_mode_set hook should touch the hardware to enable anything the ->crtc_off hook should disable anything in the hardware. Otherwise runtime pm for dpms will not work. Currently the only things left int the haswell_crtc_off hook is disabling the ddi plls. We can't move the WRPLL enabling out yet because the current ddi pll sharing code used by the haswell code doesn't separately track active users and overall users. This must be fixed by porting it to the generic shared display pll framework, which is powerful enough. But the SPLL source is only used by the crt encoder and so can be moved already. We only need to make sure that the ddi port E is already off, which hsw_fdi_disable does by calling intel_ddi_post_disable. With this the code reorg to shuffle hsw fdi/lpt specific code into a new hsw-specific crt encoder type is now finally complete. Signed-off-by: Daniel Vetter <[email protected]> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Move the SPLL enabling into hsw_crt_pre_enableDaniel Vetter2-18/+14
The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only function that still touches the hardware state from the crtc mode_set callback on hsw. Since the SPLL isn't ever shared we can easily take it out into the hsw crt encoder functions. Temporarily we'll loose a bit of WARN_ON coverage with this, but once the WRPLLs are switched over that will be restored. For the SPLL selection add a WARN in the hsw fdi link training code. Signed-off-by: Daniel Vetter <[email protected]> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: ddi: move pch cleanup before encoder->post_disableImre Deak1-4/+4
This is needed by an upcoming patch that moves the PCH/CRT PLL disabling into the post_disable hook, after which we want to keep the modeset sequence at its current state. At this point this won't have an effect since the PCH/CRT post_disable hook is atm a NOP. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: ddi: move pch setup after encoder->pre_enableImre Deak1-6/+5
This is needed by an upcoming patch that moves the PCH/CRT PLL enabling into the pre_enable hook, after which we want to keep the modeset sequence at its current state. At this point this won't have an effect since the PCH/CRT pre_enable hook is atm a NOP. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Clean up WRPLL/SPLL #definesDaniel Vetter2-9/+10
Luckily the bit definitions match, but it's still confusing to use one when handling the other. So sprinkle some OCD over the #defines to make them match and use the right version in each place. Maybe we should unify these definitions completely, but that can always be done sometime in the future. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Remove spll_refcount for hswDaniel Vetter2-29/+13
SPLL would be a reference clock we could potentially share, especially if we want to use the SSC mode. But currently we don't, so let's rip out this complexity for a simpler conversion to the new display pll framework. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Check hw state in assert_can_disable_lcpllDaniel Vetter1-4/+3
All the other checks also check hw state, so checking our software refcounts for the plls looks a bit odd. Also this will simplify the conversion over to the shared dpll framework, which itself has massive amounts of checks to make sure that we never leave a display pll enabled when we shouldn't. So after that conversion we should stil have a good enough coverage of asserts for entering pc8/runtime pm on hsw/bdw. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Add a couple WARN()'s to catch missing locksMatt Roper1-0/+4
Add !mutex_is_locked() checks to intel_pin_and_fence_fb_obj() and intel_unpin_fb_obj() to help catch failures to grab struct_mutex when operating on fb objects. Signed-off-by: Matt Roper <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: Add missing locking to primary plane handlersMatt Roper1-2/+15
intel_primary_plane_{setplane,disable} were lacking struct_mutex locking around their GEM operations. Signed-off-by: Matt Roper <[email protected]> Reported-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: get/put runtime PM at i915_semaphore_statusPaulo Zanoni1-0/+2
Otherwise we will print some WARNs when we read registers and the machine is suspended. Testcase: igt/pm_rpm/debugfs-read Cc: Ben Widawsky <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: fix D_COMP usage on BDWPaulo Zanoni2-6/+20
On HSW, the D_COMP register can be accessed through the mailbox (read and write) or through MMIO on a MCHBAR offset (read only). On BDW, the access should be done through MMIO on another address. So to account for all these cases, create hsw_read_dcomp() with the correct implementation for reading, and also fix hsw_write_dcomp() to do the correct thing on BDW. With this patch, we can now get back from the PC8+ state on BDW. We were previously getting a black screen and lots of dmesg errors. Please notice that the bug only happens when you actually reach the PC8+ states, not when you only allow it. Testcase: igt/pm_rpm/rte Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-10drm/i915: fix hsw_write_dcomp() error messagePaulo Zanoni1-1/+1
That function can be used to write anything on D_COMP, not just disable it, so print a more appropriate message. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: remove i915_rstdby_delays debugfs entryMika Kuoppala1-24/+0
CHV hard hangs on reading on 0x11100 References: https://bugs.freedesktop.org/show_bug.cgi?id=80893 Signed-off-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: remove i915_gfxec debugfs entryMika Kuoppala1-21/+0
CHV hard hangs on reading on 0x112f4. References: https://bugs.freedesktop.org/show_bug.cgi?id=80893 Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: remove i915_inttoext_table debugfs entryMika Kuoppala1-30/+0
CHV hard hangs on reading these registers. As these have not been used since cantiga & ilk, remove the debugfs entry. References: https://bugs.freedesktop.org/show_bug.cgi?id=80893 Suggested-by: Jesse Barnes <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: remove i915_delayedfreq_table debugfs entryMika Kuoppala1-27/+0
CHV hard hangs on reading these registers. As these have not been used since cantiga & ilk, remove the debugfs entry. References: https://bugs.freedesktop.org/show_bug.cgi?id=80893 Suggested-by: Jesse Barnes <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: Make use of intel_fb_obj() (v2)Matt Roper3-63/+48
This should hopefully simplify the display code slightly and also solves at least one mistake in intel_pipe_set_base() where to_intel_framebuffer(fb)->obj is referenced during local variable initialization, before 'if (!fb)' gets checked. Potential uses of this macro were identified via the following Coccinelle patch: @@ expression E; @@ * to_intel_framebuffer(E)->obj @@ expression E; identifier I; @@ I = to_intel_framebuffer(E); ... * I->obj v2: Rewrite some NULL tests in terms of the obj rather than the fb. Also add a WARN() if trying to pageflip with a disabled primary plane. [Suggested by Chris Wilson] Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: Introduce intel_fb_obj() macroMatt Roper1-0/+1
Add an intel_fb_obj() macro that returns the GEM object associated with a DRM framebuffer. This macro is safe to call on NULL framebuffers (a NULL object pointer will be returned in this case). Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915/vlv: T12 eDP panel timing enforcement during rebootClint Taylor2-0/+44
The panel power sequencer on vlv doesn't appear to accept changes to its T12 power down duration during warm reboots. This change forces a delay for warm reboots to the T12 panel timing as defined in the VBT table for the connected panel. Ver2: removed redundant pr_crit(), commented magic value for pp_div_reg Ver3: moved SYS_RESTART check earlier, new name for pp_div. Ver4: Minor issue changes Ver5: Move registration of reboot notifier to edp_connector_init, Added warning comment to handler about lack of PM notification. Signed-off-by: Clint Taylor <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: Only unbind vgacon, not other console driversDaniel Vetter1-2/+3
The console subsystem only provides a function to switch to a given console, but we want to actually only switach away from vgacon. Unconditionally switching to the dummy console resulted in switching away from fbcon in multi-gpu setups when other gpu drivers are loaded before i915. Then either the reinitialization of fbcon when i915 registers its fbdev emulation or the teardown of the fbcon driver killed the machine. So only switch to the dummy console when it's required. Kudos to Chris for the original idea, I've only refined it a bit to still unregister vgacon even when it's currently unused. This regression has been introduced in commit a4de05268e674e8ed31df6348269e22d6c6a1803 Author: Daniel Vetter <[email protected]> Date: Thu Jun 5 16:20:46 2014 +0200 drm/i915: Kick out vga console Reported-and-tested-by: Ed Tomlinson <[email protected]> Cc: Chris Wilson <[email protected]> Cc: David Herrmann <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: David Herrmann <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: Don't clobber the GTT when it's within stolen memoryVille Syrjälä2-0/+47
On most gen2-4 platforms the GTT can be (or maybe always is?) inside the stolen memory region. If that's the case, reduce the size of the stolen memory appropriately to make make sure we don't clobber the GTT. v2: Deal with gen4 36 bit physical address Signed-off-by: Ville Syrjälä <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80151 Acked-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915/vlv: Update the DSI ULPS entry/exit sequenceShobhit Kumar1-14/+15
We should keep DEVICE_READY bit set in the ULPS enter sequence. In exit sequence also we should set DEVICE_READY, but thats causing blankout for me. Also exit sequence is simplified as per hw team recommendation. This should fix - [drm:intel_dsi_clear_device_ready] *ERROR* DSI LP not going Low Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80818 Signed-off-by: Shobhit Kumar <[email protected]> Tested-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-07-09drm/i915/vlv: DPI FIFO empty check is not neededShobhit Kumar1-6/+0
While sending DPI SHUTDOWN command, we cannot wait for FIFO empty as pipes are not disabled at that time. In case of MIPI we disable port first and send SHUTDOWN command while pipe is still running and FIFOs will not be empty, causing spurious error log Signed-off-by: Shobhit Kumar <[email protected]> Tested-by: Chris Wilson <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2014-07-09drm/i915: Toshiba CB35 has a controllable backlightScot Doyle1-0/+3
The Toshiba CB35 Chromebook (with Celeron 2955U CPU) has a controllable backlight although its VBT reports otherwise. Apply quirk to ignore the backlight presence check during backlight setup. Patch tested by author on Toshiba CB35. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Signed-off-by: Scot Doyle <[email protected]> CC: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Cc: [email protected] # 3.15 only [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: Acer C720 and C720P have controllable backlightsScot Doyle1-0/+3
The Acer C720 and C720P Chromebooks (with Celeron 2955U CPU) have a controllable backlight although their VBT reports otherwise. Apply quirk to ignore the backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Tested-by: James Duley <[email protected]> Tested-by: Michael Mullin <[email protected]> Signed-off-by: Scot Doyle <[email protected]> CC: Jani Nikula <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Cc: [email protected] # 3.15 only [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09drm/i915: quirk asserts controllable backlight presence, overriding VBTScot Doyle3-2/+15
commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <[email protected]> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT caused a regression on machines with a misconfigured VBT. Add a quirk to assert the presence of a controllable backlight. Use it to ignore the VBT backlight presence check during backlight setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813 Tested-by: James Duley <[email protected]> Tested-by: Michael Mullin <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Scot Doyle <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Cc: [email protected] # 3.15 only [danvet: Add cc: stable because the regressing commit is in 3.15.] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-09Merge tag 'drm-intel-next-2014-06-20' of ↵Dave Airlie33-817/+2315
git://anongit.freedesktop.org/drm-intel into drm-next - Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and flip events. This is prep work for proper PSR support and should also be useful for DRRS&fbc. - Runtime suspend hardware on system suspend to support the new SOix sleep states, from Jesse. - PSR updates for broadwell (Rodrigo) - Universal plane support for cursors (Matt Roper), including core drm patches. - Prefault gtt mappings (Chris) - baytrail write-enable pte bit support (Akash Goel) - mmio based flips (Sourab Gupta) instead of blitter ring flips - interrupt handling race fixes (Oscar Mateo) And old, not yet merged features from the previous round: - rps/turbo support for chv (Deepak) - some other straggling chv patches (Ville) - proper universal plane conversion for the primary plane (Matt Roper) - ppgtt on vlv from Jesse - pile of cleanups, little fixes for insane corner cases and improved debug support all over * tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits) drm/i915: Update DRIVER_DATE to 20140620 drivers/i915: Fix unnoticed failure of init_ring_common() drm/i915: Track frontbuffer invalidation/flushing drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: don't take runtime PM reference around freeze/thaw drm/i915: use runtime irq suspend/resume in freeze/thaw drm/i915: Properly track domain of the fbcon fb drm/i915: Print obj->frontbuffer_bits in debugfs output drm/i915: Introduce accurate frontbuffer tracking drm/i915: Drop schedule_back from psr_exit drm/i915: Ditch intel_edp_psr_update drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Remove ctx->last_ring drm/i915/chv: Ack interrupts before handling them (CHV) drm/i915/bdw: Ack interrupts before handling them (GEN8) drm/i915/vlv: Ack interrupts before handling them (VLV) drm/i915: Ack interrupts before handling them (GEN5 - GEN7) drm/i915: Don't BUG_ON in i915_gem_obj_offset drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info drm/i915: Add some L3 registers to the parser whitelist ... Conflicts: drivers/gpu/drm/i915/i915_drv.c
2014-07-08dma-buf: use reservation objectsMaarten Lankhorst1-1/+2
This allows reservation objects to be used in dma-buf. it's required for implementing polling support on the fences that belong to a dma-buf. Signed-off-by: Maarten Lankhorst <[email protected]> Acked-by: Mauro Carvalho Chehab <[email protected]> #drivers/media/v4l2-core/ Acked-by: Thomas Hellstrom <[email protected]> #drivers/gpu/drm/ttm Acked-by: Sumit Semwal <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Vincent Stehlé <[email protected]> #drivers/gpu/drm/armada/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2014-07-08drm/i915: HWS must be in the mappable region for g33Chris Wilson1-1/+15
On g33, the documentation states "HWS_PGA: Format = Bits 28:12 of graphics memory address (bits 31:29 MBZ)." which translates to that the address of the HWS must be below 256MiB, which is conveniently the mappable aperture. This also appears to be true (but not documented as so) for gen4 and gen5. To generalise we force it into the low mappable region for all non-LLC platforms. If we locate the HWS at the top of the GTT the machine will hard hang during boot (fails on pnv, gm45, ilk and byt, but works on snb, ivb, hsw). v2: Add comments to explain why use PIN_MAPPABLE even though we have no intention of mapping the object. (Ville) Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915/vlv: WA for Turbo and RC6 to work together.Deepak S4-4/+167
With RC6 enabled, BYT has an HW issue in determining the right Gfx busyness. WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide on increasing/decreasing the freq. This logic will monitor C0 counters of render/media power-wells over EI period and takes necessary action based on these values v2: Refactor duplicate code. (Ville) v3: Reformat the comments. (Ville) v4: Enable required counters and remove unwanted code (Ville) v5: Added frequency change acceleration support and remove kernel-doc style comments. (Ville) v6: Updated comment section and Fix w/a comment. (Ville) Signed-off-by: Deepak S <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Use mmio flips to change tiling mode on BaytrailChris Wilson1-0/+6
For whatever reason, MI_DISPLAY_FLIP fails to change tiling mode on Baytrail, so just use CPU driven mmio flips instead. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76176 Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Disable RCS flips on IvybridgeChris Wilson1-0/+2
We currently see random GPU hangs when using RCS flips with multiple pipes on Ivybridge. Now that we have mmio flips, we can fairly cheaply fallback to using CPU driven flips instead. Signed-off-by: Chris Wilson <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77104 Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Extract the actual workload submission mechanism from execbufferOscar Mateo1-136/+162
So that we isolate the legacy ringbuffer submission mechanism, which becomes a good candidate to be abstracted away. This is prep-work for Execlists (which will its own workload submission mechanism). No functional changes. Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Generalize intel_ring_get_tail to take a ringbufOscar Mateo2-4/+4
Again, it's low-level enough to simply take a ringbuf and nothing else. Trivial change. Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Generalize ring_space to take a ringbufOscar Mateo1-7/+6
It's simple enough that it doesn't need to know anything about the engine. Trivial change. Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Extract ringbuffer destroy & generalize alloc to take a ringbufOscar Mateo1-10/+16
More prep work: with Execlists, we are going to start creating a lot of extra ringbuffers soon, so these functions are handy. No functional changes. v2: rename allocate/destroy_ring_buffer to alloc/destroy_ringbuffer_obj because the name is more meaningful and to mirror a similar function in the context world: i915_gem_alloc_context_obj(). Change suggested by Brad Volkin. Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Add kerneldoc comments to the intel_context structOscar Mateo1-0/+17
A bit of background on the context elements. Cc: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Emphasize that ctx->id is merely a user handleOscar Mateo5-12/+12
This is an Execlists preparatory patch, since they make context ID become an overloaded term: - In the software, it was used to distinguish which context userspace was trying to use. - In the BSpec, the term is used to describe the 20-bits long field the hardware uses to it to discriminate the contexts that are submitted to the ELSP and inform the driver about their current status (via Context Switch Interrupts and Context Status Buffers). Initially, I tried to make the different meanings converge, but it proved impossible: - The software ctx->id is per-filp, while the hardware one needs to be globally unique. - Also, we multiplex several backing states objects per intel_context, and all of them need unique HW IDs. - I tried adding a per-filp ID and then composing the HW context ID as: ctx->id + file_priv->id + ring->id, but the fact that the hardware only uses 20-bits means we have to artificially limit the number of filps or contexts the userspace can create. The ctx->user_handle renaming bits are done with this Cocci patch (plus manual frobbing of the struct declaration): @@ struct intel_context c; @@ - (c).id + c.user_handle @@ struct intel_context *c; @@ - (c)->id + c->user_handle Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and change the type to unsigned 32 bits. v2: s/handle/user_handle and change the type to uint32_t as suggested by Chris Wilson. Reviewed-by: Jesse Barnes <[email protected]> (v1) Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Emphasize that ctx->obj & ctx->is_initialized refer to the legacy ↵Oscar Mateo3-44/+48
rcs ctx We have already advanced that Logical Ring Contexts have their own kind of backing objects, but everything will be better explained in the Execlists series. For now, suffice it to say that the current backing object is only ever used with the render ring, so we're making this fact more explicit (which is a good reason on its own). As for the is_initialized flag, we only use to signify that the render state has been initialized (a.k.a. golden context, a.k.a. null context). It doesn't mean anything for the other engines, so make that distinction obvious. Done with the following Coccinelle patch (plus manual frobbing of the struct): @@ struct intel_context c; @@ - (c).obj + c.legacy_hw_ctx.rcs_state @@ struct intel_context *c; @@ - (c)->obj + c->legacy_hw_ctx.rcs_state @@ struct intel_context c; @@ - (c).is_initialized + c.legacy_hw_ctx.initialized @@ struct intel_context *c; @@ - (c)->is_initialized + c->legacy_hw_ctx.initialized This Execlists prep-work patch has been suggested by Chris Wilson and Daniel Vetter separately. Initially, it was two separate patches: drm/i915: Rename ctx->obj to ctx->rcs_state drm/i915: Make it obvious that ctx->id is merely a user handle Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: s/id/is_initialized/ to fix the subject and resolve a conflict in i915_gem_context_reset. Also introduce a new lctx local variable to avoid overtly long lines.] Signed-off-by: Daniel Vetter <[email protected]>
2014-07-08drm/i915: Extract context backing object allocationOscar Mateo1-19/+35
This is preparatory work for Execlists: we plan to use it later to allocate our own context objects (since Logical Ring Contexts do not have the same kind of backing objects). No functional changes. Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Oscar Mateo <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.