When converting from a drm_display_mode to drm_mode_modeinfo, print a
warning if the the timings values don't fit into the __u16 datatype.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm_display_mode type is a bitmask so it should be unsigned.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When doing a mode set with the special fb id -1, reject the mode set if
no fb is currently bound to the crtc.

Also remove the pointless list traversal to find the current crtc based
on the current crtc :)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Update our tree to match the current driver head.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We fall apart somewhat on resume because we don't invoke all the resume
methods as we should. Fix the silly error in the logic.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This lets the modesetting driver work better.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-core-next

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (57 commits)
  drm/nouveau: map first page of mmio early and determine chipset earlier
  drm/nvd0/disp: disconnect encoders before reprogramming them
  drm/nvd0/disp: move syncs/magic setup to or mode_set
  drm/nouveau/dp: account for channel coding overhead in link training
  drm/nvd0/disp: fix dcb sor link matching in supervisor handler
  drm/nvd0/disp: initial implementation of displayport
  drm/nouveau/dp: make dp dpms function common, call from sor code instead
  drm/nv50/hwsq: some nv92 fixes
  drm/nouveau/dp: move all nv50/sor-specific code out of nouveau_dp.c
  drm/nouveau/dp: make functions for executing various bios tables
  drm/nouveau/pm: fix oops if chipset has no pm support at all
  drm/nouveau/bios: rework vbios shadowing
  drm/nouveau/bios: attempt acpi rom fetch before pcirom
  drm/nvd0/disp: attempt to handle more than 2 crtcs if possible
  drm/nvc0/vram: get part count from PUNITS
  drm/nv40/pm: fix fanspeed regression
  drm/nouveau/pm: several fixes for nvc0 memory timings
  drm/nvc0/pm: restrict pll mode to clocks that can actually use it
  drm/nouveau/dp: fix bad comparison in dp_link_train_commit()
  drm/nouveau/mxm: call mxmi to determine revision before calling mxms
  ...

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

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

NVIDIA appear to do these around the same place they do the MODE_CTRL
methods, and for DP at least we need to bash some extra bits in "syncs"
to keep EVO happy.

It's a bit of a guess as to the 6/8bpc, but i have no better idea yet.
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>

GF119 will use this too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The shift from hwsq_data = 0x1400 to 0x080000 actually happened in nv94, not nv92
This fixes some reclocking issues on my newly acquired nv92
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
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>

More code to do the same thing, but will make it easier to handle various
changes that could possibly happen the the VBIOS tables.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Refactored to allow shadowing of VBIOS images longer than 64KiB, which
allows us to pass the VBIOS checksum test on certain boards.

There's also a workaround for reading the PROM VBIOS on some chipsets.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's cards out there with completely messed up PCIROM images that have
a perfectly valid signature.. Sigh!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Theoretically handles CRTC2/CRTC3, should any GF119 out there actually
have them enabled.  The room is there for the regs etc, so why not :)
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 patch fixes two small issues in timing generation as spotted on
several NVCx cards.

In addition, the header of the file is updated to also contain (some of)
the current developers of this code.
Signed-off-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes reclocking failure on some chips where we attempted to set PDAEMON
to PLL mode.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The comparison (lpre == DP_TRAIN_PRE_EMPHASIS_9_5) is always false:
lpre is initialized as (lane & 0x0c) >> 2, which is at most 3, while
DP_TRAIN_PRE_EMPHASIS_9_5 is defined as (3 << 3).
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's a HP laptop out there where the MXM version in the VBIOS doesn't
match what the ACPI implementation is expecting.  These tables will accept
0x00 to MXMS to return latest version, but *only* if MXMI has been called
first..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch fixes an oops cause by pm_trigger accessing the (uninitialised)
crtc list.
Reported-by: NRoy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: 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>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Fixes minor flickering on NVS295 when at perflvl 0.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

Goes a long way to correcting NVS295 memory reclocking issues.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

There's some "extended" GDDR3 chipsets out there with EMRS2 settings that
change the layout of MRS/EMRS1 bitmaps.. Sigh.. Still need to track down
how exactly we're supposed to handle this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NMartin Peres <martin.peres@labri.fr>

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