The drm drivers set the fb_info->pixmap fields without setting
fb_info->pixmap.addr. If this is not set the fb core will overwrite
these all fb_info->pixmap fields anyway, so there is not much point
in setting them in the first place.

[airlied: dropped nvidiafb piece - not mine]
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Creating a range property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Creating an enum property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

calc_mclk() returns zero on success and negative on failure but clk is
a u32.

v2: Martin Peres:
- clk should be an int, not a u32
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Due to a race it was possible for a fence to be destroyed while another
thread was trying to synchronise with it.  If this happened in the fallback
non-semaphore path, it lead to the following oops due to fence->channel
being NULL.

BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
*pde = a649c067
SMP
Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]

Pid: 2255, comm: gnome-shell Tainted: G           O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
Stack:
 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
Call Trace:
 [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
 [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
 [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
 [<fa964046>] validate_list+0x176/0x300 [nouveau]
 [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
 [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
 [<c0406481>] ? die+0x31/0x80
 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
 [<c0406481>] ? die+0x31/0x80
 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
 [<c0635c7b>] ? file_has_perm+0xcb/0xe0
 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
 [<c0564f56>] do_vfs_ioctl+0x86/0x5b0
 [<c0406481>] ? die+0x31/0x80
 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130
 [<c0554f30>] ? fget_light+0x30/0x340
 [<c05654ef>] sys_ioctl+0x6f/0x80
 [<c099e3a4>] syscall_call+0x7/0xb
 [<c0406481>] ? die+0x31/0x80
 [<c0406481>] ? die+0x31/0x80
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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

There's at least one known case where our shadowing code is buggy, and we
fail init.  Until we can be confident we're doing all this correctly, lets
succeed and risk crazy bios tables rather than failing for perfectly valid
configs too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported-by: NYuriy Khomchik <homyur@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Both changes in dc97b340 cause serious
regressions in the nouveau driver.

move_notify() was originally able to presume that bo->mem is the old node,
and new_mem is the new node.  The above commit moves the call to
move_notify() to after move() has been done, which means that now, sometimes,
new_mem isn't the new node at all, bo->mem is, and new_mem points at a
stale, possibly-just-been-killed-by-move node.

This is clearly not a good situation.  This patch reverts this change, and
replaces it with a cleanup in the move() failure path instead.

The second issue is that the call to move_notify() from cleanup_memtype_use()
causes the TTM ghost objects to get passed into the driver.  This is clearly
bad as the driver knows nothing about these "fake" TTM BOs, and ends up
accessing uninitialised memory.

I worked around this in nouveau's move_notify() hook by ensuring the BO
destructor was nouveau's.  I don't particularly like this solution, and
would rather TTM never pass the driver these objects.  However, I don't
clearly understand the reason why we're calling move_notify() here anyway
and am happy to work around the problem in nouveau instead of breaking the
behaviour expected by other drivers.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Newer nVidia cards with Optimus do not support/use the DSM switching functions.
Instead, it require a DSM function to be called prior to bringing a device into
D3 state. No other _DSM calls are necessary before/after enabling/disabling a
device. Switching between discrete and integrated GPU is not supported by
this Optimus _DSM call, therefore return on the switching method.
Signed-off-by: NPeter Lekensteyn <lekensteyn@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

According to the ACPI spec version 4, section 9.14.1, _DSM functions
must return a value with the first bit enabled if any DSM functions are
supported for the given UUID and revision ID. For a given function index n
to be marked supported, bit n must be enabled.
Signed-off-by: NPeter Lekensteyn <lekensteyn@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.

Tested on radeon only so far.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

"drm/ttm: callback move_notify any time bo placement change v4" failed to
avoid a NULL pointer dereference in nouveau caused by move_notify being
expected to handle that case now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Tested-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

No idea why I didn't do this initially... NVD9 HPD is now enabled.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

- moves out of nouveau_bios.c and demagics the logical state definitions
- simplifies chipset-specific driver interface
- makes most of gpio irq handling common, will use for nv4x hpd later
- api extended to allow both direct gpio access, and access using the
  logical function states
- api extended to allow for future use of gpio extender chips
- pre-nv50 was handled very badly, the main issue being that all GPIOs
  were being treated as output-only.
- fixes nvd0 so gpio changes actually stick, magic reg needs bashing
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We don't need more than the line id to determine the PWM controller, and
the GPIO interfaces are about to change somewhat.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

More work needs to be done on supporting the different memory types.

v2 (Ben Skeggs):
- fixed up conflicts from not having pausing patch first
- restructured code somewhat to fit with how all the other code works
- fixed bug where incorrect mpll_ctrl could get set sometimes
- removed stuff that's cargo-culted from the binary driver
- merged nv92+ display disable into hwsq
- fixed incorrect opcode 0x5f magic at end of ucode
Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Untested, -ENOHW.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

The DCB table provided by the VBIOS on most MXM chips has a number of
entries which either need to be disabled, or modified according to the
MXM-SIS Output Device Descriptors.

The x86 vbios code usually takes care of this for us, however, with the
large number of laptops now with switchable graphics or optimus, a lot
of the time nouveau is responsible for POSTing the card instead - leaving
some fun situations like, plugging in a monitor and having nouveau decide
3 connectors actually just got plugged in..

No MXM-SIS fetching methods implemented yet.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Another case where we parsed vbios data to some structs, then again use
that info once to construct another set of data.  Skip the intermediate
step.

This is also slightly improved in that we can now use DCB 3.x connector
table info, which will allow NV4x to gain hotplug support, and to make
quirks for SPWG LVDS panels unnecessary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.

The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it.  However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.

So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Was using nv_mask, which is bad.  Reading the reg senses the current line
states, which aren't necessarily the states we're trying to drive the
lines to.

Fixed to store SCL driver state just as we already do for SDA.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not much point parsing the vbios data into a struct which is only used once
to parse the data into another struct, go directly from vbios to
nouveau_i2c_chan.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This primary reason for this was mostly to avoid duplication of some of
this stuff by the MXM-SIS parser.  However, some other cleanups will also
follow this as a result.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

This simplifies some things, and hopefully won't come back to bite me.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Spotted while messing with overlay channels (probably as a result of
sending a similar "disable" sequence as we do for the flip channels).

The value in 0x61008c was 0x20, which one would reasonably guess is
"bit 5 == something to report about evo channel 5" - but who knows.

Spotted the binary driver getting this too, and it appears to not do
anything exciting as a result.  So, handle it the same way and avoid
an IRQ storm.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>