- 11 2月, 2010 6 次提交
-
-
由 Zhenyu Wang 提交于
On Ironlake plane flip interrupt means flip done event already, the behavior is not like old chips, and perform like other usual interrupt. So only need to handle flip done event when receiving that interrupt. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Jesse Barnes 提交于
When a new page flip is requested, we need to both queue an unpin for the current framebuffer, and also increment the flip pending count on the newly submitted buffer. At flip finish time, we need to unpin the old fb and decrement the flip pending count on the new buffer. The old code was conflating the two, and led to hangs when new direct rendered apps were started, replacing the existing frame buffer. This patch splits out the buffers and prevents the hangs. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NKristian Høgsberg <krh@bitplanet.net> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Jesse Barnes 提交于
On 945, we need to avoid entering self-refresh if the compressor is busy, or we may cause display FIFO underruns leading to ugly flicker. Fixes fdo bug #24314, kernel bug #15043. Tested-by: NAlexander Lam <lambchop468@gmail.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Julien Cristau <jcristau@debian.org> (fd.o #25371) Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
An untiled framebuffer must be aligned to 64k. This is normally handled by intel_pin_and_fence_fb_obj(), but the intelfb_create() likes to be different and do the pinning itself. However, it aligns the buffer object incorrectly for pre-i965 chipsets causing a PGTBL_ERR when it is installed onto the output. Fixes: KMS error message while initializing modesetting - render error detected: EIR: 0x10 [i915] http://bugs.freedesktop.org/show_bug.cgi?id=22936Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Daniel Vetter 提交于
Before changing the status of a buffer with a pending write we will await upon a new flush for that buffer. So we can take advantage of any flushes posted whilst the buffer is active and pending processing by the GPU, by clearing its write_domain and updating its last_rendering_seqno -- thus saving a potential flush in deep queues and improves flushing behaviour upon eviction for both GTT space and fences. In order to reduce the time spent searching the active list for matching write_domains, we move those to a separate list whose elements are the buffers belong to the active/flushing list with pending writes. Orignal patch by Chris Wilson <chris@chris-wilson.co.uk>, forward-ported by me. In addition to better performance, this also fixes a real bug. Before this changes, i915_gem_evict_everything didn't work as advertised. When the gpu was actually busy and processing request, the flush and subsequent wait would not move active and dirty buffers to the inactive list, but just to the flushing list. Which triggered the BUG_ON at the end of this function. With the more tight dirty buffer tracking, all currently busy and dirty buffers get moved to the inactive list by one i915_gem_flush operation. I've left the BUG_ON I've used to prove this in there. References: Bug 25911 - 2.10.0 causes kernel oops and system hangs http://bugs.freedesktop.org/show_bug.cgi?id=25911 Bug 26101 - [i915] xf86-video-intel 2.10.0 (and git) triggers kernel oops within seconds after login http://bugs.freedesktop.org/show_bug.cgi?id=26101Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Tested-by: NAdam Lantos <hege@playma.org> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
Got Ironlake DPLL parameter table, which reflects the hardware optimized values. So this one trys to list DPLL parameters for different output types, should potential fix clock issue seen on new Arrandale CPUs. This fixes DPLL setting failure on one 1920x1080 dual channel LVDS for Ironlake. Test has also been made on LVDS panels with smaller size and CRT/HDMI/DP ports for different monitors on their all supported modes. Update: - Change name of double LVDS to dual LVDS. - Fix SSC 120M reference clock to use the right range. Cc: CSJ <changsijay@gmail.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 05 2月, 2010 3 次提交
-
-
由 Chris Wilson 提交于
Following a gpu hang, we would leak the relocation buffer. So simply earrange the error path to always free the relocation buffer. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Thomas Meyer 提交于
acpi_lid_open() could take up to 10ms on my computer. Some component is calling the drm GETCONNECTOR ioctl many times in a row. This results in flickering (for example, when starting a video). Fix it by assuming an always connected lid status. Signed-off-by: NThomas Meyer <thomas@m3y3r.de> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 David John 提交于
Self Refresh should be disabled on dual plane configs. Otherwise, as the SR watermark is not calculated for such configs, switching to non VGA mode causes FIFO underrun and display flicker. This fixes Korg Bug #14897. Signed-off-by: NDavid John <davidjon@xenontk.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 30 1月, 2010 4 次提交
-
-
由 Jesse Barnes 提交于
This patch adds support for page flipping on Ironlake, which uses different interrupt bits for triggering flip submit IRQs. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-resolved for rebasing off of render power saving patch] Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Reported-by: NPhilipp Kohlbecher <xt28@gmx.de> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Li Peng 提交于
Zhenyu noticed that the ironlake vblank enabling patch has one issue that it will trigger vblank starting from irq postinstall, this isn't necessary. This patch addresses this issue by only adding the vblank into DEIER but mask them in DEIMR, so that it won't trigger vblank interrupt at irq install. Signed-off-by: NLi Peng <peng.li@intel.com> Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 28 1月, 2010 1 次提交
-
-
由 Chris Wilson 提交于
Having missed the ENOMEM return via i915_gem_fault(), there are probably other paths that I also missed. By not enabling NORETRY by default these paths can run the shrinker and take memory from the system (but not from our own inactive lists because our shrinker can not run whilst we hold the struct mutex) and this may allow the system to survive a little longer whilst our drivers consume all available memory. References: OOM killer unexpectedly called with kernel 2.6.32 http://bugzilla.kernel.org/show_bug.cgi?id=14933 v2: Pass gfp into page mapping. v3: Use new read_cache_page_gfp() instead of open-coding. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eric Anholt <eric@anholt.net> Cc: stable@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 1月, 2010 5 次提交
-
-
由 Jesse Barnes 提交于
The first page flip queued will replace the current front buffer, which should have a 0 pending flip count. So at finish time we need to handle that case (i.e. if the flip count is 0 *or* dec_and_test is 0 we need to wake the waiters). Also fix up an error path in the queue function and add some debug output (only enabled with driver debugging). Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Li Peng 提交于
Pineview doesn't has CXSR and need GTT-based hardware status page. It fixes a X boot hung issue on Pinview since commit cfdf1f Signed-off-by: NLi Peng <peng.li@intel.com> Acked-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Li Peng 提交于
so far vblank interrupt on ironlake is disabled, this would cause bad gfx performance if userspace calls drm_wait_vblank. This patch enables vblank interrupt on ironlake and follows vblank get/put model. Signed-off-by: NLi Peng <peng.li@intel.com> Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
X.org hang with [drm:i915_gem_do_execbuffer] *ERROR* in dmesg http://bugzilla.kernel.org/show_bug.cgi?id=15114 Matej found he was hitting an error path within i915_gem_do_execbuffer() that led to the attempt to dereference an uninitialised pointer during cleanup. This path used to be safe as we used to calloc the object lists, but this was changed in c8e0f93a. Daniel Vetter had also spotted this error and proposed a similar patch. [ 6379.732892] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list [ 6379.740976] [drm:i915_gem_do_execbuffer] *ERROR* Object ffff880098cd6540 appears more than once in object list [ 6379.740995] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0 [ 6379.740998] IP: [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741006] PGD babab067 PUD bb435067 PMD 0 [ 6379.741010] Oops: 0002 [#1] PREEMPT SMP [ 6379.741014] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.2/0000:06:00.0/ieee80211/phy0/rfkill0/state [ 6379.741017] CPU 1 [ 6379.741021] Pid: 2186, comm: X Not tainted 2.6.33-rc4-00399-g24bc7347 #142 M11D/ESPRIMO Mobile M9400 [ 6379.741023] RIP: 0010:[<ffffffff8122ddb5>] [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741027] RSP: 0018:ffff8800b9047b78 EFLAGS: 00213206 [ 6379.741029] RAX: 0000000000000000 RBX: 000000000000004f RCX: ffff880098cac800 [ 6379.741032] RDX: ffff880098caca78 RSI: ffff8800b9047c98 RDI: ffff880098cd6540 [ 6379.741034] RBP: ffff8800b9047c78 R08: ffffffff814b96b5 R09: 0000000000000006 [ 6379.741036] R10: 0000000000000000 R11: 0000000000000003 R12: 000000000000004e [ 6379.741038] R13: 00000000fffffff7 R14: 0000000000000000 R15: 0000000000000001 [ 6379.741041] FS: 0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0 [ 6379.741043] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 6379.741041] FS: 0000000000000000(0000) GS:ffff880001900000(0063) knlGS:00000000f72636c0 [ 6379.741043] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 [ 6379.741045] CR2: 00000000000000a0 CR3: 00000000b9000000 CR4: 00000000000006e0 [ 6379.741048] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6379.741050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 6379.741052] Process X (pid: 2186, threadinfo ffff8800b9046000, task ffff8800bb5d8000) [ 6379.741054] Stack: [ 6379.741055] ffffc90023f57000 ffffc90023f56fff ffffc90023f56fff ffffc90023f55000 [ 6379.741059] <0> ffff8800b9047c98 ffff8800bb43c840 ffff8800bf1de800 ffff8800bf1de820 [ 6379.741063] <0> ffff8800b9047bd8 ffff880098cac800 0000000000000000 0000000000000002 [ 6379.741068] Call Trace: [ 6379.741072] [<ffffffff8122e6cb>] ? i915_gem_execbuffer+0x6b/0x370 [ 6379.741077] [<ffffffff810a5f52>] ? __vmalloc_node+0xa2/0xb0 [ 6379.741080] [<ffffffff8122e6cb>] ? i915_gem_execbuffer+0x6b/0x370 [ 6379.741083] [<ffffffff8122e816>] i915_gem_execbuffer+0x1b6/0x370 [ 6379.741086] [<ffffffff8120cd55>] drm_ioctl+0x1d5/0x460 [ 6379.741089] [<ffffffff8122e660>] ? i915_gem_execbuffer+0x0/0x370 [ 6379.741093] [<ffffffff81248c35>] i915_compat_ioctl+0x45/0x50 [ 6379.741097] [<ffffffff810f1659>] compat_sys_ioctl+0xa9/0x1570 [ 6379.741102] [<ffffffff810b1d5c>] ? vfs_read+0x13c/0x1a0 [ 6379.741106] [<ffffffff81028424>] sysenter_dispatch+0x7/0x2b [ 6379.741108] Code: 08 85 c0 74 52 31 db 0f 1f 80 00 00 00 00 48 63 c3 48 8b 8d 68 ff ff ff 48 8d 14 c1 48 8b 02 48 85 c0 74 25 48 8b 80 80 00 00 00 <c7> 80 a0 00 00 00 00 00 00 00 48 8b 3a 48 85 ff 74 0c 48 c7 c6 [ 6379.741142] RIP [<ffffffff8122ddb5>] i915_gem_do_execbuffer+0xba5/0x1260 [ 6379.741145] RSP <ffff8800b9047b78> [ 6379.741147] CR2: 00000000000000a0 [ 6379.741159] ---[ end trace 0598809afa4c31db ]--- Reported-by: NMatej Laitl <strohel@gmail.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
This tries to fix CRT detect loop hang seen on some Ironlake form factor, to clear up hotplug detect state before taking CRT detect to make sure next hotplug detect cycle is consistent. Cc: Stable Team <stable@kernel.org> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 16 1月, 2010 8 次提交
-
-
由 Zhenyu Wang 提交于
This enables possible 36bit address mask on 965G that use physical address for hw status page. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
eDP could be on pipe A or B. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
Original DP mode_valid check didn't take pixel color depth into account, which made one 1600x900 eDP panel's mode check invalid because of overclock, but actually this 6bpc panel does can work with x1 lane at 2.7G. This one trys to take bpp value properly both in mode validation and mode setting. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Jesse Barnes 提交于
Many platform support this feature, and it can provide significant power savings when the reduced refresh rate is low. However, on some platforms a secondary (reduced) timing is provided but not actually supported by the hardware. This results in undesirable flicker at runtime. So disable the feature by default, but allow users to opt-in to the reduced clock behavior with a new module parameter, lvds_downclock, that can be set to 1 to enable the feature. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Reviewed-by: NEric Anholt <eric@anholt.net> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Eric Anholt 提交于
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> (in principle) Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zou Nan hai 提交于
On Ironlake, there is an interrupt master control bit. With the bit disabled before clearing IIR, we do not need to handle extra interrupt in a loop. This patch removes the loop in Ironlake interrupt handler. It fixed irq lost issue on some Ironlake platforms. Cc: Stable Team <stable@kernel.org> Signed-off-by: NZou Nan hai <Nanhai.zou@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 13 1月, 2010 5 次提交
-
-
由 Zhenyu Wang 提交于
When we setup buffer for display plane, we'll check any pending required GPU flush and possible make interruptible wait for flush complete. But that wait would be most possibly to fail in case of signals received for X process, which will then fail modeset process and put display engine in unconsistent state. The result could be blank screen or CPU hang, and DDX driver would always turn on outputs DPMS after whatever modeset fails or not. So this one creates new helper for setup display plane buffer, and when needing flush using uninterruptible wait for that. This one should fix bug like https://bugs.freedesktop.org/show_bug.cgi?id=24009. Also fixing mode switch stress test on Ironlake. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
There exist multiple DDC buses for the SDVO cards with multiple outputs. When we can't get the EDID by using the select DDC bus, we can try the other possible DDC bus to see whether the EDID can be obtained. https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
For some SDVO cards based on conexant chip, we can't read the EDID if we don't read the response after issuing SDVO DDC bus switch command. From the SDVO spec once when another I2C transaction is finished after completing the I2C transaction of issuing the bus switch command, it will be switched back to the SDVO internal state again. So we can't initiate a new I2C transaction to read the response after issuing the DDC bus switch command. Instead we should issue DDC bus switch command and read the response in the same I2C transaction. https://bugs.freedesktop.org/show_bug.cgi?id=23842 https://bugs.freedesktop.org/show_bug.cgi?id=24458 https://bugs.freedesktop.org/show_bug.cgi?id=24522 https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
On some boxes the BIOS will report different child device arrays when the system is booted with/without the dock. In such case the HDMI/DP port can't be setup correctly. So revert two commits (fc816655/ 6e36595a) that use the child device parsed from VBT to setup HDMI/DP. http://bugzilla.kernel.org/show_bug.cgi?id=14854 http://bugzilla.kernel.org/show_bug.cgi?id=14860Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Tested-by: NSean Young <sean@mess.org> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Rafael J. Wysocki 提交于
Commit cbda12d7 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d7. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> [anholt: added comment explaining when .suspend/.resume matter] Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 09 1月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit cbda12d7 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d7. [ The DRM layer will not use the class-specific suspend/resume functions if the driver is marked MODESET-aware, and conversely it will not register the PCI device if the drievr isn't so marked, so you always end up with _either_ the drm-class suspend/resume _or_ the PCI layer PM functionality, never both. - Linus ] Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 1月, 2010 4 次提交
-
-
由 Zhao Yakui 提交于
Without this fix, some modes couldn't find appropriate clocks. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net> Tested-by: NMatthew Garrett <mjg@redhat.com>
-
由 Zhao Yakui 提交于
For any given clock we can use the find_pll to get the corresponding DPLL setting. It is unnecessary to use the find_reduce_pll callback function to calculate the DPLL parameter for LVDS downclock in order to get the same divider factor(P) for the normal and downclock. In theory when the LVDS downclock is supported by LVDS panel, we should get the same DPLL divider factor(P) for the normal clock and reduced downclock. If we get the diferent divider factor(P) for normal clock and reduced downclock, it means that the found downclock is incorrect and should be discarded. So we should use find_pll callback to calculate the DPLL parameter for the LVDS reduced downclock as for the normal clock. Then we can do the cleanup about find_reduced_pll. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> cc: Jesse Barnes <jbarnes@virtuousgeek.org> cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is closed and we can't use it reliabily for LVDS detection. So add the two boxes into the quirk list. http://bugzilla.kernel.org/show_bug.cgi?id=14957 http://bugzilla.kernel.org/show_bug.cgi?id=14554Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhenyu Wang 提交于
As we removed TV hotplug, don't check its status ever. Reviewed-by: NAdam Jackson <ajax@redhat.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 07 1月, 2010 3 次提交
-
-
由 Zhenyu Wang 提交于
drm_pci_alloc() has input of address mask for setting pci dma mask on the device, which should be properly setup by drm driver. And leave it as a param for drm_pci_alloc() would cause confusion or mistake would corrupt the correct dma mask setting, as seen on intel hw which set wrong dma mask for hw status page. So remove it from drm_pci_alloc() function. Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Zhenyu Wang 提交于
This one reverts 9e3a6d15. As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485, this dump will cause hang problem on some machine. If something really needs this kind of full registers dump, that could be done within intel-gpu-tools. Cc: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Zhao Yakui 提交于
For some clocks, the old Ironlake DPLL calculator wold give m/n/p combinations that didn't match the spreadsheet of what HW validation tests. Instead, use the G4X DPLL calculator, which does a better job at it. So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS on ironlake. At the same time to consider the dpll setting for display port, we add the display port DPLL limit on ironlake, which will directly use the function of intel_find_pll_ironlake_dp to get the corresponding dpll setting. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-