- 19 May, 2012 17 commits
-
-
Eugeni Dodonov authored
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>
-
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:
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
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:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Smash Paulo's locking fix onto Chris' patch.] 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:
Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-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 17 commits
-
-
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:
-
Daniel Vetter authored
Generally we call stuff with i9xx_ when it's valid for gen3+. But gen3 and early gen4 only support hdmi with sdvo cards, and writing infoframes works completely different there. v2: Use g4x instead of gm45 - it applies to the desktop variant, too. v3: Properly align the paramters of g4x_write_infoframe again, noticed by Paulo Zanoni. Acked-by:
-
Daniel Vetter authored
Simplifies things because for all the infoframes we care about, we always send them on each vblank. Also, this gets rid of one of the hw specific functions mislabelled with the intel_ prefix - hsw will completely change how this works! Acked-by:
-
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
Just like Gen 4, IBX has a "Port Select" field on the DIP register, but the ports are different. Signed-off-by:
-
Paulo Zanoni authored
IBX does not need the workaround used in cpt_write_infoframe that requires the AVI frame to be enabled while being updated. Signed-off-by:
-
Paulo Zanoni authored
The registers are on the PCH, so use the PCH name instead of the CPU name. Also, the way this function is implemented is really only for CPT and PPT. For now, both functions have the same implementations: the next patch will fix ibx_write_infoframe. Signed-off-by:
-
Paulo Zanoni authored
Signed-off-by:
-
Paulo Zanoni authored
Better safe than sorry. Currently we never change the frequency and use the same for every infoframe type, so the only way to reproduce a bug would be with the BIOS doing something. Signed-off-by:
-
Paulo Zanoni authored
That's what the VIDEO_DIP_CTL documentation says we need to do. Except when it's the AVI InfoFrame and we're ironlake_write_infoframe. Signed-off-by:
-
Paulo Zanoni authored
This will allow us to disable an infoframe without changing its frequency. Signed-off-by:
-
Paulo Zanoni authored
Should prevent bugs when changing the port. Signed-off-by:
-
Paulo Zanoni authored
Make sure we're doing the right thing, just like we do on gen5+. Signed-off-by:
-
Paulo Zanoni authored
Don't use intermediate variables, change the value of 'val' as we go through the function. The new style looks more similar to the rest of our code. IMHO, it's also easier to read and change. 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:
-
Daniel Vetter authored
Backmerge of drm-next to resolve a few ugly conflicts and to get a few fixes from 3.4-rc6 (which drm-next has already merged). Note that this merge also restricts the stencil cache lra evict policy workaround to snb (as it should) - I had to frob the code anyway because the CM0_MASK_SHIFT define died in the masked bit cleanups. We need the backmerge to get Paulo Zanoni's infoframe regression fix for gm45 - further bugfixes from him touch the same area and would needlessly conflict. Signed-Off-by:
-
- 07 May, 2012 2 commits
-
-
git://people.freedesktop.org/~danvet/drm-intelDave Airlie authored
Daniel prepared this branch with a back-merge as git was getting very confused about changes in intel_display.c
-
Daniel Vetter authored
Conflicts: drivers/gpu/drm/i915/intel_display.c Ok, this is a fun story of git totally messing things up. There /shouldn't/ be any conflict in here, because the fixes in -rc6 do only touch functions that have not been changed in -next. The offending commits in drm-next are 14415745..1fa61106 which simply move a few functions from intel_display.c to intel_pm.c. The problem seems to be that git diff gets completely confused: $ git diff 14415745..1fa61106 is a nice mess in intel_display.c, and the diff leaks into totally unrelated functions, whereas $git diff --minimal 14415745..1fa61106 is exactly what we want. Unfortunately there seems to be no way to teach similar smarts to the merge diff and conflict generation code, because with the minimal diff there really shouldn't be any conflicts. For added hilarity, every time something in that area changes the + and - lines in the diff move around like crazy, again resulting in new conflicts. So I fear this mess will stay with us for a little longer (and might result in another backmerge down the road). Signed-Off-by:
-
