“172b4c5c8afdb7471d9b03fc96a6b6455a49e19d”上不存在“README.md”
- 09 10月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
I've discovered this on my ivb machine while stress-testing the new flip_tests. Only harmful effect observed is that the timestamp is a bit bogus. Note that this is empirical duct-tape: I've noticed that we seem to only ever miss the very first vblank irq right after enabling the pipe. And with this hack applied I couldn't reproduce the failure case anywhere else any more. Tested-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 10月, 2012 1 次提交
-
-
由 Willy Tarreau 提交于
starting an old X server causes a kernel BUG since commit 1b50247a: ------------[ cut here ]------------ kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3661! invalid opcode: 0000 [#1] SMP Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss uvcvideo +videobuf2_core videodev videobuf2_vmalloc videobuf2_memops uhci_hcd ath9k mac80211 snd_hda_codec_realtek ath9k_common microcode +ath9k_hw psmouse serio_raw sg ath cfg80211 atl1c lpc_ich mfd_core ehci_hcd snd_hda_intel snd_hda_codec snd_hwdep snd_pcm rtc_cmos +snd_timer snd evdev eeepc_laptop snd_page_alloc sparse_keymap Pid: 2866, comm: X Not tainted 3.5.6-rc1-eeepc #1 ASUSTeK Computer INC. 1005HA/1005HA EIP: 0060:[<c12dc291>] EFLAGS: 00013297 CPU: 0 EIP is at i915_gem_entervt_ioctl+0xf1/0x110 EAX: f5941df4 EBX: f5940000 ECX: 00000000 EDX: 00020000 ESI: f5835400 EDI: 00000000 EBP: f51d7e38 ESP: f51d7e20 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: b760e0a0 CR3: 351b6000 CR4: 000007d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process X (pid: 2866, ti=f51d6000 task=f61af8d0 task.ti=f51d6000) Stack: 00000001 00000000 f5835414 f51d7e84 f5835400 f54f85c0 f51d7f10 c12b530b 00000001 c151b139 c14751b6 c152e030 00000b32 00006459 00000059 0000e200 00000001 00000000 00006459 c159ddd0 c12dc1a0 ffffffea 00000000 00000000 Call Trace: [<c12b530b>] drm_ioctl+0x2eb/0x440 [<c12dc1a0>] ? i915_gem_init+0xe0/0xe0 [<c1052b2b>] ? enqueue_hrtimer+0x1b/0x50 [<c1053321>] ? __hrtimer_start_range_ns+0x161/0x330 [<c10530b3>] ? lock_hrtimer_base+0x23/0x50 [<c1053163>] ? hrtimer_try_to_cancel+0x33/0x70 [<c12b5020>] ? drm_version+0x90/0x90 [<c10ca171>] vfs_ioctl+0x31/0x50 [<c10ca2e4>] do_vfs_ioctl+0x64/0x510 [<c10535de>] ? hrtimer_nanosleep+0x8e/0x100 [<c1052c20>] ? update_rmtp+0x80/0x80 [<c10ca7c9>] sys_ioctl+0x39/0x60 [<c1433949>] syscall_call+0x7/0xb Code: 83 c4 0c 5b 5e 5f 5d c3 c7 44 24 04 2c 05 53 c1 c7 04 24 6f ef 47 c1 e8 6e e0 fd ff c7 83 38 1e 00 00 00 00 00 00 e9 3f ff ff +ff <0f> 0b eb fe 0f 0b eb fe 8d b4 26 00 00 00 00 0f 0b eb fe 8d b6 EIP: [<c12dc291>] i915_gem_entervt_ioctl+0xf1/0x110 SS:ESP 0068:f51d7e20 ---[ end trace dd332ec083cbd513 ]--- The crash happens here in i915_gem_entervt_ioctl() : 3659 BUG_ON(!list_empty(&dev_priv->mm.active_list)); 3660 BUG_ON(!list_empty(&dev_priv->mm.flushing_list)); -> 3661 BUG_ON(!list_empty(&dev_priv->mm.inactive_list)); 3662 mutex_unlock(&dev->struct_mutex); Quoting Chris : "That BUG_ON there is silly and can simply be removed. The check is to verify that no batches were submitted to the kernel whilst the UMS/GEM client was suspended - to which the BUG_ONs are a crude approximation. Furthermore, the checks are too late, since it means we attempted to program the hardware whilst it was in an invalid state, the BUG_ONs are the least of your concerns at that point." Note that this regression has been introduced in commit 1b50247a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 24 15:47:30 2012 +0100 drm/i915: Remove the list of pinned inactive objects Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NWilly Tarreau <w@1wt.eu> [danvet: Added note about the regressing commit and cc: stable.] Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 10月, 2012 1 次提交
-
-
由 Ben Widawsky 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 10月, 2012 5 次提交
-
-
由 Daniel Vetter 提交于
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: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
... 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: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
Falling into default case in vmi915_gem_fault is a bug. Be more verbose about it. Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Dmitry Rogozhkin 提交于
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: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
In commit cdb0e95b 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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 10月, 2012 5 次提交
-
-
由 Jesse Barnes 提交于
We don't have bit 6 swizzling on VLV, so this function is easy. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Adam Jackson 提交于
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: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Adam Jackson 提交于
v2: Fix parenthesis mismatch, spotted by Jani Nikula Tested-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> [danvet: Fixup merge conflict and MAX_DOWNSTREAM #define as spotted by Jani.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Adam Jackson 提交于
Tested-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NAdam Jackson <ajax@redhat.com> Acked-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 10月, 2012 2 次提交
-
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Added i-g-t note and cc: stable] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
A side-effect of commit 7d54a904 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: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 9月, 2012 2 次提交
-
-
由 Ben Widawsky 提交于
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: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
The dithering introduced in commit 3b5c78a3 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 4344b813 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: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 9月, 2012 3 次提交
-
-
由 Chris Wilson 提交于
Finishes commit 02d71956 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: Nyangguang <guang.a.yang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
... 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 4e89ee17: 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=46761Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 9月, 2012 1 次提交
-
-
由 Paulo Zanoni 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 9月, 2012 2 次提交
-
-
由 Dave Airlie 提交于
This fixes the gpio reset problem so the Retina MBP works, but avoids breaking the Dell systems. Ben will work on a better solution for 3.7. Tested by me on retina MBP. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Simon Kitching 提交于
Cards typically have 5-7 scratch registers; one of these is reserved for rdev->rptr_save_reg. Unfortunately the reservation is done in function r100_cp_init, which is called by all drivers except r600 - and this function is also invoked on resume from suspend. After several resumes, no scratch registers are free and graphics acceleration is disabled. Dmesg then reports either: *ERROR* radeon: cp failed to get scratch reg (-22). *ERROR* radeon: cp isn't working(-22). radeon 0000:01:00.0: failed initializing CP (-22). or: *ERROR* radeon: failed to get scratch reg (-22). *ERROR* radeon: failed testing IB on GFX ring (-22). *ERROR* ib ring test failed (-22). The chain of calls on boot for all except r600 is: radeon_init -> ... -> (rXXX_init) -> rXXX_startup -> r100_cp_init The chain of calls on resume for all except r600 is: rXXX_resume -> rXXX_startup -> r100_cp_init. R600 correctly allocates rptr_save_reg in r600_init (ie once only, not in resume). However moving the code into the init functions for all drivers means touching 4 drivers. So instead, this patch just adds a test in r100_cp_init to avoid reallocating on resume. As the rdev structure is allocated via kzalloc in radeon_driver_load_kms, and zero is not a valid registerid, zero safely implies not-yet-allocated. This issue appears to have been introduced in c7eff978 (3.6.0-rcN) Signed-off-by: NSimon Kitching <skitching@vonos.net> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 20 9月, 2012 17 次提交
-
-
由 Ben Widawsky 提交于
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: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Wang Xingchao 提交于
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: NWang Xingchao <xingchao.wang@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
... 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: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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 1b3c7a47 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: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Tested-by (IVB): Ben Widawsky <ben@bwidawsk.net> Acked-by: NBen Widawsky <ben@bwidawsk.net> [danvet: Squashed-in follow-up fix for gen2/3 registers file size from Chris Wilson.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
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: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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 32f9d658 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 b329530c 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 417e822d 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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Lekensteyn 提交于
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=45452Tested-by: NPeter Wu <lekensteyn@gmail.com> Signed-off-by: NPeter Wu <lekensteyn@gmail.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=44001Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
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: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-