summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_cdclk.c
AgeCommit message (Collapse)AuthorFilesLines
2017-07-03drm/i915: reintroduce VLV/CHV PFI programming power domain workaroundGabriel Krisman Bertazi1-0/+20
There are still cases on these platforms where an attempt is made to configure the CDCLK while the power domain is off, like when coming back from a suspend. So the workaround below is still needed. This effectively reverts commit 63ff30442519 ("drm/i915: Nuke the VLV/CHV PFI programming power domain workaround"). Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 886015a0ad43c7fc034b23ea4614ba39162f9ddd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-06-12drm/i915/cnl: Allow dynamic cdclk changes on CNLRodrigo Vivi1-4/+56
All the low level cdclk bits are present, so let's add the required hooks to reconfigure cdclk on the fly. Cannonlake also needs to adjust the minimal pixel rate as gen9 platforms. Specially for the Azalia audio case. v2: Rebase due to cnl_sanitize_cdclk() v3: Rebased by Rodrigo on top of Ville's cdclk rework. v4: Rebase moving cnl_calc_cdclk up to follow same order as previous platforms. v2: Squash drm/i915/cnl: Adjust min pixel rate. to address the current limitation where CDCLK cannot be set to 168MHz if audio is used with 96MHz. (Imre) v3: adjust some of the clock limits within bdw_adjust_min_pipe_pixel_rate. (Ville/DK/Imre). Fix commit message messed by squash. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Sanyog Kale <sanyog.r.kale@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-4-git-send-email-rodrigo.vivi@intel.com
2017-06-12drm/i915/cnl: Implement CNL display init/unit sequenceVille Syrjälä1-1/+107
Implement the CNL display init/uninit sequence as outlined in Bspec. Quite similar to SKL/BXT. The main complicaiton is probably the extra procmon setup we must do based on the process/voltage information we can read out from some register. v2: s/skl_dbuf/gen9_dbuf/ to follow upstream bxt needed a cdclk sanitize step, so let's add it for cnl too v3: s/CHICKEN_MISC_1/CHICKEN_MISC_2/ (Ander) v4: Rebased by Rodrigo after Ville's cdclk rework v5: Removed unecessary Aux IO forced enable/disable, Fix DW10 setup Fix procpon Mask. (Credits-to Paulo and Clint) Remove A0 workaround. v6: Rebased on top of recent code (Rodrigo). v7: Respect the order of sanitize_ after set_ (Done by Rodrigo, Requested by Ville) v8: Commit message updated to matvh v5 changes besides Remove unused DW8 and an extra blank line. (all noticed by Imre). v9: Remove __attribute__((unused)) added on latest version of drm/i915/cnl: Implement .set_cdclk() for CNL. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-3-git-send-email-rodrigo.vivi@intel.com
2017-06-12drm/i915/cnl: Implement .set_cdclk() for CNLVille Syrjälä1-0/+106
Add support for changing the cdclk frequency on CNL. Again, quite similar to BXT, but there are some annoying differences which means trying to share more code might not be feasible: * PLL ratio now lives in the PLL enable register * pcode came from SKL, not from BXT We support three cdclk frequencies: 168,336,528 Mhz. The first two use the same PLL frequency, the last one uses a different one meaning we once again may need to toggle the PLL off and on when changing cdclk. v2: Rebased by Rodrigo on top of Ville's cdclk rework. v3: Respect order of set_ bellow get_ (Ville) v4: Added __attribute__((unused)) to avoid broken compilation with Werror. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-2-git-send-email-rodrigo.vivi@intel.com
2017-06-12drm/i915/cnl: Implement .get_display_clock_speed() for CNLVille Syrjälä1-1/+55
Add support for reading out the cdclk frequency from the hardware on CNL. Very similar to BXT, with a few new twists and turns: * the PLL is now called CDCLK PLL, not DE PLL * reference clock can be 24 MHz in addition to the 19.2 MHz BXT had * the ratio now lives in the PLL enable register * Only 1x and 2x CD2X dividers are supported v2: Deal with PLL lock bit the same way as BXT/SKL do now v3: DSSM refclk indicator is bit 31 not 24 (Ander) v4: Rebased by Rodrigo after Ville's cdclk rework. v5: Set cdclk to the ref clock as previous platforms. (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-1-git-send-email-rodrigo.vivi@intel.com
2017-06-02drm/i915/cnp: Get/set proper Raw clock frequency on CNP.Rodrigo Vivi1-1/+28
RAWCLK_FREQ register has changed for platforms with CNP+. [29:26] This field provides the denominator for the fractional part of the microsecond counter divider. The numerator is fixed at 1. Program this field to the denominator of the fractional portion of reference frequency minus one. If the fraction is 0, program to 0. 0100b = Fraction .2 MHz = Fraction 1/5. 0000b = Fraction .0 MHz. [25:16] This field provides the integer part of the microsecond counter divider. Program this field to the integer portion of the reference frequenct minus one. Also this register tells us that proper raw clock should be read from SFUSE_STRAP and programmed to this register. Up to this point on other platforms we are reading instead of programming it so probably relying on whatever BIOS had configured here. Now on let's follow the spec and also program this register fetching the right value from SFUSE_STRAP as Spec tells us to do. v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of reading the value relying someone else will program that for us. v3: Add missing else. (Jani) v4: Addressing all Ville's catches: Use macro for shift bits instead of defining shift. Remove shift from the cleaning bits with mask that already has it. Add missing I915_WRITE to actually write the reg. Stop using useless DIV_ROUND_* on divider that is exact dividion and use DIV_ROUND_CLOSEST for the fraction part. v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville). v6: Change is per PCH instead of per platform. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1496434004-29812-3-git-send-email-rodrigo.vivi@intel.com
2017-05-05drm/i915: Fix rawclk readout for g4xVille Syrjälä1-4/+2
Turns out our skills in decoding the CLKCFG register weren't good enough. On this particular elk the answer we got was 400 MHz when in reality the clock was running at 266 MHz, which then caused us to program a bogus AUX clock divider that caused all AUX communication to fail. Sadly the docs are now in bit heaven, so the fix will have to be based on empirical evidence. Using another elk machine I was able to frob the FSB frequency from the BIOS and see how it affects the CLKCFG register. The machine seesm to use a frequency of 266 MHz by default, and fortunately it still boot even with the 50% CPU overclock that we get when we bump the FSB up to 400 MHz. It turns out the actual FSB frequency and the register have no real link whatsoever. The register value is based on some straps or something, but fortunately those too can be configured from the BIOS on this board, although it doesn't seem to respect the settings 100%. In the end I was able to derive the following relationship: BIOS FSB / strap | CLKCFG ------------------------- 200 | 0x2 266 | 0x0 333 | 0x4 400 | 0x4 So only the 200 and 400 MHz cases actually match how we're currently decoding that register. But as the comment next to some of the defines says, we have been just guessing anyway. So let's fix things up so that at least the 266 MHz case will work correctly as that is actually the setting used by both the buggy machine and my test machine. The fact that 333 and 400 MHz BIOS settings result in the same register value is a little disappointing, as that means we can't tell them apart. However, according to the gmch datasheet for both elk and ctg 400 Mhz is not even a supported FSB frequency, so I'm going to make the assumption that we should decode it as 333 MHz instead. Cc: stable@vger.kernel.org Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100926 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170504181530.6908-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
2017-04-06drm/i915/glk: limit pixel clock to 99% of cdclk workaroundMadhav Chauhan1-3/+13
As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. Practically we can achive only 99% of these cdclk values (HW team checking on this). So cdclk should be calculated for the given pixclk as per that otherwise it may lead to screen corruption, explained below: 1. For DSI AUO panel(1920x1200 @60) required pixclk is 157100 KHZ 2. glk_calc_cdclk returns 79200 KHZ for this pixclk, For 2PPC it will be 158400 KHZ 3. Practically 100% of the cdclk can’t be achieved, so 99% of 158400 KHZ = 156816 which is less than the desired pixlclk and causes panel corruption. v2: Rebased to new CDLCK code framework v3: Addressed review comments from Ander/Jani - Add comment in code about 99% usage of CDCLK - Calculate max dot clock as well with 99% limit v4 by Jani: - drop superfluous whitespace change - rewrite code comments to clarify v5: Added details of non-working scenario in commit message Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491397463-13637-1-git-send-email-madhav.chauhan@intel.com
2017-03-22drm/i915: Implement cdclk restrictions based on Azalia BCLKPandiyan, Dhinakaran1-0/+12
According to BSpec, "The CD clock frequency must be at least twice the frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by default. This check is needed because BXT and GLK support cdclk frequencies less than 192 MHz. v2: Include other Gen9 platforms too for completeness.(Paulo) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489531556-2926-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-22drm/i915/glk: Apply cdclk workaround for DP audioPandiyan, Dhinakaran1-6/+11
Implement the DP-Audio cdclk restriction for GLK, similar to what is implemented for BDW and other GEN9 platforms. The max. pixel clock adjustment for GLK, however factors in the 2 pixels per clock output that GLK generates. Separating min. cdclk and max. pixel_rate would be nicer, but let's defer that to future and fix the GLK bug for now. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1488931972-2865-1-git-send-email-dhinakaran.pandiyan@intel.com
2017-03-13drm/i915: Use new atomic iterator macros in cdclkMaarten Lankhorst1-1/+1
Calculating the max pixel rate requires the new state, so use it there. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489071125-917-6-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-03-07drm/i915: remove potentially confusing IS_G4X checksPaulo Zanoni1-2/+2
The IS_G4X macro is defined as IS_G45 || IS_GM45. We have two points in our code where we have an if statement checking for GM45 followed by an else if statement checking for IS_G4X. This can be confusing since the IS_G4X check won't be catching the previously-checked GM45. Someone quickly trying to check which functions run on each platform may end up getting confused while reading the code. Fix the potential confusion by limiting the else if statements to only check for the platform that was not already checked earlier in the if ladder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1487620842-22893-3-git-send-email-paulo.r.zanoni@intel.com
2017-02-08drm/i915: Replace the .modeset_commit_cdclk() hook with a more direct ↵Ville Syrjälä1-46/+33
.set_cdclk() hook With the cdclk state, all the .modeset_commit_cdclk() hooks are now pointless wrappers. Let's replace them with just a .set_cdclk() function pointer. However let's wrap that in a small helper that does the state comparison and prints a unified debug message across all platforms. We didn't even have the debug print on all platforms previously. This reduces the clutter in intel_atomic_commit_tail() a little bit. v2: Wrap .set_cdclk() in intel_set_cdclk() v3: Add kernel-docs v4: Deal with IS_GEN9_BC() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170126195201.32638-1-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Nuke the VLV/CHV PFI programming power domain workaroundVille Syrjälä1-14/+0
The hack to grab the pipe A power domain around VLV/CHV cdclk programming has surely outlived its usefulness. We should be holding sufficient power domains during any modeset, so let's just nuke this hack. v2: Fix typo in commit message (Ander) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-13-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Move PFI credit reprogramming into vlv/chv_set_cdclk()Ville Syrjälä1-1/+4
Move the vlv_program_pfi_credits() into vlv_set_cdclk() and chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk(). v2: Do the PFI programming after cdclk readout since it currently depends on the readout to fill dev_priv->cdclk.hw Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170126195719.309-1-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Pass the cdclk state to the set_cdclk() functionsVille Syrjälä1-30/+48
Rather than passing all the different parameters (cdclk,vco so far) sparately to the set_cdclk() functions, just pass the entire cdclk state. v2: Deal with churn v3: Drop the usless .ref assignment (Ander) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-11-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Pass dev_priv to remainder of the cdclk functionsVille Syrjälä1-15/+10
Clean up the dev vs. dev_priv straggles that are making things look inconsistentt. v2: Deal with churn Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-10-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Track full cdclk state for the logical and actual cdclk frequenciesVille Syrjälä1-45/+78
The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess. So here I'm introducing the "actual" and "logical" naming for our cdclk state. "actual" is what we'll bash into the hardware and "logical" is what everyone should use for state computaion/checking and whatnot. We'll track both using the intel_cdclk_state as both will need other differing parameters than just the actual cdclk frequency. While doing that we can at the same time unify the appearance of the .modeset_calc_cdclk() implementations a little bit. v2: Commit dev_priv->cdclk.actual since that already has the new state by the time .modeset_commit_cdclk() is called. v3: s/locical/logical/ and improve the docs a bit Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-9-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Start moving the cdclk stuff into a distinct state structureVille Syrjälä1-156/+226
Introduce intel_cdclk state which for now will track the cdclk frequency, the vco frequency and the reference frequency (not sure we want the last one, but I put it there anyway). We'll also make the .get_cdclk() function fill out this state structure rather than just returning the current cdclk frequency. One immediate benefit is that calling .get_cdclk() will no longer clobber state stored under dev_priv unless ex[plicitly told to do so. Previously it clobbered the vco and reference clocks stored there on some platforms. We'll expand the use of this structure to actually precomputing the state and whatnot later. v2: Constify intel_cdclk_state_compare() v3: Document intel_cdclk_state_compare() v4: Deal with i945gm_get_cdclk() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207183345.19763-1-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Pass computed vco to bxt_set_cdclk()Ville Syrjälä1-14/+19
Rather than compute the vco inside bxt_set_cdclk() let's precompute it outside and pass it in. A small step towards a fully precomputed cdclk state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-7-ville.syrjala@linux.intel.com
2017-02-08drm/i915: Move most cdclk/rawclk related code to intel_cdclk.cVille Syrjälä1-0/+1794
Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk stuff to a new file. It's all reasonably self contained so we don't even have to add that many non-static symbols. We'll also take the opportunity to shuffle around the functions a bit to get things in a more consistent order based on the platform. v2: Add kernel-docs (Ander) v3: Deal with IS_GEN9_BC() v4: Deal with i945gm_get_cdclk() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207183305.19656-1-ville.syrjala@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 06:33:33 +0000