- 04 Nov, 2014 40 commits
-
-
Mika Kuoppala authored
When looking at the bug report logs with triggered WARN_ON, the person doing bug triaging will have to find exact kernel source and match file/line. Attach the condition that triggered the WARN_ON to kernel log. In most cases the context is self evident and this way we can save developer time. The drawback is ~16kbytes bigger i915.ko Signed-off-by:
Mika Kuoppala <miku@iki.fi> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
When we suspend we turn everything off so the pps should be idle, and we also (or at least should) disable all power wells which will reset the power sequencer port assignment. So when we resume all power sequencers should be in their reset state. However it's at least theoretically possible that the BIOS would touch the power seuqencer(s), so to be safe we ought to read out the current port assignment like we do at driver init time. To do that we can simply call vlv_initial_power_sequencer_setup() from the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize(). There's no danger or clobbering the pps delays since we now have those stored within intel_dp and we don't change them once initialized. This will make sure that the vdd state gets correctly tracked post-resume in case the BIOS enabled it. We need to shuffle things around a bit to get the locking right, and while at it, make intel_edp_panel_vdd_sanitize() static and move it around a bit to avoid a forward declaration. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The pps timestamp initialization was accidentally lost on vlv/chv in commit a4a5d2f8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:20 2014 +0300 drm/i915: Track which port is using which pipe's power sequencer Restore it so that we avoid introducing random delays into the pps operations during/after driver init time. Cc: Imre Deak <imre.deak@intel.com> Reported-by:
-
Jani Nikula authored
We'll never end up in the hooks with eld[0] unset, as that's checked by drm_select_eld(). Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Introduce functions to enable/disable the audio codec, incorporating the ELD setup within enable. The disable is initially limited to HSW, covering exactly what was done previously. The only functional difference is that ELD valid is no longer set if there is no connector with ELD, which should be the right thing to do anyway. Otherwise the sequence remains the same, with warts and all, in preparation for applying more sanity. v2: add kernel doc. Signed-off-by:
-
Jani Nikula authored
The audio programming sequence states that the ELD must be written and enabled after the pipe is ready. Indeed, this should clarify the situation with commit c7905792 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 16 16:56:09 2014 +0200 drm/i915: Remove vblank wait from haswell_write_eld and Ville's review of it [1]. Moreover, we should not touch the relevant registers before we get the audio power domain. [1] http://mid.gmane.org/20140416155309.GK18465@intel.comSigned-off-by:
-
Jani Nikula authored
Keep the driver modifications to ELD together. This also sets the Conn_Type for G4X DP which wasn't done before. Clean up the debugs while at it; this is all obvious from the connector name. v3: add missing ~ (Rodrigo) Signed-off-by:
-
Ville Syrjälä authored
It seems that the pipe-a power well has replaced the disp2d power well on chv. At least that's the case with the current punit firmware. So enable the pipe-a power and expand its domains to cover everything the disp2d well ought to cover. The other power wells (apart from the cmnlane wells) still seem awol in the current punit firmware. So leave them disabled in the code. This fixes a hilarious oops during resume on bsw where intel_hdmi_get_config() would read the port register and get back 0xffffffff and thus think the port is enabled on pipe D. It would then go and index the pipe_to_crtc_mapping[] array with PIPE_D and blow up when intel_hdmi_get_config() tries to write to crtc->config. Someone really ought to replace all naked pipe_to_crtc_mapping[] uses with the appropriate function call so we could add a warning there if the pipe doesn't actually exist... We must also call the power seqeuencer state reset function from the pipe-a well disable just like we do from disp2d on vlv. Otherwise the eDP panel won't recover at resume time since the PPS has lost its hold on the port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84903Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
CHV has a programmable CSC unit on the pipe B sprites. Program the unit appropriately for BT.601 limited range YCbCr to full range RGB color conversion. This matches the programming we currently do for sprites on the other pipes and on other platforms. It seems the CSC only works when the input data is YCbCr. For RGB pixel formats it doesn't matter what we program into the CSC registers. Doesn't make much sense to me especially since the register names give the impression that RGB input data would also work. But that's how it behaves here. In the review discussions there's been some nice math to explain the values obtained here. First about the YCbCr->RGB matrix: "I had the RGB->YCbCr matrix, inverted it and the values came out. But they should match the wikipedia article. Also keep in mind that the coefficients are in .12 in fixed point format, hence we need a 1<<12 factor. So let's try it: Kb=.114 Kr=.299 (1<<12) * 255/219 ~= 4769 -(1<<12) * 255/112*(1-Kb)*Kb/(1-Kb-Kr) ~= -1605 -(1<<12) * 255/112*(1-Kr)*Kr/(1-Kb-Kr) ~= -3330 (1<<12) * 255/112*(1-Kr) ~= 6537 (1<<12) * 255/112*(1-Kb) ~= 8263 "Looks like the same values to me." And then about the limits used for clamping: "> where did you get these min/max? "The hardware apparently deals in 10bit values, so we need to multiply everything by 4 when we start with the 8bit min/max values. Y = [16:235] * 4 = [64:940] CbCr = ([16:240] - 128) * 4 = [-112:112] * 4 = [-448:448] "The -128 being the -0.5 bias that the hardware already applied before the data entered the CSC unit." Raw data is also supplied in 10bpc in the registers. Signed-off-by:
-
Paulo Zanoni authored
We want to run intel_uncore_early_sanitize() before we touch any registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit is set, so we need to clear it - through intel_uncore_early_sanitize() - before we do anything else. With the current code, we don't clear the bit before our first register access, so we print a WARN complaining about an unclaimed register error. v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume" v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV" v3: This one, on top of the intel_resume_prepare() rework. v4: Rebase. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Because, really, the abstraction is not working for us. It is nice for VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change this code due to a recently-discovered bug, but we can't seem to find a nice solution that repects the current abstraction. So let's kill intel_resume_prepare() and its friends, and add an equivalent implementation to both its callers. Also, look at the diffstat! v2: - Rebase. Signed-off-by:
-
Ville Syrjälä authored
CHV adds a bunch of new registers for primary plane size/position and pipe blender setup. Initialize all those registers to avoid nasty surprises. PRIMSIZE is especially important as without programming it the outout will be garbled whenever the primary plane size would not match what the BIOS set up. Also program the sprite constant alpha register to disable the constant alpha blending factor. This applies to vlv as well as chv. Signed-off-by:
-
Ville Syrjälä authored
In case the cmnlane power well is down but cmnreset isn't asserted we would currently skip the off+on toggle for the power well. That could leave cmnreset deasserted while cmnlane is powered down which might lead to problems with the PHY. To avoid such issues skip the cmnlane toggle only if both cmnlane and disp2d wells are up and cmnreset is already deasserted. In all other cases power down the cmnlane well which will also make sure cmnreset gets asserted correctly while cmnlane is powered down. Signed-off-by:
-
Gustavo Padovan authored
Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by:
-
Gustavo Padovan authored
take out pin_fb code so the commit phase can't fail anymore. Signed-off-by:
-
Gustavo Padovan authored
Take out the pin_fb code so commit phase can't fail anymore. Signed-off-by:
-
Ville Syrjälä authored
The power seqeuencer kick procedure requires the DPLL to be running in order to complete successfully. In case the DPLL isn't currently running when we need to kick the power seqeuncer enable it temporarily. This can happen eg. during ->detect() when the pipe is not already active. To avoid needlessly duplicating the DPLL programming re-use the already existing functions by passing a temporary pipe config to them instead of having them consult the current pipe config at crtc->config. v2: Introduce vlv_force_pll_{on,off}() (Daniel) v3: Rebase due to drm_crtc vs. intel_crtc changes Fix a typo in commit msg (checkpatch) Signed-off-by: -
Ville Syrjälä authored
eDP ports need the power seqeuncer whenever the port is active. Warn if we accidentally steal the power sequener from an active eDP port. This should not happen unless there's a bug somewhere else, but it's best to scream loudly if it happens to help with debugging. Note that this only checks for active pipes and not for enabled pipes which are turned off with dpms. Which means we might run the risk that the pps might get stolen and we can't reacquire one when enabling the pipe again with dpms on. But on current platforms that's impossible since we only support two edp ports with just two panel power sequencers. So a more elaborate scheme which reserves the pps even when the pipe is inactive isn't required. Signed-off-by:
-
Ville Syrjälä authored
We should never enable the panel power twice. That would indicate a bug somewhere else as we would need to enable the port twice without disabling it in between. Also print the port name. Signed-off-by:
-
Ville Syrjälä authored
Print the port name in the VDD/PPS debugs messages. Signed-off-by:
-
Ville Syrjälä authored
In case we fumble something and end up picking an already used power seqeuencer in vlv_power_sequencer_pipe() at least try to steal it gracefully. In theory this should never happen though. Signed-off-by:
-
Ville Syrjälä authored
There's no power sequencer on pipe C on VLV/CHV so scream a bit if we try to steal one from pipes other than A and B. Signed-off-by:
-
Ville Syrjälä authored
VLV gets confused if two power sequencers have the same port selected. It would seem the port doesn't start up properly in the is case and vlv_wait_port_ready() will fail as will the link training. Clearing the port select in the PP_ON_DELAYS register fixes this problem. CHV doesn't seem to need this, but it doesn't seem to hurt either so let's just do it for both to keep the code between the platforms as uniform as possible. Signed-off-by:
-
Ville Syrjälä authored
If there's no power sequencer assigned to the port currently we can't very well have vdd or panel power enabled either. If we would try to check that from the pps registers we'd need to pick a power seqeuncer and kick it. So let's skip the register read and the kick. Note that there's still a bit an issue about correctly recovering pps state from resume if the bios is nasty: With this check we'll always assume that the pps is off. But that's better done in a follow-up patch and it shouldn't be too harmful - at most we waste time enabling the pps if it's on already. Signed-off-by:
-
Ville Syrjälä authored
When we pick a new power sequencer for the port but we're not doing a full modeset, the power sequencer may have locked on to another port (or no port). So kick it a bit to make sure it controls the port we want. Again just like when we attempt to actually enable the DP port, we must first write the port register with the approriate value except the enable bit, and then we must enable the port to make the power sequencer happy. In this case since we don't want the port actually enabled we just toggle it on and immediately back off. Going forward the power sequencer will keep working on that specific port until again moved to another port. v2: Refine the kick procedure Signed-off-by:
-
Ville Syrjälä authored
When switching from one pipe to another, the power sequencer of the new pipe seems to need a bit of kicking to lock into the port. Even the vdd force bit doesn't work before the power sequencer has been sufficiently kicked, so this must be done before any AUX transactions are attempted. After extensive experimentation I've determined that it's sufficient to first write the port register with the correct values except the port must remain disabled, then we can do a second write to enable the port, after which the power sequencer is operational and allows the port to start up properly. Contrary to my earlier theories we don't need to enable the port with the idle pattern, so let's just use training pattern 1 as that's what other platforms use here. v2: Refine the kick procedure Signed-off-by:
-
Ville Syrjälä authored
There's no point in checking if the data lanes came out of reset after link training. If the data lanes aren't ready link training will fail anyway. Suggested-by:
Todd Previte <tprevite@gmail.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Just grab the pps_mutex once and do all the pps panel startup operations while holding the mutex instead of grabbing the mutex separately for each individual step. Signed-off-by:
-
Ville Syrjälä authored
We'll be needing to the call the power seqeuencer functions while already holding pps_mutex, so split the locking out to small wrapper functions. Signed-off-by:
-
Ville Syrjälä authored
Since we read the current power seqeuncer delays from the registers (as well as looking at the vbt and spec values) we may end up corrupting delays we already initialized when we switch to another pipe and the power seqeuncer there has different values currently in the registers. So make sure we only initialize the delays once even if intel_dp_init_panel_power_sequencer() gets called multiple times. There was some discussion in the review about when exactly we need to unlock the pps. Quoting Bspec: "If this bit is not a zero, it activates the register write protect and writes to those registers will be ignored unless the write protect key value is set in the panel sequencing control register." Signed-off-by:
-
Ville Syrjälä authored
The power seqeuncer delays are fixed for a given panel, so we can keep them around once computed. Not that on VLV/CHV we still re-compute them every time we initialize the power seqeuncer registers, but that will change soon enough. Signed-off-by:
-
Ville Syrjälä authored
want_panel_vdd is a bool so it can't cope with interleaving on/off calls from multiple threads. If we want to make that possible we'd need to convert want_panel_vdd into a proper ref count. But an easier fix is to remove the high level vdd on/off calls from detect/hpd code paths and just rely on the delayed vdd off to avoid needless vdd on<->off ping pong. After this change only the encoder enable/disable paths use the high level functions, which is fine since both the on and off low level edp vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in between and so want_panel_vdd can't change in between. Signed-off-by:
-
Ville Syrjälä authored
Only ports B and C have the power sequencer and backlight controls, so complain if we ever try to register an eDP connector on some other port. Signed-off-by:
-
Paulo Zanoni authored
Because I got annoyed that I had to document what values "int ddi_personality" is supposed to hold. A good side-effect of this change is that now the compilers can do some additional checks on our code, which may prevent some bugs in the future. A bad side-effect of this change is that now the compilers do some additional checks on our code and complain when a switch statement doesn't check for all possible values, so we need to add "default" cases to all those switches. Hopefully, this may help preventing confusions against DRM_MODE_CONNECTOR_* and DRM_MODE_ENCODER_*. I guess that just by looking at the patch, some people will think this change is not worth its benefits. In this case, I don't really mind dropping the patch. Also, there's probably still a few more places where we can s/int/enum intel_output_type/, but we can change that later, when we spot the places. Signed-off-by:
-
Jani Nikula authored
This will simplify things later on. No functional changes. Signed-off-by:
-
Jani Nikula authored
Everything else can be derived from that. No functional changes. Signed-off-by:
-
Jani Nikula authored
Most importantly, "i" need not be the universal variable used for everything. No functional changes. Signed-off-by:
-
Jani Nikula authored
Const is good. Signed-off-by:
-
Jani Nikula authored
In preparation for some additional cleanup. No functional changes. Signed-off-by:
-
Gustavo Padovan authored
The fb check introduced to drm_plane_helper_check_update() just make this check impossible to branch in. Signed-off-by:
-
