- 19 Apr, 2013 5 commits
-
-
Paulo Zanoni authored
... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL register per CPU transcoder, not per pipe. This solves "unclaimed register" messages when booting with eDP only and using the i915.disable_power_well=1. Also fix a comment and remove an useless empty line. The error messages were caused by: commit 88adfff1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 28 10:42:01 2013 +0100 drm/i915: hw readout support for ->has_pch_encoders Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
This fixes "unclaimed register" messages when booting with eDP only and i915.disable_power_well=1. The error messages were caused by: commit 0e8ffe1b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 28 10:42:00 2013 +0100 drm/i915: add hw state readout/checking for pipe_config Signed-off-by:
-
Paulo Zanoni authored
This is bad news and shouldn't be happening. V2: Rebase. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
In this commit we enable both CPU and PCH FIFO underrun reporting and start reporting them. We follow a few rules: - after we receive one of these errors, we mask the interrupt, so we won't get an "interrupt storm" and we also won't flood dmesg; - at each mode set we enable the interrupts again, so we'll see each message at most once per mode set; - in the specific places where we need to ignore the errors, we completely mask the interrupts. The downside of this patch is that since we're completely disabling (masking) the interrupts instead of just not printing error messages, we will mask more than just what we want on IVB/HSW CPU interrupts (due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll also be masking PCH FIFO underruns for pipe B, because both are reported by SERR_INT, which has to be either completely enabled or completely disabled (in othe words, there's no way to disable/enable specific bits of GEN7_ERR_INT and SERR_INT). V2: Rename some functions and variables, downgrade messages to DRM_DEBUG_DRIVER and rebase. Signed-off-by: -
Jesse Barnes authored
In Valleyview voltage swing, pre-emphasis and lane control registers can be programmed only through the h/w side band fabric. Update vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the appropriate programming. We need to make sure that the tx lane reset occurs in both the full mode set and DPMS paths, so factor things out to allow that. v2: use different DPIO_DIVISOR values for VGA and DisplayPort v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values for all display interfaces v4: collapse with various updates v5: squash with crtc enable/pll enable bits v6: split out DP code (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) remove unneeded check in 9xx pll div update (Jani) wrap VLV pll update call in IS_VALLEYVIEW (Jani) move port enable back to end of crtc enable (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) v7: fix up conflicts against latest drm-intel-next-queued v8: use DPIO reg names, fix pipes (Jani) from mPhy_registers_VLV2_ww20p5 doc v9: update to latest info from driver enabling notes doc driver_vbios_notes_9 v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work simultaneously (Jesse) v11: use pll/port callbacks for DPIO port activity (Daniel) use separate VLV CRTC enable function (Daniel) move around port ready checks (Jesse) Signed-off-by:Pallavi G <pallavi.g@intel.com> Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Drop pfit changes and add a little comment explaining that vlv has a different enable sequence and so needs it's own crtc_enable callback. Also apply a fixup patch from Wu Fengguang to shut up some compiler warnings.] Signed-off-by:
-
- 18 Apr, 2013 35 commits
-
-
Jesse Barnes authored
This is a reset feature we don't actually need. Signed-off-by:
-
Pallavi G authored
Program few Tx buffer Swing control settings through DPIO. v2: fix up codingstyle (Daniel) call from set_signal_levels (Ville, Daniel) use proper port numbers (Jesse) Signed-off-by:Yogesh M <yogesh.mohan.marimuthu@intel.com> Signed-off-by:
-
Daniel Vetter authored
Stolen from a patch with the below impressive sob-section. Signed-off-by:
-
Daniel Vetter authored
Magic updates. v2: use 64 bit types and math (Ville) v3: Trim out all the m/n/p calculation changes since they are still under discussion. Instead squash in a fixup for hdmi limits which slipped into a different patch. Signed-off-by:
-
Jesse Barnes authored
Uses slightly different interfaces than other platforms. v2: track actual set freq, not requested (Rohit) fix debug prints in init code (Jesse) v3: don't write sleep reg (Jesse) re-add RC6 wake limit write (Ben) fixup thresholds to match other platforms (Ben) clean up mem freq calculation (Ben) clean up debug prints (Ben) v4: move defines from punit patch (Ville) v5: remove writes to nonexistent regs (Jesse) put RP and RC regs together (Jesse) fix RC6 enable (Jesse) v6: use correct fuse reads from NC (Jesse) split out min/max funcs for use in sysfs (Jesse) add debugfs & sysfs freq controls (Jesse) v7: update with Ben's hw_max changes (Jesse) Signed-off-by: -
Jesse Barnes authored
When requesting frequency changes or querying status from the Punit, we need to use an opcode that corresponds to the frequency, taking into account the memory frequency. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ville Syrjälä authored
Add sprite_name() macro which should be used with the kind of sprites that are fixed to pipes (gen4.5+). Also use dev_priv->num_plane to calculate the sprite index insted assuming two sprites per pipe. This should make it print the right name. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Print the alphabetical name for transcoders. The code already used the pipe_name() macro for transcoders, so I did the same. But we do have the (unused) transcoder_name() macro which could be used instead. Signed-off-by:
-
Ville Syrjälä authored
Alway use the alphabetical names in debug/error messages for planes, pipes and ports, instead of using decimal numbers occasionally. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Get rid of the few remaining open coded copies of pipe_name() and port_name(). Signed-off-by:
-
Daniel Vetter authored
When adding the pipe config computation step I've accidentally moved this a bit away. Which momentarily confused me since the pipe config step rejected some modesetting operations I expected and so left me looking in vain for that debug output. v2: Move the debug output into the right function to prevent this from happening again. v3: Make it compile (Ville). Also reorder the patch so that the two bugfixes are first. Signed-off-by: -
Daniel Vetter authored
We can only enable the pfit if the pipe is disabled. Ensure that this is obeyed with a neat assert. Also check whether the pfit is off before enabling it - if not we've lost track of things somewhere since the pfit is only ever used by the lvds output. v2: Fix spell fail in the commit message pointed out by Ville&Jani. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
The i9xx modeset sequence is currently pretty fishy, so tight it all up with some good assert-sprinkling. We already have good coverage on the disable side, but the enable side is spotty (since until recently it was wrong). Reviewed-by:
-
Daniel Vetter authored
Just blows through 50ms for naught, since the pipe is off. Reviewed-by:
-
Daniel Vetter authored
This is horrible lore and we should be able to get rid of it now that the lvds/pfit handling code actually does the right thing. Reviewed-by:
-
Daniel Vetter authored
Oops. This regression has been introduced in commit 5d2d38dd Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:45:01 2013 +0100 drm/i915: clean up pipe bpp confusion Reported-by:
-
Daniel Vetter authored
For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Paulo Zanoni authored
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits are being zeroed, but I couldn't find a reason for this, so leave them as they are for now to avoid regressions. Signed-off-by:
-
Paulo Zanoni authored
Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by:
-
Egbert Eich authored
We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by:Egbert Eich <eich@suse.de> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Egbert Eich authored
This patch disables hotplug interrupts if an 'interrupt storm' has been detected. Noise on the interrupt line renders the hotplug interrupt useless: each hotplug event causes the devices to be rescanned which will will only increase the system load. Thus disable the hotplug interrupts and fall back to periodic device polling. v2: Fixed cleanup typo. v3: Fixed format issues, clarified a variable name, changed pr_warn() to DRM_INFO() as suggested by Jani Nikula <jani.nikula@linux.intel.com>. Signed-off-by: -
Egbert Eich authored
To disable previously enabled HPD IRQs we need to reset them and set the enabled ones individually. Signed-off-by:
-
Egbert Eich authored
When an encoder is shared on several connectors there is only one hotplug line, thus this line needs to be shared among these connectors. If HPD detect only works reliably on a subset of those connectors, we want to poll the others. Thus we need to make sure that storm detection doesn't mess up the settings for those connectors. Therefore we store the settings in the intel_connector struct and restore them from there. If nothing is set but the encoder has a hpd_pin set we assume this connector is hotplug capable. On init/reset we make sure the polled state of the connectors is (re)set to the default value, the HPD interrupts are marked enabled. Signed-off-by:
-
Egbert Eich authored
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt fires more than 5 times / sec). Rationale: Despite of the many attempts to fix the problem with noisy hotplug interrupt lines we are still seeing systems which have issues: Once cause of noise seems to be bad routing of the hotplug line on the board: cross talk from other signals seems to cause erronous hotplug interrupts. This has been documented as an erratum for the the i945GM chipset and thus hotplug support was disabled for this chipset model but others seem to have this problem, too. We have seen this issue on a G35 motherboard for example: Even different motherboards of the same model seem to behave differently: while some only see only around 10-100 interrupts/s others seem to see 5k or more. We've also observed a dependency on the selected video mode. Also on certain laptops interrupt noise seems to occur duing battery charging when the battery is at a certain charge levels. Thus we add a simple algorithm here that detects an 'interrupt storm' condition. v2: Fixed comment. v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff. v4: Followed by Jesse Barnes to use a time_..() macro. v5: Fixed coding style as suggested by Jani Nikula. Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Cc: stable@vger.kernel.org Signed-off-by:
-
Paulo Zanoni authored
We have the exact same comment inside intel_init_display. This is a leftover from when we moved a lot of code from intel_display.c to intel_pm.c. Signed-off-by:
-
Ben Widawsky authored
Caused by me with v2 of commit 219f4fdb Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Mar 15 11:17:54 2013 -0700 drm/i915: Introduce GEN7_FEATURES for device info I don't have a VLV to test it with, Jesse, Ken, can one of you test? Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Chris Wilson authored
Haswell introduces a separate frequency domain for the ring (uncore). So where we used to increase the CPU (IA) clock with GPU busyness, we now need to scale the ring frequency directly instead. As the ring limits our memory bandwidth, it is vital for performance that when the GPU is busy, we increase the frequency of the ring to increase the available memory bandwidth. v2: Fix the algorithm to actually use the scaled gpu frequency for the ring. v3: s/max_ring_freq/min_ring_freq/ as that is what it is Signed-off-by:
-
Mika Kuoppala authored
commit 647416f9 Author: Kees Cook <keescook@chromium.org> Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix is to strip out preamples on all simple attributes that have one. v2: Fix all simple attributes (Daniel Vetter) Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Daniel Vetter authored
The recent rework of the pfit handling didn't take into account that the panel fitter is fixed to pipe B: commit 24a1f16d Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe Fix this up by properly computing the pipe the pfit is on. Also extract the logic into its own function, add a debug assert to check that the pipe is off (mostly just documentation) and add some debug output. If pipe A was disabled after pipe B was set up, the panel fitter will be disabled. Now most userspace doesn't do modesets in this order, which is why I couldn't ever reproduce this and why it took me so long to figure out. We really need hw state readout and check support for the pannel fitter ... Reported-by:
Hans de Bruin <jmdebruin@xmsnet.nl> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Hans de Bruin <jmdebruin@xmsnet.nl> References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049Reviewed-by:
-
Daniel Vetter authored
Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb->depth, so this is a regression brought to light with commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 Cc: stable@vger.kernel.org References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.htmlTested-by:
Richard Cochran <richardcochran@gmail.com> Reviewed-by:
-
Jani Nikula authored
Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701Signed-off-by:
Peter Verthez <peter.verthez@skynet.be> Cc: stable@vger.kernel.org Signed-off-by:
-
Paulo Zanoni authored
This solves some "unclaimed register" messages when booting the machine with eDP attached. V2: Rebase and add the comment requested by Daniel. Signed-off-by:
-
