- 27 6月, 2015 3 次提交
-
-
由 Damien Lespiau 提交于
We can't improve a 0 deviation, so when we find such a divider, skip the remaining ones they won't be better. This short-circuit the search for 34 of the 373 test frequencies in the corresponding i-g-t test (tools/skl_compute_wrpll) v2: Place the short-circuiting code in skl_compute_wrpll() (Paulo) (I'm sure nobody will notice the spurious removal of a blank line) Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Suggested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Currently, if an odd divider improves the deviation (minimizes it), we take that divider. The recommendation is to prefer even dividers. v2: Move the check at the right place after having inverted the two for loops in the previous patch. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
The HW validation team came back from further testing with a slightly changed constraint on the deviation between the DCO frequency and the central frequency. Instead of +-4%, it's now +1%/-6%. Unfortunately, the previous algorithm didn't quite cope with these new constraints, the reason being that it wasn't thorough enough looking at the possible divider candidates. The new algorithm looks at all dividers, which is definitely a hammer approach (we could reduce further the set of dividers to good ones as a follow up, at the cost of a bit more complicated code). But, at least, we can now satisfy the +1%/+6% rule for all the "Well known" HDMI frequencies of my test set (373 entries). On that subject, the new code is quite extensively tested in intel-gpu-tools (tools/skl_compute_wrpll). v2: Fix cycling between central frequencies and dividers (Paulo) Properly choose the minimal deviation between postive and negative candidates (Paulo). On the 373 test frequencies, v2 computes better dividers than v1 (ie more even dividers and lower deviation on average): v1: average deviation: 206.52 v2: average deviation: 194.47 Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 6月, 2015 2 次提交
-
-
由 Imre Deak 提交于
According to bspec the DDI PHY vswing scale value is "don't care" in case the scale enable bit [27] is clear. But this doesn't seem to be correct. The scale value seems to also matter if the scale mode bit [26] is set. So both bit 26 and 27 depend on the value. Setting the scale value to 0 while either bit is set results in a failed modeset on HDMI (sink reports no signal). After reset the scale value is 0x98, but according to the spec we have to program it to 0x9a. So for consistency program it always to 0x9a regardless of the scale enable bit. Signed-off-by: NImre Deak <imre.deak@intel.com> Tested-by: NMatt Roper <matthew.d.roper@intel.com> Acked-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Damien Lespiau 提交于
intel_update_cdclk() will already display the boot CDCLK for DDI platforms, no need to repeat there. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 03 6月, 2015 1 次提交
-
-
由 Sonika Jindal 提交于
BXT supports following intermediate link rates for edp: 2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz. Adding support for programming the intermediate rates. v2: Adding clock in bxt_clk_div struct and then look for the entry with required rate (Ville) v3: 'clock' has the selected value, no need to use link_bw or rate_select for selecting pll(Ville) v4: Make bxt_dp_clk_val const and remove size (Ville) v5: Rebased v6: Removed setting of vco while rebasing in v5, adding it back Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Reviewed-by: NVandana Kannan <vandana.kannan@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 29 5月, 2015 11 次提交
-
-
由 Damien Lespiau 提交于
The orignal code started by storing the actual central frequency (in Hz, using a uint64_t) in a uint32_t which codes for the register value. That can't be right. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Those functions were the only one in existence when they were introduced. We now know they are only valid for HSW/BDW. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
abs_diff() properly protects its parameters, so no need for the outer () here. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
div_u64() can be either a inline function or a define, but in either case it's safe to provide expressions as parameters without outer () around them. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
This part doesn't depend on how we compute the DPLL dividers (p and p0/p1/p2) and can be reused even if we change the algorithm to do so. (something that is planned for a followup patch) Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
We can coalesce the WARN() condition with the WARN() itself and, as we are returning early, we can de-intent the rest of the function. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
At the moment, even if we fail to find a suitable divider, we'll still try to set the mode with bogus parameters. Just fail the modeset if we can't generate the frequency. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
This helps debugging. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Right now, when finishing the cycle with odd dividers without finding a suitable candidate, we end up in an infinite loop. Make sure to break in that case. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
The hotplug callbacks for DP and DDI effectively did nothing. Remove them. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
There are plenty of hotplug related fields in struct drm_i915_private scattered all around. Group them under one hotplug struct. Clean up naming while at it. No functional changes. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 5月, 2015 1 次提交
-
-
由 Damien Lespiau 提交于
We need to re-init the display hardware when going out of suspend. This includes: - Hooking the PCH to the reset logic - Restoring CDCDLK - Enabling the DDB power Among those, only the CDCDLK one is a bit tricky. There's some complexity in that: - DPLL0 (which is the source for CDCLK) has two VCOs, each with a set of supported frequencies. As eDP also uses DPLL0 for its link rate, once DPLL0 is on, we restrict the possible eDP link rates the chosen VCO. - CDCLK also limits the bandwidth available to push pixels. So, as a first step, this commit restore what the BIOS set, until I can do more testing. In case that's of interest for the reviewer, I've unit tested the function that derives the decimal frequency field: #include <stdio.h> #include <stdint.h> #include <assert.h> #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x))) static const struct dpll_freq { unsigned int freq; unsigned int decimal; } freqs[] = { { .freq = 308570, .decimal = 0b01001100111}, { .freq = 337500, .decimal = 0b01010100001}, { .freq = 432000, .decimal = 0b01101011110}, { .freq = 450000, .decimal = 0b01110000010}, { .freq = 540000, .decimal = 0b10000110110}, { .freq = 617140, .decimal = 0b10011010000}, { .freq = 675000, .decimal = 0b10101000100}, }; static void intbits(unsigned int v) { int i; for(i = 10; i >= 0; i--) putchar('0' + ((v >> i) & 1)); } static unsigned int freq_decimal(unsigned int freq /* in kHz */) { return (freq - 1000) / 500; } static void test_freq(const struct dpll_freq *entry) { unsigned int decimal = freq_decimal(entry->freq); printf("freq: %d, expected: ", entry->freq); intbits(entry->decimal); printf(", got: "); intbits(decimal); putchar('\n'); assert(decimal == entry->decimal); } int main(int argc, char **argv) { int i; for (i = 0; i < ARRAY_SIZE(freqs); i++) test_freq(&freqs[i]); return 0; } v2: - Rebase on top of -nightly - Use (freq - 1000) / 500 for the decimal frequency (Ville) - Fix setting the enable bit of HSW_NDE_RSTWRN_OPT (Ville) - Rename skl_display_{resume,suspend} to skl_{init,uninit}_cdclk to be consistent with the BXT code (Ville) - Store boot CDCLK in ddi_pll_init (Ville) - Merge dev_priv's skl_boot_cdclk into cdclk_freq - Use LCPLL_PLL_LOCK instead of (1 << 30) (Ville) - Replace various '0' by SKL_DPLL0 to be a bit more explicit that we're programming DPLL0 - Busy poll the PCU before doing the frequency change. It takes about 3/4 cycles, each separated by 10us, to get the ACK from the CPU (Ville) v3: - Restore dev_priv->skl_boot_cdclk, leaving unification with dev_priv->cdclk_freq for a later patch (Daniel, Ville) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 5月, 2015 3 次提交
-
-
由 Vandana Kannan 提交于
Making lane stagger calculation common for HDMI and DP v2: Imre's comments addressed - Remove lane stagger from bxt_clk_div and make it a local variable in ddi_pll_select Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
BUN 1: prop_coeff, int_coeff, tdctargetcnt programming updated and tied to VCO frequencies. Program i_lockthresh in PORT_PLL_9. VCO calculated based on the formula: Desired Output = Port bit rate in MHz (DisplayPort HBR2 is 5400 MHz) Fast Clock = Desired Output / 2 VCO = Fast Clock * P1 * P2 Prop_coeff, int_coeff, and tdctargetcnt modified according to above calculation. BUN 2: Port PLLs require additional programming at certain frequencies - DCO amplitude in PORT_PLL_10 Review comments from Siva which were addressed in the initial version of the patch. - Change PORT_PLL_LOCK_THRESHOLD to PORT_PLL_LOCK_THRESHOLD_MASK - Calculate for HDMI - Correct values for vco = 5.4 - return in case of invalid vco range v2: Imre's review comments addressed - change dcoampovr_en to dcoampovr_en_h - change PORT_PLL_DCO_AMP_OVR_EN to PORT_PLL_DCO_AMP_OVR_EN_H - Correct lane stagger value for 324MHz - Make coef common for HDMI and DP - remove superfluous comments v3: Imre's comments addressed - Remove Prop_coeff, int_coeff, tdctargetcnt, dcoampovr_en, gain_ctl, dcoampovr_en_h from bxt_clk_div and make them local variables. Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> [v1] Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
In the following commit, the place where the contents of dpll_hw_state in crtc_state where zeroed was changed. Prior to that commit, it happened when the new state was allocated, but now that happens just before the call the .crtc_compute_clock() hook. The DP code for SKL, however, sets up the (private) PLL in the encoder compute config function that has already run by the time that memset() is reached, causing the previous value to be lost. This patch fixes the issue by moving the memset() down the call chain, so that it is only called if the values in dpll_hw_state are going to be updated. commit 4978cc93 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:13:21 2015 +0300 drm/i915: Preserve shared DPLL information in new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reported-and-tested-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 5月, 2015 4 次提交
-
-
由 Damien Lespiau 提交于
A part of this function was indented with 2 tabs and 1 space instead of just 2 tabs. We're going to touch that code, so start by re-indenting it. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
Simplifies looping over connector states a bit. Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Sonika Jindal 提交于
This provides an option to override the value set by VBT for selecting edp Vswing Pre-emph setting table. v2: Adding comment about this being a temporary workaround and making the parameter read-only (Jani) v3: Changing mode to 0400 instead of 0 (Jani) https://bugs.freedesktop.org/show_bug.cgi?id=89554Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 4月, 2015 2 次提交
-
-
由 Imre Deak 提交于
At the moment intel_prepare_ddi buffer will iterate through both MST and CRT encoders, which is incorrect. Neither of these encoder types have an embedding intel_digital_port object, so for these encoder types we will use random data when dereferencing the corresponding intel_digital_port->port field. Introduced in commit b403745c Author: Damien Lespiau <damien.lespiau@intel.com> Date: Mon Aug 4 22:01:33 2014 +0100 drm/i915: Iterate through the initialized DDIs to prepare their buffers v2: - fix getting at the port for MST encoders too - make sure that intel_prepare_ddi_buffers() gets called for port E too (Paulo) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90067Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
In the next patch we'll need to get at both the encoder's intel_digital_port object - which maybe NULL for a CRT - and it's port, so factor out this functionality. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 16 4月, 2015 11 次提交
-
-
由 Vandana Kannan 提交于
VSwing programming sequence as specified in the updated BXT BSpec v2: Satheesh's review comments addressed. - clear value before setting into registers - move print statement to bxt function Other changes - since signal level will not be set into DDI_BUF_CTL, the value need not be returned to intel_dp_set_signal_levels(). Making the bxt specific function to return void and setting signal_levels = 0 for bxt inside intel_dp_set_signal_levels() - instead of signal levels, printing vswing level and pre-emphasis level - in case none of the pre-emphasis levels or vswing levels are set, setting default of 400mV + 0dB v3: Satheesh's review comments - Check for mask before printing signal_levels. - Removing redundant register writes - Call intel_prepare_ddi_buffers only for HAS_PCH_SPLIT - Making register write part generic as it will be required for HDMI as well. Re-structure the code to include an array for vswing related values, set signal levels v4: Satheesh's review comments - Rebase over latest renaming patches - use hsw_signal_levels for HAS_DDI Other changes - Modified vswing_sequence() func definition - Rebased on top of register macro definitions v5: Satheesh's review comments - Check ddi translation table size v6: Imre's review comments - removed comments in vswing sequence - added vswing, pre-emphasis prints in intel_dp_set_signal_levels - added comment explaining use of DP vswing values for eDP - initialize n_entries and ddi_transaltion table based on encoder type - create bxt_ddi_buf_trans structure and use decimal values - adding a flag in bxt buffer translation table to indicate def entry v7: (imre) - squash in Vandana's "VSwing register definition", "HDMI VSwing programming", "Re-enable vswing programming", "Fix vswing sequence" patches - use BXT_PORT_* regs directly instead of via a temp var - simplify BXT_PORT_* macro definitions - add code comment why we read lane while write group registers - fix readout of DP_TRAIN_PRE_EMPHASIS in debug message Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v6) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
We don't actually need to write the HDMI entry on DDIs that have no chance to be used as HDMI ports. While this patch shouldn't change the current behaviour, it makes further enabling work easier as we'll have an eDP table filling the full 10 entries. v2: Rely on the logic from intel_ddi_init() to figure out if the DDI port supports HDMI or not (Paulo). Suggested-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Not every DDIs is necessarily connected can be strapped off and, in the future, we'll have platforms with a different number of default DDI ports. So, let's only call intel_prepare_ddi_buffers() on DDI ports that are actually detected. We also use the opportunity to give a struct intel_digital_port to intel_prepare_ddi_buffers() as we'll need it in a following patch to query if the port supports HMDI or not. On my HSW machine this removes the initialization of a couple of (unused) DDIs. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
Add placeholder function for calculating programmed pixel clock. Note: Formula to back calculate link clock from dividers not available currently. v2: - rebased on upstream s/crtc_config/crtc_state/ change (imre) Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
Assign PLL for pipe (dependent on port attached to the pipe) v2: - fix incorrect encoder vs. new_encoder check for crtc (imre) v3: - warn and return error if no encoder is attached (imre) Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> [danvet: Don't move intel_ddi_get_crtc_new_encoder around.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
Calculate and cache clock parameters. Follow bspec algorithm for HDMI. Use precalculated values for DisplayPort linkrates. v2: (imre) - rebase against upstream crtc_state change - use the existing CHV based helper instead of handrolling the same Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
Plug bxt PLL code into existing shared DPLL framework. v2: (imre) - squash in Satheeshakrishna's "Define BXT clock registers" and "Add state variables for bxt clock registers" patches - squash in Vandanas's "Change grp access to lane access for PLL" - fix group vs. lane access in bxt_ddi_pll_get_hw_state - add code comment why we read from lane registers while writing to group registers - clean up register macros - use BXT_PORT_PLL_* macros instead of open-coding the same - check if BXT_PORT_PCS_DW12_LN01 matches BXT_PORT_PCS_DW12_LN23 during hardware state readout - add missing LANESTAGGER_STRAP_OVRD masking - add note about missing step according to the latest BUN for PORT_PLL_9/lockthresh Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
PORT_CLK_SEL programming is needed only on HSW/BDW. v2: - don't program PORT_CLK_SEL from mst encoders either (imre) v3: - fix the check for GEN9+ in intel_mst_pre_enable_dp() (damien) Signed-off-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Sonika Jindal 提交于
The HDMI translation table is added back to bspec, so adding it, and defaulting the 800mV+0dB entry. The HDMI translation table was removed by following commit as per HW team's recommendation: commit 7ff44670 ("drm/i915/skl: Only use the 800mV+2bB HDMI translation entry") v2: Adding reference to commit which removed this table (Jani) Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Add PHY specific display initialization sequence as per BSpec. Note that the PHY initialization/uninitialization are done at their current place only for simplicity, in a future patch - when more of the runtime PM features will be enabled - these will be moved to power well#1 and modeset encoder enabling/disabling hooks respectively. The call to uninitialize the PHY during system/runtime suspend will be added later in this patchset. v1: Added function definitions in header files v2: Imre's review comments addressed - Moved CDCLK related definitions to i915_reg.h - Removed defintions for CDCLK frequency - Split uninit_cdclk() by adding a phy_uninit function - Calculate freq and decimal based on input frequency - Program SSA precharge based on input frequency - Use wait_for 1ms instead 200us udelay for DE PLL locking - Removed initial value for divider, freq, decimal, ratio. - Replaced polling loops with wait_for - Parameterized latency optim setting - Fix the parts where DE PLL has to be disabled. - Call CDCLK selection from mode set v3: (imre) - add note about the plan to move the cdclk/phy init to a better place - take rps.hw_lock around pcode access - fix DDI PHY timeout value - squash in Vandana's "PORT_CL2CM_DW6_A BUN fix", "DDI PHY programming register defn", "Do ddi_phy_init always", - move PHY register macros next to the corresponding CHV/VLV macros - move DE PLL register macros here from another patch since they are used here first - add BXT_ prefix to CDCLK flags - s/COMMON_RESET/COMMON_RESET_DIS/ and clarify related code comments - fix incorrect read value for the RMW of BXT_PHY_CTL_FAMILY_DDI - fix using GT_DISPLAY_EDP_POWER_ON vs. GT_DISPLAY_DDI_POWER_ON when powering on DDI ports - fix incorrect port when setting BXT_PORT_TX_DW14_LN for DDI ports - add missing masking when programming CDCLK_FREQ_DECIMAL - add missing powering on for DDI-C port, rename OCL2_LDOFUSE_PWR_EN to OCL2_LDOFUSE_PWR_DIS to reduce confusion - add note about mismatch with bspec in the PORT_REF_DW6 fields - factor out PHY init code to a new function, so we can call it for PHY1 and PHY0, instead of open-coding the same v4: (ville) - split the CDCLK/PHY parts into two patches, update commit message accordingly - use the existing dpio_phy enum instead of adding a new one for the same purpose - flip the meaning of PHYs so that PHY_A is PHY1 and PHY_BC is PHY0 to better match CHV - s/BXT_PHY/_BXT_PHY/ - use _PIPE for _BXT_PHY instead of open-coding it - drop _0_2_0_GTTMMADR suffix from BXT_P_CR_GT_DISP_PWRON - define GT_DISPLAY_POWER_ON in a more standard way - make a note that the CHV ConfigDB also disagrees about GRC_CODE field definitions - fix lane optimization refactoring fumble from v3 - add per PHY uninit functions to match the init counterparts Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Add CDCLK specific display clock initialization sequence as per BSpec. Note that the CDCLK initialization/uninitialization are done at their current place only for simplicity, in a future patch - when more of the runtime PM features will be enabled - these will be moved to power well#1 and modeset encoder enabling/disabling hooks respectively. This also means that atm dynamic power gating power well #1 is effectively disabled. The call to uninitialize CDCLK during system/runtime suspend will be added later in this patchset. v1: Added function definitions in header files v2: Imre's review comments addressed - Moved CDCLK related definitions to i915_reg.h - Removed defintions for CDCLK frequency - Split uninit_cdclk() by adding a phy_uninit function - Calculate freq and decimal based on input frequency - Program SSA precharge based on input frequency - Use wait_for 1ms instead 200us udelay for DE PLL locking - Removed initial value for divider, freq, decimal, ratio. - Replaced polling loops with wait_for - Parameterized latency optim setting - Fix the parts where DE PLL has to be disabled. - Call CDCLK selection from mode set v3: (imre) - add note about the plan to move the cdclk/phy init to a better place - take rps.hw_lock around pcode access - move DE PLL register macros here from another patch since they are used here first - add BXT_ prefix to CDCLK flags - add missing masking when programming CDCLK_FREQ_DECIMAL v4: (ville) - split the CDCLK/PHY parts into two patches, update commit message accordingly - s/DISPLAY_PCU_CONTROL/HSW_PCODE_DE_WRITE_FREQ_REQ/ - simplify BXT_DE_PLL_RATIO macros - fix BXT_DE_PLL_RATIO_MASK - s/bxt_select_cdclk_freq/broxton_set_cdclk_freq/ - move cdclk init/uninit/set code from intel_ddi.c to intel_display.c - remove redundant code comments for broxton_set_cdclk_freq() - sanitize fixed point<->integer frequency value conversion - use DRM_ERROR instead of WARN - do RMW when programming BXT_DE_PLL_CTL for safety - add note about PLL lock timeout being exactly 200us - make PCU error messages more descriptive - instead of using 0 freq to mean PLL off/bypass freq use 19200 for clarity, as the latter one is the actual rate - simplify pcode programming, removing duplicated sandybridge_pcode_write() call - sanitize code flow, remove unnecessary scratch vars in broxton_set_cdclk() (imre) - Remove bound check for maxmimum freq to match current code. This check will be added later at a more proper platform independent place once atomic support lands. - add note to remove freq guard band which isn't needed on BXT - add note to reduce freq to minimum if no pipe is enabled - combine broxton_modeset_global_pipes() with valleyview_modeset_global_pipes() Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 13 4月, 2015 2 次提交
-
-
Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. Broken by commit 944b0c76 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri Mar 20 16:18:07 2015 +0200 drm/i915: Copy the staged connector config to the legacy atomic state v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: NNicolas Kalkhof <nkalkhof@web.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: NNicolas Kalkhof <nkalkhof@web.de> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-