This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NHongliang Tao <taohl@lemote.com>
Signed-off-by: NHua Yan <yanh@lemote.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NHongliang Tao <taohl@lemote.com>
Signed-off-by: NHua Yan <yanh@lemote.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.

Remove the raw_edid field, and fix drivers as necessary.
Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EDID returned by drm_get_edid() was never freed.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EDID returned by drm_get_edid() was never freed.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We should be making this call not praying that the values are right.
In addition as noted by Josiah Standing we should be calling this
for eDP as well.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I don't know why the DP/eDP is affected by the clock gating. But the test
shows that it really fixes the DP/eDP clock issue during enabling DP/eDP.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[Updated to only apply the workaround if the device has DP. We don't want
 to do this on netbooks]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Introduce the eDP support into the driver.

This has been reworked a bit because kernel driver proper uses encoder/connectors
while the legacy Intel driver uses the old output stuff.

It also diverges on the backlight handling. The legacy Intel driver adds a panel
abstraction based upon the i915 one. It's only really used for backlight bits
and we have a perfectly good backlight abstraction which can extend instead.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[ported to upstream driver, redid backlight abstraction]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This will give the basic support only
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is mostly just aligning bits of behaviour
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based on bits from Yakui <yakui.zhao@intel.com>

We can import various little bits of code before we plumb it all
in and hopefully this way catch any regressions more easily.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Import the pieces we need in order to do DisplayPort. Don't wire them
up yet as there is work to do to integrate them.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based on the spec, the CRT output doesn't use the lane. And the HDMI B output
uses the Lane0/1 while the HDMI C output uses the Lane 2/3. But currently
it will program all the four lanes for the CRT/HDMI.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[Ported to the in-kernel driver]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently when trying to call the DPMS off again for one CRTC with DPMS off,
it will firstly disable the SR and can't enable it again because of the
incorrect check/logic. In such case the self refresh is still disabled
although one CRTC pipe is active. This is wrong.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
[Ported to in kernel driver]
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'drm-doc' of git://linuxtv.org/pinchartl/fbdev:
  Documentation: DocBook DRM framework documentation

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NRob Clark <rob.clark@linaro.org>

Daniel writes:

" First -next pull for 3.7. Highlights:
- hsw hdmi improvements (Paulo)
- ips/rps locking rework and cleanups
- rc6 on ilk by default again
- hw context&dp&dpff support for hsw (Ben)
- GET_PARAM_HAS_SEMAPHORES (Chris)
- gen6+ pipe_control improvements (Chris)
- set_cacheing ioctl and assorted support code (Chris)
- cleanups around the busy/idle/pm code (Chris&me)
- flushing_list removal, hopefully for good (Chris)
- read_reg ioctl (Ben)
- support the ns2501 dvo (Thomas Richter)
- avoid the costly gen6+ "missed IRQ" workaround where we don't need a
  race-free seqno readback (Chris)
- various bits&pieces, mostly early patches from the modeset rework branch"

* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (54 commits)
  drm/i915: don't grab dev->struct_mutex for userspace forcewak
  drm/i915: try harder to find WR PLL clock settings
  drm/i915: use the correct encoder type when comparing
  drm/i915: Lazily apply the SNB+ seqno w/a
  drm/i915: enable rc6 on ilk again
  drm/i915: fix up ilk drps/ips locking
  drm/i915: DE_PCU_EVENT irq is ilk-only
  drm/i915: kill dev_priv->mchdev_lock
  drm/i915: move all rps state into dev_priv->rps
  drm/i915: use mutex_lock_interruptible for debugfs files
  drm/i915: fixup up debugfs rps state handling
  drm/i915: properly guard ilk ips state
  drm/i915: add parentheses around PIXCLK_GATE definitions
  drm/i915: reindent Haswell register definitions
  drm/i915: completely reset the value of DDI_FUNC_CTL
  drm/i915: correctly set the DDI_FUNC_CTL bpc field
  drm/i915: set the DDI sync polarity bits
  drm/i915: fix pipe DDI mode select
  drm/i915: dump the device info
  drm/i915: fixup desired rps frequency computation
  ...

Backmerge Linux 3.6-rc2 to resolve a few funny conflicts before we put
even more madness on top:

- drivers/gpu/drm/i915/i915_irq.c: Just a spurious WARN removed in
  -fixes, that has been changed in a variable-rename in -next, too.

- drivers/gpu/drm/i915/intel_ringbuffer.c: -next remove scratch_addr
  (since all their users have been extracted in another fucntion),
  -fixes added another user for a hw workaroudn.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.

The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.
Signed-off-by: NIan Kent <raven@themaw.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull VFIO fix from Alex Williamson:
 "Just a trivial patch to include vfio.h in the installed headers so we
  can complete userspace integration into QEMU."

* tag 'vfio-for-v3.6-rc1' of git://github.com/awilliam/linux-vfio:
  vfio: Include vfio.h in installed headers

Pull fuse updates from Miklos Szeredi.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
  fuse: verify all ioctl retry iov elements
  fuse: add missing INIT flag descriptions
  fuse: add missing INIT flags
  fuse: update attributes on aio_read
  fuse: invalidate inode mapping if mtime changes
  fuse: add FUSE_AUTO_INVAL_DATA init flag

Merge tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen

Pull Xen fix from Konrad Rzeszutek Wilk:
 "Way back in v3.5 we added a mechanism to populate back pages that were
  released (they overlapped with MMIO regions), but neglected to reserve
  the proper amount of virtual space for extend_brk to work properly.

  Coincidentally some other commit aligned the _brk space to larger area
  so I didn't trigger this until it was run on a machine with more than
  2GB of MMIO space."

 * On machines with large MMIO/PCI E820 spaces we fail to boot b/c
   we failed to pre-allocate large enough virtual space for extend_brk.

* tag 'stable/for-linus-3.6-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back.

Pull SuperH fixes from Paul Mundt.

* tag 'sh-for-linus' of git://github.com/pmundt/linux-sh:
  sh: intc: Handle domain association for sparseirq pre-allocated vectors.
  sh: sh7269: Fix LCD pinmux
  sh: dma: fix request_irq usage

Moved to djbw@fb.com

Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: NDan Williams <djbw@fb.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When dumping "Code: " sections from an oops, the trapping instruction
%rip points to can be a string copy

  2b:*  f3 a5                   rep movsl %ds:(%rsi),%es:(%rdi)

and the line contain a bunch of ":".  Current "cut" selects only the and
the second field output looks funnily overlaid this:

  2b:*  f3 a5                   rep movsl %ds     <-- trapping instruction:(%rsi),%es:(%rdi

Fix this by selecting the remaining fields too.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull two slave-dmaengine fixes from Vinod Koul:
 "One fixes the correct use of clock API in imx driver and the other
  enables clock for tegra driver, which is used for other tegra driver
  conversion to dmanegine in -next."

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dma: tegra: enable/disable dma clock
  dma: imx-dma: Fix kernel crash due to missing clock conversion

Pull more drm fixes from Dave Airlie:
 "Just some intel and nouveau ones this time, intel has more edp panel
  fixes for macbooks and nouveau has a suspend/resume regression fix in
  there."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: Apply post-sync write for pipe control invalidates
  drm/i915: reorder edp disabling to fix ivb MacBook Air
  drm/nv86/fifo: suspend fix
  drm/nouveau: disable copy engine on NVAF
  nouveau: fixup scanout enable in nvc0_pm
  drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
  drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
  drm/i915: ensure i2c adapter is all set before adding it
  drm/i915: ignore eDP bpc settings from vbt
  drm/i915: Fix blank panel at reopening lid
  drm/nve0/fifo: add support for the flip completion swmthd

Pull two sparc fixes from David S. Miller.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc64: Be less verbose during vmemmap population.
  sparc64: do not clobber personality flags in sys_sparc64_personality()

* 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6:
  drm/nv86/fifo: suspend fix
  drm/nouveau: disable copy engine on NVAF
  nouveau: fixup scanout enable in nvc0_pm
  drm/nouveau/aux: mask off higher bits of auxch index in i2c table entry
  drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
  drm/nve0/fifo: add support for the flip completion swmthd

Daniel Vetter writes:

"A few important fixers:
- fix various lvds backlight issues, regressed in 3.6 (Takashi Iwai)
- make the retina mbp work (ignore bogus edp bpc value in vbt)
- fix a gmbus regression introduced in (iirc) 3.4 (Jani Nikula)
- fix an edp panel power sequence regression, fixes the new macbook air
- apply the tlb invalidate w/a

Otherwise we still have another gmbus regression (patches are awaiting
tested-bys) and there's something odd going with some rare systems not
entering rc6 often enough (and hence blowing through too much power).  It
seems to be a timing-related issue and can be mitigated by frobbing the
magic tuning parameters. We're still working on that one. Also, we still
have some fallout from the hw context support, but you can only hit that
with mesa master."

* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
  drm/i915: Apply post-sync write for pipe control invalidates
  drm/i915: reorder edp disabling to fix ivb MacBook Air
  drm/i915: ensure i2c adapter is all set before adding it
  drm/i915: ignore eDP bpc settings from vbt
  drm/i915: Fix blank panel at reopening lid

On a 2-node machine with 256GB of ram we get 512 lines of
console output, which is just too much.

This mimicks Yinghai Lu's x86 commit c2b91e2e
(x86_64/mm: check and print vmemmap allocation continuous) except that
we aren't ever going to get contiguous block pointers in between calls
so just print when the virtual address or node changes.

This decreases the output by an order of 16.

Also demote this to KERN_DEBUG.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When invalidating the TLBs it is documentated as requiring a post-sync
write. Failure to do so seems to result in a GPU hang.

Exposure to this hang on IVB seems to be a result of removing the extra
stalls required for SNB pipecontrol workarounds:

commit 6c6cf5aa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 18:02:28 2012 +0100

    drm/i915: Only apply the SNB pipe control w/a to gen6

Note: Manually switch the pipe_control cmd to 4 dwords to avoid a
(silent) functional conflict with -next. This way will get a loud (but
conflict with next (since the scratch_addr has been deleted there).

Reported-and-tested-by: yex.tian@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53322Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: added note about merge conflict with -next.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in

commit 6cb49835
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel

But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.

Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.

For reference the old bug, which hopefully doesn't get broken by this:

https://bugzilla.kernel.org/show_bug.cgi?id=43163

In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.

v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.

v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671Tested-by: NRoberto Romer <sildurin@gmail.com>
Tested-by: NDaniel Wagner <wagi@monom.org>
Tested-by: NKeith Packard <keithp@keithp.com>
Cc: stable@vger.kernel.org
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>