- 02 Sep, 2015 1 commit
-
-
Maarten Lankhorst authored
The driver doesn't support UMS any more, so set DRIVER_MODESET by default, remove the legacy s/r callbacks, and rename the s/r functions to make it more clear they're only in use by switcheroo now. Also remove an obsolete comment about atomic. Normal updates are supported only async updates aren't yet. v2: Don't unconditionally set DRIVER_ATOMIC, we're not yet there. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 Sep, 2015 8 commits
-
-
Ville Syrjälä authored
Make the code mode readable by pulling the "does this crtc have any encoders?" deduction into a separate function. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The BIOS sometimes likes to enable pipes w/o any ports, at least on older machines. Currently we fail to assign anything sensible to crtc->hwmode.crtc_clock which leads to complaints from the vblank code. Deal with active pipes w/o ports and assign something sensible to crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will override this if the port is enabled. Gets rid of rest of these on my gen4: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate constants, dotclock = 0! [drm:i915_get_vblank_timestamp] crtc 1 is disabled v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
At various points when changing the DPIO lane/phy power states, construct an expected value of the DISPLAY_PHY_STATUS register and compare it with the real thing. To construct the expected value we look at our shadow PHY_CONTROL register value (which should match what we've just written to the hardware), and we also need to look at the actual state of the cmn power wells as a disabled power well causes the relevant LDO status to be reported as 'on' in DISPLAY_PHY_STATUS. When initially powering up the PHY it performs various internal calibrations for which it fully powers up. That means that if we check for the expetected power state immediately upon releasing cmnreset we would get the occasional false positive. But we can of course poll until the expected value appears. It shouldn't be too long so this shouldn't make modesets substantially longer. One extra complication is introduced when we cross the streams, ie. drive port B with pipe B. In this case we trick CL2 (where the DPLL lives) into life by temporaily powering up the lanes in the second channel, and once the pipe is up and runnign we release the lane power override. At that point the power state of CL2 has somehow gotten entangled with the power state of the first channel. That means that constructing the expected DISPLAY_PHY_STATUS value is a bit tricky since based on the lane power states in the second channel, CL2 should also be powered down. But we can use the DPLL enable bit to determine when CL2 should be alive even if the lanes are powered down. However the power state of CL2 isn't actually tied in with the DPLL state, but to the state of the lanes in first channel, so we have to avoid checking the expected state between shutting down the DPLL and powering down the lanes in the first channel. So no calling assert_chv_phy_status() before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(), but after the write is a safe time to check. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add some checks that the state of the DPIO lanes is more or less what we expect based on the overrides. The hardware only provides two bits per channel indicating whether all or some of the lanes are powered down, so we can't do an exact check. Additionally, CL2 powering down before we can check it adds another twist. To work around this we simply check for the 0 value of the CL2 register (which is what we get when it's powered down) and adjust our expectations. Signed-off-by:
-
Ville Syrjälä authored
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:
-
Francisco Jerez authored
This was forgotten in commit d351f6d9 Author: Francisco Jerez <currojerez@riseup.net> Date: Fri May 29 16:44:15 2015 +0300 drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist. Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jani Nikula authored
Cc: Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
- 28 Aug, 2015 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 26 Aug, 2015 30 commits
-
-
Maarten Lankhorst authored
This partially reverts commit 74c090b1. The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async support. Signed-off-by:
-
Paulo Zanoni authored
Dear git bisect user, Even though this is the patch that introduced the WARN() you're bisecting, please notice that it's very likely that the problem you're facing was already present before this commit. In other words: this commit adds code to detect errors and give WARN()s about them, but the errors were already there. In order to continue your debug, please use the i915.mmio_debug option, check the backtraces and try to discover which read or write operation is causing the error message. Then check if this is happening because the register does not exist or because its power well is down when the operation is being done. On my SKL machine, if I use i915.mmio_debug=999, this patch triggers 42 WARNs just by booting. I didn't investigate them yet. Normal users are only going to get a single WARN due to the default i915.mmio_debug setting. Thank you for your comprehension, Paulo Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We can choose to leave the display PHY CL2 powerdown up to some hardware signals, or we can force it. The BXT code forces the nonexistent CL2 in the x1 PHY to power down. Follow suit on CHV. Maybe it can still save some extra power by disabling some extra logic in CL1, or something. Signed-off-by:
-
Ville Syrjälä authored
CHV has supports some form of automagic clock gating for the DPIO SUS clock. We can simply enable the magic bits and the hardware should take care of the rest. Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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: -
Ville Syrjälä authored
Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV, and having VGA mode enabled causes some problems for CHV. So let's just pull the code to configure those bits into the disp2d well enable hook. With the DPLL disable code also fixed to leave those bits alone we should now have a consistent DPLL state all the time even if the DPLL is disabled. This also neatly removes some duplicated code between the VLV and CHV codepaths. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Most of our char* arrays are markes as const already, but a few slipped through the cracks. Fix it. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
A couple of hand rolled ARRAY_SIZE()s caught my eye. Get rid of them. Signed-off-by:
-
Ville Syrjälä authored
Simple one: drivers/gpu/drm/i915/i915_debugfs.c:2449:57: warning: Using plain integer as NULL pointer And something a bit more peculiar: drivers/gpu/drm/i915/i915_debugfs.c:4953:18: warning: Variable length array is used. drivers/gpu/drm/i915/i915_debugfs.c:4953:32: warning: Variable length array is used. We pass a 'const int' as the array size which results in the warning, dropping the const gets rid of the warning. Weird, but I think getting rid of the warnings is better than holding on to the const. Signed-off-by:
-
Jani Nikula authored
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:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
-
Jani Nikula authored
Choose the right function at the intel_digital_port_connected level. Signed-off-by:
-
Jani Nikula authored
Choose the right function at the intel_digital_port_connected level. Signed-off-by:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
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:
-
Jani Nikula authored
The function can be made static there. No functional changes. Reviewed-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DVO. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - clock check against max dotclock moved inside 'if (fixed_mode)' V5: - dot clock check against fixed_mode clock when available Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DSI. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk - moved dot clock checking inside 'if (fixed_mode)' V5: - dot clock checked against fixed_mode clock Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to LVDS. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - moved supported dotclock check from mode_valid() to intel_lvds_init() V5: - dotclock check moved back to mode_valid() function - dotclock check for fixed mode Signed-off-by:
-
Mika Kahola authored
Store max dotclock into dev_priv structure so we are able to filter out the modes that are not supported by our platforms. V2: - limit the max dot clock frequency to max CD clock frequency for the gen9 and above - limit the max dot clock frequency to 90% of the max CD clock frequency for the older gens - for Cherryview the max dot clock frequency is limited to 95% of the max CD clock frequency - for gen2 and gen3 the max dot clock limit is set to 90% of the 2X max CD clock frequency V3: - max_dotclk variable renamed as max_dotclk_freq in i915_drv.h - in intel_compute_max_dotclk() the rounding method changed from round up to round down when computing max dotclock V4: - Haswell and Broadwell supports now dot clocks up to max CD clock frequency Signed-off-by:
-
Ville Syrjälä authored
Add vlv_dport_to_phy() and fix up the return values of vlv_dport_to_channel() and vlv_pipe_to_channel() to use the appropriate enums. Signed-off-by:
-
Ville Syrjälä authored
With DPIO powergating active on CHV, we can't even access the DPIO PLL registers until the lane power state overrides have been enabled. That will happen from the encoder .pre_pll_enable() hook, so move chv_prepare_pll() to happen after that point, which puts it just before chv_enable_pll() actually. Do the same for VLV to avoid accumulating weird differences between the platforms. Both platforms seem happy with the new arrangement. Signed-off-by:
-
Ville Syrjälä authored
dev_priv->chv_phy_control is protected by the power_domains->lock elsewhere, so also grab it when initializing chv_phy_control. Signed-off-by:
-
Ville Syrjälä authored
To implement DPIO lane power gating on CHV we're going to need to access DPIO registers from the cmn power well enable hook. That gets called rather early, so we need to move the DPIO port IOSF sideband port assignment earlier as well. Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
When fractional m2 divider isn't used on CHV the fractional part is ignore by the hardware. Despite that, program the fractional value (0 in this case) to the hardware register just to keep things a bit more consistent. Might at least make register dumps a bit less confusing when there isn't some stale fractional part hanging around. Signed-off-by:
-
Dave Gordon authored
The current versions of these two macros don't work correctly if the argument expression happens to contain a modulo operator (%) -- when stringified, it gets interpreted as a printf formatting character! With a specifically crafted parameter, this could probably cause a kernel OOPS; consider WARN_ON(p%s) or WARN_ON(f %*pEp). Instead, we should use an explicit "%s" format, with the stringified expression as the coresponding literal-string argument. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
