Init-compute-mem was the last piece missing for nv0x-nv3x card
cold-booting. This implementation is somewhat lacking but it's been
reported to work on most chipsets it was tested in. Let me know if it
breaks suspend to RAM for you.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Tested-by: NPatrice Mandin <patmandin@gmail.com>
Tested-by: NBen Skeggs <bskeggs@redhat.com>
Tested-by: NXavier Chantry <chantry.xavier@gmail.com>
Tested-by: NMarcin Kościelnicki <koriakin@0x04.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Also collect all the PFB registers in a single place and remove some
duplicated definitions.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It doesn't like variable length arrays.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A previous commit started additionally using the SOR link when trying to
match the correct output script.  However, we never fill in this field
for LVDS so we can never match a script at all.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Based on a patch from Matthew Garrett.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Acked-by: NMatthew Garrett <mjg@redhat.com>

There's a report of this quirk breaking modesetting on at least one board.
After discussion with Francisco Jerez, we've decided to remove it:

<darktama> it's not worth limiting the quirk to just where we know it can
           work?  i'm happy either way really :)
<curro> hmm, don't think so, most if not all DCB15 cards have just one DAC
<curro> and with that quirk there's no way to tell if the load comes from
        the VGA or DVI port
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Acked-by: NFrancisco Jerez <currojerez@riseup.net>

On nv50 it became impossible to attempt a PCI ROM shadow of the VBIOS,
which will break some setups.

This patch also removes the different ordering of shadow methods for
pre-nv50 chipsets.  The reason for the different ordering was paranoia,
but it should hopefully be OK to try shadowing PRAMIN first.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No need to spam the logs when they're found, they're equivalent to
INIT_DONE.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Uncertain if this is a weirdo configuration, or a BIOS bug.  If it's not
a BIOS bug, we still don't know how to make it work anyway so ignore a
"conflicting" DCB entry to prevent a display hang.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

As long as we know the length of the opcode, we're probably better off
trying to parse the remainder of an init table rather than aborting in
the middle of it.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The nv05 card in the bug report [1] doesn't have usable I2C port
register offsets (they're all filled with zeros). Ignore them and use
the defaults.

[1] http://bugs.launchpad.net/bugs/569505Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We just need to clear the SBA and ENABLE bits to reset the AGP
controller: If the AGP bridge was configured to use "fast writes",
clearing the FW bit would break the subsequent MMIO writes and
eventually end with a lockup.

Note that all the BIOSes I've seen do the same as we did (it works for
them because they don't use MMIO), OTOH the blob leaves FW untouched.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

dcb->i2c[] has DCB_MAX_NUM_I2C_ENTRIES entries.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It appears version 0x21 'U' and 'd' tables require us to take the SOR link
into account when selecting the appropriate table for a particular output.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some of the laptops with the switchable graphics, seem to not post the secondary GPU at all, and we can't find a copy of the BIOS anywhere except in the ACPI rom retrieval.

This adds support for ACPI ROM retrieval to nouveau.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

This resulted in accidently switching off the eDP panel on certain laptops
since the default state in the GPIO table was off.

Fixes rh#582621
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We totally fail at detecting un-POSTed chipsets prior to G80.  This commit
changes the pre-G80 POST detection to read the programmed horizontal total
from CRTC 0, and assume the card isn't POSTed if it's 0.

NVIDIA use some other heuristics more similar to what we do on G80, but I
wasted quite a long time trying to figure out the exact specifics of what
they do so we can try this for a bit instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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>

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>

And use our own version of the GPIO table for the INIT_GPIO opcode.
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>

The connector table index in the DCB entry for each output type is an
index into the connector table, and does *not* necessarily match up
with what was previously called "index" in the connector table entries
themselves.

Not real sure what that index is exactly, renamed to "index2" as we
still use it to prevent creating multiple TV connectors.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Not entirely identical to 0x21, the per-encoder table header lacks the
third init table pointer.  However, our current parsing of the table
should work just fine.
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>