- 11 Jul, 2014 1 commit
-
-
Ville Syrjälä authored
In commit 62942ed7 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Jun 13 09:28:33 2014 -0700 drm/i915/vlv: disable PPGTT on early revs v3 we forgot about CHV. IS_VALLEYVIEW() is true for CHV, so we need to explicitly avoid disabling PPGTT on CHV. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 Jul, 2014 32 commits
-
-
Chris Wilson authored
We can eliminate a lot of special case code by making the computation of the interrupt mask be correct for all callers. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Place the RPS counters inside the RPS struct. Signed-off-by:
-
Damien Lespiau authored
C is super happy to asign anything pointer to void *. Don't pretend otherwise. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
We may reach this point while the machine is still runtime suspended, so we'll hit a WARN. The other encoders also don't touch registers at this point, so instead of waking the machine up, write some code to keep the register always at the same state, including after we runtime suspend/resume. Testcase: igt/pm_rpm Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463Signed-off-by:
-
Paulo Zanoni authored
Just like we do for the other encoders. This should fix some WARNs when running pm_rpm on SNB. Testcase: igt/pm_rpm Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463Signed-off-by:
-
Paulo Zanoni authored
Just like we already do in haswell_get_pipe_config(). This should prevent some WARNs when we run pm_rpm on SNB. Testcase: igt/pm_rpm Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463Signed-off-by:
-
Paulo Zanoni authored
Since we now have support for shared DPLLS. Signed-off-by:
-
Daniel Vetter authored
To be able to do this we need to separately keep track of how many crtcs need a given WRPLL and how many actually actively use it. The common shared dpll framework already has all this, including massive state readout and cross checking. Which allows us to do this switch in a fairly small patch. Reviewed-by:
-
Daniel Vetter authored
Mostly this patch is one big excersize in deleting code and asserts which are no longer needed. Note that we still abuse the shared dpll framework a bit since we call the enable/disable functions from the crtc mode_set and off hooks. But changing the actual hardware sequence will be done in the next step. Note that besides the massive amount of changes in this patch the places and order in which the low-level WRPLL code is called is absolutely unchanged. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Daniel Vetter authored
This time around another cute hack to pre-fill the pll->hw_state with the right values. And also remove a bunch of checks which will be replaced by lots more checks in the common framework. Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Paulo Zanoni authored
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=80463Signed-off-by:
-
Daniel Vetter authored
The WRPLLs won't use them. Reviewed-by:
-
Daniel Vetter authored
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 authored
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:
Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
Don't let it fall in the HAS_PCH_SPLIT() case. Signed-off-by:
-
Daniel Vetter authored
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 authored
Just boring sed job for preparation. Signed-off-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
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 authored
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:
-
Imre Deak authored
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 authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Matt Roper authored
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 <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
intel_primary_plane_{setplane,disable} were lacking struct_mutex locking around their GEM operations. Signed-off-by: -
Paulo Zanoni authored
Otherwise we will print some WARNs when we read registers and the machine is suspended. Testcase: igt/pm_rpm/debugfs-read Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Paulo Zanoni authored
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 authored
That function can be used to write anything on D_COMP, not just disable it, so print a more appropriate message. Signed-off-by:
-
- 09 Jul, 2014 6 commits
-
-
Mika Kuoppala authored
CHV hard hangs on reading on 0x11100 References: https://bugs.freedesktop.org/show_bug.cgi?id=80893Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Mika Kuoppala authored
CHV hard hangs on reading on 0x112f4. References: https://bugs.freedesktop.org/show_bug.cgi?id=80893Suggested-by:
-
Mika Kuoppala authored
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=80893Suggested-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Mika Kuoppala authored
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=80893Suggested-by:
-
Matt Roper authored
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 authored
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:
-
- 08 Jul, 2014 1 commit
-
-
Chris Wilson authored
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:Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
