These are FIFO methods, it doesn't matter what subchannel is being used.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There was once good reasons for wanting the drm to be able to use M2MF etc
on user channels, but they're not relevant anymore.  For the general
buffer move case, we've already lost by transferring between vram/sysmem
already so the context switching overhead is minimal in comparison.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Off-chip encoders (which we don't support yet anyway), and newer chipsets
(such as NVD9...), will need their own code for this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v2 (Emil Velikov <emil.l.velikov@gmail.com>):
- Fixed a regression on certain nv50 IGP due to not passing the correct
  target type to nv50_vm_addr()
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Tested-by: NJohannes Obermayr <johannesobermayr@gmx.de>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Statically generating the PFB register and MR values for each timing set
turns out to be insufficient.  There's at least one (so far) known piece
of information which effects MR values which is stored in the perflvl
entry on some chipsets (and in another table on later ones), which is
disconnected from the timing table entries.

After this change we will generate a timing set based on an input clock
frequency instead, and have this data stored in the performance level
data.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Roy Spliet:
- Implement according to specs
- Simplify
- Make array for mc latency registers

Martin Peres:
- squash and split all the commits from Roy
- rework following Ben Skeggs comments
- add a form of timings validation
- store the initial timings for later use

Ben Skeggs
- merge slightly modified tidy-up patch with this one
- remove perflvl-dropping logic for the moment
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

- Rename several VBIOS entries to closer match the real world
- Add the missing 0x100238 and 0x100240 register values
- Parse bit 14 of the VBIOS timing table
- "Magic value" -> tCWL, fixing some minor bugs in the process
- Also name a few more by their name rather than their number.
- Some values seem to be dependent on the memory type. Fix

Edits by Martin Peres <martin.peres@labri.fr>:
- this is a squash commit
- reworked for fixing some style issues
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

M version 2 appears to have a table with some form of memory type info
available.

NVIDIA appear to ignore the table information except for this DDR2/DDR3
case (which has the same value in 0x100714).  My guess is this is due to
some of the supported memory types not being represented in the table.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NV20/NV30 is partially educated guesswork at this point, based on any
information around about available memory types and a horribly unspeakable
amount of vbios image scouring.  I'm not entirely certain the GDDR3 define
is correct, I have not spotted a single vbios with that value yet (though
it is mentioned in some 1218-using nv4x vbios), but there are reports that
some nv3x did use it..

NV40(100914) confirmed by switching an NV49 to DDR1/DDR2 values and making
sure that the binary driver behaviour showed it had detected DDR1/DDR2
instead of GDDR3 before dying horribly.

NV40(100474) confirmed by doing much the same task as above on an NV44,
except this was *much* easier as changing the values didn't seem to have
any noticable effect on the memory controller aside from changing the
binary driver's behaviour.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Most functions were quite different between NV10/NV20 already, and they're
about to get even more so.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Also, display detected memory type in logs - though, we don't even try to
detect this yet.
Signed-off-by: NBen Skeggs <bskeggs@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>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Tested-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>

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>

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>

Known to fix some serious issues with hibernate on a couple of systems.
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 area is horrifically complicated on these chipsets, and it's likely we
will need at least a few more tweaks yet.

Oh yes, and it's completely disabled on IGPs for the moment.  From traces,
things look potentially different there yet again.  Sigh...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reporting an error is better than silently refusing to reclock.

V2: Use the same logic on nv40
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Exposes the same connector properties as the Radeon implementation, however
their behaviour isn't exactly the same.  The primary difference being that
unless both hborder/vborder have been defined by the user, the driver will
keep the aspect ratio of the overscanned area the same as the mode the
display is programmed for.

Enabled for digital outputs on GeForce 8 and up, excluding GF119.
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>

The handling of the internal pwm fan controller is similar enough between
current chipsets that it makes sense to share the logic, and bugfixes :)

No hw backends converted yet, will automatically fall-through to the
"old" per-chipset fanspeed hooks for now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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