When we setup buffer for display plane, we'll check any pending
required GPU flush and possible make interruptible wait for flush
complete. But that wait would be most possibly to fail in case of
signals received for X process, which will then fail modeset process
and put display engine in unconsistent state. The result could be
blank screen or CPU hang, and DDX driver would always turn on outputs
DPMS after whatever modeset fails or not.

So this one creates new helper for setup display plane buffer, and
when needing flush using uninterruptible wait for that.

This one should fix bug like https://bugs.freedesktop.org/show_bug.cgi?id=24009.
Also fixing mode switch stress test on Ironlake.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.

https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: NEric Anholt <eric@anholt.net>

For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.

From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.

https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: NEric Anholt <eric@anholt.net>

On some boxes the BIOS will report different child device arrays when
the system is booted with/without the dock. In such case the HDMI/DP
port can't be setup correctly.  So revert two commits
(fc816655/
6e36595a) that use the child device
parsed from VBT to setup HDMI/DP.

http://bugzilla.kernel.org/show_bug.cgi?id=14854
http://bugzilla.kernel.org/show_bug.cgi?id=14860Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSean Young <sean@mess.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit cbda12d7 (drm/i915: implement
new pm ops for i915), among other things, removed the .suspend and
.resume pointers from the struct drm_driver object in i915_drv.c,
which broke resume without KMS on my MSI Wind U100.

Fix this by reverting that part of commit cbda12d7.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: added comment explaining when .suspend/.resume matter]
Signed-off-by: NEric Anholt <eric@anholt.net>

Without this fix, some modes couldn't find appropriate clocks.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NMatthew Garrett <mjg@redhat.com>

For any given clock we can use the find_pll to get the corresponding DPLL
setting. It is unnecessary to use the find_reduce_pll callback function
to calculate the DPLL parameter for LVDS downclock in order to get the same
divider factor(P) for the normal and downclock.

In theory when the LVDS downclock is supported by LVDS panel, we should get the
same DPLL divider factor(P) for the normal clock and reduced downclock.
If we get the diferent divider factor(P) for normal clock and reduced downclock,
it means that the found downclock is incorrect and should be discarded.

So we should use find_pll callback to calculate the DPLL parameter for the
LVDS reduced downclock as for the normal clock. Then we can do the cleanup
about find_reduced_pll.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
cc: Jesse Barnes <jbarnes@virtuousgeek.org>
cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The HP comaq nx9020/Samsung SX20S laptop always report that the LID status is
closed and we can't use it reliabily for LVDS detection. So add the two boxes
into the quirk list.

http://bugzilla.kernel.org/show_bug.cgi?id=14957
http://bugzilla.kernel.org/show_bug.cgi?id=14554Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

As we removed TV hotplug, don't check its status ever.
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

* korg/drm-radeon-next:
  drm/radeon/kms: rs600: use correct mask for SW interrupt
  gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test
  drm/radeon/radeon_device.c: move a dereference below a NULL test
  drm/radeon/radeon_fence.c: move a dereference below the NULL test
  drm/radeon/radeon_connectors.c: add a NULL test before dereference
  drm/radeon/kms: fix memory leak
  drm/radeon/kms: add missing breaks in i2c and ss lookups
  drm/radeon/kms: add primary dac adj values table
  drm/radeon/kms: fallback to default connector table

The mask happens to be the same, but the IH is reading the status, not the
not the control register.
Signed-off-by: NLuca Tettamanti <kronos.it@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13338
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13335
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a NULL value is possible, the dereference should only occur after the
NULL test.

Coverity CID: 13334
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The encoder variable can be NULL in this function so I believe it should
be checked before dereference.

Coverity CID: 13253

[airlied: extremely unlikely to happen]
Signed-off-by: NDarren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Stanse found a memory leak in radeon_master_create. master_priv is not
freed/assigned on all paths. Fix that.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* drm-core-next:
  drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line()
  drm/edid: Fix CVT width/height decode
  drm/edid: Skip empty CVT codepoints
  drm: remove address mask param for drm_pci_alloc()

This always evaluates to true.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_pci_alloc() has input of address mask for setting pci dma
mask on the device, which should be properly setup by drm driver.
And leave it as a param for drm_pci_alloc() would cause confusion
or mistake would corrupt the correct dma mask setting, as seen on
intel hw which set wrong dma mask for hw status page. So remove
it from drm_pci_alloc() function.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (23 commits)
  drm/i915: remove full registers dump debug
  drm/i915: Add DP dpll limit on ironlake and use existing DPLL search function
  drm/i915: Select the correct BPC for LVDS on Ironlake
  drm/i915: Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake
  drm/i915: Enable/disable the dithering for LVDS based on VBT setting
  drm/i915: Permit pinning whilst the device is 'suspended'
  drm/i915: Hold struct mutex whilst pinning power context bo.
  drm/i915: fix unused var
  drm/i915: Storage class should be before const qualifier
  drm/i915: remove render reclock support
  drm/i915: Fix RC6 suspend/resume
  drm/i915: execbuf2 support
  drm/i915: Reload hangcheck timer too for Ironlake
  drm/i915: only enable hotplug for detected outputs
  drm/i915: Track whether cursor needs physical address in intel_device_info
  drm/i915: Implement IS_* macros using static tables
  drm/i915: Move PCI IDs into i915 driver
  drm/i915: Update LVDS connector status when receiving ACPI LID event
  drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
  drm/i915: implement new pm ops for i915
  ...

The MMU code uses the copy_*_user_page() variants in access_process_vm()
rather than copy_*_user() as the former includes an icache flush.  This
is important when doing things like setting software breakpoints with
gdb.  So switch the NOMMU code over to do the same.

This patch makes the reasonable assumption that copy_from_user_page()
won't fail - which is probably fine, as we've checked the VMA from which
we're copying is usable, and the copy is not allowed to cross VMAs.  The
one case where it might go wrong is if the VMA is a device rather than
RAM, and that device returns an error which - in which case rubbish will
be returned rather than EIO.
Signed-off-by: NJie Zhang <jie.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDavid McCullough <david_mccullough@mcafee.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NGreg Ungerer <gerg@uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When working with FDPIC, there are many shared mappings of read-only
code regions between applications (the C library, applet packages like
busybox, etc.), but the current do_mmap_pgoff() function will issue an
icache flush whenever a VMA is added to an MM instead of only doing it
when the map is initially created.

The flush can instead be done when a region is first mmapped PROT_EXEC.
Note that we may not rely on the first mapping of a region being
executable - it's possible for it to be PROT_READ only, so we have to
remember whether we've flushed the region or not, and then flush the
entire region when a bit of it is made executable.

However, this also affects the brk area.  That will no longer be
executable.  We can mprotect() it to PROT_EXEC on MPU-mode kernels, but
for NOMMU mode kernels, when it increases the brk allocation, making
sys_brk() flush the extra from the icache should suffice.  The brk area
probably isn't used by NOMMU programs since the brk area can only use up
the leavings from the stack allocation, where the stack allocation is
larger than requested.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The current code will load the stack size and protection markings, but
then only use the markings in the MMU code path.  The NOMMU code path
always passes PROT_EXEC to the mmap() call.  While this doesn't matter
to most people whilst the code is running, it will cause a pointless
icache flush when starting every FDPIC application.  Typically this
icache flush will be of a region on the order of 128KB in size, or may
be the entire icache, depending on the facilities available on the CPU.

In the case where the arch default behaviour seems to be desired
(EXSTACK_DEFAULT), we probe VM_STACK_FLAGS for VM_EXEC to determine
whether we should be setting PROT_EXEC or not.

For arches that support an MPU (Memory Protection Unit - an MMU without
the virtual mapping capability), setting PROT_EXEC or not will make an
important difference.

It should be noted that this change also affects the executability of
the brk region, since ELF-FDPIC has that share with the stack.  However,
this is probably irrelevant as NOMMU programs aren't likely to use the
brk region, preferring instead allocation via mmap().
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-2.6.33' of git://linux-nfs.org/~bfields/linux:
  sunrpc: fix peername failed on closed listener
  nfsd: make sure data is on disk before calling ->fsync
  nfsd: fix "insecure" export option

There're some warnings of "nfsd: peername failed (err 107)!"
socket error -107 means Transport endpoint is not connected.
This warning message was outputed by svc_tcp_accept() [net/sunrpc/svcsock.c],
when kernel_getpeername returns -107. This means socket might be CLOSED.

And svc_tcp_accept was called by svc_recv() [net/sunrpc/svc_xprt.c]

        if (test_bit(XPT_LISTENER, &xprt->xpt_flags)) {
        <snip>
                newxpt = xprt->xpt_ops->xpo_accept(xprt);
        <snip>

So this might happen when xprt->xpt_flags has both XPT_LISTENER and XPT_CLOSE.

Let's take a look at commit b0401d72, this commit has moved the close
processing after do recvfrom method, but this commit also introduces this
warnings, if the xpt_flags has both XPT_LISTENER and XPT_CLOSED, we should
close it, not accpet then close.
Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
Cc: J. Bruce Fields <bfields@fieldses.org>
Cc: Neil Brown <neilb@suse.de>
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

nfsd is not using vfs_fsync, so I missed it when changing the calling
convention during the 2.6.32 window.  This patch fixes it to not only
start the data writeout, but also wait for it to complete before calling
into ->fsync.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>

* 'davinci-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci:
  DaVinci: DM365: Add the device_enable for the DaVinci Keyscan
  davinci: enable ARCH_HAS_HOLES_MEMORYMODEL for DaVinci
  davinci: da8xx/omap-l1: mark RTC as a wakeup source
  davinci: cp_intc: provide set_wake function
  Davinci VPFE Capture: Take i2c adapter id through platform data

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] lpfc 8.3.7: Update Driver version to 8.3.7
  [SCSI] lpfc 8.3.7: Fix discovery failures.
  [SCSI] lpfc 8.3.7: Fix SCSI protocol related errors.
  [SCSI] lpfc 8.3.7: Fix hardware/SLI relates issues
  [SCSI] lpfc 8.3.7: Fix NPIV operation errors
  [SCSI] lpfc 8.3.7: Fix FC protocol errors
  [SCSI] stex: fix scan of nonexistent lun
  [SCSI] pmcraid: fix to avoid twice scsi_dma_unmap for a command
  [SCSI] qla2xxx: Update version number to 8.03.01-k9.
  [SCSI] qla2xxx: Added to EEH support.
  [SCSI] qla2xxx: Extend base EEH support in qla2xxx.
  [SCSI] qla2xxx: Fix for a multiqueue bug in CPU affinity mode
  [SCSI] qla2xxx: Get the link data rate explicitly during device resync.
  [SCSI] cxgb3i: Fix a login over vlan issue

This one reverts 9e3a6d15.
As reported by http://bugzilla.kernel.org/show_bug.cgi?id=14485,
this dump will cause hang problem on some machine. If something
really needs this kind of full registers dump, that could be done
within intel-gpu-tools.

Cc: Ben Gamari <bgamari.foss@gmail.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

For some clocks, the old Ironlake DPLL calculator wold give m/n/p
combinations that didn't match the spreadsheet of what HW validation
tests.  Instead, use the G4X DPLL calculator, which does a better job
at it.

So we use the intel_g4x_find_best_pll to calculate the DPLL for CRT/HDMI/LVDS
on ironlake. At the same time to consider the dpll setting for display port, we
add the display port DPLL limit on ironlake, which will directly use the
function of intel_find_pll_ironlake_dp to get the corresponding dpll setting.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Select the correct BPC for LVDS on Ironlake. If it is 18-bit LVDS panel,
the BPC will be 6. When it is 24-bit LVDS panel, the BPC will 8.
At the same time the BPC will be 8 when the output device is CRT/HDMI/DP.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Make the BPC in FDI rx/transcoder be consistent with that in pipeconf on Ironlake.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Enable/disable the dithering for LVDS based on VBT setting. On the 965/g4x
platform the dithering flag is defined in LVDS register. And on the ironlake
the dithering flag is defined in pipeconf register.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

As pinning (allocating and binding GTT memory) does not actually invoke
GPU commands, it is safe, and indeed is attempted, during resumption
from suspension:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Hugh found an error path where we were attempting to unref a bo without
holding the struct mutex:

  [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16
  ------------[ cut here ]------------
  WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e()
  Hardware name: ESPRIMO Mobile V5505
  Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device
  Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4
  Call Trace:
   [<7815298e>] warn_slowpath_common+0x59/0x6b
   [<781529b3>] warn_slowpath_null+0x13/0x18
   [<78317c1a>] ? drm_gem_object_free+0x20/0x5e
   [<78317c1a>] drm_gem_object_free+0x20/0x5e
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7829df11>] kref_put+0x38/0x45
   [<7833a5f0>] intel_init_clock_gating+0x232/0x271
   [<78317bfa>] ? drm_gem_object_free+0x0/0x5e
   [<7832c307>] i915_restore_state+0x21a/0x2b3
   [<7832379d>] i915_resume+0x3c/0xbb
   [<78174fe5>] ? trace_hardirqs_on_caller+0xfc/0x123
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<7831c78d>] drm_class_resume+0x37/0x3e
   [<78351e0a>] legacy_resume+0x1e/0x51
   [<78351ece>] device_resume+0x91/0xab
   [<7831c756>] ? drm_class_resume+0x0/0x3e
   [<78352226>] dpm_resume+0x58/0x10f
   [<783522fb>] dpm_resume_end+0x1e/0x2c
   [<78180f80>] suspend_devices_and_enter+0x61/0x84
   [<78180ff8>] enter_state+0x55/0x83
   [<7818091c>] state_store+0x94/0xaa
   [<7829d09e>] kobj_attr_store+0x1e/0x23
   [<782098e0>] sysfs_write_file+0x66/0x99
   [<781cd2f0>] vfs_write+0x8a/0x108
   [<781cd408>] sys_write+0x3c/0x63
   [<78125c10>] sysenter_do_call+0x12/0x36
  ---[ end trace a343537f29950fda ]---

It is in fact slightly more insiduous that first appears since we are
attempting to not just free the object without the lock, but are trying
to do the whole bo manipulation without holding the lock.
Reported-by: NHugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function

Partly this is because gcc isn't smart enough.  But `ll_base' does get used
uninitialised in the DRM_DEBUG() call.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>