Mutliple issues.  INIT_ZM_I2C_BYTE/INIT_I2C_BYTE didn't even try and
use the register value, and all the handlers were using the wrong
slave address.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It appears to be meant to reference the second "default index".
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We may not have parsed the entry yet if the i2c_index is for an i2c bus
that's not referenced by a DCB encoder.

This could be done oh so much more nicely, except we have to care about
prehistoric DCB tables too, and they make life painful.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some handlers don't report specific errors, but we still *really* want to
know if we failed to parse a complete init table.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We really want to be able to distinguish between INIT_DONE and an actual
error sometimes.  This commit fixes up several lazy "return 0;" to be
actual error codes, and explicitly reserves "0" as "success, but stop
parsing this table".
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

There appears to be some kind of switch on certain chips to control whether
the DP auxch or traditional i2c bus will be operational on a connector,
this commit hopefully fixes nouveau to do the right thing.

Likely only relevent on chips with DP outputs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

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

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

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

I actually thought these were gone already when the initial commit was
done.. I guess not!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.

v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.

v3: add config lock take inside polling, add intel/nouveau poll init/fini calls

v4: config lock was a bit agressive, only needed around connector list reading.
otherwise it could re-enter.

glisse: discard drm_helper_hpd_irq_event

v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

let vga16fb claim 0xA0000+0x10000 region as its aperture;
drm drivers don't use it, so we have to detect it and kick
vga16fb manually - but only if drm is driving the primary card
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: James Simmons <jsimmons@infradead.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.

Fix it by kicking firmware driver(s) before we start touching the hardware.
Reported-by: NDidier Spaier <didier.spaier@epsm.fr>
Tested-by: NDidier Spaier <didier.spaier@epsm.fr>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It removes a hack from nouveau code which had to detect which
region to pass to kick vesafb/efifb.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use kmemdup when some other buffer is immediately copied into the
allocated region.

A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression from,to,size,flag;
statement S;
@@

-  to = \(kmalloc\|kzalloc\)(size,flag);
+  to = kmemdup(from,size,flag);
   if (to==NULL || ...) S
-  memcpy(to, from, size);
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All TTM driver have been converted to new io_mem_reserve/free
interface which allow driver to choose and return proper io
base, offset to core TTM for ioremapping if necessary. This
patch remove what is now deadcode.

V2 adapt to match with change in first patch of the patchset
V3 update after io_mem_reserve/io_mem_free callback balancing
V4 adjust to minor cleanup
V5 remove the needs ioremap flag
V6 keep the ioremapping facility in TTM

[airlied- squashed driver removals in here also]
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This add the support for the new fault callback, does change anything
from driver point of view, thought it should allow nouveau to add
support for unmappable VRAM.

Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.

Patch hasn't been tested on any hw.

V2 don't derefence bo->mem.mm_node as it's not NULL only for
   VRAM or GTT
V3 update after io_mem_reserve/io_mem_free callback balancing
V4 callback has to ioremap
V5 ioremap is done by ttm
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When drivers embed the core gem object into their own structures,
they'll have to do this. Temporarily this results in an ugly

kfree(gem_obj);

in every gem driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There's one known case where we never stop recieving DEFER, and loop here
forever.  Lets not do that..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

And use our own version of the GPIO table for the INIT_GPIO opcode.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes garbled 3D on an nv46 card.
Reported-by: NFrancesco Marella <francesco.marella@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Allows *some* DP cards to keep working in some corner cases that most
people shouldn't hit.  I hit it all the time with development, so this
can stay for now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On DP outputs we'll likely end up running vbios init tables here, which
may sleep.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This value interacts with some registers we don't currently know how to
program properly ourselves.  The default of 5 that we were using matches
what the VBIOS on early DP cards do, but later ones use 6, which would
cause nouveau to program an incorrect mode on these chips.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

Should fix:
 https://bugzilla.redhat.com/show_bug.cgi?id=505132
 https://bugzilla.redhat.com/show_bug.cgi?id=543091
 https://bugzilla.redhat.com/show_bug.cgi?id=530425
 https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/
 +bug/539730
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

All indications seem to be that the version 0x30 table should be handled
the same way as 0x40 (as used on G80), at least for the parts that we
currently try use.

This commit cleans up the parsing to make it clearer about what we're
actually trying to achieve, and unifies the 0x30/0x40 parsing.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

As opposed to repeatedly reading the amount back from the GPU every
time we need to know the VRAM size.

We should now fail to load gracefully on detecting no VRAM, rather than
something potentially messy happening.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>