aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAge
* Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-10-07
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff, as discussed on irc. Otherwise just small things: - regression fix to finally make 6bpc auto-dither on dp work (Jani) - reinstate an snb ctx w/a that accidentally got lost in a rework (Chris) - fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris) - fix set_caching locking (Ben) - fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika) - some pageflip correctness fixes (still hunting down some issues, but these are the worst offenders of confused code that we've tracked down thus far) from Chris and me - fixup swizzling settings on vlv (Jesse) - gt_mode w/a from Ben added, fixes snb gt1 rc6+hw ctx hangs. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Fix GT_MODE default value drm/i915: don't frob the vblank ts in finish_page_flip drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: print warning if vmi915_gem_fault error is not handled drm/i915: EBUSY status handling added to i915_gem_fault(). drm/i915: Try harder to complete DP training pattern 1 drm/i915: set swizzling to none on VLV drm/dp: Make sink count DP 1.2 aware drm/dp: Document DP spec versions for various DPCD registers drm/i915/dp: Be smarter about connection sense for branch devices drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/dp: Update DPCD defines drm: Export drm_probe_ddc() drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Fix set_caching locking drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
| * drm/i915: Fix GT_MODE default valueBen Widawsky2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | I can't even find how I figured this might be needed anymore. But sure enough, the value I'm reading back on platforms doesn't match what the docs recommends. It seemed to fix Chris' GT1 in limited testing as well. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: don't frob the vblank ts in finish_page_flipDaniel Vetter2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we correctly generate it, this hack is no longer required (and might actually paper over a serious bug). pageflip timestamps are sanity check in the latest version of the flip-test in intel-gpu-tools. v2: Also remove the gettimeofday(&now) which is no longer used. Noticed by Mario Kleiner. Reviewed-by: mario.kleiner@tuebingen.mpg.de Tested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: call drm_handle_vblank before finish_page_flipDaniel Vetter2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... since finish_page_flip needs the vblank timestamp generated in drm_handle_vblank. Somehow all the gmch platforms get it right, but all the pch platform irq handlers get is wrong. Hooray for copy& pasting! Currently this gets papered over by a gross hack in finish_page_flip. A second patch will remove that. Note that without this, the new timestamp sanity checks in flip_test occasionally get tripped up, hence the cc: stable tag. Cc: stable@vger.kernel.org Reviewed-by: mario.kleiner@tuebingen.mpg.de Tested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: print warning if vmi915_gem_fault error is not handledMika Kuoppala2012-10-04
| | | | | | | | | | | | | | | | | | Falling into default case in vmi915_gem_fault is a bug. Be more verbose about it. 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>
| * drm/i915: EBUSY status handling added to i915_gem_fault().Dmitry Rogozhkin2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS. Note that this fixes i-g-t/tests/gem_threaded_tiled_access. Tested-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Try harder to complete DP training pattern 1Chris Wilson2012-10-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit cdb0e95bf571dccc1f75fef9bdad21b167ef0b37 Author: Keith Packard <keithp@keithp.com> Date: Tue Nov 1 20:00:06 2011 -0700 drm/i915: Try harder during dp pattern 1 link training extra passes were made to retry the same voltage and then retry a full clock reset. However, as coverity pointed out, we never tried the full clock reset as we broke out of the loop early. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: set swizzling to none on VLVJesse Barnes2012-10-03
| | | | | | | | | | | | | | We don't have bit 6 swizzling on VLV, so this function is easy. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/dp: Make sink count DP 1.2 awareAdam Jackson2012-10-02
| | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: Be smarter about connection sense for branch devicesAdam Jackson2012-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If there's no downstream device, DPCD success is good enough. If there's a hotplug-capable downstream device, count the number of connected sinks in DP_SINK_STATUS and return success if it's non-zero. Otherwise, probe DDC and report appropriately. v2: Check DP_SINK_STATUS instead of something unrelated to sink status. Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: Fetch downstream port info if needed during DPCD fetchAdam Jackson2012-10-02
| | | | | | | | | | | | | | | | | | | | | | v2: Fix parenthesis mismatch, spotted by Jani Nikula Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Fixup merge conflict and MAX_DOWNSTREAM #define as spotted by Jani.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Flush the pending flips on the CRTC before modificationChris Wilson2012-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was meant to be the purpose of the intel_crtc_wait_for_pending_flips() function which is called whilst preparing the CRTC for a modeset or before disabling. However, as Ville Syrjala pointed out, we set the pending flip notification on the old framebuffer that is no longer attached to the CRTC by the time we come to flush the pending operations. Instead, we can simply wait on the pending unpin work to be finished on this CRTC, knowning that the hardware has therefore finished modifying the registers, before proceeding with our direct access. Fixes i-g-t/flip_test on non-pch platforms. pch platforms simply schedule the flip immediately when the pipe is disabled, leading to other funny issues. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Added i-g-t note and cc: stable] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/aChris Wilson2012-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A side-effect of commit 7d54a904285b6e780291b91a518267bec5591913 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 10 10:18:10 2012 +0100 drm/i915: Apply post-sync write for pipe control invalidates was that only a request to emit invalidate flush would result in the TLB being invalidated (since it requires synchronisation and so incurs a performance penalty). However, the stated w/a for hardware contexts is that the TLBs must be invalidated prior to a MI_SET_CONTEXT, yet the w/a itself did not request the TLBs to be invalidated... Note this w/a does not prevent the hard system hang I experience when using hw contexts (with rc6 enabled) on SNB GT1. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix set_caching lockingBen Widawsky2012-09-27
| | | | | | | | | | | | | | | | | | On the EINVAL case we don't release struct_mutex. It should be safe to grab the lock after checking the parameters, which also resolves the issues. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flagJani Nikula2012-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dithering introduced in commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf Author: Adam Jackson <ajax@redhat.com> Date: Tue Dec 13 15:41:00 2011 -0800 drm/i915/dp: Dither down to 6bpc if it makes the mode fit stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use the original mode, without the flag, so it would never have any effect. However, the BPC was clamped by VBT settings, making things work by coincidence, until that part was removed in commit 4344b813f105a19f793f1fd93ad775b784648b95 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Aug 10 11:10:20 2012 +0200 Use adjusted_mode instead of mode when checking for INTEL_MODE_DP_FORCE_6BPC to make the flag have effect. v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by Daniel both before and after sending the first patch. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47621 CC: Adam Jackson <ajax@redhat.com> CC: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-10-04
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
| * drm/i915: Wrap external callers to IPS state with appropriate locksChris Wilson2012-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Finishes commit 02d719562ef40483648b2cc46899d4a2ff5953bb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 9 16:44:54 2012 +0200 drm/i915: properly guard ilk ips state The core functions were annotated with their locking requirements, but we overlooked that they were exported, without any control over the locking, to debugfs. So in order to enable debugfs to read the registers without triggering sanity checks, we change the exported entry points to properly take the required locks before calling the core routines. Reported-by: yangguang <guang.a.yang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: s/cacheing/caching/Ben Widawsky2012-09-26
| | | | | | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make sure we write all the DIP data bytesPaulo Zanoni2012-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... even if the actual infoframe is smaller than the maximum possible size. If we don't write all the 32 DIP data bytes the InfoFrame ECC may not be correctly calculated in some cases (e.g., when changing the port), and this will lead to black screens on HDMI monitors. The ECC value is generated by the hardware. I don't see how this should break anything since we're writing 0 and that should be the correct value, so this patch should be safe. Notice that on IVB and older we actually have 64 bytes available for VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the others are either read-only ECC values or marked as "reserved". On HSW we only have 32 bytes, and the ECC value is stored on its own separate read-only register. See BSpec. This patch fixes bug #46761, which is marked as a regression introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d: drm/i915: set the DIP port on ibx_write_infoframe Before commit 4e89 we were just failing to send AVI infoframes when we needed to change the port, which can lead to black screens in some cases. After commit 4e89 we started sending infoframes, but with a possibly wrong ECC value. After this patch I hope we start sending correct infoframes. Version 2: - Improve commit message - Try to make the code more clear Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'v3.6-rc7' into drm-intel-next-queuedDaniel Vetter2012-09-24
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Manual backmerge of -rc7 to resolve a silent conflict leading to compile failure in drivers/gpu/drm/i915/intel_hdmi.c. This is due to the bugfix in -rc7: commit b98b60167279df3acac9422c3c9820d9ebbcf9fb Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 07:43:22 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug Since this code moved around a lot in -next git put that snippet at the wrong spot. I've tried to fix this by making the conflict explicit by merging a version for next with: commit 3cce574f0190dd149472059fb69267cf83d290f9 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 11:19:00 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally But that failed to solve the entire problem. To avoid pushing out further -nightly branch to our QA where this is broken, do the backmerge and manually add the stuff git adds to -next from the patch in -fixes. Note that this doesn't show up in git's merge diff (and hence is also not handled by git rerere), which adds to the reasons why I'd like to fix this with a verbose backmerge. The git merge diff only shows a bunch of trivial conflicts of the "code changed in lines next to each another" kind. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: BUG() on unexpected HDMI registerPaulo Zanoni2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | This should never happen, but the silent "return" makes me wonder every time I try to debug InfoFrame bugs, so promote this to BUG() to make sure people will complain if we ever break this. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix !CONFIG_PM sysfs for real this timeBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow this hunk got dropped from my last patch. We do not have the rc6_attrs when there is no CONFIG_PM so this causes a compilation error. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Assert that the exec object lookup table is a power-of-twoChris Wilson2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | As we make the simplification of using a power-of-two size for the execbuffer handle-to-object TLB, we should validate that this is actually true and so clarify that premise. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionallyWang Xingchao2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clear Audio Enable bit to trigger unsolicated event to notify Audio Driver part the HDMI hot plug change. The patch fixed the bug when remove HDMI cable the bit was not cleared correctly. In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will be set to trigger unsolicated event to notify Alsa driver the change. intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after remove the hdmi cable, here's debug log: [ 187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2 [ 187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0 so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this cause the eld infomation and pin presence doesnot update accordingly in alsa driver side. This patch will also trigger unsolicated event to alsa driver to notify the hot plug event: [ 187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1 [ 187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Convert the dmabuf object to use the new i915_gem_object_opsChris Wilson2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By providing a callback for when we need to bind the pages, and then release them again later, we can shorten the amount of time we hold the foreign pages mapped and pinned, and importantly the dmabuf objects then behave as any other normal object with respect to the shrinker and memory management. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: update dpms property in set_modeDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hopefully this makes userspace slightly less confused about us frobbing the dpms state behind its back. Yeah, it would be better to be more careful with not changing the dpms state, but that is quite more invasive. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: don't call dpms funcs after set_modeDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... because our current set_mode implementation doesn't bother to adjust for the dpms state, we just forcefully update it. So stop pretending that we're better than we are and rip out this extranous call. Note that this totally confuses userspace, because the exposed connector property isn't actually updated ... Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: don't disable fdi links harder in ilk_crtc_enableDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Because they should have been disabled when shutting down the display pipe previously. To ensure that this is the case, add a few assserts instead of unconditionally disabling the fdi link. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: rip out intel_disable_pch_portsDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even with the old crtc helper code we should have disabled all encoders on that pipe by now, and with the new code this would definitely paper over a bug. We already have the necessary checks in place in intel_disable_transcoder, so if we accidentally leave a pch port on, this will be caught. Hence just rip this all out. Note that up to the patch in this giant modeset series that removes the LVDS special case to avoid disabling LVDS in the encoder->prepare callback ("drm/i915/lvds: ditch ->prepare special case"), this was not the case for all outputs. Also note that in commit 1b3c7a47f993bf9ab6c4c7cc3bbf5588052b58f4 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Nov 25 13:09:38 2009 +0800 drm/i915: Fix LVDS stability issue on Ironlake this was already discovered independently and worked around. How I bloody hate this entire mess of cludges piled on top of other cludges. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Limit the ioremap of the PCI bar to the registersChris Wilson2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the future we may like to experiment with using a WC map of the GTT portion. However, that will conflict with i915.ko mapping the entire bar as UC in order to access the GPU registers. Instead we can shrink the register ioremap to only map the register block. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net> Acked-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Squashed-in follow-up fix for gen2/3 registers file size from Chris Wilson.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Show render P state thresholds in sysfsBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is useful for userspace utilities which wish to use the previous interface, specifically for micromanaging the increase/decrease steps by setting min == max. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add setters for min/max frequencyBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provide a standardized sysfs interface for setting min, and max frequencies. The code which reads the limits were lifted from the debugfs files. As a brief explanation, the limits are similar to the CPU p-states. We have 3 states: RP0 - ie. max frequency RP1 - ie. "preferred min" frequency RPn - seriously lowest frequency Initially Daniel asked me to clamp the writes to supported values, but in conforming to the way the cpufreq drivers seem to work, instead return -EINVAL (noticed by Jesse in discussion). The values can be used by userspace wishing to control the limits of the GPU (see the CC list for people who care). v4: Make exceeding the soft limits return -EINVAL as well (Daniel) v3: bug fix (Ben) - was passing the MHz value to gen6_set_rps instead of the step value. To fix, deal only with step values by doing the divide at the top. v2: add the dropped mutex_unlock in error cases (Chris) EINVAL on both too min, or too max (Daniel) v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: rip out edp special case from dp_link_downDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has been tons of fun to figure out with git blame. The first notion of this code block goes back to the original cpu edp enabling for ilk in commit 32f9d658aee5be09ebdd28fc730630e61d0b46db Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Fri Jul 24 01:00:32 2009 +0800 drm/i915: Add eDP support on IGDNG mobile chip Two things are notable in this commit wrt to the this edp special case: - The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports. - The cpu edp port is disabled at the top of the dp_link_down function. My theory is that these hacks was added to work around the completely different modeset sequence for cpu edp ports compared to pch edp ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up, this shouldn't be required any more. The really interesting question is how this special cases survived this long in the code. The first step is declaring the pch port D as eDP if it's used for an internal panel: commit b329530ca7cdf6bf014f2124efd983e01265d623 Author: Adam Jackson <ajax@redhat.com> Date: Fri Jul 16 14:46:28 2010 -0400 drm/i915/dp: Correctly report eDP in the core connector type This commit unfortunately failed to notice that not all edp ports are created equal. Then follow a flurry of refactorings, culminating in a patch from Keith Packard which resulted in the current logic (by making it "correct" for all platforms that have edp): commit 417e822deee1d2bcd8a8a60660c40a0903713f2b Author: Keith Packard <keithp@keithp.com> Date: Tue Nov 1 19:54:11 2011 -0700 drm/i915: Treat PCH eDP like DP in most places None of these cleanups or refactorings supply any reason why we need this code, they've simply carried it on as-is. Hence presume it might be harmful with the current code and rip it out. We do rewrite the link training bits completely anyway when re-training the link. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Drop the misleading cast to the wrong user pointer typeChris Wilson2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | The exec_list is of type drm_i915_gem_exec_object2 and so casting it to a drm_i915_gem_relocation_entry is very confusing! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | i915: initialize CADL in opregionLekensteyn2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452 Tested-by: Peter Wu <lekensteyn@gmail.com> Signed-off-by: Peter Wu <lekensteyn@gmail.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: disable the cpu edp port after the cpu pipeDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See bspec, Vol3 Part2, Section 1.1.3 "Display Mode Set Sequence". This applies to all platforms where we currently support eDP on, i.e. ilk, snb & ivb. Without this change we fail to light up the eDP port on previously unused crtcs (likely because something is stuck on the old pipe), and we also fail to properly disable the old pipe (i.e. bit 30 in the PIPECONF register is stuck as set until the next reboot). v2: Rebased on top of the edp panel off sequence changes in 3.6-rc2. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: rip out dp port enabling cludges^WchecksDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These have been added because dp links are fiddle things and don't like it when we try to re-train an enabled output (or disable a disabled output harder). And because the crtc helper code is ridiculously bad add tracking the modeset state. But with the new code in place it is simply a bug to disable a disabled encoder or to enable an enabled encoder again. Hence convert these to WARNs (and bail out for safety), but flatten all conditionals in the code itself. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: robustify edp_pll_on/offDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the previous patch to clean up where exactly these two functions are getting called, this patch can tackle the enable/disable code itself: - WARN if the port enable bit is in the wrong state or if the edp pll bit is in the wrong state, just for paranoia's sake. - Don't disable the edp pll harder in the modeset functions just for fun. - Don't set the edp pll enable flag in intel_dp->DP in modeset, do that while changing the actual hw state. We do the same with the actual port enable bit, so this is a bit more consistent. - Track the current DP register value when setting things up and add some comments how intel_dp->DP is used in the disable code. v2: Be more careful with resetting intel_dp->DP - otherwise dpms off->on will fail spectacularly, becuase we enable the eDP port when we should only enable the eDP pll. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: clean up the cpu edp pll special caseDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By using the new pre_enable/post_disable functions. To ensure that we only frob the cpu edp pll while the pipe is off add the relevant asserts. Thanks to the new output state staging, this is now really easy. With this fixed we can now finally rip out the special-case handling in the dp dpms code and replace it by the common intel_connector_dpms. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: add encoder->pre_enable/post_disableDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cpu eDP encoder has some horrible hacks to set up the DP pll at the right time. To be able to move them to the right place, add some more encoder callbacks so that this can happen at the right time. LVDS has some similar funky hacks, but that would require more work (we need to move around the pll setup a bit). Hence for now only wire these new callbacks up for ilk+ - we only have cpu eDP on these platforms. v2: Bikeshed the vtable ordering, requested by Chris Wilson. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: rip out early dp port write for gm45/ilkDaniel Vetter2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's bogus. If I've followed the history of this piece of code correctly, i.e. the initial register write with the following vblank wait, this goes all the way back to the original enabling of DP support in commit a4fc5ed69817c73e32571ad7837bb707f9890009 Author: Keith Packard <keithp@keithp.com> Date: Tue Apr 7 16:16:42 2009 -0700 drm/i915: Add Display Port support Unfortunately it seems to be nothing more than glorified duct-tape and sometimes actively harmful. Adam Jackson noticed this for CPT platforms with commit e85194641bec56179dcf5e1704ce5c6bf30340c6 Author: Adam Jackson <ajax@redhat.com> Date: Thu Jul 21 17:48:38 2011 -0400 drm/i915/dp: Don't turn CPT DP ports on too early Unfortunately this kept the code around for ilk and gm45. The specific failure case I'm seeing here is that after a dpms off/on cycle we have the bits from the last link training (hopefully successful link training) set in intel_dp->DP. This is requiered so that complete_link_train can enable the port with the right tuning values. Unfortunately writing these again to the disabled port at dpms on time kills the port somehow until it's disabled - dp link training fails in an endless loop without this patch on my mobile ilk and gm45. Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Error checks in gen6_set_rpsBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the new "standardized" sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: POSTING_READ the new rps valueBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to keep our cached values in sync with the hardware, we need a posting read here. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add current/max/min GPU freq to sysfsBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace applications such as PowerTOP are interesting in being able to read the current GPU frequency. The patch itself sets up a generic array for gen6 attributes so we can easily add other items in the future (and it also happens to be just about the cleanest way to do this). The patch is a nice addition to commit 1ac02185dff3afac146d745ba220dc6672d1d162 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 30 13:26:48 2012 +0200 drm/i915: add a tracepoint for gpu frequency changes Reading the GPU frequncy can be done by reading a file like: /sys/class/drm/card0/render_frequency_mhz Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: #define gpu freq multiplerBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Magic numbers are bad mmmkay. In this case in particular the value is especially weird because the docs say multiple things. We'll need this value for sysfs, so extracting it is useful for that as well. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: variable renamesBen Widawsky2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Name variables a bit better for copy-pasters. This got turned up as part of review for upcoming sysfs patches. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: extract compute_clocks from ironlake_crtc_mode_setPaulo Zanoni2012-09-20
| | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: resolved conflicts due to missing some earlier patches.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: simplify setting DSPCNTR inside ironlake_crtc_mode_setPaulo Zanoni2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Because declaring a variable in the beginning of the function, then initializing it 100 lines later, then using it 100 lines later does not make our code look good IMHO. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: extract ironlake_set_pipeconf form ironlake_crtc_mode_setPaulo Zanoni2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | Because ironlake_crtc_mode_set is a giant function that used to have 404 lines. Let's try to make it less complex/confusing. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Replace the array of pages with a scatterlistChris Wilson2012-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than have multiple data structures for describing our page layout in conjunction with the array of pages, we can migrate all users over to a scatterlist. One major advantage, other than unifying the page tracking structures, this offers is that we replace the vmalloc'ed array (which can be up to a megabyte in size) with a chain of individual pages which helps reduce memory pressure. The disadvantage is that we then do not have a simple array to iterate, or to access randomly. The common case for this is in the relocation processing, which will typically fit within a single scatterlist page and so be almost the same cost as the simple array. For iterating over the array, the extra function call could be optimised away, but in reality is an insignificant cost of either binding the pages, or performing the pwrite/pread. v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the trivial compile error from rebasing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-08 15:24:56 -0500