- 01 Apr, 2016 2 commits
-
-
Shubhangi Shrivastava authored
Current DP detection has DPCD operations split across intel_dp_hpd_pulse and intel_dp_detect which contains duplicates as well. Also intel_dp_detect is called during modes enumeration as well which will result in multiple dpcd operations. So this patch tries to solve both these by bringing all DPCD operations in one single function and make intel_dp_detect use existing values instead of repeating same steps. v2: Pulled in a hunk from last patch of the series to this patch. (Ander) v3: Added MST hotplug handling. (Ander) v4: Added a flag to check if detect is performed to prevent multiple detects on hotplug. (Ander) Tested-by:Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> [anderco: fix parenthesis aligment] Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-2-git-send-email-shubhangi.shrivastava@intel.com
-
Shubhangi Shrivastava authored
intel_dp_detect() is called for not just detection but during modes enumeration as well. Repeating the whole sequence during each of these calls is wasteful and time consuming. This patch moves probing for panel, DPCD read etc done in intel_dp_detect() to a new function intel_dp_long_pulse(). Note that the behavior of intel_dp_detect() is changed to report connected or disconnected depending on whether the EDID is available or not. This change will be required by further patches in the series to avoid performing duplicated DPCD operations on hotplug. v2: Moved a hunk to next patch of the series. Moved intel_dp_unset_edid to out. (Ander) v3: Rephrased commit message and intel_dp_unset_dp() is called within intel_dp_set_dp() to free the previous EDID. (Ander) v4: Added overriding of status to disconnected for MST. (Ander) Tested-by:
-
- 31 Mar, 2016 5 commits
-
-
Joonas Lahtinen authored
Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt", "vm" or indirectly through other variables like "dev_priv->ggtt.base" to avoid confusion with the i915_ggtt object itself and PPGTT VMs. Refer to the GGTT as "ggtt" instead of indirectly through chaining. As a bonus gets rid of the long-standing i915_obj_to_ggtt vs. i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt! v2: - Added some more after grepping sources with Chris v3: - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm (Chris) v4: - Convert all dev_priv->ggtt->foo accesses to ggtt->foo. v5: - Make patch checker happy Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Maarten Lankhorst authored
Without this a vblank may occur between updating color management and planes, which should be prevented. intel_color_set_csc was called in update pipe config because the handover from hardware may not have any csc set, which resulted in a black screen. Because of this also update color management during fastset. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Maarten Lankhorst authored
This is already tested by its callers. Signed-off-by:
-
-
Maarten Lankhorst authored
With async modesets this is no longer protected with connection_mutex, so ensure that each pll has its own lock. The pll configuration state is still protected; it's only the pll updates that need locking against concurrency. Changes since v1: - Rebased. - Fix locking to protect all accesses. (Durgadoss) Changes since v2: - Make the dpll_lock global to protect concurrent updates to the same register, for example DPLL_CTRL1 on skl. (Ander) Signed-off-by:
-
- 30 Mar, 2016 10 commits
-
-
Daniel Vetter authored
And move the comment to the right macro. This was mixed up in commit cfb23ed6 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Jul 14 12:17:40 2015 +0200 drm/i915: Allow fuzzy matching in pipe_config_compare, v2 v2: Rebase. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330476-32453-1-git-send-email-daniel.vetter@ffwll.ch
-
Rodrigo Vivi authored
We now have KBL machines running in our CI systems and with no blocking issues that could cause a full hangs or blank screens. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459349881-951-1-git-send-email-rodrigo.vivi@intel.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
This effectively reverts commit 8e5fd599 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:50 2014 +0300 drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed as under continuous execlists load we can saturate the IRQ handler, destablising the tsc clock and triggering the NMI watchdog to declare a hung CPU. [ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff [ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff [ 552.756210] clocksource: Switched to clocksource refined-jiffies [ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18 [ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000 [ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000 [ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e [ 575.217967] Call Trace: [ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72 [ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160 [ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0 [ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20 [ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460 [ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50 [ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130 [ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470 [ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e [ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0 [ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20 [ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40 [ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330 [ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130 However, not servicing all available IIR within the handler does hurt the throughput of pathological nop execbuf by about 20%, with a similar effect upon the dispatch latency of a series of execbuf. v2: use do {} while(0) for a smaller patch, and easier to revert again I have reasonable confidence that we do not miss GT interrupts (as execlists provides a stress case with a failure mechanism easily detected by igt), however I have less confidence about all the other sources of interrupts and worry that may lose a display hotplug interrupt, for example. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467 Testcase: igt/gem_exec_nop/basic # requires NMI watchdog Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
__force_wake_get() only acquires a temporary wakeref on forcewake that is automatically released when a timer expires. When reading the code again, I confused __intel_uncore_forcewake_get() for __force_wake_get() and to my shame thought I found a bug in unbalanced wake_count handling. I claim that if the function had been called __force_wake_auto() instead I would not have embarrassed myself. Signed-off-by:
-
Joonas Lahtinen authored
Rename and document the GGTT init functions to give a better idea of the context where they are called from. i915_gem_gtt_init => i915_ggtt_init_hw i915_gem_init_global_gtt => i915_gem_init_ggtt i915_global_gtt_cleanup => i915_ggtt_cleanup_hw Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
Lets BUG_ON and don't bother with a WARN and returning an error, so we can remove the need to pollute the code with error handling, after all it is a programmer error to provide NULL view. Also while we're here remove redundant NULL ggtt_view check. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Acked-by:
-
Bjørn Mork authored
commit e2c8b870 moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 #385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] #6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by: -
Lyude authored
Since we need MST devices ready before we try to resume displays, calling this after intel_display_resume() can result in some issues with various laptop docks where the monitor won't turn back on after suspending the system. This order was originally changed in commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state") In order to fix some unclaimed register errors, however the actual cause of those has since been fixed. CC: stable@vger.kernel.org Signed-off-by:
Lyude <cpaul@redhat.com> [danvet: Resolve conflicts with locking changes.] Signed-off-by:
-
Lukas Wunner authored
The ->lastclose callback invokes intel_fbdev_restore_mode() and has been witnessed to run before intel_fbdev_initial_config_async() has finished. We might likewise receive hotplug events before we've had a chance to fully set up the fbdev. Fix by waiting for the asynchronous thread to finish. v2: An async_synchronize_full() was also added to intel_fbdev_set_suspend() in v1 which turned out to be entirely gratuitous. It caused a deadlock on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela for CI support) and was unnecessary since a device is never suspended until its ->probe callback (and all asynchronous tasks it scheduled) have finished. See dpm_prepare(), which calls wait_for_device_probe(), which calls async_synchronize_full(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Reported-by:
Gustav Fägerlind <gustav.fagerlind@gmail.com> Reported-by:
"Li, Weinan Z" <weinan.z.li@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
- 29 Mar, 2016 4 commits
-
-
Jani Nikula authored
Set from VBT, but never used. Good riddance. Reviewed-by:
-
Jani Nikula authored
Move all data initialized from VBT under dev_priv->vbt. No functional changes. Reviewed-by:
-
Jani Nikula authored
Move all data initialized from VBT under dev_priv->vbt. No functional changes. Reviewed-by:
-
Jani Nikula authored
Housekeeping, similar to psr, backlight, and dsi. No functional changes. Reviewed-by:
-
- 24 Mar, 2016 4 commits
-
-
Dave Gordon authored
Having provided for_each_engine_id() for cases where the third (id) argument is useful, we can now replace all the remaining instances with a simpler version that takes only two parameters. In many cases, this also allows the elimination of the local variable used in the iterator (usually 'i'). v2: s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson] Signed-off-by:Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Dave Gordon authored
Equivalent to the existing for_each_engine() macro, this will replace the latter wherever the third argument *is* actually wanted (in most places, it is not used). The third argument is renamed to emphasise that it is an engine id (type enum intel_engine_id). All the callers of the macro that actually need the third argument are updated to use this version, and the argument (generally 'i') is also updated to be 'id'. Other callers (where the third argument is unused) are untouched for now; they will be updated in the next patch. Signed-off-by:
-
Imre Deak authored
Currently the machine hangs during booting while accessing the BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some experimentation I found that the hang is caused by the DSI PLL being disabled, or it being enabled but with an incorrect divider configuration. Enabling the PLL got rid of the boot problem, so fix this by checking the PLL enabled state/configuration before attempting to read out the HW state. The DSI_PLL_ENABLE register is in the always-on power well, while the BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the transcoder power domain, but what we really need is just a runtime PM reference, which is provided by any power domain. Ville also found this dependency specified in BSpec, so I added a reference to that too. v2: - Make sure we hold a power reference while accessing the PLL registers. v3: (Jani) - Simplify check in bxt_get_dsi_transcoder_state() - Add comment explaining why we check for valid dividers in bxt_dsi_pll_is_enabled() CC: Shashank Sharma <shashank.sharma@intel.com> CC: Uma Shankar <uma.shankar@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Fixes: c6c794a2 ("drm/i915/bxt: Initialize MIPI DSI for BXT") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458816100-31269-1-git-send-email-imre.deak@intel.com
-
Maarten Lankhorst authored
intel_post_plane_update did an extra vblank wait that's no longer needed when enabling ips. Changes since v1: - Add comment explaining why vblank wait is performed. (Paulo) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56F29B28.5070804@linux.intel.com
-
- 23 Mar, 2016 15 commits
-
-
Chris Wilson authored
In commit 0a878716 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 14:23:01 2015 +0200 drm/i915: restore ggtt double-bind avoidance we wrote the ggtt_bind_vma() observing a number of cleanups we could do over the template of aliasing_gtt_bind_vma(). Now let's apply the cleanups we made there back to the original. The essence is to avoid redundant variables and assignements, and by doing so make the code easier to read. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split a pnv_crtc_compute_clock(), so the differences between platforms become more obvious. With this, there are no more users of intel_limit() or the ->find_dpll() hook, so get rid of them. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split a G4X specific version from i9xx_crtc_compute_clock(). With this the differences between platforms become more obvious. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Split a GEN2 specific version from i9xx_crtc_compute_clock(). With this there is no need for i9xx_get_refclk() anymore, and the differences between platforms become more obvious. v2: Use i8xx as prefix instead of gen2. (Ville and Daniel) Signed-off-by:
-
Ander Conselvan de Oliveira authored
In order for VLV and CHV to use i9xx_crtc_compute_clocks(), a number of if ladders is necessary: one for setting the find_dpll() hook, one for choosing the limits struct, one for choosing the right compute dpll function and one for initializing the crtc_compute_clock() hook. By extracting a platform specific implementation for each platform, the number of if-ladders is reduced to one. While at it also clean up bxt_find_best_dpll() which depends on some of the CHV code. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Merge ironlake_compute_clocks() into ironlake_crtc_compute_clock() so the clock computation logic is all in one place. The resulting function is still quite simple. Follow up patches will make the similar code for GMCH platforms look similar. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Follow what is done in i8xx_compute_dpll() and i9xx_compute_dpll() and move the lower level details of setting crtc_state->dpll_hw_state into the _compute_dpll() function. Reviewed-by:
-
Ander Conselvan de Oliveira authored
When calculating clocks, just pass a pointer to crtc_state->dpll directly to the find_dpll() hook. Back when this was introduced in commit f47709a9 ("drm/i915: create pipe_config->dpll for clock state") there was no staged crtc config or atomic crtc state, so it was possible to overwrite the current configuration on error. That hasn't been the case for a while now, so finally make it "disappear". Signed-off-by:
-
Ander Conselvan de Oliveira authored
None of the code in ironlake_crtc_compute_clock() is relevant for CPU eDP. The CPU eDP PLL is turned on and off in ironlake_edp_pll_{on,off} from the DP code and that doesn't depend on the crtc_state->dpll values, so just return early in that case. v2: Rebase without patch that drops lvds downclock code. (Ville) Signed-off-by: -
Ander Conselvan de Oliveira authored
The checks were added in commit 5dc5298b ("drm/i915: add proper CPU/PCH checks to crtc_mode_set functions") in a time when there was doubts on what PCHs would be supported by HSW. There are similar checks for PCH type in intel_detect_pch() and the function pointers are initialized based on platform/pch information, so the removed WARN can't ever be reached. v2: Rebase without patch that drops lvds downclock code. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Remove the clock calculation from ironlake_crtc_compute_clock() when the encoder compute_config() already set one. The value was just thrown away in that case. Note that the previously set clock is not validated against the limits anymore. That is ok since the fixed clocks from DP and SDVO are within the supported range, so the call to ironlake_compute_clocks() would never fail in that case. v2: Add note about not checking fixed clocks agains limits. (Maarten) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Check has_reduced_clock only once when setting dpll_hw_state, making the code slightly more readable. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The call to dev_priv->display.find_dpll() is already in platform specific code, so avoid the extra detour. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function intel_ironlake_limit() is only called by the crtc compute clock path. By merging it into ironlake_compute_clocks(), the code gets clearer, since there's no more if-ladders to follow. Signed-off-by:
-
Ander Conselvan de Oliveira authored
A previous patch made ironlake_get_refclk() very simple, so merge it into its only caller. Signed-off-by:
-
