- 06 Jun, 2012 1 commit
-
-
Daniel Vetter authored
Let's be a bit more paranoid here. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 Jun, 2012 1 commit
-
-
Daniel Vetter authored
... instead of abusing mode->clock by storing it in there - we shouldn't touch that one at all. This patch is the first prep step to constify the mode argument of the intel_dp_mode_fixup function. The next patch will stop us from modifying mode->clock. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by:
-
- 31 May, 2012 2 commits
-
-
Daniel Vetter authored
Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor, but we have the identical code in ironlake_ccrtc_mode_set. And that function is huge, so extracting some code full of magic numbers is always nice. Noticed while trying to get a handle on our dp clock code. Reviewed-by:
-
Daniel Vetter authored
Already discovered in commit 5a117db7 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Thu Jan 5 09:34:29 2012 -0200 drm/i915: there is no pipe CxSR on ironlake but we've failed to rip out the code from the ironlake specific code. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
- 24 May, 2012 1 commit
-
-
Chris Wilson authored
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:
-
- 22 May, 2012 1 commit
-
-
Laurent Pinchart authored
The DRM mode config functions structure declared by drivers and pointed to by the drm_mode_config funcs field is never modified. Make it a const pointer. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Rob Clark <rob.clark@linaro.org> Reviwed-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 20 May, 2012 1 commit
-
-
Daniel Vetter authored
This should fix breakage introduced in commit ee7b9f93 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:
-
- 19 May, 2012 18 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=49712 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:
-
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
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:
Ben Widawsky <ben@bwidawsk.net> Signed-off-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
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
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
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
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:
-
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:
-
- 08 May, 2012 4 commits
-
-
Chris Wilson authored
The principle of intel_mark_busy() is that we want to spot the transition of when the display engine is being used in order to bump powersaving modes and increase display clocks. As such it is only important when the display is changing, i.e. when rendering to the scanout or other sprite/plane, and these are characterised by being pinned. v2: Mark the whole device as busy on execbuffer and pageflips as well and rebase against dinq for the minor bug fix to be immediately applicable. Signed-off-by:
-
Paulo Zanoni authored
intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake and newer, so now we use PIPEFRAME. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Ditch the check for disable pipe from the new ilk wait for vblank function to keep it consisten with existing behaviour.] Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
Gen3+ is 13 bits (12:0), and on gen2 only 12 (11:0). For both the high bits are marked reserved, read-only so continue to mask them. Bit 31 is not reserved and has a meaning. Signed-off-by:
-
- 04 May, 2012 1 commit
-
-
Daniel Vetter authored
Our handling of the crtc timing computation has been nicely cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over the place. But with commit f9bef081 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Apr 15 19:53:19 2012 +0200 drm/i915: don't clobber the special upscaling lvds timings and commit ca9bfa7e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 we now only set the crtc timing fields in the encoder->mode_fixup (lvds only) and in crtc->mode_fixup (for everyone else). And since commit 75c13993 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 23:48:46 2012 +0100 drm/i915: fixup overlay checks for interlaced modes the only places we actually need the crtc timings is in the mode_set function. I guess the idea of the drm core is that every time it creates a drm mode, it also sets the timings. But afaics it never uses them, safe for the precise vblank timestamp code (but that can only run on active modes, i.e. after our mode_fixup functions have been called). The problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the timings are pretty much bogus for us anyway (at least with interlaced support). So I guess it's the drivers job that every active modes needs to have crtc timings that suits it, and with these patches we should have that. drm core doesn't seem to care about modes that just get passed around. Hence we can now safely rip out all the remaining calls to set_crtcinfo left in the driver and clean up this confusion. Reviewed-by:
-
- 03 May, 2012 8 commits
-
-
Chris Wilson authored
Every time we use the device after a period of idleness, check that the power management setup is still sane. This is to workaround a bug whereby it seems that we begin suppressing power management interrupts, preventing SandyBridge+ from going into turbo mode. This patch does have a side-effect. It removes the mark-busy for just moving the cursor - we don't want to increase the render clock just for the sprite, though we may want to bump the display frequency. I'd argue that we do not, and certainly don't want to take the struct_mutex here due to the large latencies that introduces. References: https://bugs.freedesktop.org/show_bug.cgi?id=44006 Signed-off-by:
-
Chris Wilson authored
When initialising the PLL registers we may have to clear existing state from the BIOS - that is the PLL may already be enabled. So we need to disable it, wait for the clocks to settle and then rewrite it. The issue came to light when Ben tested commit 88ca4bb7974277793e602d88739d4e8f56b89e64 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 drm/i915: manage PCH PLLs separately from pipes and found that booting into a VGA monitor was no longer working. Closer inspection suggests that it was a pre-existing bug now being hit by the rearranged code. Perhaps Ben was not even the first person to stumble upon this bug, https://bugs.freedesktop.org/show_bug.cgi?id=37029 . Signed-off-by: -
Daniel Vetter authored
Unfortunately it looks like further vlv patches are still stalled due to fried hw, and too many people are a bit annoyed about the unused function warning. So let's just rip it out, we can easily put it back in again. Acked-by:
-
Daniel Vetter authored
This is a pretty racy way to close these races, and we have much better means to cope with these races meanwhile: For non-broken userspace we correctly wait for any outstanding rendering, for broken userspace the hangcheck will save the day. Reviewed-by:
-
Daniel Vetter authored
The LP refers to 'low priority' as opposed to the high priority ring on gen2/3. So lets constrain its use to the code of that era. Unfortunately we can't yet completely remove the associated macros from common headers and shove them into i915_dma.c to the other dri1 legacy support code, a few cleanups are still missing for that. Reviewed-by:
-
Daniel Vetter authored
Also ditch the cargo-culted dev_priv checks - either we have a giant hole in our setup code or this is useless. Plainly bogus to check for it in either case. v2: Chris Wilson noticed that I've missed one bogus dev_priv check. v3: The check in the overlay code is redundant (Chris) Reviewed-by:
-
Chris Wilson authored
Enabling the plane before we have assigned valid address means that it will access random PTE (often with conflicting memory types) and cause GPU lockups. However, enabling the plane too early appears to workaround a number of bugs in our modesetting code. Cc: Franz Melchior <melchior.franz@gmail.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=39947 References: https://bugs.freedesktop.org/show_bug.cgi?id=41091 References: https://bugs.freedesktop.org/show_bug.cgi?id=49041 Signed-off-by:
-
Jesse Barnes authored
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just treat them as part of the pipe. So split the code out and manage PCH PLLs separately, allocating them when needed or trying to re-use existing PCH PLL setups when the timings match. v2: add num_pch_pll field to dev_priv (Daniel) don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) put register offsets in pll struct (Chris) v3: Decouple enable/disable of PLLs from get/put. v4: Track temporary PLL disabling during modeset v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni) v6: Avoid mishandling allocation failure by embedding the small array of PLLs into the device struct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+) Reviewed-by:
-
- 02 May, 2012 1 commit
-
-
Chris Wilson authored
We only execute intel_decrease_pllclock for pre-PCH hardware, typically gen4 mobiles. However, in the variable declaration we did read from the non-PCH DPLL register, quite naughty and detected by SandyBridge. Reported-and-tested-by:
Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by:
-
- 18 Apr, 2012 1 commit
-
-
Chris Wilson authored
When the change to start adjusting the sync polarity of the LVDS mode was introduced in commit aa9b500d Author: Bryan Freed <bfreed@google.com> Date: Wed Jan 12 13:43:19 2011 -0800 drm/i915: Honour LVDS sync polarity from EDID we made the change in state verbose so that we could quickly spot any regressions that made have also been introduced with it. As there do not appear to have been any, remove the extra logging. v2: Remove the no longer used variables. Signed-off-by:
-
