* 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next:
  drm/nouveau: fix earlier mistake when fixing merge conflict
  drm/nvc0: fix thinko in instmem suspend/resume
  drm/nouveau: Workaround missing GPIO tables on an Apple iMac G4 NV18.
  drm/nouveau: Add TV-out quirk for an MSI nForce2 IGP.
  drm/nv50-nvc0: ramht_size is meant to be in bytes, not entries
  drm/nouveau: punt some more log messages to debug level
  drm/nouveau: remove warning about unknown tmds table revisions
  drm/nouveau: check for error when allocating/mapping dummy page
  drm/nouveau: fix race condition when under memory pressure
  drm/nv50: fix minor thinko from nvc0 changes
  drm/nouveau: Don't try DDC on the dummy I2C channel.

Looks like this got copied from the ddx wrong.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

When enabling underscan for hdmi monitors, attempt to detect
whether we are driving a TV or a monitor.  The should hopefully
prevent underscan from being enabled on monitors attached via
hdmi that do not overscan the image.  Only enable underscan
if the mode is a common hdtv mode (480p, 720p, etc.).
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

The meaning of ucMemoryType changed on recent boards, however,
ulBootUpSidePortClock should be set properly across all boards.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

We are passing a ttm type when we want to pass true/false.
Reported-by: Dr. David Alan Gilbert <linux@treblig.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Fixes the pink line that shows up with some hdmi monitors.  This
will need to be revisited when audio support is added.

Fixes:
http://bugs.freedesktop.org/show_bug.cgi?id=27452Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This seems to have gotten lost in the hyper-z merge.

Noticed by legume on IRC.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29327Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Asics that use an AGP to PCIE bridge don't have the AGP_STATUS
register so just use whatever mode the host side setup.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

"fb_helper_conn" is dereferenced before the check for NULL.  It's never
actually NULL here, so this is mostly to keep the static checkers happy.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

"agpmem" is never NULL here because it is the list cursor of a
list_for_each_entry() list.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

If the connector is eDP, it can only be DP, not TMDS.
Always set the detected sink type.  If the sink is
detected as non-DP, but there is no EDID, you can still
manually force the port on.  If the sink type is DP
and there's no DPCD, there's no way to force the monitor
on since you need both ends to train the link.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

The pins for ddc and aux are shared so you need to switch the
mode when doing ddc.  The ProcessAuxChannel table already sets
the pin mode to DP.  This should fix unreliable ddc issues
on DP ports using non-DP monitors.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

If we aren't changing the power state, no need to take
locks and schedule fences, etc.

There seem to be lock ordering issues in the CP and
fence code in some cases; see bug 29140 below.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=29140
Possibly also:
https://bugzilla.kernel.org/show_bug.cgi?id=16581Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

This allows the tables to be run in some additional cases
where the connector info isn't necessary.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

- INIT action takes the actual connector type id, not the enum id
- some evergreen cards have the ENABLE_OUTPUT/DISABLE_OUTPUT actions
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

On most newer asics, digital encoders have two links each
and they can be used independantly.  As such, treat them as
separate encoders otherwise the individual links will not
get programmed properly at modeset time.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Add options necessary bits for:
- SS on DP
- SS on LVDS
- set clocks right for DP
- deep color on hdmi (needs additional encoder and edid work as well)
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Always zero-init a structure on the stack which is returned by a
function. Otherwise you may leak random stack data from previous
function calls.

This fixes the following warning I was seeing:
  CC [M]  drivers/gpu/drm/radeon/radeon_atombios.o
drivers/gpu/drm/radeon/radeon_atombios.c: In function "radeon_atom_get_hpd_info_from_gpio":
drivers/gpu/drm/radeon/radeon_atombios.c:261: warning: "hpd.plugged_state" is used uninitialized in this function
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

GTT/VRAM overlapping test had a typo which leaded to not
detecting case when vram_end > gtt_end. This patch fix the
logic and should fix #16574
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

With the current screwed but its ABI, ioctls for the drm, Linus pointed out that we could allow userspace to specify the allocation size, but we pass it to the driver which then uses it blindly to store a struct. Now if userspace specifies the allocation size as smaller than the driver needs, the driver can possibly overwrite memory.

This patch restructures the driver ioctls so we store the structure size we are expecting, and make sure we allocate at least that size. The copy from/to userspace are still restricted to the size the user specifies, this allows ioctl structs to grow on both sides of the equation.

Up until now we didn't really use the DRM_IOCTL defines in the kernel, so this cleans them up and adds them for nouveau.

v2:
fix nouveau pushbuf arg (thanks to Ben for pointing it out)
Reported-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

non-critical issue, CVE-2010-2803

Userspace controls the amount of memory to be allocate, so it can
get the ioctl to allocate more memory than the kernel uses, and get
access to kernel stack. This can only be done for processes authenticated
to the X server for DRI access, and if the user has DRI access.

Fix is to just memset the data to 0 if the user doesn't copy into
it in the first place.
Reported-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This should fix the reported TV-out load detection false positives
(fdo bug 29455).
Reported-by: Vlado Plaga <rechner@vlado-do.de>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

The blob also thinks there's a TV connected, so hardware bug...
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fixes an infinite loop that can happen in RAMHT lookup.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This message is apparently confusing people, and is being blamed for some
modesetting issues.  Lets remove the message, and instead replace it
with an unconditional printout of the table revision.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

When VRAM is running out it's possible that the client's push buffers get
evicted to main memory.  When they're validated back in, the GPU may
be used for the copy back to VRAM, but the existing synchronisation code
only deals with inter-channel sync, not sync between PFIFO and PGRAPH on
the same channel.  This leads to PFIFO fetching from command buffers that
haven't quite been copied by PGRAPH yet.

This patch marks push buffers as so, and forces any GPU-assisted buffer
moves to be done on a different channel, which triggers the correct
synchronisation to happen before we submit them.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

nouveau starting using these APIs, the first on non-x86 hw, and this
include isn't required on anything with real amounts of vmalloc space.

this fixes a build problem on powerpc.
Signed-off-by: Dave Airlie <airlied@redhat.com>

We don't actually need this include on any platform.

built on powerpc + x86, reported on m68k.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

When we find no ROM we understand and a device-tree is present, see
if we can retreive clock info from there.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This never really got fixed in mesa, and the kernel deals with the problem
just fine, so don't got reporting things that confuse people.
Signed-off-by: Dave Airlie <airlied@redhat.com>

0 is a valid DMA address from pci_map_page(), use pci_dma_mapping_error()
instead to check for errors

[airlied: fix warning + two other places with errors.]
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

When removing of the BKL the locking around lastclose() was rearranged
and resulted in the holding of the open_count spinlock over the call
into drm_lastclose(). The drivers were not ready for this path to be
atomic - it may indeed involve long waits to release old objects and
cleanup the GPU - and so we ended up scheduling whilst atomic.

[   54.625598] BUG: scheduling while atomic: X/3546/0x00000002
[   54.625600] Modules linked in: sco bridge stp llc input_polldev rfcomm bnep l2cap crc16 sch_sfq ipv6 md_mod acpi_cpufreq mperf cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod btusb bluetooth usbhid hid zaurus cdc_ether usbnet mii cdc_wdm cdc_acm uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 snd_hda_codec_conexant arc4 pcmcia ecb snd_hda_intel joydev sdhci_pci sdhci snd_hda_codec tpm_tis firewire_ohci mmc_core e1000e uhci_hcd thinkpad_acpi nvram yenta_socket pcmcia_rsrc pcmcia_core tpm wmi sr_mod firewire_core iwlagn ehci_hcd snd_hwdep snd_pcm usbcore tpm_bios thermal led_class snd_timer iwlcore snd soundcore ac snd_page_alloc pcspkr psmouse serio_raw battery sg mac80211 evdev cfg80211 i2c_i801 iTCO_wdt iTCO_vendor_support cdrom processor crc_itu_t rfkill xfs exportfs sd_mod crc_t10dif ahci libahci libata scsi_mod [last unloaded: scsi_wait_scan]
[   54.625663] Pid: 3546, comm: X Not tainted 2.6.35-04771-g17879857 #301
[   54.625665] Call Trace:
[   54.625671]  [<ffffffff8102d599>] __schedule_bug+0x57/0x5c
[   54.625675]  [<ffffffff81384141>] schedule+0xe5/0x832
[   54.625679]  [<ffffffff81163e77>] ? put_dec+0x20/0x3c
[   54.625682]  [<ffffffff81384dd4>] schedule_timeout+0x275/0x29f
[   54.625686]  [<ffffffff810455e1>] ? process_timeout+0x0/0xb
[   54.625688]  [<ffffffff81384e17>] schedule_timeout_uninterruptible+0x19/0x1b
[   54.625691]  [<ffffffff81045893>] msleep+0x16/0x1d
[   54.625695]  [<ffffffff812a2e53>] i9xx_crtc_dpms+0x273/0x2ae
[   54.625698]  [<ffffffff812a18be>] intel_crtc_dpms+0x28/0xe7
[   54.625702]  [<ffffffff811ec0fa>] drm_helper_disable_unused_functions+0xf0/0x118
[   54.625705]  [<ffffffff811ecde3>] drm_crtc_helper_set_config+0x644/0x7c8
[   54.625708]  [<ffffffff811f12dd>] ? drm_copy_field+0x40/0x50
[   54.625711]  [<ffffffff811ebca2>] drm_fb_helper_force_kernel_mode+0x3e/0x85
[   54.625713]  [<ffffffff811ebcf2>] drm_fb_helper_restore+0x9/0x24
[   54.625717]  [<ffffffff81290a41>] i915_driver_lastclose+0x2b/0x5c
[   54.625720]  [<ffffffff811f14a7>] drm_lastclose+0x44/0x2ad
[   54.625722]  [<ffffffff811f1ed2>] drm_release+0x5c6/0x609
[   54.625726]  [<ffffffff810d1275>] fput+0x109/0x1c7
[   54.625728]  [<ffffffff810ce5e4>] filp_close+0x61/0x6b
[   54.625731]  [<ffffffff810ce680>] sys_close+0x92/0xd4
[   54.625734]  [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b

v2: The spinlock is actually superfluous as access to open_count is
entirely serialised by drm_global_mutex and so can be dropped. The
count_lock spinlock instead appears to be used to protect access to
dev->buf_alloc and dev->buf_use.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>