aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-05-24drm/i915: always use RPNSWREQ for turbo change requestsJesse Barnes
Media turbo requests can either use RPVSWREQ or RPNSWREQ to indicate what the interrupt handler should do. Since we only deal with the latter in our turbo code, make the media engine use that for turbo requests. Cc: stable@vger.kernel.org. Tested-by: Joe Bloggsian <joebloggsian@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: reject doubleclocked cea modes on dpDaniel Vetter
These are ultra-low-res modes used to upscale SDTV content and we don't know how to support these on dp on intel hw: - It's unclear whether we can send avi infoframes over dp ports. - And the pixel repeat setting that work for hdmi/sdvo explicitly don't work for dp. So don't bother and just reject these modes. These modes have been introduced in commit 54ac76f851a1789b047b74a8e14980f2dd1ac749 Author: Christian Schmidt <schmidt@digadd.de> Date: Mon Dec 19 14:53:16 2011 +0000 drm/edid: support CEA video modes. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Tested-by: Yuang Guang <guang.a.yang@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: Adding TV Out Missing modes.Rodrigo Vivi
These 2 modes were removed by mistake during a clean up. So, now it is time to add them back. For further info about supported mode and standard timing table please check: VOL_3_display_registers_updated.pdf at intellinuxgraphics.org. Note that this regression has been introduce in commit 55a6713b3f30a5024056027e9dbf03ac8f13bfc9 Author: Rodrigo Vivi <rodrigo.vivi@gmail.com> Date: Thu Dec 15 14:47:33 2011 -0200 drm/i915: Removing TV Out modes. and this commit partially reverts it by re-adding the wrongly removed modes. Reported-by: Robert Lowery <rglowery@exemail.com.au> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Pimped commit message to cite the commit that introduced this regression.] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: wait for a vblank to pass after tv detectDaniel Vetter
Otherwise the hw will get confused and result in a black screen. This regression has been most likely introduce in commit 974b93315b2213b74a42a87e8a9d4fc8c0dbe90c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 5 00:44:20 2010 +0100 drm/i915/tv: Poll for DAC state change That commit replace the first msleep(20) with a busy-loop, but failed to keep the 2nd msleep around. Later on we've replaced all these msleep(20) by proper vblanks. For reference also see the commit in xf86-video-intel: commit 1142be53eb8d2ee8a9b60ace5d49f0ba27332275 Author: Jesse Barnes <jbarnes@hobbes.lan> Date: Mon Jun 9 08:52:59 2008 -0700 Fix TV programming: add vblank wait after TV_CTL writes Fxies FDO bug #14000; we need to wait for vblank after writing TV_CTL or following "DPMS on" calls may not actually enable the output. v2: As suggested by Chris Wilson, add a small comment to ensure that no one accidentally removes this vblank wait again - there really seems to be no sane explanation for why we need it, but it is required. Launchpad: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688 Reported-and-Tested-by: Robert Lowery <rglowery@exemail.com.au> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: no lvds quirk for HP t5740e Thin ClientJan-Benedict Glaw
This box has DisplayPort and VGA, but no LVDS. Product specs are at http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/12454-12454-321959-338927-3640406-4282707.html?dnr=1 and dmidecode output can be found at http://www.getslash.de/bug_attachments/dmidecode-t5740e.txt Signed-off-by: Jan-Benedict Glaw <jbglaw@getslash.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: enable vdd when switching off the eDP panelDaniel Vetter
We have one bug report from a validation team that we get the eDP panel sequencing still somewhat wrong: We need to enable VDD while switching off the panel and backlight. Unfortunately that reporter seems to have fallen off the earth :( For another reporter this actually fixes a black panel issue because without this the backlight/panel gets confused and doesn't light up again. v2: I've forgotten to remove the vdd_off call in panel_off which is now bogus. This essentially reverts commit 17038de5f16569a25343cf68668f3b657eafb00e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 16 22:43:42 2012 +0100 drm/i915/dp: Flush any outstanding work to turn the VDD off v3: the current panel_off code forces off the vdd power, too. Which is bogus and resulted in some funny warnings later on when we've tried to do aux channel communications with just the vdd forced on. Fix this, too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163 Tested-by: Vincent Frentzel <zcecc22@gmail.com> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: Fix PCH PLL assertions to not assume CRTC:PLL relationshipChris Wilson
The existing assertions were written under the assumption that we wanted to test the related PLL to a CRTC. With the split of PLL into a separately managed entity which may be shared amongst CRTCs, we need to pass in both the CRTC and the PLL to the assertion routine. Occassionally, this means passing NULL for the CRTC as we wish to check the status of the PLL irrespective of the current CRTC. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: Always update RPS interrupts thresholds along with frequencyChris Wilson
In order to avoid missed down-interrupts when coming out of RC6, it is advised that we always reset the down-threshold upon a PM event. This is due to that the PM unit goes through a little dance when coming out of RC6, it first brings the GPU up at the lowest frequency then a short time later it restores the thresholds. During that interval, the down-interval may expire and the interrupt be suppressed. Now aware of the dance taking place within the GPU when coming out of RC6, one wonders what other writes need to be queued in the fifo buffer in order to be properly sequenced; setting the RP state appears to be one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44006 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-24drm/i915: properly handle interlaced bit for sdvo dtd conversionDaniel Vetter
We've simply ignored this, which isn't too great. With this, interlaced 1080i works on my HDMI screen connected through sdvo. For no apparent reason anything else still doesn't work as it should. While at it, give these magic numbers in the dtd proper names and add a comment that they match with EDID detailed timings. v2: Actually use the right bit for interlaced. Tested-by: Peter Ross <pross@xvid.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-22drm/i915: fix module unload since error_state reworkDaniel Vetter
We need to remove the debugfs file. Regression introduce in commit d54423037f141518950f324af88a551a82449496 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 27 15:17:40 2012 +0200 drm/i915: allow the existing error_state to be destroyed Reported-and-Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-21drm/i915: be more careful when returning -ENXIO in gmbus transferDaniel Vetter
... flaky ddc hardware can cause a spurious NAK, resulting in the i2c core and drm edid functions not trying to retry the edid transfer. Luckily the gmbus quiescenting also times out for these cases, so we can get out of this mess by returning -ETIMEDOUT for this specific case. This way we keep the fast-fail of returning -ENXIO if there is no device present, speeding up the boot process. This regression has been introduced in commit e646d5773572bf52017983d758bdf05777dc5600 Author: Daniel Kurtz <djkurtz@chromium.org> Date: Fri Mar 30 19:46:38 2012 +0800 drm/i915/intel_i2c: always wait for IDLE before clearing NAK v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs, suggested by Daniel Kurtz. Cc: Daniel Kurtz <djkurtz@chromium.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518 Reported-and-Tested-by: Julian Simioni <julian.simioni@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-21Merge tag 'drm-intel-next-2012-05-20' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel wrote: The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly bugfixes: - last few patches for basic hsw enabling (Eugeni, infoframe support by Paulo) - Fix up infoframe support, we've hopefully squashed all the cargo-culting in there (Paulo). Among all the issues, this finally fixes some of the infoframe regressions seen on g4x and snb systems. - Fixup sdvo infoframe support, this fixes a regression from 2.6.37. - Correctly enable semaphores on snb, we've enabled it already for 3.5, but the dmar check was slightly wrong. - gen6 irq fixlets from Chris. - disable gmbus on i830, the hw seems to be simply broken. - fix up the pch pll fallout (Chris & me). - for_each_ring macro from Chris - I've figured I'll merge this now to avoid backport pain. - complain when the rps state isn't what we expect (Chris). Note that this is shockingly easy to hit and hence pretty much will cause a regression report. But it only tells us that the gpu turbo state got out of whack, a problem we know off since a long time (it cause the gpu to get stuck a a fixed frequency, usually the lowest one). Chris is working on a fix, but we haven't yet found a magic formula that works perfectly (only patches that massively reduce the frequency of this happening). - MAINTAINERS patch, I'm now officially the guy to beat up." * tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits) drm/i915: IBX has a fixed pch pll to pch pipe mapping drm/i915: implement hsw_write_infoframe drm/i915: small hdmi coding style cleanups drm/i915: fixup infoframe support for sdvo drm/i915: Enable the PCH PLL for all generations after link training drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN drm/i915: don't clobber the pipe param in sanitize_modesetting drm/i915: disable gmbus on i830 drm/i915: Replace the feature tests for BLT/BSD with ring init checks drm/i915: Check whether the ring is initialised prior to dispatch drm/i915: Introduce for_each_ring() macro drm/i915: Assert that the transcoder is indeed off before modifying it drm/i915: hook Haswell devices in place drm/i915: prepare HDMI link for Haswell drm/i915: move HDMI structs to shared location drm/i915: add WR PLL programming table drm/i915: add support for DDI-controlled digital outputs drm/i915: detect digital outputs on Haswell drm/i915: program iCLKIP on Lynx Point drm/i915: program WM_LINETIME on Haswell ...
2012-05-20drm/i915: IBX has a fixed pch pll to pch pipe mappingDaniel Vetter
This should fix breakage introduced in commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 drm/i915: manage PCH PLLs separately from pipes v2: Add a DRM_DEBUG_KMS message to explain why a given pll was selected, suggested by Chris Wilson. v3: Actually run git add. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712 Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20drm/i915: implement hsw_write_infoframePaulo Zanoni
Both the control and data registers are completely different now. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20drm/i915: small hdmi coding style cleanupsPaulo Zanoni
- Changed the coding style of auxiliary infoframe functions to make them smaller - Fixed the column alignment of some function definitions - Remove definition of "struct drm_crtc" in some places as they're used only to retrieve "struct intel_crtc" Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20drm/i915: fixup infoframe support for sdvoDaniel Vetter
At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647 Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-20drm/kms: fix Kconfig for new drivers.Dave Airlie
Reported-by: Jiri Slaby <jslaby@suse.cz> Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-19drm/i915: Enable the PCH PLL for all generations after link trainingChris Wilson
Hidden away within one chipset specific path was the necessary logic to turn on the PLL. This needs to be done everywhere in order for us to drive any display! As such as soon as we tested on a non-CougarPoint chipset, we failed to bring up any DisplayPorts and generated a nice set of assertion failures in the process. At least one part of our logic is working, the part that assumes that we have no idea what we are doing. Reported-by: guang.a.yang@intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=49712 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: Convert BUG_ON(!pll->active) and friends to a WARNChris Wilson
Turn a fatal lockup into a merely blank display with lots of shouty messages. v2: Whilst in the area, convert the other BUG_ON into less fatal errors. In particular, note that we may be called on a PCH platform not using PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: don't clobber the pipe param in sanitize_modesettingDaniel Vetter
... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 22 15:00:50 2012 +0000 drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: stable@kernel.org (the regression was Cc: stable, too) Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: disable gmbus on i830Daniel Vetter
The hw just returns garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838 Reported-and-tested-by: Vladyslav <DFEW.Entwickler@googlemail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: Replace the feature tests for BLT/BSD with ring init checksChris Wilson
When userspace asks whether the driver supports the BLT or BSD rings for this chip, simply report whether those particular rings are initialised v2: Use intel_ring_initialized() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: Check whether the ring is initialised prior to dispatchChris Wilson
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check whether the ring we are about to dispatch the execbuffer on is initialised. v2: Use intel_ring_initialized() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: Introduce for_each_ring() macroChris Wilson
In many places we wish to iterate over the rings associated with the GPU, so refactor them to use a common macro. Along the way, there are a few code removals that should be side-effect free and some rearrangement which should only have a cosmetic impact, such as error-state. Note that this slightly changes the semantics in the hangcheck code: We now always cycle through all enabled rings instead of short-circuiting the logic. v2: Pull in a couple of suggestions from Ben and Daniel for intel_ring_initialized() and not removing the warning (just moving them to a new home, closer to the error). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added note to commit message about the small behaviour change, suggested by Ben Widawsky.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: Assert that the transcoder is indeed off before modifying itChris Wilson
Inspired by a recent regression that seems to confuse pch transcoder state, let's be a bit more paranoid. References: https://bugs.freedesktop.org/show_bug.cgi?id=49712 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Pimped commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: hook Haswell devices in placeEugeni Dodonov
This patch enables i915 driver to handle Haswell devices. It should go in last, when things are working stable enough. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: prepare HDMI link for HaswellEugeni Dodonov
On Haswell, we need to properly train the DDI buffers prior to enabling HDMI, and enable the required clocks with correct dividers for the desired frequency. Also, we cannot simple reuse HDMI routines from previous generations of GPU, as most of HDMI-specific stuff is being done via the DDI port programming instead of HDMI-specific registers. This commit take advantage of the WR PLL clock table which is in a separate (previous) commit to select the right divisors for each mode. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: move HDMI structs to shared locationEugeni Dodonov
Move intel_hdmi data structure and support functions to a shared location, to allow their usage from intel_ddi module. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: add WR PLL programming tableEugeni Dodonov
This table is used for programming WR PLL clocks, used by HDMI and DVI outputs. I split it into a separate patch to simplify the HDMI enabling patch which was getting huge. Note that this table is a temporary solution for WR PLL programming. It will be reworked into a more exact algorithm at a later stage. But for now, it provides the most accurate clock setting solution, so we use it here. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: add support for DDI-controlled digital outputsEugeni Dodonov
Those are driven by DDIs on Haswell architecture, so we need to keep track of which DDI is being used on each output. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: detect digital outputs on HaswellEugeni Dodonov
Digital port detection on Haswell is indicated by the presence of a bit in DDI_BUF_CTL for port A, and by a different register for ports B, C and D. So we check for those bits during the initialization time and let the hdmi function know about those. Note that this bit does not indicates whether the output is DP or HDMI. However, the DDI buffers can be programmed in a way that is shared between DP/HDMI and FDI/HDMI except for PORT E. So for now, we detect those digital outputs as being HDMI, but proper DP support is still pending. Note that DDI A can only drive eDP, so we do not handle it here for hdmi initialization. v2: simplify Haswell handling logic v3: use generic function for handling digital outputs. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: program iCLKIP on Lynx PointEugeni Dodonov
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order to do so, it must be programmed to properly do the clock ticks according to the divisor, phase direction, phase increments and a special auxiliary divisor for 20MHz clock. v2: calculate divisor values directly instead of relying on a table. v3: merged a fix from Ben to properly check for invalid divider values. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: program WM_LINETIME on HaswellEugeni Dodonov
The line time can be programmed according to the number of horizontal pixels vs effective pixel rate ratio. v2: improve comment as per Chris Wilson suggestion v3: incorporate latest changes in specs. v4: move into wm update routine, also mention that the same routine can program IPS watermarks. We do not have their enablement code yet, nor handle the required clock settings at the moment, so this patch won't program those values for now. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: define Haswell watermarks and clock gatingEugeni Dodonov
For now, we simple reuse the Ivy Bridge routines here. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: use ironlake eld write routine for HaswellEugeni Dodonov
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: support DDI training in FDI modeEugeni Dodonov
Starting with Haswell, DDI ports can work in FDI mode to support connectivity with the outputs located on the PCH. This commit adds support for such connections in the intel_ddi module, and provides Haswell-specific functionality to make it work. v2: simplify the commit as per Daniel Vetter suggestion. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: initialize DDI buffer translationsEugeni Dodonov
DDI is introduced starting with Haswell GPU generation. So to simplify its management in the future, we also add intel_ddi.c to hold all the DDI-related items. Buffer translations for DDI links must be initialized prior to enablement. For FDI and DP, first 9 pairs of values are used to select the connection parameters. HDMI uses the last pair of values and ignores the first 9 pairs. So we program HDMI values in both cases, which allows HDMI to work over both FDI and DP-friendly buffers. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: account for only one PCH receiver on HaswellEugeni Dodonov
On Haswell, only one pipe can work in FDI mode, so this patch prevents messing with wrong registers when FDI is being used by non-first pipe. And to prevent this, we also specify that the VGA can only be used on pipe 0 for now in the crtc_mask value. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: handle DDI-related assertionsEugeni Dodonov
Prevent bogus asserts on DDI-related paths. Longer explanation from Eugeni by mail: "For the asserts there are 3 paths where we hit them: - in assert_fdi_tx (we don't have the FDI_TX_CTL anymore, backup plan DDI_FUNC_CTL is used instead) - in assert_fdi_tx_pll_enabled (we have the combination of iCLKIP and DDI_FUNC_CTL, plus PORT_CLK_SEL and PIPE_CLK_SEL now to make things work). We could use an assert here indeed - if we configure port to use one clock, and pipe to use another, everything hangs. Right now, we configure all of them in one place only; but yes, when DP code lands it will get more funky. - and in ironlake_fdi_pll_enable. I reuse part of this function (to configure the TU sizes), but as in the 1st case, FDI_TX_CTL is gone so I just ignore it here." Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: Pasted Eugeni's explanation into the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: add LPT PCH checksEugeni Dodonov
Avoid bogus asserts and PCH PLL accesses on Lynx Point. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: enable power wells on Haswell initEugeni Dodonov
This attempts to enable all the available power wells during the initialization. Those power wells can be enabled in parallel or on-demand, and disabled when no longer needed, but this is out of scope of this initial enablement. Proper tracking of who uses which power well will require a considerable rework of our display handling, so we just leave them all enabled when the driver is loaded for now. v2: use more generic and future-proof code Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: detect PCH encoders on HaswellEugeni Dodonov
On Haswell, the recommended PCH-connected output is the one driven by DDI E in FDI mode, used for VGA connection. All the others are handled by the CPU. Note that this does not accounts for Haswell/PPT combination yet, so if we encounter such combination an error message is thrown to indicate that things could go wrong. v2: improve non-LPT detection warning per Daniel Vetter's suggestion. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: do not use fdi_normal_train on HaswellEugeni Dodonov
This should be already configured when FDI auto-negotiation is done. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: show unknown sdvox registers on hdmi initEugeni Dodonov
This will throw a BUG() message when an unknown sdvox register is given to intel_hdmi_init. When this happens, things could going to be pretty much broken afterwards, so we better detect this as soon as possible. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: properly check for pipe countEugeni Dodonov
As suggested by Chris Wilson and Daniel Vetter, this chunk of code can be simplified with a more simple check. Also, as noticed by Jesse Barnes, it is worth mentioning that plane is an enum and num_pipe is an int, so we could be more paranoid here about those validation checks eventually. CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: calculate watermarks for devices that have 3 pipesEugeni Dodonov
This adds proper support for calculating those watermarks, checking for number of available pipes instead of specific GPU variants when deciding if watermarks for 3rd pipe are necessary. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: add support for SBI opsEugeni Dodonov
With Lynx Point, we need to use SBI to communicate with the display clock control. This commit adds helper functions to access the registers via SBI. v2: de-inline the function and address changes in bits names v3: protect operations with dpio_lock, increase timeout to 100 for paranoia sake. v4: decrease paranoia a bit, as noticed by Chris Wilson Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: reuse Ivy Bridge interrupts code for HaswellEugeni Dodonov
Haswell interrupts are mostly similar with Ivy Bridge, so we share same routines with it. This patch also simplifies the vblank counter handling for all the Gen5+ architectures. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: add new Haswell DIP controls registersEugeni Dodonov
Haswell has different DIP control registers and offsets which we need to use for infoframes, which this patch adds. Note that this does not adds full DIP frames support, but only the basic functionality necessary for HDMI to work in early enablement. v2: replace infoframe handling with a debug message, proper support will be added via a patch from Paulo Zanoni later. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-19drm/i915: gen6_enable_rps() wants to be called after ring initialisationChris Wilson
Currently we call gen6_enable_rps() (which writes into the per-ring register mmio space) from intel_modeset_init_hw() which is called before we initialise the rings. If we defer intel_modeset_init_hw() until afterwards (in the intel_modeset_gem_init() phase) all is well. v2: Rectify ordering of gem vs display HW init upon resume. (Daniel) v3: Fix up locking. (Paulo) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Smash Paulo's locking fix onto Chris' patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 18:15:48 +0000