- 19 5月, 2020 1 次提交
-
-
由 Ville Syrjälä 提交于
Looks like elk redefines some of the CLKCFG FSB values to make room for 400 MHz FSB. The setting overlaps with one of the 266MHz settings (which is even documented in the ctg docs, and cofirmed to be correct on my ctg). So we limit the special case to elk only. Though it might also be that we have some kind of desktop vs. mobile difference going on here as eg. both g35 and elk use 0x0 for the 266 MHz setting, vs. 0x6 used by ctg). The g35 doesn't let me select 400MHz for the FSB strap so can't confirm which way it would go here. But anyways as it seems only elk has the 400MHz option we shouldn't lose anything by limiting the special case to it alone. My earlier experiments on this appear to have been nonsense as the comment I added claims that FSB strap of 400MHz results in a value of 0x4, but I've now retested it and I definitely get a value of 0x6 instead. So let's remove that bogus comment. v2: s/_ELK/_ALT/ in the define in anticipation of a full mobile vs. desktop CLKCFG split Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200514123838.3017-1-ville.syrjala@linux.intel.comAcked-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 10 3月, 2020 1 次提交
-
-
由 Ville Syrjälä 提交于
gmbus/aux may be clocked by cdclk, thus we should make sure no transfers are ongoing while the cdclk frequency is being changed. We do that by simply grabbing all the gmbus/aux mutexes. No one else should be holding any more than one of those at a time so the lock ordering here shouldn't matter. v2: Use mutex_lock_nest_lock() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302174442.5803-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 23 2月, 2020 1 次提交
-
-
由 Pankaj Bharadiya 提交于
drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-2-pankaj.laxminarayan.bharadiya@intel.com
-
- 19 2月, 2020 1 次提交
-
-
由 Chris Wilson 提交于
Read the rawclk_freq during runtime info probing, prior to its first use in computing the CS timestamp frequency. Then store it in the runtime info, and include it in the debug printouts. Closes: https://gitlab.freedesktop.org/drm/intel/issues/834Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk
-
- 12 2月, 2020 1 次提交
-
-
由 Ville Syrjälä 提交于
s/before/after/ again after accidentally changing it the other way in commit 5604e9ce ("drm/i915: Simplify intel_set_cdclk_{pre,post}_plane_update() calling convention") Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204154803.25403-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 11 2月, 2020 1 次提交
-
-
由 Matt Roper 提交于
A recent bspec update added an extra voltage level that we didn't have on ICL and new criteria for selecting the level. Bspec: 49208 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200207001417.1229251-2-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 31 1月, 2020 11 次提交
-
-
由 Ville Syrjälä 提交于
Let's add a copy of the active_pipes bitmask into the cdclk_state. While this is duplicating a bit of information we may already have elsewhere, I think it's worth it to decopule the cdclk stuff from whatever else wants to use that bitmask. Also we want to get rid of all the old ad-hoc global state which is what the current bitmask is, so this removes one obstacle. The one extra thing we have to remember is write locking the cdclk state whenever the bitmask changes. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-19-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
Let's convert cdclk_state to be a proper global state. That allows us to use the regular atomic old vs. new state accessor, hopefully making the code less confusing. We do have to deal with a few more error cases in case the cdclk state duplication fails. But so be it. v2: Fix new plane min_cdclk vs. old crtc min_cdclk check Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
Our current global state handling is pretty ad-hoc. Let's try to make it better by imitating the standard drm core private object approach. The reason why we don't want to directly use the private objects is locking; Each private object has its own lock so if we introduce any global private objects we get serialized by that single lock across all pipes. The global state apporoach instead uses a read/write lock type of approach where each individual crtc lock counts as a read lock, and grabbing all the crtc locks allows one write access. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-15-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
Give the cdclk init/uninit functions a _hw suffix to make it clear they are about initializing the actual hardware. I'll be wanting to to add a intel_cdclk_init() which is purely initializing software structures. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-12-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
To make life less confusing let's swap() the entire cdclk state rather than swapping some parts, copying other parts, and leaving the rest just as is. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-11-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
Use the same structure to store the cdclk state in both intel_atomic_state and dev_priv. First step towards proper old vs. new cdclk states. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Move all the old vs. new state shenanigans into intel_set_cdclk_{pre,post}_plane_update() so that the caller doesn't need to know any of it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-9-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
I want to have a higher level cdclk state object so let's rename the current lower level thing to cdclk_config (because I lack imagination). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-8-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
intel_cdclk_needs_cd2x_update() is named rather confusingly. We don't have to do a cd2x update, rather we are allowed to do one (as opposed to a full PLL reprogramming with its heavy handed modeset). So let's rename the function to intel_cdclk_can_cd2x_update(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
-
由 Ville Syrjälä 提交于
Move the min_cdclk[] and min_voltage_level[] arrays under the rest of the cdclk state. And while at it provide a simple helper (intel_cdclk_clear_state()) to clear the state during the ww_mutex backoff dance. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
由 Ville Syrjälä 提交于
Move the initial setup of state->{cdclk,min_cdclk[],min_voltage_level[]} into intel_modeset_calc_cdclk(), and we'll move the counterparts into intel_cdclk_swap_state(). This encapsulates the cdclk state much better. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 27 1月, 2020 1 次提交
-
-
由 Jani Nikula 提交于
The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/762b11289d22e1db46697c5b4596e49defc8190f.1579871655.git.jani.nikula@intel.com
-
- 23 1月, 2020 1 次提交
-
-
由 Wambui Karuga 提交于
Converts instances of the printk based debugging macros with the new struct drm_device based logging macros in i915/display/intel_cdclk.c. The conversion is achieved using the following coccinelle script that transforms based on the existence of a struct drm_i915_private device in the function: @rule1@ identifier fn, T; @@ fn(struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) ) ...+> } @rule2@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) ) ...+> } Resulting checkpatch warnings were fixed manually. Signed-off-by: NWambui Karuga <wambui.karugax@gmail.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121134559.17355-6-wambui.karugax@gmail.com
-
- 13 1月, 2020 1 次提交
-
-
由 Stanislav Lisovskiy 提交于
There seems to be some undocumented bandwidth bottleneck/dependency which scales with CDCLK, causing FIFO underruns when CDCLK is too low, even when it's correct from BSpec point of view. Currently for TGL platforms we calculate min_cdclk initially based on pixel_rate divided by 2, accounting for also plane requirements, however in some cases the lowest possible CDCLK doesn't work and causing the underruns. We've found experimentally that raising cdclk to at least pixel_rate (rather than pixel_rate/2) eliminates these underruns, so let's use this as a temporary workaround until the hardware team can suggest a more precise remedy. Explicitly stating here that this seems to be currently rather a Hack, than final solution. v2: Use clamp operation instead of min(Matt Roper) v3: - Fixed commit message(Matt Roper) - Now using pixel_rate instead of max_cdclk(Jani Nikula) - Switched to max from clamp(Ville Syrjälä) Hopefully this hybrid satisfies everyone :) Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/402Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109220547.23817-1-stanislav.lisovskiy@intel.com
-
- 25 11月, 2019 1 次提交
-
-
由 Matt Roper 提交于
The bspec was recently updated with new cdclk -> voltage level tables to accommodate the new 324/326.4 cdclk values. Bspec: 21809 Fixes: 63c9dae7 ("drm/i915/ehl: Add voltage level requirement table") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> (cherry picked from commit d1474838) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 19 11月, 2019 1 次提交
-
-
由 Matt Roper 提交于
The bspec was recently updated with new cdclk -> voltage level tables to accommodate the new 324/326.4 cdclk values. Bspec: 21809 Fixes: 63c9dae7 ("drm/i915/ehl: Add voltage level requirement table") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
-
- 01 11月, 2019 2 次提交
-
-
由 Maarten Lankhorst 提交于
Split up crtc_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_crtc_state *T; @@ -T->base +T->uapi Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-5-maarten.lankhorst@linux.intel.com
-
由 Maarten Lankhorst 提交于
Split up crtc_state->base to hw where appropriate. This is done using the following patch: @@ struct intel_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -T->base.x +T->hw.x @@ struct drm_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -to_intel_crtc_state(T)->base.x +to_intel_crtc_state(T)->hw.x Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-4-maarten.lankhorst@linux.intel.com
-
- 25 10月, 2019 3 次提交
-
-
由 Ville Syrjälä 提交于
Various pixel formats and plane scaling impose additional constraints on the cdclk frequency. Provide a new plane->min_cdclk() hook that will be used to compute the minimum acceptable cdclk frequency for each plane. Annoyingly on some platforms the numer of active planes affects this calculation so we must also toss in more planes into the state when the number of active planes changes. The sequence of state computation must also be changed: 1. check_plane() (updates plane's visibility etc.) 2. figure out if more planes now require update min_cdclk computaion 3. calculate the new min cdclk for each plane in the state 4. if the minimum of any plane now exceeds the current logical cdclk we recompute the cdclk 4. during cdclk computation take the planes' min_cdclk into accoutn 5. follow the normal cdclk programming to change the cdclk frequency. This may now require a modeset (except on bxt/glk in some cases), which either succeeds or fails depending on whether userspace has given us permission to perform a modeset or not. v2: Fix plane id check in intel_crtc_add_planes_to_state() Only print the debug message when cdclk needs bumping Use dev_priv->cdclk... as the old state explicitly Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-5-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
So far we've sort of protected the global state under dev_priv with the connection_mutex. I wan to change that so that we can change the cdclk even for pure plane updates. To that end let's formalize the protection of the global state to follow what I started with the cdclk code already (though not entirely properly) such that any crtc mutex will suffice as a read lock, and all crtcs mutexes act as the write lock. We'll also pimp intel_atomic_state_clear() to clear the entire global state, so that we don't accidentally leak stale information between the locking retries. As a slight optimization we'll only lock the crtc mutexes to protect the global state, however if and when we actually have to poke the hw (eg. if the actual cdclk changes) we must serialize commits across all crtcs so that a parallel nonblocking commit can't get ahead of the cdclk reprogamming. We do that by adding all crtcs to the state. TODO: the old global state examined during commit may still be a problem since it always looks at the _latest_ swapped state in dev_priv. Need to add proper old/new state for that too I think. v2: Remeber to serialize the commits if necessary Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
由 Ville Syrjälä 提交于
To make the logs a bit less confusing let's toss in some debug prints to indicate whether the cdclk reprogramming is going to happen with a single pipe active or whether we need to turn all pipes off for the duration. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-2-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
- 15 10月, 2019 1 次提交
-
-
由 Ville Syrjälä 提交于
While not all platforms allow us to change the cdclk frequency we should still verify that the fixed cdclk frequency isn't too low. To that end let's cook up a .modeset_calc_cdclk() implementation that only does the min_cdclk vs. actual cdclk frequency check for such platforms. Also we mustn't forget about double wide pipe on gen2/3 when doing this. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708125325.16576-11-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 16 9月, 2019 1 次提交
-
-
由 Ville Syrjälä 提交于
Exfiltrate the cdclk code from intel_modeset_checks() into intel_modeset_calc_cdclk(). Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913193157.9556-4-ville.syrjala@linux.intel.com
-
- 12 9月, 2019 4 次提交
-
-
由 Ville Syrjälä 提交于
Reuse the same .modeset_calc_cdclk() function for all bxt+. The only difference in between the cnl/icl and the bxt variants is the call to cnl_compute_min_voltage_level(). We can do that call just fine on older platforms since they leave min_voltage_level[] zeroed. Let's rename the function to bxt_compute_min_voltage_level() just so it stays consistent with the rest of the naming scheme. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190911133129.27466-4-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
The cnl and icl .modeset_calc_cdclk() functions are identical. Drop one copy. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190911133129.27466-3-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
We're forgetting to mask off all three pipe select bits from the CDCLK_CTL value on icl+ which may lead to the extra bit being left in. That will cause us to consider the current hardware cdclk state as invalid, and we proceed to sanitize it even though the hardware may have active pipes and whatnot. Fix up the mask so we get rid of all three pipe select bits and thus hopefully no longer sanitize cdclk when it's already correctly programmed. Cc: Matt Roper <matthew.d.roper@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111641 Fixes: 0c1279b5 ("drm/i915: Consolidate {bxt,cnl,icl}_init_cdclk") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190911133129.27466-2-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
On tgl/bxt/glk the cdclk bypass frequency depends on the PLL reference clock. So let's read out the ref clock before we try to compute the bypass clock. Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 71dc367e ("drm/i915: Consolidate bxt/cnl/icl cdclk readout") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190911133129.27466-1-ville.syrjala@linux.intel.com
-
- 11 9月, 2019 7 次提交
-
-
由 Chris Wilson 提交于
Commit 736da811 ("drm/i915: Use literal representation of cdclk tables") pushed the cdclk logic into tables, adding glk_cdclk_table but not using yet: drivers/gpu/drm/i915/display/intel_cdclk.c:1173:38: error: ‘glk_cdclk_table’ defined but not used [-Werror=unused-const-variable=] Fixes: 736da811 ("drm/i915: Use literal representation of cdclk tables") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911074727.32585-1-chris@chris-wilson.co.uk
-
由 Matt Roper 提交于
The BXT and CNL functions were already basically identical, whereas ICL's function tried to do its own sanitization rather than calling bxt_sanitize_cdclk. This should actually fix a bug in our ICL initialization where it would consider the /2 CD2X divider invalid and force an unnecessary sanitization (we now have valid clock frequencies that use this divider). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-9-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
When reading out the BIOS-programmed cdclk state, let's make sure that the cdclk value is on the valid list for the platform, ensure that the VCO matches the cdclk, and ensure that the CD2X divider was set properly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-8-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
With all of the cdclk function consolidation, we can cut down on a lot of platform if/else logic by creating a vfunc that's initialized at startup. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-7-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
The uninitialize flow is the same on all of these platforms, aside from calculating a different frequency level. v2: Reverse platform conditional order for consistency. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-6-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
The CNL variant of this function is identical to the BXT variant aside from not needing to handle SSA precharge. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-5-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
We'd previously combined ICL/TGL logic into the cnl_set_cdclk function, but BXT is pretty similar as well. Roll the cnl/icl/tgl logic back into the bxt function; the only things we really need to handle separately are punit notification and calling different functions to enable/disable the cdclk PLL. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190910154252.30503-4-matthew.d.roper@intel.com
-