- 19 May, 2012 2 commits
-
-
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:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 15 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:
-
Kirill A. Shutemov authored
Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Kirill A. Shutemov authored
cc1: warning: include/drm: No such file or directory [enabled by default] It's reproducible if you build with O=/some/obj/dir and W=1. Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
This was mostly already fixed but this one change is needed to match Kirill's original submission Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Kirill A. Shutemov authored
Signed-off-by:
-
Alan Cox authored
We need this for Poulsbo Signed-off-by:
-
Alan Cox authored
Add the opregion support and bring us in line with the opregion functionality in the reference driver code. We can't share this with i915 currently because there are hardcoded assumptions about dev_priv etc in both versions. [airlied: include opregion.h fix] Signed-off-by:
-
- 06 May, 2012 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes form Peter Anvin * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver x86, relocs: Remove an unused variable asm-generic: Use __BITS_PER_LONG in statfs.h x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it
-
