- 08 Feb, 2013 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: "Probably the last feature pull for 3.9, there's some fixes outstanding thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ... Anyway, highlights of this pull: - Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements on vlv, big thanks to Ville. - Dynamic power well support for Haswell, shaves away a bit when only using the eDP port on pipe A (Paulo). Plus unclaimed register fixes uncovered by this. - Clarifications of the gpu hang/reset state transitions, hopefully fixing a few spurious -EIO deaths in userspace. - Haswell ELD fixes. - Some more (pp)gtt cleanups from Ben. - A few smaller things all over. Plus all the stuff from the previous rather small pull request: - Broadcast RBG improvements and reduced color range fixes from Ville. - Ben is on a "kill legacy gtt code for good" spree, first pile of patches included. - No-relocs and bo lut improvements for faster execbuf from Chris. - Some refactorings from Imre." * tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits) GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too drm/i915: Kill IS_DISPLAYREG() drm/i915: Introduce i915_vgacntrl_reg() drm/i915: gen6_gmch_remove can be static drm/i915: dynamic Haswell display power well support drm/i915: check the power down well on assert_pipe() drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A drm/i915: don't run hsw power well code on !hsw drm/i915: kill cargo-culted locking from power well code drm/i915: Only run idle processing from i915_gem_retire_requests_worker drm/i915: Fix CAGF for HSW drm/i915: Reclaim GTT space for failed PPGTT drm/i915: remove intel_gtt structure drm/i915: Add probe and remove to the gtt ops drm/i915: extract hw ppgtt setup/cleanup code drm/i915: pte_encode is gen6+ drm/i915: vfuncs for ppgtt drm/i915: vfuncs for gtt_clear_range/insert_entries drm/i915: Error state should print /sys/kernel/debug ...
-
- 01 Feb, 2013 1 commit
-
-
Yasuaki Ishimatsu authored
acpi_bus_get_device() returns int not acpi_status. The patch change not to apply ACPI_FAILURE() to the return value of acpi_bus_get_device(). Signed-off-by:
Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 31 Jan, 2013 22 commits
-
-
Ville Syrjälä authored
From BSpec / SR01 - Clocking Mode: "The following sequence must be used when disabling the VGA plane. Write SR01 to set bit 5 = 1 to disable video output. Wait for 100us. Disable the VGA plane via Bit 31 of the MMIO VGA control." So simply call i915_disable_vga() from i915_redisable_vga(). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
All display registers should now include the proper offset on VLV. That means IS_DISPLAYREG() is now useless, and we can eliminate it. Signed-off-by:
-
Ville Syrjälä authored
The VGACNTRL register has moved around between different platforms. To handle the differences add i915_vgacntrl_reg() which returns the correct offset for the VGACNTRL register. Signed-off-by:
-
Changlong Xie authored
Signed-off-by:
Changlong Xie <changlongx.xie@intel.com> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Daniel Vetter authored
We can disable (almost) all the display hw if we only use pipe A, with the integrated edp transcoder on port A. Because we don't set the cpu transcoder that early (yet), we need to help us with a trick to simply check for any edp encoders. v2: Paulo Zanoni pointed out that we also need to configure the eDP cpu transcoder correctly. v3: Made by Paulo Zanoni - Rebase patch to be on top of "fix intel_init_power_wells" patch - Fix typos - Fix a small bug by adding a "connectors_active" check - Restore the initial code that unconditionally enables the power well when taking over from the BIOS v4: Made by Paulo Zanoni - One more typo spotted by Jani Nikula v5: Made by Paulo Zanoni - Rebase Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Paulo Zanoni authored
If the power well is disabled, we should not try to read its registers, otherwise we'll get "unclaimed register" messages. V2: Don't check whether the power well is enabled or not, just check whether we asked it to be enabled or not: if we asked to disable the power well, don't use the registers on it, even if it's still enabled. V3: Fix bug that breaks all non-Haswell machines. Signed-off-by:
-
Paulo Zanoni authored
The DP_TP_STATUS register for PORT_A doesn't exist. Our documentation will be fixed soon, so the code does not match it for now. This solves "Timed out waiting for DP idle patterns" and "unclaimed register" messages on eDP. V1: Was called "drm/i915: don't read DP_TP_STATUS(PORT_A)" V2: Was called "drm/i915: don't send DP idle pattern before normal pattern on HSW" V3: Only change the code that touches PORT_A. Signed-off-by:
-
Daniel Vetter authored
Dumps annoying noise into the dmesg: [drm:intel_set_power_well] *ERROR* Timeout enabling power well Reported-by:
Sedat Dilek <sedat.dilek@gmail.com> Cc: Sedat Dilek <sedat.dilek@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
-
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:
-
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:
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:
-
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:
-
- 27 Jan, 2013 3 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:
-
Daniel Vetter authored
One of the early return cases missed the mutex unlocking. Hilarity ensued. This regression has been introduced in commit 7b24056b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 12 00:35:33 2012 +0100 drm: don't hold crtc mutexes for connector ->detect callbacks Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59750Signed-off-by:
Cancan Feng <cancan.feng@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 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 3 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:
-
