- 20 3月, 2018 1 次提交
-
-
由 Dhinakaran Pandiyan 提交于
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reported-by: NLaura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: 5ea2355a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by: NLaura Abbott <labbott@redhat.com> Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com (cherry picked from commit ad260ab3) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 19 12月, 2017 3 次提交
-
-
由 Rodrigo Vivi 提交于
In case we have multiple modesets for different connectors happening in parallel we could have a race on the RMW on these shared registers. This possibility was initially raised by Paulo when reviewing commit '555e38d2 ("drm/i915/cnl: DDI - PLL mapping")' but the original possibility comes from commit '5416d871 ("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe later when atomic commits entered into picture. Apparently the discussion around this topic showed that the right solution would be on serializing the atomic commits in a way that we don't have the possibility of races here since if that parallel modeset happenings apparently many other things will be on fire. Code is there since SKL and there was no report of issue, but since we never looked back to that serialization possibility, and also we don't have an igt case for that it is better to at least protect this corner. Suggested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Fixes: 5416d871 ("drm/i915/skl: Set the eDP link rate on DPLL0") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20171215224310.19103-1-rodrigo.vivi@intel.com (cherry picked from commit 8edcda12) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
drivers/gpu/drm/i915/intel_ddi.c:2098 intel_ddi_clk_select() warn: inconsistent indenting References: 8edcda12 ("drm/i915: Protect DDI port to DPLL map from theoretical race.") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171219112649.9388-1-chris@chris-wilson.co.uk
-
由 Rodrigo Vivi 提交于
In case we have multiple modesets for different connectors happening in parallel we could have a race on the RMW on these shared registers. This possibility was initially raised by Paulo when reviewing commit '555e38d2 ("drm/i915/cnl: DDI - PLL mapping")' but the original possibility comes from commit '5416d871 ("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe later when atomic commits entered into picture. Apparently the discussion around this topic showed that the right solution would be on serializing the atomic commits in a way that we don't have the possibility of races here since if that parallel modeset happenings apparently many other things will be on fire. Code is there since SKL and there was no report of issue, but since we never looked back to that serialization possibility, and also we don't have an igt case for that it is better to at least protect this corner. Suggested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Fixes: 5416d871 ("drm/i915/skl: Set the eDP link rate on DPLL0") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20171215224310.19103-1-rodrigo.vivi@intel.com
-
- 05 12月, 2017 1 次提交
-
-
由 James Ausmus 提交于
Without masking out the old value, we can end up pointing the DDI to a disabled PLL, which makes the system fall over. Mask out the previous value before setting the PLL to DDI mapping. This can be observed by running igt/testdisplay with both an eDP and HDMI/DP output active. v2: Add the Bugzilla link Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Testcase: igt/testdisplay Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103997 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: NJames Ausmus <james.ausmus@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201021700.13504-1-james.ausmus@intel.com (cherry picked from commit 23a7068e) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 02 12月, 2017 1 次提交
-
-
由 James Ausmus 提交于
Without masking out the old value, we can end up pointing the DDI to a disabled PLL, which makes the system fall over. Mask out the previous value before setting the PLL to DDI mapping. This can be observed by running igt/testdisplay with both an eDP and HDMI/DP output active. v2: Add the Bugzilla link Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Testcase: igt/testdisplay Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103997 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: NJames Ausmus <james.ausmus@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171201021700.13504-1-james.ausmus@intel.com
-
- 01 12月, 2017 1 次提交
-
-
由 Ville Syrjälä 提交于
Transcoder EDP does not support audio. Let's not try to read the state of the audio enable bit HSW_AUD_PIN_ELD_CP_VLD based on the pipe when using transcoder EDP. While at it make the function static and flatten it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171129164303.18793-3-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
- 14 11月, 2017 1 次提交
-
-
由 Mika Kahola 提交于
To make looping through transcoders in intel_ddi.c more generic, let's switch to use 'for_each_pipe()' macro to do this. v2: Add a notion that we are dealing with transcoders instead of pipes (Jani) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1510216670-16848-1-git-send-email-mika.kahola@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
- 10 11月, 2017 1 次提交
-
-
由 Ville Syrjälä 提交于
Remove intel_digital_port->port and replace its users with intel_encoder->port. intel_encoder->port is a superset of intel_digital_port->port, and it works correctly even for MST encoders. v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK) Performed with cocci: @@ @@ struct intel_digital_port { ... - enum port port; ... } @@ struct intel_digital_port *D; expression E; @@ - D->port = E; @@ struct intel_digital_port *D; @@ - D->port + D->base.port @ expression E; @@ ( - dp_to_dig_port(E)->port + dp_to_dig_port(E)->base.port | - enc_to_dig_port(E)->port + to_intel_encoder(E)->port ) @@ expression E; @@ - to_intel_encoder(&E->base) + E @@ struct intel_digital_port *D; identifier I, M; @@ I = &D->base <... ( - D->base.M + I->M | - &D->base + I ) ...> @@ identifier D; expression E; identifier M; @@ D = enc_to_dig_port(&E->base) <... ( - D->base.M + E->M | - &D->base + E ) ...> @@ identifier D, DP; expression E; identifier M; @@ DP = enc_to_intel_dp(&E->base) <... ( - dp_to_dig_port(DP)->base.M + E->M | - &dp_to_dig_port(DP)->base + E ) ...> @@ expression E; identifier M; @@ ( - enc_to_dig_port(&E->base)->base.M + E->M | - enc_to_dig_port(&E->base)->base + E | - enc_to_mst(&E->base)->primary->base.port + E->port ) @@ expression E; identifier D; @@ - struct intel_digital_port *D = E; ... when != D Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171109152434.32074-1-ville.syrjala@linux.intel.com
-
- 01 11月, 2017 1 次提交
-
-
由 Ville Syrjälä 提交于
Explicitly pass the crtc and connector states into the audio code enable/disable hooks, and plumb them all the way down. This gets rid of almost all crtc->config and encoder->crtc uses. The one place where we still use them is i915_audio_component_sync_audio_rate() since that gets called from the audio driver and we don't have explicit states around then. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171030184654.17429-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
- 31 10月, 2017 6 次提交
-
-
由 Ville Syrjälä 提交于
Eliminate the partially duplicated DDI readout code from MST, and instead just call intel_ddi_get_config(). As a nice bonus we get more cross checking as intel_ddi_get_config() will populate output_types based on the actual mode of the DDI port. Additonally intel_ddi_get_config() must be changed to get the crtc from the passed in crtc state rather than from the encoder->crtc link. encoder->crtc really shouldn't be used anyway. v2: Rebased on BXT MST latency_optim fix Make intel_ddi_clock_get() static Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-7-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
Pass an old crtc state to intel_ddi_post_disable() from the MST code. Note that this crtc state won't necessaitly match the one that was passed to intel_ddi_pre_enable() if the first stream to be enabled isn't the last stream to be disabled. But this is fine since the states should be identical in every important way. This does mean people frobbing the DDI pre_enable/post_disable hooks have to pay attention in what parts of the state they consult. The alternative would be to inline the relevant code into the MST code. That is actually what we used to do for pre_enable before commit e081c846 ("drm/i915: Remove duplicate DDI enabling logic from MST path"). For post_disable we've always called the DDI hook. v2: Pimp up the comments explaining the MST issues Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-6-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
We should be using the DPLL hw state we got from the current crtc state to determine the corresponding port clock frequency rather than getting it via the current state programmed into the DPLL. v2: Rebase due to intel_dpll_id changes Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-5-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
encoder->port works for FDI, and it also works for MST (regardless of whether we're dealing with the "fake" MST encoder, or mst->primary). So let's eliminate intel_ddi_get_encoder_port(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-4-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Currently the DDI encoder->type will change at runtime depending on what kind of hotplugs we've processed. That's quite bad since we can't really trust that that current value of encoder->type actually matches the type of signal we're trying to drive through it. Let's eliminate that problem by declaring that non-eDP DDI port will always have the encoder type as INTEL_OUTPUT_DDI. This means the code can no longer try to distinguish DP vs. HDMI based on encoder->type. We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and there's a bunch of code that relies on that value to identify eDP encoders. We'll introduce a new encoder .compute_output_type() hook. This allows us to compute the full output_types before any encoder .compute_config() hooks get called, thus those hooks can rely on output_types being correct, which is useful for cloning on oldr platforms. For now we'll just look at the connector type and pick the correct mode based on that. In the future the new hook could be used to implement dynamic switching between LS and PCON modes for LSPCON. v2: Fix BXT/GLK PPS explosion with DSI/MST encoders v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg v4: Rebase v5: Populate output_types in .get_config() rather than in the caller v5: Split out populating output_types in .get_config() (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
Rather than having the caller of .get_config() set output_types based on encoder->type, let's just have .get_config() itself populate output_types. This way we are isolated from encoder->type, which won't be useable for this purpose anyway soon (at least for DDI encoders). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 28 10月, 2017 1 次提交
-
-
由 Ville Syrjälä 提交于
Call the DDI .pre_pll_enable() hook from the MST code so that BXT gets the correct lane latency optimal setting applied. And we obviously need to compute the correct value, and read it out to keep the state checker happy. While at it drop the useless 'encoder' parameter to bxt_ddi_phy_calc_lane_lat_optim_mask() Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171027134348.31190-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 27 10月, 2017 3 次提交
-
-
由 Ville Syrjälä 提交于
intel_ddi_enable_transcoder_func() already has the crtc state so we can use that instead of the untrustworthy encoder->type. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019133721.11794-5-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
Eliminate intel_prepare_dp_ddi_buffers()'s reliance on the encoder->type by passing in the crtc state. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019133721.11794-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
encoder->type isn't reliable for DP/HDMI so instead extract the correct type from the crtc state in intel_ddi_set_pipe_settings(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019133721.11794-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 25 10月, 2017 2 次提交
-
-
由 Ville Syrjälä 提交于
On CNL we may need to bump up the system agent voltage not only due to CDCLK but also when driving DDI port with a sufficiently high clock. To that end start tracking the minimum acceptable voltage for each crtc. We do the tracking via crtcs because we don't have any kind of encoder state. Also there's no downside to doing it this way, and it matches how we track cdclk requirements on account of pixel rate. v2: Allow disabled crtcs to use the min voltage Add IS_CNL check to intel_ddi_compute_min_voltage() since we're using CNL specific values there s/intel_compute_min_voltage/cnl_compute_min_voltage/ since the function makes hw specific assumptions about the voltage values v3: Drop the test hack leftovers from skl_modeset_calc_cdclk() v4: s/voltage/voltage_level/ (Rodrigo) Replace DPLL DVFS FIXMEs with an explanation why we don't do anything there (Rodrigo) Cc: Mika Kahola <mika.kahola@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-9-ville.syrjala@linux.intel.com
-
由 Rodrigo Vivi 提交于
As we faced in BXT, on CNL DDI_A_4_LANES is not set as expected when system is boot with multiple monitors connected. This result in wrong lane setup impacting the max data rate available and consequently blocking modeset on eDP, resulting in a blank screen. Most of CNL SKUs don't support DDI-E. The only SKU that supports DDI-E is the same that supports the full A/E split called DDI-F. Also when DDI-F is used DDI-E cannot be used because they share Interrupts. So DDI-E is almost useless. Anyways let's consider this is possible and rely on VBT for that. This patch was initialy start by Clint, but required many changes including full commit message. So Credits entirely to Clint for finding this. v2: Extract all messy conditions into a helper function as suggested by Ville. Along with simplification I removed the debug message on the working case since now all conditions are grouped. v3: Split the conditions even more as suggested by Ville. Get's cleaner and easier to add new cases in the future. Suggested-by: NClint Taylor <clinton.a.taylor@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023173920.22890-1-rodrigo.vivi@intel.com
-
- 21 10月, 2017 1 次提交
-
-
由 Rodrigo Vivi 提交于
No functional change expected. Just let's use this enum when possible and also same standard pll_id name so we can rework gen9+ port clock later. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171018195407.8618-1-rodrigo.vivi@intel.com
-
- 19 10月, 2017 10 次提交
-
-
由 Ville Syrjälä 提交于
A bunch of functions are now exclusively used for HDMI, so naming the variables with hdmi prefix/suffix is redundant. Also use int rather than u32 for the translation level consistently. v2: Rebase due to hdmi_level=-1 avoidance Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171018181958.4423-1-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
Handle missing buf trans tables, or out of bounds buf trans levels the same way everywhere. These should never be hit under normal conditions, but let's play it safe for now. v2: Avoid the hdmi_level=-1 case (James) Cc: James Ausmus <james.ausmus@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171018181934.4229-1-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
SKL DDI B/C/D only have 9 usable buf trans registers for DP/eDP. That matches the normal DP buf trans tables, but the low vswing eDP tables have 10 entries. Thus the eDP tables can only be used safely with DDI A and E. We try to catch cases where DDI B/C/D gets used with the wrong number of entires in some parts of the code, but not everywhere. Let's move the code to deal with that deeper into intel_ddi_get_buf_trans_edp(). And for sake of symmetry do the same in intel_ddi_get_buf_trans_dp(). That would also avoid explosions in the rather unlikely case that the DP tables would get revised to 10 entries as well. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-9-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
default_index contained in the BXT buf_trans tables is actually useless. For DP we should always have a valid level selected (otherwise the link training logic would be buggy), and for HDMI we can just do what the other platforms do and pick the correct entry in intel_ddi_hdmi_level(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-8-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
encoder->type is unreliable for DP/HDMI, so pass it in explicity into cnl_ddi_vswing_sequence(). This matches what we do for BXT. v2: Pass intel_encoder down to cnl_ddi_vswing_program(), and clean up the argument types while at it Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-7-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
Make BXT less special by following the CNL approach and handling it in intel_ddi_dp_voltage_max() alognside every other DDI platform. v2: Clean up the argument types to bxt_ddi_vswing_sequence() while at it Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-6-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
The caller of intel_prepare_hdmi_ddi_buffers() alreday figured out the level, so let's just pass it in instead if figuring it out again. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-5-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
encoder->type isn't reliable for DP/HDMI encoders, so pass the type explicity to skl_set_iboost(). Also take the opportunity to streamline the code. v2: Clean up the argument types to skl_ddi_set_iboost() while at it Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-4-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
由 Ville Syrjälä 提交于
Introduce intel_ddi_get_buf_trans_hdmi() and start using it where we can. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-3-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
-
由 Ville Syrjälä 提交于
We'll want to use the intel_ddi_get_buf_trans_*() functions a bit earlier in the file, so move them up. While at it start using them in the iboost setup to get rid of the platform checks there. v2: Rebase due to BDW FDI buf trans fix Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-2-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
-
- 17 10月, 2017 3 次提交
-
-
由 Rodrigo Vivi 提交于
On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on the clock for the DDI and map the DPLL to the DDI" So we first do the map and then we unset DDI_CLK_OFF to turn the clock on. We do this in 2 separated steps. However, on this second step where we should only unset the off bit we are also unmapping the ddi from the pll. So we end up using the pll 0 for almost everything. Consequently breaking cases with more than one display. Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Kahola, Mika <mika.kahola@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-2-rodrigo.vivi@intel.com (cherry picked from commit 87145d95) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
The compiler warns: drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses hsw_ddi_translations_fdi[] for both Haswell and *Broadwell* Fixes: 7d1c42e6 ("drm/i915: Refactor code to select the DDI buf translation table") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 1210d388) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Rodrigo Vivi 提交于
On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on the clock for the DDI and map the DPLL to the DDI" So we first do the map and then we unset DDI_CLK_OFF to turn the clock on. We do this in 2 separated steps. However, on this second step where we should only unset the off bit we are also unmapping the ddi from the pll. So we end up using the pll 0 for almost everything. Consequently breaking cases with more than one display. Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Kahola, Mika <mika.kahola@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-2-rodrigo.vivi@intel.com
-
- 14 10月, 2017 4 次提交
-
-
由 Chris Wilson 提交于
The compiler warns: drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses hsw_ddi_translations_fdi[] for both Haswell and *Broadwell* Fixes: 7d1c42e6 ("drm/i915: Refactor code to select the DDI buf translation table") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
由 Ville Syrjälä 提交于
Untangle intel_enable_ddi() by splitting it into DP and HDMI specific variants. v2: Keep using intel_ddi_get_encoder_port() for now Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-10-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Rather that plumb the link parameters separately to intel_ddi_pre_enable_dp() let's just pass the entire crtc state. intel_ddi_pre_enable_hdmi() already took the crtc state, but for some reason intel_ddi_pre_enable() still wanted to extract has_infoframe from therein and pass it in separately. Let's not do that since it's pointless. v2: Rebase due to more code getting pulled into the DDI hooks Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Untangle intel_disable_ddi() by splitting it into DP and HDMI specific variants. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-8-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-