- 19 May, 2012 11 commits
-
-
Eugeni Dodonov authored
Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-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:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Smash Paulo's locking fix onto Chris' patch.] 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:Ben Widawsky <ben@bwidawsk.net> 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 14 commits
-
-
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:
-
Eugeni Dodonov authored
This adds intel_pm routine for generic power-related infrastructure initialization. v2: now that all the platform-specific stuff is initialized in one place, we can also add back the static definitions to platform-specific functions which we abstract now. Acked-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
Eugeni Dodonov authored
This moves the clock gating-related functions into intel_pm module. Also, please note that we do change the function type from static to non-static in this patch for the move, to prevent breaking bisecting with non-working intermediate commit. Those are returned back to static form in the following patch which setups a generic PM initialization function, which was split into a different one to simplify review. v2: rebase on top of latest drm-intel-next-queued to incorporate all the changes that went there meanwhile. Acked-by:
-
Eugeni Dodonov authored
This moves the Ironlake energy monitoring functionality into intel_pm module. Acked-by:
-
Eugeni Dodonov authored
This moves DRPS, RPS and RC6-related functionality into intel_pm module. It also removes the linux/cpufreq.h include from intel_display, as its only user was the GPU turbo-related functionality in Gen6+ code path. v2: rebase on top of latest drm-intel-next-queued adding the bits that shifted around since the last patch. Acked-by:
-
Eugeni Dodonov authored
Move watermarks and helper functions (such as cxsr and fifo buffers) into intel_pm module. Signed-off-by:
-
Eugeni Dodonov authored
This commit moves Frame Buffer Compression-related operations and support functions into the new intel_pm module. Signed-off-by:
-
Chris Wilson authored
We never succeeded in getting pipelined fencing to work (unresolved spurious GPU hangs), so begin the process of dismantling and removal the broken code. Step 1 is the removal of the pipeline parameter to get_fence(). Signed-off-by:
-
Chris Wilson authored
During modeset we have to disable the pipe to reconfigure its timings and maybe its size. Userspace may have queued up command buffers that depend upon the pipe running in a certain configuration and so the commands may become confused across the modeset. At the moment, we use a less than satisfactory kick-scanline-waits should the GPU hang during the modeset. It should be more reliable to wait for the pending operations to complete first, even though we still have a window for userspace to submit a broken command buffer during the modeset. Signed-off-by:
-
Chris Wilson authored
As we need to manipulate our device structure and allocate queue a task, it is no longer a simple atomic operation and cannot be performed along the atomic modeset paths. Instead make sure that we disable FBC (which must be therefore kept as a set of simple register writes) when performing the atomic modeset and leave the heavy-weight intel_update_fbc() for the normal modeset. Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
-
Ben Widawsky authored
This originally started as a patch from Bernard as a way of simply setting the VS scheduler. After submitting the RFC patch, we decided to also modify the DS scheduler. To be most explicit, I've made the patch explicitly set all scheduler modes, and included the defines for other modes (in case someone feels frisky later). The rest of the story gets a bit weird. The first version of the patch showed an almost unbelievable performance improvement. Since rebasing my branch it appears the performance improvement has gone, unfortunately. But setting these bits seem to be the right thing to do given that the docs describe corruption that can occur with the default settings. In summary, I am seeing no more perf improvements (or regressions) in my limited testing, but we believe this should be set to prevent rendering corruption, therefore cc stable. v1: Clear bit 4 also (Ken + Eugeni) Do a full clear + set of the bits we want (Me). Cc: Bernard Kilarski <bernard.r.kilarski@intel.com> Cc: stable <stable@vger.kernel.org> Reviewed-by (RFC): Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Ben Widawsky authored
This should contain all the changes which require no thought to make sparse happy. Signed-off-by:
-
Chris Wilson authored
Not only do the pageflip work without it at non-native modes (i.e. with the panel fitter enabled), it also causes normal (non-pageflipped) modesets to fail. Reported-by:
Adam Jackson <ajax@redhat.com> Tested-by:
-
- 17 Apr, 2012 1 commit
-
-
Armin Reese authored
The purpose of this patch is to avoid zeroing the lower 12 reserved bits of surface base address registers (framebuffer & sprite). There are bits in that range that may occasionally be set by BIOS or by other components. Signed-off-by:
Armin Reese <armin.c.reese@intel.com> Reviewed-by:
-
