- 30 May, 2016 3 commits
-
-
Ville Syrjälä authored
v2: Fix intel_crtc leak on failure to allocate the name Use a local 'name' variable to make things easier v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani) v4: Pass the printf style format string to drm_crtc_init_with_planes() v5: Drop spurious code changes Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
We have plane->name, so let's use that in debug messages instead of just printing the more or less useless object ID. v2: slap on a commit message Signed-off-by:
-
Ville Syrjälä authored
We have crtc->name, so let's use that in debug messages instead of just printing the more or less useless object ID. v2: Rebased due to intel_dpll_mgr.c, slap on a commit message Signed-off-by:
-
- 27 May, 2016 1 commit
-
-
Ville Syrjälä authored
Reject the modeset if the requested dotclock exceeds the maximum allowed by the hardware. So far we've only checked this on gen2/3 while also handling the double wide vs. single wide pipe selection. Extend the check to all platforms since we have the max dotclock correctly populated now across the board. Testcase: igt/kms_invalid_dotclock Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 26 May, 2016 2 commits
-
-
Ander Conselvan de Oliveira authored
In commit f9476a6c ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error check, that can lead to a NULL pointer dereference when trying to enable three pipes. BUG: unable to handle kernel NULL pointer dereference at 0000000000000068 IP: [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] PGD cec87067 PUD d30ce067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: snd_hda_intel i915 drm_kms_helper drm intel_gtt sch_fq_codel cfg80211 binfmt_misc i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp agpgart kvm_intel snd_hda_codec_hdmi kvm iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic irqbypass aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse pcspkr snd_hda_codec i2c_i801 snd_hwdep snd_hda_core snd_pcm snd_timer lpc_ich mfd_core snd soundcore wmi evdev tpm_tis tpm [last unloaded: drm] CPU: 3 PID: 5810 Comm: kms_flip Tainted: G U W 4.6.0-test+ #3 Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013 task: ffff8800d3908040 ti: ffff8801166c8000 task.ti: ffff8801166c8000 RIP: 0010:[<ffffffffa0482275>] [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP: 0018:ffff8801166cba60 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002 RDX: 0000000000000001 RSI: ffff8800d07f1bf8 RDI: 0000000000000000 RBP: ffff8801166cba88 R08: 0000000000000002 R09: ffff8800d32e5698 R10: 0000000000000001 R11: ffff8800cc89ac88 R12: ffff8800d07f1bf8 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f4c3fc8d8c0(0000) GS:ffff88011bcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000068 CR3: 00000000d3b4c000 CR4: 00000000001406e0 Stack: 0000000000000000 ffff8800d07f1bf8 0000000000000000 ffff8800d04c0000 0000000000000000 ffff8801166cbaa8 ffffffffa04823a7 ffff8800d07f1bf8 ffff8800d32e5698 ffff8801166cbab8 ffffffffa04840cf ffff8801166cbaf0 Call Trace: [<ffffffffa04823a7>] ibx_get_dpll+0x47/0xa0 [i915] [<ffffffffa04840cf>] intel_get_shared_dpll+0x1f/0x50 [i915] [<ffffffffa046d080>] ironlake_crtc_compute_clock+0x280/0x430 [i915] [<ffffffffa0472ac0>] intel_crtc_atomic_check+0x240/0x320 [i915] [<ffffffffa03da18e>] drm_atomic_helper_check_planes+0x14e/0x1d0 [drm_kms_helper] [<ffffffffa0474a0c>] intel_atomic_check+0x5dc/0x1110 [i915] [<ffffffffa029d3aa>] drm_atomic_check_only+0x14a/0x660 [drm] [<ffffffffa029d086>] ? drm_atomic_set_crtc_for_connector+0x96/0x100 [drm] [<ffffffffa029d8d7>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa03dc3b7>] restore_fbdev_mode+0x237/0x260 [drm_kms_helper] [<ffffffffa029c65a>] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm] [<ffffffffa03de9b3>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper] [<ffffffffa03dea2d>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [<ffffffffa03de93a>] drm_fb_helper_hotplug_event+0xaa/0xf0 [drm_kms_helper] [<ffffffffa03de9d6>] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80 [drm_kms_helper] [<ffffffffa0490f72>] intel_fbdev_restore_mode+0x22/0x80 [i915] [<ffffffffa04ba45e>] i915_driver_lastclose+0xe/0x20 [i915] [<ffffffffa02810de>] drm_lastclose+0x2e/0x130 [drm] [<ffffffffa028148c>] drm_release+0x2ac/0x4b0 [drm] [<ffffffff811a6b2d>] __fput+0xed/0x1f0 [<ffffffff811a6c6e>] ____fput+0xe/0x10 [<ffffffff81079156>] task_work_run+0x76/0xb0 [<ffffffff8105aaab>] do_exit+0x3ab/0xc60 [<ffffffff810a145f>] ? trace_hardirqs_on_caller+0x12f/0x1c0 [<ffffffff8105c67e>] do_group_exit+0x4e/0xc0 [<ffffffff8105c704>] SyS_exit_group+0x14/0x20 [<ffffffff8158bb25>] entry_SYSCALL_64_fastpath+0x18/0xa8 Code: 14 80 48 8d 34 90 b8 01 00 00 00 d3 e0 09 04 b3 5b 41 5c 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 41 54 53 <44> 8b 67 68 48 89 f3 48 8b be 08 02 00 00 4c 8b 2e e8 15 9d fd RIP [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915] RSP <ffff8801166cba60> CR2: 0000000000000068 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Reported-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
-
Lyude authored
Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL configurations. This causes issues on the first modeset, since we don't expect SSC to be left on and as a result, can't successfully power down the pipes or the transcoders using it. Here's an example from this Dell OptiPlex 990: [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled [drm:intel_modeset_init] 2 display pipes available. [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm:intel_crt_reset] crt adpa set to 0xf40000 [drm:intel_dp_init_connector] Adding DP connector on port C [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1 [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0 [drm:ironlake_init_pch_refclk] Disabling SSC entirely … later we try committing the first modeset … [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A [drm:intel_dump_pipe_config] cpu_transcoder: A … [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07 [drm:intel_dump_pipe_config] planes on this crtc [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258 [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600 [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0 [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0 [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A [drm:intel_disable_pipe] disabling pipe A ------------[ cut here ]------------ WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915] pipe_off wait timed out … ---[ end trace 94fc8aa03ae139e8 ]--- [drm:intel_dp_link_down] [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A Later modesets succeed since they reset the DPLL's configuration anyway, but this is enough to get stuck with a big fat warning in dmesg. A better solution would be to add refcounts for the SSC source, but for now leaving the source clock on should suffice. Changes since v3: - Move temp variable into loop - Move checks for using_ssc_source to after we've figured out has_ck505 - Add using_ssc_source to debug output Changes since v2: - Fix debug output for when we disable the CPU source Changes since v1: - Leave the SSC source clock on instead of just shutting it off on all of the DPLL configurations. Cc: stable@vger.kernel.org Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464199863-9397-1-git-send-email-cpaul@redhat.com
-
- 25 May, 2016 3 commits
-
-
Imre Deak authored
I noticed that during S4 resume BIOS incorrectly sets bits 18, 19 which are reserved/MBZ and sets the decimal frequency fields to all 0xff in the CDCLK register. The result is a hard lockup as display register accesses are attempted later. Work around this by sanitizing the CDCLK PLL/dividers the same way it's done on SKL. While this is clearly a BIOS bug which should be fixed separately, it doesn't hurt to check/sanitize this regardless. v2: - Use the same condition for VCO and CDCLK in broxton_init_cdclk as is used in skl_init_cdclk for the same purpose. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
If the CDCLK PLL isn't locked or incorrectly configured we can just assume that it's off resulting in fully re-initializing both CDCLK PLL and CDCLK dividers. This way the CDCLK PLL sanitization added in the following patch can be done on BXT the same way as it's done on SKL. v2: (Ville) - Remove the remaining PLL specific checks from skl_sanitize_cdclk() and depend instead on the corresponding check in skl_dpll0_update(). - Use vco == 0 instead of the corresponding boolean check in skl_sanitize_cdclk(). CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
This reverts the following patches: d55dbd06 drm/i915: Allow nonblocking update of pageflips. 15c86bdb drm/i915: Check for unpin correctness. 95c2ccdc Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b73 drm/i915: Make unpin async. 03f476e1 drm/i915: Prepare connectors for nonblocking checks. 2099deff drm/i915: Pass atomic states to fbc update functions. ee7171af drm/i915: Remove reset_counter from intel_crtc. 2ee004f7 drm/i915: Remove queue_flip pointer. b8d2afae drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d9 drm/i915: Remove cs based page flip support. 143f73b3 drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b drm/i915: Add the exclusive fence to plane_state. 6885843a drm/i915: Convert flip_work to a list. aa420ddd drm/i915: Allow mmio updates on all platforms, v2. afee4d87 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates" "drm/i915: Allow nonblocking update of pageflips" should have been split up, misses a proper commit message and seems to cause issues in the legacy page_flip path as demonstrated by kms_flip. "drm/i915: Make unpin async" doesn't handle the unthrottled cursor updates correctly, leading to an apparent pin count leak. This is caught by the WARN_ON in i915_gem_object_do_pin which screams if we have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins. Unfortuantely we can't just revert these two because this patch series came with a built-in bisect breakage in the form of temporarily removing the unthrottled cursor update hack for legacy cursor ioctl. Therefore there's no other option than to revert the entire pile :( There's one tiny conflict in intel_drv.h due to other patches, nothing serious. Normally I'd wait a bit longer with doing a maintainer revert, but since the minimal set of patches we need to revert (due to the bisect breakage) is so big, time is running out fast. And very soon (especially after a few attempts at fixing issues) it'll be really hard to revert things cleanly. Lessons learned: - Not a good idea to rush the review (done by someone fairly new to the area) and not make sure domain experts had a chance to read it. - Patches should be properly split up. I only looked at the two patches that should be reverted in detail, but both look like the mix up different things in one patch. - Patches really should have proper commit messages. Especially when doing more than one thing, and especially when touching critical and tricky core code. - Building a patch series and r-b stamping it when it has a built-in bisect breakage is not a good idea. - I also think we need to stop building up technical debt by postponing atomic igt testcases even longer. I think it's clear that there's enough corner cases in this beast that we really need to have the testcases _before_ the next step lands. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 24 May, 2016 11 commits
-
-
Chris Wilson authored
One of the uses for i915_gem_objects is pin-pointing leaks. For this, we can compare the number of allocated objects and who owns them, a discrepancy here often indicates a kernel bug. One allocator of unreported objects is for backing context objects, so include those in the listing. v2: Take filelist_mutex which requires a little dance with struct_mutex to avoid nesting filelist_mutex inside struct_mutex. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-10-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pack the integers and related types together inside the struct. Signed-off-by:
-
Chris Wilson authored
struct intel_context contains two substructs, one for the legacy RCS and one for every execlists engine. Since legacy RCS is a subset of the execlists engine support, just combine the two substructs. v2: Only pin the default context for legacy mode (the object only exists for legacy, but adding i915.enable_execlists provides symmetry with the cleanup functions). Signed-off-by:
-
Chris Wilson authored
Just move the kernel_context member of drm_i915_private next to the engines it is associated with. Signed-off-by:
-
Chris Wilson authored
Print the context's owner (via the pid under file_priv) under debugfs. In doing so, we must be careful that the filp is not accessed after it is freed (notified via i915_gem_context_close). v2: Mark the file_priv as closed. Signed-off-by:
-
Chris Wilson authored
Rather than have every context ask "am I owned by the kernel? pin!", move that logic into the creator of the kernel context, in order to improve code comprehension. v2: Throw away the user_handle on failure to allocate the ppgtt. Signed-off-by:
-
Chris Wilson authored
We want to give a name to the currently anonymous per-engine struct inside the context, so that we can assign it to a local variable and save clumsy typing. The name we have chosen is intel_context as it reflects the HW facing portion of the context state (the logical context state, the registers, the ringbuffer etc). Signed-off-by:
-
Chris Wilson authored
i915_gem_context_get() is a very simple wrapper around idr_find(), so simple that it would be smaller to do the lookup inline. Also we use the verb 'lookup' to return a pointer from a handle, freeing 'get' to imply obtaining a reference to the context. Signed-off-by:
-
Chris Wilson authored
Markup the functions that require the caller to hold struct_mutex with lockdep_assert_held(). In the hopefully not-too-distant future we will split the struct_mutex up, and in doing so we need to be sure that we know what it protects - here the lockdep annotations are invaluable. Signed-off-by:
-
Chris Wilson authored
Our goal is to rename the anonymous per-engine struct beneath the current intel_context. However, after a lively debate resolving around the confusion between intel_context_engine and intel_engine_context, the realisation is that the two structs target different users. The outer struct is API / user facing, and so carries the higher level GEM information. The inner struct is hw facing. Thus we want to name the inner struct intel_context and the outer one i915_gem_context. As the first step, we need to rename the current struct: s/struct intel_context/struct i915_gem_context/ which fits much better with its constructors already conveying the i915_gem_context prefix! Signed-off-by:
-
Tvrtko Ursulin authored
New GuC code is logging errors at runtime suspend and resume which causes CI testing to log "orange" status. Default to not trying to load the firmware until this is resolved. Example of the log: [drm] RC6 on [drm:intel_runtime_suspend] Suspending device [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. ret=-110 status=0x00000501 response=0x40000000 ... [drm:intel_runtime_resume] Resuming device [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. ret=-110 status=0x00000502 response=0x40000000 [drm:intel_runtime_resume] Device resumed Signed-off-by:
-
- 23 May, 2016 20 commits
-
-
Ville Syrjälä authored
Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling. Let's make sure it has correctly restored the dbuf state to enabled when we disable the DC states. v2: s/skl/gen9/ in function name (Imre) Cc: Imre Deak <imre.deak@intel.com> Suggested-by:
-
Ville Syrjälä authored
In case the driver is initialized without active displays, we should just drop the cdclk to the minimum frequency right off the bat. There might not be a modeset to drop it to the minimum late rafter all. With DMC supposedly we should always have the cdclk up and running. The DMC will shut the DE PLL down when appropriate, so let's nuke the related FIXMEs as well. Trying to do anything different would go against the expectations of the DMC firmware, and we all know how fragile the DMC firmware is. Signed-off-by:
-
Ville Syrjälä authored
Rather than having a BXT specific function to make sure the DE PLL is enabled after disabling DC6, let's just make sure the current cdclk is the same as what we last programmed. Having another check in bxt_display_core_init() almost immediately after the cdclk init seems redundant, so let's just kill that one. Signed-off-by:
-
Ville Syrjälä authored
Make bxt_set_cdclk() more readable by looking at current vs. target DE PLL vco to determine if the DE PLL needs disabling and/or enabling. We can also calculate the CD2X divider simply as (vco/cdclk) instead of depending on magic numbers. The magic numbers are still needed though, but only to map the supported cdclk frequencies to corresponding DE PLL frequencies. Note that w'll now program CDCLK_CTL correctly even for the bypass case. Actually the CD2X divider should not matter in that case since the hardware will bypass it too, but the "decimal" part should matter (if we want to do gmbus/aux with the bypass enabled). Signed-off-by:
-
Ville Syrjälä authored
Now that we've read out the DE PLL vco and refclk, we can just use them in the cdclk calculation. While at it switch over to DIV_ROUND_CLOSEST(). Signed-off-by:
-
Ville Syrjälä authored
Let's make sure our cached cdclk state is accurate right after broxton_init_cdclk() whether or not we end up changing the cdclk frequency. Signed-off-by:
-
Ville Syrjälä authored
We have need to know the DE PLL refclk and output frequency in various cdclk calculations, so let's store those in dev_priv. Signed-off-by:
-
Ville Syrjälä authored
Enabling and disalbing the DE PLL are two nice self contained operations, so let's move them into a few small helper functions. Makes it easier to see the forest from the trees in broxton_set_cdclk(). Signed-off-by:
-
Ville Syrjälä authored
Future platforms will have multiple options for the cdclk PLL reference clock, so let's start tracking that under dev_priv alreday on SKL, although on SKL it's always 24 MHz. Signed-off-by:
-
Ville Syrjälä authored
We'll want to store the cdclk PLL (whatever PLL that is in reality) vco frequency somewhere on other platforms too, so let's rename the skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz to match most of the other clocks. v2: Drop the spurious > vs != change (Imre) Signed-off-by:
-
Ville Syrjälä authored
The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz. Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz. Let's use the slightly more accurate numbers. Potentially we might change to computing all of these based on dividers, but let's stick to the current theme for now.. Signed-off-by:
-
Ville Syrjälä authored
SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice shouldn't hurt since you're just setting the request bit again when it was already set. We can also toss in a few WARNs about the register values into skl_get_dpll0_vco() now that we know that things should always be sane there. Flatten skl_init_cdclk() while at it. v2: s/skl/gen9/ in function names (Imre) Signed-off-by:
-
Ville Syrjälä authored
Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we first run through the cdclk sanitation code, which will first verify that the PLL is programmed correctly, after which we can read out the current cdclk frequency, and once the cdclk is known we verify that the cdclk "decimal" frequency is programmed correctly. If any of these fail we will force a cdclk change, and to be safe we also force the PLL to be turned off and on again. If the sanitation step didn't notice anything amiss, we'll skip the cdclk programming which will prevent cdclk reprogramming when the displays might be active. We can also toss in a few WARNs about the register values into skl_update_dpll0() since we now know that the PLL state should always be sane when that function is called. Signed-off-by:
-
Ville Syrjälä authored
Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw out a few unneeded variables, and write the CDCLK_CTL check a bit more legible way. Signed-off-by:
-
Ville Syrjälä authored
Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need something that keeps track of which vco frequency we want to use in case the current vco is 0. This would be important across supend/resume since we'll disable DPLL0 around those parts. We'll also update our idea of max cdclk/dotclock when the preferred vco changes. That could happen if out initial guess was wrong, and later eDP would force us to change it. One issue here could be that changing the max dotclock could cause our mode list to change during next time the displays get probed. But I don't see a good way to avoid that, except perhaps by allowing either vco frequency to be used as needed. But the docs suggest that such usage wasn't really inteded. Also need to make sure we don't update our max_cdclk value before we have a preferred vco value, which means moving that to happen after the cdclk sanitation. Signed-off-by:
-
Ville Syrjälä authored
In case we originally guessed wrong which lcpll vco frequency to use, we will need to shut down the pll and restart it when reprogamming the cdclk. This also allows us to track the actual vco frequency in dev_priv instead of just a guess. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Currently we're trying to guess which lcpll vco frequency is used use based on the cdclk. That doesn't work for cdclk==540 since both vco frequencies can generate a 540 Mhz output. Let's stop guessing and just read the actual vco frequency from the hardware. Signed-off-by:
-
Ville Syrjälä authored
We have many places where we want to pick a suitable cdclk frequency for skl based on the dotclock and lcpll vco. Split that code into a small helper and call it from all over. Signed-off-by:
-
Ville Syrjälä authored
Shared plls won't get assigned until the .compute_clocks() hook gets called, which happens from the crtc .atomic_check hook. That's too late as the cdclk computation has already happened. So let's move the DPLL0 VCO computation into intel_dp_compute_config() so that it's done when the cdclk computation happens. Also only do it for eDP since we only pick DPLL0 for eDP. Signed-off-by:
-
