- 20 May, 2012 2 commits
-
-
Paulo Zanoni authored
- 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>
-
Daniel Vetter authored
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 3c17fe4b is the first bad commit commit 3c17fe4b 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:
-
- 19 May, 2012 33 commits
-
-
Chris Wilson authored
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=49712Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Chris Wilson authored
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:
-
Daniel Vetter authored
... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2 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:
-
Daniel Vetter authored
The hw just returns garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838Reported-and-tested-by:
Vladyslav <DFEW.Entwickler@googlemail.com> Acked-by:
-
Chris Wilson authored
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 authored
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:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Chris Wilson authored
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 authored
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:
-
Eugeni Dodonov authored
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 authored
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 authored
Move intel_hdmi data structure and support functions to a shared location, to allow their usage from intel_ddi module. Reviewed-by:
-
Eugeni Dodonov authored
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 authored
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:
-
Eugeni Dodonov authored
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 authored
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:
-
Eugeni Dodonov authored
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 authored
For now, we simple reuse the Ivy Bridge routines here. Signed-off-by:
-
Eugeni Dodonov authored
Signed-off-by:
-
Eugeni Dodonov authored
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 authored
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:
-
Eugeni Dodonov authored
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:
-
Eugeni Dodonov authored
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 authored
Avoid bogus asserts and PCH PLL accesses on Lynx Point. Signed-off-by:
-
Eugeni Dodonov authored
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 authored
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 authored
This should be already configured when FDI auto-negotiation is done. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Eugeni Dodonov authored
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 authored
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:
-
Eugeni Dodonov authored
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:
-
Eugeni Dodonov authored
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:
-
Eugeni Dodonov authored
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 authored
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:
Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
-
Chris Wilson authored
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:
-
- 10 May, 2012 3 commits
-
-
Chris Wilson authored
We can take advantage that the PCH_IIR is a subordinate register to reduce one of the required IIR reads, and that we only need to clear interrupts handled to reduce the writes. And by simply tidying the code we can reduce the line count and hopefully make it more readable. v2: Split out the bugfix from the refactoring. Signed-off-by:
-
Chris Wilson authored
Currently the code re-reads PCH_IIR during the hotplug interrupt processing. Not only is this a wasted read, but introduces a potential for handling a spurious interrupt as we then may not clear all the interrupts processed (since the re-read IIR may contains more interrupts asserted than we clear using the result of the original read). Signed-off-by:
-
Daniel Vetter authored
Inspired by the recent ppgtt regression report, where switching of dmar only for the gpu seems to fix things completely, I've looked again at the semaphores+vt-d situation. Contrary to my earlier testing a few months back my system is now stable with dmar disabled for the igd, and not only when disabling dmar completely. So I'm rather hopeful that all our recent fixes for snb have changed things for code and it's time to try enabling semaphores again. We've also had issues with enabling semaphores which are not vt-d related, but I guess these are all fixed by the autoreport-disabling and lazy request fix. And there's only one way to find out whether there are still other issues ... When I've tried to apply this patch I've noticed that semaphores on gen6 have already silently been enabled in commit 2911a35b Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Apr 5 14:47:36 2012 -0700 drm/i915: use semaphores for the display plane Fix this up by only checking whether dmar is enabled on the gfx (not on the entire system). Reviewed-by:
-
- 09 May, 2012 1 commit
-
-
Daniel Vetter authored
... given that I essentially run the show already, let's make this official. Acked-by:
Dave Airlie <airlied@redhat.com> Signed-Off-by:
-
- 08 May, 2012 1 commit
-
-
Daniel Vetter authored
These two functions are actually hw-specific and only valid for gm45 thru gen7. HSW completely changes how this works, so label them accordingly. v2: s/gm45/g4x/ like for the previous patch. Acked-by:
-
