- 02 Dec, 2015 8 commits
-
-
Ville Syrjälä authored
Currently we round the AUX clock divider down on g4x, to closest on HSW/BDW port A, and up everywhere else. We are supposed to get as close to 2MHz as we can, so round to closest seems like the best option. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Somehow we accumulated a duplicated .get_display_clock_speed() assignment for PNV in commit 34edce2f ("drm/i915: Add cdclk extraction for g33, g965gm and g4x") No real harm on having two, we just never reach the second one, so simply kill it. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
We have HAS_PCH_LPT_LP() already, so add HAS_PCH_LPT_H() and use it where appropriate. Signed-off-by:
-
Ville Syrjälä authored
CTG uses hrawclk for backlight, so calculate the max based on that instead of cdclk. Fixes: aa17cdb4 ("drm/i915: initialize backlight max from VBT") Signed-off-by:
-
Ville Syrjälä authored
Convert the MHz number coming from intel_rawclk() into Hz in i9xx_hz_to_pwm() on PNV. Otherwise we'll get something totally bogus as a result. Fixes: aa17cdb4 ("drm/i915: initialize backlight max from VBT") Signed-off-by:
-
Imre Deak authored
Per bspec, "Backlight PWM may stop in the asserted state, causing backlight to stay fully on. WA: Before disabling PWM, set CLKGATE_DIS_0 0x46530 bit 13 PWM1 Gating Dis (for PWM1) or bit 14 PWM2 Gating Dis (for PWM2). The bits can remain set without harm." (There's no workaround name for this.) This fixes some Broxton backlight issues. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jani Nikula authored
If the backlight modulation frequency can't be extracted from the registers or from VBT, use 200 Hz as the default. This may enable backlight on some machines that previously failed. Reviewed-by:
-
Jani Nikula authored
The only missing piece is the function to convert frequency to PWM register value. The PWM is based on 19.2 MHz clock, except for BXT A step, which is based on CDCLK, and which we ignore. Reviewed-by:
-
- 01 Dec, 2015 4 commits
-
-
Matt Roper authored
BXT power well support is not yet stable. Starting with patch commit 9f836f90 Author: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Date: Mon Nov 16 16:20:01 2015 +0100 drm/i915/gen9: Turn DC handling into a power well DPMS off operations may actually cause the entire system to powerdown or reboot. Disable power well support for now until Broxton gets fixes similar to what we have for SKL. Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> References: http://lists.freedesktop.org/archives/intel-gfx/2015-November/081037.htmlSigned-off-by:Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448990818-11005-1-git-send-email-matthew.d.roper@intel.comReviewed-by:
-
Ville Syrjälä authored
ironlake_crtc_compute_clock() gets called during atomic compute phase, so we must check the future pipe type instead of the current type. Signed-off-by:
-
Ville Syrjälä authored
The .get_config() hooks should not reference anything in crtc->config, everything should be based on the passed in pipe_config instead. So don't dig out the cpu_transcoder from crtc->config on ddi platfforms, and also avoid using the encoder->crtc link and instead look up the pipe via pipe_config->base.crtc. I don't think this will actually fix anything since during the initial state readout we set up the encoder->crtc link prior to calling .get_config(), and during the modeset state check the encoder->crtc ought to be correct anyway since it's that state we just programmed. But this seems the right thing to do anyway. While at it, do some house cleaning on the local variables in the .infoframe_enabled() hooks. Signed-off-by:
-
Daniel Vetter authored
Similar to commit 37ca8d4c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Oct 30 19:20:27 2015 +0200 drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB we can only enable fifo underrun reporting when using the fdi/lpt after everything is set up and after a bit of waiting. The waiting is required, enabling it right after enabling encoders will first trigger an underrun on the pch and then, 1 frame later, an underrun on the cpu. Two vblank waits after encoder enabling seems enough to curb it. And similar to Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 20 22:09:18 2015 +0200 drm/i915: Suppress spurious CPU FIFO underruns on ILK-IVB we also need to make sure cpu fifo underrun reporting is disabled when enabling the fdi rx/tx and pch transcoder&port. But somehow this is only needed when enabling, not also when disabling. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448705139-12534-1-git-send-email-daniel.vetter@ffwll.ch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91578Tested-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
- 30 Nov, 2015 4 commits
-
-
Jani Nikula authored
DSI has quite a few special cases, like DP, so add it to crtc state. This way we can get rid of a number of intel_pipe_has_type() checks for DSI. This isn't necessarily the prettiest way, but it's a step towards being aligned with what's being done with other encoders. Reviewed-by:
-
Jani Nikula authored
The hook was added to cater for DSI, but with the hooks rearranged on the DSI encoder side, this is no longer needed. It was a bit silly anyway to have two hooks called back-to-back. Reviewed-by:
-
Jani Nikula authored
For DSI, the pre_pll_enable and the pre_enable hooks are called back-to-back on all platforms that support DSI. The distinction is artificial for DSI, for which we enable the DSI PLL in the encoder hooks. Do everything in pre_enable, and remove DSI pre_pll_enable hook. Reviewed-by:
-
Namrta Salonie authored
Found by static code analysis tool. v2: Inserted block instead of goto & renamed variables (Chris) v3: Aligned code as per the opening brace (Chris) Rebased on top of nightly (Daniel) Signed-off-by:Namrta Salonie <namrta.salonie@intel.com> Signed-off-by:
Deepak S <deepak.s@intel.com> Signed-off-by:
-
- 26 Nov, 2015 7 commits
-
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Pull the BDW+ DE pipe interrupt mask frobbing into a central place, like we have for other platforms. v2: Fix the kerneldoc (Daniel) Signed-off-by:
-
Ville Syrjälä authored
ironlake_{enable,disable}_display_irq() each just call ilk_update_display_irq() so let's make them static inlines. While at it s/ironlake/ilk/ to make things shorter, and a bit more consistent with the ibx functions. Signed-off-by: -
Ville Syrjälä authored
No reason why ibx_{enable,disable}_display_interrupt() couldn't be static inlines instead of cpp macros. Signed-off-by: -
Jani Nikula authored
This reverts commit 97e5ed11 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise With the proper fix ("drm/i915: fix the SDE irq dmesg warnings properly") reliably in place, bring back the error message. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Jani Nikula authored
We had the "The master control interrupt lied (SDE)!" check and error message in place for a long time without any problems, until commit aaf5ec2e Author: Sonika Jindal <sonika.jindal@intel.com> Date: Wed Jul 8 17:07:47 2015 +0530 drm/i915: Handle HPD when it has actually occurred caused the errors to start happening. This was bisected and reported, but the error message was silenced in commit 97e5ed11 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise shooting the messenger while the debugging for why Sonika's commit triggered the errors was still in progress. It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG register even though the hotplug trigger indicates there isn't a hotplug irq to handle. The PCH doesn't seem to really ack the the interrupt to the CPU unless we touch the hotplug register. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Gerd Hoffmann authored
Commit "30c964a6 drm/i915: Detect virtual south bridge" detects and handles the southbridge emulated by vmware esx. Add the ich9 south bridge emulated by 'qemu -M q35'. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
- 24 Nov, 2015 11 commits
-
-
Jani Nikula authored
commit b04c5bd6 Author: Borun Fu <borun.fu@intel.com> Date: Sat Jul 12 10:02:27 2014 +0530 drm/i915: Power gating display wells during i915_pm_suspend moved for_each_power_domain from intel_display.c to i915_drv.h but we still have the definition around in intel_display.c, due to a merge conflict resolution gone wrong in commit 4dac3edf Merge: 48777767 e05444be Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 29 20:49:36 2014 +0200 Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Just remove the extra definition left behind. Reviewed-by:
-
Ville Syrjälä authored
On some machines the CRT connector may be fused off. The weird thing about this setup is that the ADPA register works otherwise normally, except the enable bit is hardwired to 0. No one knows of any fuse register that would tell us if this is the case, so the only thing we can do (apart from a blacklist) is to try and set the enable bit and see if it sticks. If not, we don't register the connector at all. Obviously if the bit is already set when loading the driver we can just assume it works. I've smoke tested this approach on several machines (GMCH and PCH), some with actual CRT connectors, some with shadow connectors, and obviously the machine (IVB) with the fused off connector. So far I've not seen any ill effects from this probe. The main benefit is that we can actually run igt on machines with fused off connectors, without totally upsetting the state checker. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
To get a better idea if underruns occurred during crtc disabling, let's check for them explicitly. This helps in cases where the error interrupt isn't active, or there is no underrun interrupt support at all. Signed-off-by:
-
Ville Syrjälä authored
We sometimes get a spurious CPU pipe underrun somewhere between enabling port A and enabling vdd for the panel. Observed on both ILK and IVB with port A eDP. Suppress FIFO underrun reporting around the port and vdd enable to avoid the dmesg errors. Not sure if port D eDP would suffer from the same issue, but assume that it doesn't until proven differently. Testcase: igt/kms_setmode Signed-off-by:
-
Ville Syrjälä authored
We still get spurious pipe underruns on ILK/SNB/IVB under two circumstances when dealing with PCH ports: * When the pipe has been disabled, but FDI RX/TX is still enabled * During FDI link training Both cases seem to happen at least when we do VGA+HDMI cloning from the same pipe. I don't think I've seen them when not cloning, but can't be 100% sure. Disable underrun reporting around those places to eliminate the dmesg errors. Testcase: igt/kms_setmode/basic-clone-single-crtc Signed-off-by:
-
Rodrigo Vivi authored
It is not a bad idea to disable the PSR feature on Sink when we are disabling on the Source. v2: Move dpcd write inside mutex protected area as suggested by Sonika. Cc: Sonika Jindal <sonika.jindal@intel.com> Suggested-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Whenever DMC firmware put the HW into DC State a bunch of registers including this perf counter is reset to 0. Even with PSR active and working we could still read "Performance_Counter: 0" what will misslead people to believe PSR is broken. For instance on SKL we can only see PC10 residency with screen on if PSR is working properly. However Performance_Counter was showing 0. Even if it restored properly on DC6 exit we don't want to give users the wrong impression that PSR is not working while we know for sure it is. So, it is better to remove this counter information while we don't have a better way to track PSR residency. Signed-off-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
When we introduced PSR we let LPSP masked allowing us to get PSR independently from the audio runtime PM. However in one of the attempts to get PSR enabled by default one user reported one specific case where he would miss screen updates if scrolling the firefox in a Gnome environment when i915 runtime pm was enabled. So for this specific case that (I could never create an i-g-t test case) we decided to remove the LPSP mask and let HW tracking taking care of this case. The mask got removed later by my commit 09108b90 ("drm/i915: PSR: Remove Low Power HW tracking mask.") So we started depending on audio driver again, what is bad. With previous commit "drm/i915: PSR: Let's rely more on frontbuffer tracking." we transfered the PSR exit responsability totally to SW frontbuffer tracking. So now can safelly shut off a bit the HW tracking, or at least this case that makes us to depend on other drivers. v2: Update commit message since this patch by itself doesn't solve the bugzilla entries. v3: Another attempt to improve commit message. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau damien.lespiau@intel.com Signed-off-by:
-
Rodrigo Vivi authored
The ultimate goal here is to remove the dependency we currently have on audio driver power to get PSR working. Since with audio driver runtime PM disabled the Hardware tracking believes graphics is fully active and prevent PSR Entry, or in other words continuously exit PSR. So, the idea is to transfer the PSR exit responsability from the HW tracking to the SW tracking (frontbuffer tracking), who is really mature right now. However with LPSP masked out there might be cases where we could miss exit from HW tracking since it can be relying on this, like a specific case reported at our mailing list who user reported he would miss screen updates if scrolling firefox in a Gnome environment when i915 runtimepm was enabled. So before masking out LPSP again to make us independent from the audio driver we need to make sure that all our cases are coverred from the frontbuffer tracking perspective, where the flush means invalidate and flush. Without this patch for HSW, BDW and SKL we just do the invalidate part when the flush wasn't originated by a page flip because we were trusting the HW tracking for the flip case. So let's rely more on frontbuffer tracking and do the invalidation regardless the origin as expected for all platforms. v2: Improve commit message as suggested by Paulo. v3: Another attempt to let commit message more clear. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Commit (89251b17) intended to remove this line and let only one DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated at the code. Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It was like that since I introduced this call but probably the idea was to be informative and make clear statement that we were not using the link standby. So it is better to remove this one here and let the code a bit cleaner. v2: Improve commit message as requested by Paulo. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
-
Tvrtko Ursulin authored
Commit e9f24d5f Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Oct 5 13:26:36 2015 +0100 drm/i915: Clean up associated VMAs on context destruction Added a warning based on an incorrect assumption that all VMAs in a VM will be on the inactive list at the point last reference to a context and VM is dropped. This is not true because i915_gem_object_retire__read will not put VMA on the inactive list until all activities on the object in question (in all VMs) have been retired. As a consequence, whether or not a context/VM will be destroyed with its VMAs still on the active list, can depend on completely unrelated activities using the same object from a different context or engine. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638 Testcase: igt/gem_request_retire/retire-vma-not-inactive Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448025816-25584-1-git-send-email-tvrtko.ursulin@linux.intel.comSigned-off-by:
-
- 23 Nov, 2015 6 commits
-
-
Daniel Stone authored
If we experience a refcounting failure in a power domain/well (unref'ing at least one too many times), log the name of the offending domain or well. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
-
Daniel Stone authored
Let us print human-parseable values from the power domain code; upcoming display code also wants to use it. This requires moving it out of i915_debugfs.c, as that is only conditionally compiled. v2: Move it out of the header. Signed-off-by:
-
Imre Deak authored
Now that the known DMC/DC issues are fixed, let's try again and re-enable the power well support. Signed-off-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447869230-21416-1-git-send-email-imre.deak@intel.com
-
Imre Deak authored
During suspend-to-idle we need to keep the DMC firmware active and DC6 enabled, since otherwise we won't reach deep system power states like PC9/10. The lead for this came from Nivedita who noticed that the kernel's turbostat tool didn't report any PC9/10 residency change across an 'echo freeze > /sys/power/state'. Reported-by:
Nivedita Swaminathan <nivedita.swaminathan@intel.com> Signed-off-by:
-
Daniel Vetter authored
Linux 4.4-rc2 Backmerge to get at commit 1b0e3a04 Author: Imre Deak <imre.deak@intel.com> Date: Thu Nov 5 23:04:11 2015 +0200 drm/i915/skl: disable display side power well support for now so that we can proplery re-eanble skl power wells in -next. Conflicts are just adjacent lines changed, except for intel_fbdev.c where we need to interleave the changs. Nothing nefarious. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
Signed-off-by:
-
