- 25 11月, 2015 1 次提交
-
-
由 Takashi Iwai 提交于
Currently a DDI port may register the DP hotplug handler even though it's used with HDMI, and the DP HPD handler overrides the encoder type forcibly to DP. This caused the inconsistency on a machine connected with a HDMI monitor; upon a hotplug event, the DDI port is suddenly switched to be handled as a DP although the same monitor is kept connected, and this leads to the erroneous blank output. This patch papers over the bug by excluding the previous HDMI encoder type from this override. This should be fixed more fundamentally, e.g. by moving the encoder type reset from the HPD or by having individual encoder objects for HDMI and DP. But since the bug has been present for a long time (3.17), it's better to have a quick-n-dirty fix for now, and keep working on a cleaner fix. Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=955190 Fixes: 0e32b39c ('drm/i915: add DP 1.2 MST support (v0.7)') Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by: NTakashi Iwai <tiwai@suse.de> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1447931396-19147-1-git-send-email-tiwai@suse.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 13 10月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
Drop some useless 'reg' variables when we only use them once. v2: A few more, including a few variable moves Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 10月, 2015 1 次提交
-
-
由 Sudip Mukherjee 提交于
Use goto to handle the error path to avoid duplicating the same code. In the error path intel_dig_port is the last one to be released as it was the first one to be allocated and ideally the error path should be the reverse of the execution path. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 10月, 2015 2 次提交
-
-
The link training functions had confusing names. The start function actually does the clock recovery phase of the link training, and the complete function does the channel equalization. So call them that instead. Also, every call to intel_dp_start_link_train() was followed by a call to intel_dp_complete_link_train(), so add a new start function that calls clock_recory and channel_equalization. Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The docs are unclear as usual, so it's not clear whether LRC should be bypassed, performed normally or GRC code should be used as the LRC code. Some old docs stated that LRC bypass ought to be used, more recent ones no longer say that. Some docs indicated that we could use GRC as the LRC code on CHV, but the BIOS doesn't do that, so let's not do it either. Besides to enable LRC bypass properly, I believe we should set the bit already before deasserting cmnreset. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 9月, 2015 2 次提交
-
-
由 Jani Nikula 提交于
Previously we've relied on having basically one backlight and one backlight type per platform. This is already a bit quirky with PMIC PWM support on VLV/CHV platforms with MIPI DSI. In the foreseeable future we'll have at least DPCD based backlight control on eDP and DCS command based backlight control on MIPI DSI. Backlight is becoming more and more connector specific, so reflect this fact by making the backlight control hooks connector specific. This enables further work to reuse generic backlight code in intel_panel.c while adding more specific backlight code accessed via the hooks. Cc: Deepak M <m.deepak@intel.com> Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDeepak M <m.deepak@intel.com> Reviewed-by: NYetunde Adebisi <yetundex.adebisi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Make adjusted_mode const whereever we don't have to modify it. This only covers cases when we have a local adjusted_mode variable, and doesn't make any difference for cases where we just dereference pipe_config->adjusted_mode. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NMika Kahola <mika.kahola@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 9月, 2015 2 次提交
-
-
由 Ville Syrjälä 提交于
We don't support eDP on g4x, so let's not even look at the VBT to determine the port type, just in case the VBT is bonkers on some g4x machines and indicates the precense of eDP. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Sonika Jindal 提交于
The Bspec is very clear that Live status must be checked about before trying to read EDID over DDC channel. This patch makes sure that HDMI EDID is read only when live status is up. The live status doesn't seem to perform very consistent across various platforms when tested with different monitors. The reason behind that is some monitors are late to provide right voltage to set live_status up. So, after getting the interrupt, for a small duration, live status reg fluctuates, and then settles down showing the correct staus. This is explained here in, in a rough way: HPD line ________________ |\ T1 = Monitor Hotplug causing IRQ | \______________________________________ | | | | | | T2 = Live status is stable | | _____________________________________ | | /| Live status _____________|_|/ | | | | | | | | | | T0 T1 T2 (Between T1 and T2 Live status fluctuates or can be even low, depending on the monitor) After several experiments, we have concluded that a max delay of 30ms is enough to allow the live status to settle down with most of the monitors. This total delay of 30ms has been split into a resolution of 3 retries of 10ms each, for the better cases. This delay is kept at 30ms, keeping in consideration that, HDCP compliance expect the HPD handler to respond a plug out in 100ms, by disabling port. v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions to check digital port status. Adding a separate function to get bxt live status (Daniel) v3: Using intel_encoder->hpd_pin to check the live status (Siva) Moving the live status read to intel_hdmi_probe and passing parameter to read/not to read the edid. (me) v4: * Added live status check for all platforms using intel_digital_port_connected. * Rebased on top of Jani's DP cleanup series * Some monitors take time in setting the live status. So retry for few times if this is a connect HPD v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob which was missed. v6: Drop the (!detect_edid && !live_status check) check because for DDI ports which are enumerated as hdmi as well as DP, we don't have a mechanism to differentiate between DP and hdmi inside the encoder's hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well as hdmi which leads to issues during unplug because of the above check. v7: Make intel_digital_port_connected global in this patch, some reformatting of while loop, adding a print when live status is not up. (Rodrigo) v8: Rebase it on nightly which involved skipping the hot_plug hook for now and letting the live_status check happen in detect until the hpd handling part is finalized (Daniel) Signed-off-by: NShashank Sharma <shashank.sharma@intel.com> Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 9月, 2015 1 次提交
-
-
由 Jani Nikula 提交于
SKL port E handling was added in commit 26951caf Author: Xiong Zhang <xiong.y.zhang@intel.com> Date: Mon Aug 17 15:55:50 2015 +0800 drm/i915/skl: enable DDI-E hotplug but the whole function was moved in a another branch in commit b93433cc Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Aug 20 10:47:36 2015 +0300 drm/i915: move ibx_digital_port_connected to intel_dp.c and the addition was lost at some backmerge that I was unable to identify. Put it back in. Tested-by: NTomi Sarvela <tomix.p.sarvela@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 14 9月, 2015 1 次提交
-
-
由 Sonika Jindal 提交于
Using intel_encoder's hpd_pin to check the live status because of BXT A0/A1 WA for HPD pins and hpd_pin contains the updated pin for the corresponding port. Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 9月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
When we get an i2c defer or short ack for i2c-over-aux write we need to switch to WRITE_STATUS_UPDATE to poll for the completion of the original request. i915 doesn't try to interpret wht request type apart from separating reads from writes, and so we should be able to treat this the same as a normal i2c write. Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 04 9月, 2015 3 次提交
-
-
由 Jani Nikula 提交于
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
TPS3 is mandatory for downstream devices that support HBR2, and Intel platforms that support HBR2 also support TPS3. Whenever TPS3 is supported by both the source and sink, it should be used. In other words, whenever the source and sink are capable of 5.4 Gbps link, we should anyway go for TPS3, regardless of the link rate being selected. Log an error if the sink has advertized HBR2 capability without TPS3 capability. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
There is no need to have a separate flag for tps3 as the information is only used at one location. Move the logic there to make it easier to follow. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 9月, 2015 1 次提交
-
-
由 Jani Nikula 提交于
Make it available outside of intel_dp.c. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 9月, 2015 4 次提交
-
-
由 Ville Syrjälä 提交于
Currently we release the lane soft reset before lane stagger settings have been programmed. I believe that means we don't actually do lane staggering. So move the soft reset deassert to happen after lane staggering has been programmed. The one confusing thing in this is that when we remove the power down override from the lanes, they power up with defaul register values, which do not have the soft reset overrides enabled. And according to some docs by default the data lane resets are tied to cmnreset. So that would mean that lanes would come out of reset without staggering as soon as the power down overrides are removed. But since we can't access either the lane stagger register nor the soft reset override registers until the lanes are powered on, we can't really do anything about it. So let's just set the soft reset overrides as soon as the lane is powered on and hope for the best. v2: Fix typos in commit message (Daniel) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
The DP MST encoder config function never sets ddi_pll_sel, even though its value is programmed in its ->pre_enable() hook. That used to work because a new pipe_config was kzalloc'ed at every modeset, and the value of zero selects the highest clock for the PLL. Starting with the commit below, the value of ddi_pll_sel is preserved through modesets, and since the correct value wasn't properly setup by the MST code, it could lead to warnings and blank screens. commit 8504c74c Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri May 15 11:51:50 2015 +0300 drm/i915: Preserve ddi_pll_sel when allocating new pipe_config Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628 Cc: stable@vger.kernel.org # 7e6313a2 drm/i915: Don't use link_bw for PLL setup Cc: stable@vger.kernel.org Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
No functional changes. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [danvet: s/intel_dp_tps/drm_dp_tps/.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Use port_clock instead of link_bw when picking the PLL parameters for DP. link_bw may be zero with an eDP 1.4 sink that supports DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it to the sink appropriately. v2: Fix typo in commit message (Sivakumar) Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> [Jani: cherry-picked from future.] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 31 8月, 2015 2 次提交
-
-
由 Rodrigo Vivi 提交于
Enable eDP on DDI-E. Also let's remove duplicated definitions to avoid later confusion. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NXiong Zhang <xiong.y.zhang@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
We are no longer checkling the DP link status on long hpd. We used to do that from the .hot_plug() handler, but it was removed when MST got introduced. If there's no userspace we now fail to retrain the link if the sink power is toggled (or cable yanked and replugged), meaning the user is left staring at a blank screen. With the retraining put back that should be fixed. Also remove the leftover comment that referred to the old retraining from .hot_plug(). Fixes a regression introduced in: commit 0e32b39c Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453Tested-by: NPalmer Dabbelt <palmer@dabbelt.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641 Cc: Dave Airlie <airlied@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 26 8月, 2015 14 次提交
-
-
由 Ville Syrjälä 提交于
With DPIO powergating active the DPLL can't be accessed unless something else is keeping the common lane in the channel on. That means the PPS kick procedure could fail to enable the PLL. Power up some data lanes to force the common lane to power up so that the PLL can be enabled temporarily. v2: Avoid gcc uninitilized variable warning Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Normmally the common lane in a PHY channel gets powered up when some of the data lanes get powered up. But when we're driving port B with pipe B we don't want to enabled any of the data lanes, and just want the DPLL in the common lane to be active. To make that happens we have to temporarily enable some data lanes after which we can access the DPLL registers in the common lane. Once the pipe is up and running we can drop the power override on the data lanes allowing them to shut down. From this point forward the common lane will in fact stay powered on until the data lanes in the other channel get powered down. Ville's extended explanation from the review thread: On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote: > One Q, why only for port B? Port C is also in same common lane right? Port B is in the first PHY channel which also houses CL1. CL1 always powers up whenever any lanes in either PHY channel are powered up. CL2 only powers up if lanes in the second channel (ie. the one with port C) powers up. So in this scenario (pipe B->port B) we want the DPLL from CL2, but ideally we only want to power up the lanes for port B. Powering up port B lanes will only power up CL1, but as we need CL2 instead we need to, temporarily, power up some lanes in port C as well. Crossing the streams the other way (pipe A->port C) is not a problem since CL1 powers up whenever anything else powers up. So powering up some port C lanes is enough on its own to make the CL1 DPLL operational, even though CL1 and the lanes live in separate channels. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> [danvet: Amend commit message with extended explanation.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Powergate the PHY lanes when they're not needed. For HDMI all four lanes are needed always, but for DP we can enable only the needed lanes. To power down the unused lanes we use some power down override bits in the DISPLAY_PHY_CONTROL register. Without the overrides it appears that the hardware always powers on all the lanes. When the port is disabled the power down override is not needed and the lanes will shut off on their own. That also means the override is critical to actually be able to access the DPIO registers before the port is actually enabled. Additionally the common lanes will power down when not needed. CL1 remains on as long as anything else is on, CL2 will shut down when all the lanes in the same channel will shut down. There is one exception for CL2 that will be dealt in a separate patch for clarity. With potentially some lanes powered down, the DP code now has to check the number of active lanes before accessing PCS/TX registers. All registers in powered down blocks will reads as 0xffffffff, and soe we would drown in warnings from vlv_dpio_read() if we allowed the code to access all those registers. Another important detail in the DP code is the "TX latency optimal" setting. Normally the second TX lane acts as some kind of reset master, with the other lanes as slaves. But when only a single lane is enabled, that single lane obviously has to be the master. A bit of extra care is needed to reconstruct the initial state of the DISPLAY_PHY_CONTROL register since it can't be read safely. So instead read the actual lane status from the DPLL/PHY_STATUS registers and use that to determine which lanes ought to be powergated initially. We also need to switch the PHY power modes to "deep PSR" to avoid a hard system hang when powering down the single channel PHY. Also sprinkle a few debug prints around so that we can monitor the DISPLAY_PHY_STATUS changes without having to read it and risk corrupting it. v2: Add locking to chv_powergate_phy_lanes() v3: Actually enable dynamic powerdown in the PHY and deal with the fallout Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
BXT platform uses live status bits from 0x44440 register to obtain DP status on hotplug. The existing g4x_digital_port_connected() uses a different register and hence misses DP hotplug events on BXT platform. This patch fixes it by using the appropriate register(0x44440) and live status bits(3:5). Based on a patch by Durgadoss R <durgadoss.r@intel.com>, from whom the commit message is shamelessly copy pasted. Reported-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Choose the right function at the intel_digital_port_connected level. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Choose the right function at the intel_digital_port_connected level. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Add a common intel_digital_port_connected() that splits out to functions for different platforms. No functional changes. v2: make the function return a boolean Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
With the case added for eDP on port A (always connected from this function's point of view), we should not be hitting any of the default cases in ibx_digital_port_connected, so add MISSING_CASE annotation. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
We should not be hitting any of the default cases in g4x_digital_port_connected, so add MISSING_CASE annotation and return boolean status. The current behaviour is just cargo culting from the days of yonder when the display port support was added to i915. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
The function can be made static there. No functional changes. Reviewed-by: NDurgadoss R <durgadoss.r@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Move the CHV clock buffer disable from chv_disable_pll() to the new encoder .post_pll_disable() hook. This is more symmetric since the clock buffer enable happens from the .pre_pll_enable() hook. We'll have more use for the new hook soon. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The docs give you the impression that the unique transition scale value shouldn't matter when unique transition scale is enabled. But as Imre found on BXT (and I verfied also on BSW) the value does matter. So from now on just program the same value 0x9a always. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
With MST there won't be a crtc assigned to the main link encoder, so trying to dig up the pipe_config from there is a recipe for an oops. Instead store the parameters (lane_count and link_rate) in the encoder, and use those values during link training etc. Since those parameters are now assigned only when the link is actually enabled, .compute_config() won't clobber them as it did before. Hardware state readout is still bonkers though as we don't transfer the link parameters from pipe_config intel_dp. We should do that during encoder sanitation. But since we don't even do a proper job of reading out the main link encoder state for MST there's littel point in worrying about this now. Fixes a regression with MST caused by: commit 90a6b7b0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Jul 6 16:39:15 2015 +0300 drm/i915: Move intel_dp->lane_count into pipe_config v2: Different apporoach that should keep intel_dp_check_mst_status() somewhat less oopsy Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Xiong Zhang 提交于
v2: fix one error found by checkpath.pl v3: Add one ignored break for switch-case. DDI-E hotplug function doesn't work after updating drm-intel tree, I checked the code and found this missing which isn't the root cause for broke DDI-E hp. The broken DDI-E hp function is fixed by "Adding DDI_E power well domain". Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: NTimo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 24 8月, 2015 1 次提交
-
-
由 Thulasimani,Sivakumar 提交于
This patch fixes the bug that SKL SKUs before B0 might return HBR2 as supported even though it is not supposed to be enabled on such platforms. v2: optimize if else condition (Jani) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> [Jani: minor whitespace fix.] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 19 8月, 2015 3 次提交
-
-
由 Thulasimani,Sivakumar 提交于
This patch removes TP3 support on CHV since there is no support for HBR2 on this platform. v2: rename the function to indicate it checks source rates (Jani) v3: update comment to indicate TP3 dependency on HBR2 supported hardware (Jani) Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> [Jani: fixed a couple of checkpatch warnings.] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Thulasimani,Sivakumar 提交于
This patch removes 5.4Gbps from supported link rate for CHV since it is not supported in it. v2: change the ordering for better readability (Ville) Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Thulasimani,Sivakumar 提交于
This reverts commit fe51bfb9. Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Mar 12 17:10:38 2015 +0200 CHV does not support intermediate frequencies so reverting the patch that added it in the first place Cc: stable@vger.kernel.org # v4.1+ Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-