- 31 Jan, 2013 14 commits
-
-
Daniel Vetter authored
We may not concurrently change the power wells code. Which is already guaranteed since modesets aren't concurrent. That leaves races against setup/teardown/suspend/resume, and for those we already (try) rather hard not to hit concurrent modesets. No debug WARN_ON added since that would require us to grab the modeset locks in init/suspend code. Which is again just cargo culting since just grabbing the locks in those paths isn't good enough, we need the right order of operations, too. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
When adding the fb idle detection to mark-inactive, it was forgotten that userspace can drive the processing of retire-requests. We assumed that it would be principally driven by the retire requests worker, running once every second whilst active and so we would get the deferred timer for free. Instead we spend too many CPU cycles reclocking the LVDS preventing real work from being done. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by:
Alexander Lam <lambchop468@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843 Cc: stable@vger.kernel.org Reviewed-by:
-
Ben Widawsky authored
The shift changed, hurray. Reported-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
When the PPGTT init fails, we may as well reuse the space that we were reserving for the PPGTT PDEs. This also fixes an extraneous mutex_unlock. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ben Widawsky authored
With the probe call in our dispatch table, we can now cut away the last three remaining members in the intel_gtt shared struct and so remove it completely. v2: Rebased on top of Daniel's series Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: bikeshed commit message a bit.] Signed-off-by:
-
Ben Widawsky authored
The idea, and much of the code came originally from: commit 0712f0249c3148d8cf42a3703403c278590d4de5 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Jan 18 17:23:16 2013 -0800 drm/i915: Create a vtable for i915 gtt Daniel didn't like the color of that patch series, and so I asked him to start something which appealed to his sense of color. The preceding patches are those, and now this is going on top of that. [extracted from the original commit message] One immediately obvious thing to implement is our gmch probing. The init function was getting massively bloated. Fundamentally, all that's needed from GMCH probing is the GTT size, and the stolen size. It makes design sense to put the mappable calculation in there as well, but the code turns out a bit nicer without it (IMO) The intel_gtt bridge thing is still here, but the subsequent patches will finish ripping that out. Signed-off-by: -
Daniel Vetter authored
At the moment only cosmetics, but being able to initialize/cleanup arbitrary ppgtt address spaces paves the way to have more than one of them ... Just in case we ever get around to implementing real per-process address spaces. Note that in that case another vfunc for ppgtt would be beneficial though. But that can wait until the code grows a second place which initializes ppgtts. Reviewed-by:
-
Daniel Vetter authored
All the other gen6+ hw code has the gen6_ prefix, so be consistent about it. Reviewed-by:
-
Daniel Vetter authored
Like for the global gtt we want a notch more flexibility here. Only big change (besides a few tiny function parameter adjustments) was to move gen6_ppgtt_insert_entries up (and remove _sg_ from its name, we only have one kind of insert_entries since the last gtt cleanup). We could also extract the platform ppgtt setup/teardown code a bit better, but I don't care that much. With this we have the hw details of pte writing nicely hidden away behind a bit of abstraction. Which should pave the way for different/multiple ppgtts (e.g. what we need for real ppgtt support). Reviewed-by:
-
Daniel Vetter authored
We have a few too many differences here, so finally take the prepared abstraction and run with it. A few smaller changes are required to get things into shape: - move i915_cache_level up since we need it in the gt funcs - split up i915_ggtt_clear_range and move the two functions down to where the relevant insert_entries functions are - adjustments to a few function parameter lists Now we have 2 functions which deal with the gen6+ global gtt (gen6_ggtt_ prefix) and 2 functions which deal with the legacy gtt code in the intel-gtt.c fake agp driver (i915_ggtt_ prefix). Init is still a bit a mess, but honestly I don't care about that. One thing I've thought about while deciding on the exact interfaces is a flag parameter for ->clear_range: We could use that to decide between writing invalid pte entries or scratch pte entries. In case we ever get around to fixing all our bugs which currently prevent us from filling the gtt with empty ptes for the truly unused ranges ... Signed-off-by:
-
Ben Widawsky authored
/sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by:
Carl Worth <cworth@cworth.org> Reviewed-by:
-
Daniel Vetter authored
Note that this slightly changes the order, but we only move it within the block of registers that restore encoder state. Specifically LVDS is now restored after DP, whereas previously it was done before. Legacy vga is still restored afterwards, which seems to be the important thing (if there's anything important in this restore ordering at all). Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Daniel Vetter authored
The only thing we really care about that it is off. To do so, reuse the recently created i915_redisable_vga function, which is already used to put obnoxious firmware into check on lid reopening. Reviewed-by:
-
Daniel Vetter authored
Similarly to how i915_dma.c is shaping up to be the dungeon hole for all things supporting dri1, create a new one to hide all the crazy things which are only really useful for ums support. Biggest part is the register suspend/resume support. Unfortunately a lot of it is still intermingled with bits and pieces we might still need, so needs more analysis and needs to stay in i915_suspend.c for now. Reviewed-by:
-
- 28 Jan, 2013 2 commits
-
-
Daniel Vetter authored
That way the control flow is clearer, and it prepares the stage to extract these ums functions and hide them somewhere. There's still tons of display stuff outside of these, but that requires more work. Reviewed-by:
-
Ben Widawsky authored
Implements WaVSRefCountFullforceMissDisable as documented in the BSpec 3D workarounds chapter. Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 27 Jan, 2013 2 commits
-
-
Paulo Zanoni authored
Our suspend code touches a lot of registers all over the place, so we need to enable the power well before suspending. Signed-off-by:
-
Paulo Zanoni authored
Instead of setting it at the beginning of haswell_crtc_mode_set, let's set it at the beginning of intel_crtc_mode_set. When intel_crt_mode_set calls drm_vblank_pre_modeset we already need to have the transcoder_edp correctly set, because eventually drm_vblank_pre_modeset calls functions that call i915_pipe_enabled from i915_irq.c, which will read PIPECONF(cpu_transcoder). This is a bug that affects us since we added support for TRANSCODER_EDP, but I was only able to see the problem after suspending a machine with the power well disabled (got an "unclaimed register" error. Signed-off-by:
-
- 26 Jan, 2013 8 commits
-
-
Paulo Zanoni authored
We should avoid touching registers that are on the power down well when we don't need to, because if we touch these registers when the power well is disabled we'll get tons of "unclaimed register" messages. This commit fixes some of these messages. Signed-off-by:
-
Paulo Zanoni authored
The current code was wrong in many different ways, so this is a full rewrite. We don't have "different power wells for different parts of the GPU", we have a single power well, but we have multiple registers that can be used to request enabling/disabling the power well. So let's be a good citizen and only use the register we're suppose to use, except when we're loading the driver, where we clear the request made by the BIOS. If any of the registers is requesting the power well to be enabled, it will be enabled. If none of the registers is requesting the power well to be enabled, it will be disabled. For now we're just forcing the power well to be enabled, but in the next commits we'll change this. V2: - Remove debug messages that could be misleading due to possible race conditions with KVMr, Debug and BIOS. - Don't wait on disabling: after a conversaion with a hardware engineer we discovered that the "restriction" on bit 31 is just for the "enable" case, and we don't even need to wait on the "disable" case. Signed-off-by: -
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
SR01 needs to be touched to disable VGA on non-UMS setups too. So the sequencer registers need to include the appripriate offset on VLV. Signed-off-by:
-
Ville Syrjälä authored
When passing the DP/HDMI/SDVO registers to the encoder init functions, include the VLV specific offset in the value. v2: Resolved conflicts w/ VLV SDVO elimination Signed-off-by:
-
Ville Syrjälä authored
Don't call intel_sdvo_init() for VLV. Preserve the same behaviour as when intel_sdvo_init() would have returned false. Signed-off-by:
-
Ville Syrjälä authored
Instead of using ADPA/VLV_ADPA/PCH_ADPA in various parts of intel_crt code, just use adpa_reg which always contains the correct value for the platform. Signed-off-by:
-
Ville Syrjälä authored
v2: Dropped the clock gating registers Signed-off-by:
-
- 24 Jan, 2013 14 commits
-
-
Ville Syrjälä authored
This will cause display registers to include the correct offset on VLV. Signed-off-by:
-
Ville Syrjälä authored
GPIO/GMBUS registers must be offset on VLV, so simply adjust gpio_mmio_base to include the correct offset. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx). Signed-off-by:
-
Ville Syrjälä authored
Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx). Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
CURSIZE is not present on VLV, so it was left out, as were the IVB specific cursor B registers. Signed-off-by:
-
