Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We need to ensure that writes through the GTT land before any
modification to the MMIO registers and so must impose a mandatory write
barrier when flushing the GTT domain. This was revealed by relaxing the
write ordering by experimentally mapping the registers and the GATT as
write-combining.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As has_gem is unconditionally set to true, the conditional immediately
following that assignment is superfluous.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

These functions need to be reworked for Ironlake and above, but until
then at least avoid reading non-existent registers.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: combine with a gratuitous tidy]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When bringing up new hardware, or otherwise experimenting, GPU hangs are
a way of life. However, the automatic GPU reset can do more harm than
good under these circumstances, as we may wish to capture a full trace for
debugging.

Based on a patch by Zhenyu Wang.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On Ironlake, the LP0 latency is hardcoded and in ns unit, while on
Sandybridge, it comes from a register and with unit 0.1 us. So, fix
the wrong latency value while computing wm0 on Ironlake and Sandybridge.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch actually makes the watermark code even uglier (if that's
possible), but has the advantage of sharing code between SNB and ILK at
least.  Longer term we should refactor the watermark stuff into its own
file and clean it up now that we know how it's supposed to work.

Supporting WM2 on my Vaio reduced power consumption by around 0.5W, so
this patch is definitely worthwhile (though it also needs lots of test
coverage).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: pass the watermark structs arounds]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On i830 if the tail pointer is set to within 2 cachelines of the end of
the buffer, the chip may hang. So instead if the tail were to land in
that location, we pad the end of the buffer with NOPs, and start again
at the beginning.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There should be no difference, but we can eliminate redundant code.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In some configuration, the PCU may allow us to overclock the GPU.
Check for this case and adjust the max frequency as appropriate.  Also
initialize the min/max frequencies to default values as indicated by
hardware.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and just any combination of bits & ~PFIT_ENABLE. This way we do not
attempt disable to the panel fitter controller uselessly upon
intel_lvds_disable().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

By tracking the current status of the backlight we can prevent recording
the value of the current backlight when we have disabled it. And so
prevent restoring it to 'off' after an unbalanced sequence of
intel_lvds_disable/enable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Alex Fiestas reported an issue with his HDMI connector being misdetected
as DVI unless he had something connected upon boot. By moving the
decision as to whether to use HDMI or DVI encoding for the HDMI capable
output until we probe the monitor means that we should avoid sending a
HDMI signal to a DVI monitor and also correctly detect hardware like
Alex's.

However, to really determine what connector is soldered onto the wire we
need to inspect the VBT sdvo child devices - but can we trust it?
Reported-by: NAlex Fiestas <alex@eyeos.org>
Tested-by: NAlex Fiestas <alex@eyeos.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Some voltage swing/pre-emphasis level use the same value on eDP
Sandybridge, like 400mv_0db and 600mv_0db are with the same value
of (0x0 << 22). So, fix them, and point out the value if it isn't
a supported voltage swing/pre-emphasis level.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated
regardless of the type of monitor attached.

The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is received. Obviously this
approach does not work with DVI-I where the analog and digital outputs
share a common DDC bus.

In a similar manner to the shared DDC wire, ala the "Mac Mini Hack", we
need an additional check to make sure that there really is an analog
device attached to the DDC.
Signed-off-by: NDavid Müller <d.mueller@elsoft.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

When trying to do channel equalization, we need to make sure we still
have clock recovery on all lanes while training.  We also need to try
clock recovery again if we lose the clock or if channel eq fails 5
times.  We'll try clock recovery up to 5 more times before giving up
entirely.

Gets suspend/resume working on my Vaio again and brings us back into
compliance with the DP training sequence spec.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We were using a stale pointer in the check which caused us to use CPU
attached DP params when we should have been using PCH attached params.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988Tested-by: NJan-Hendrik Zab <jan@jhz.name>
Tested-by: NChristoph Lukas <christoph.lukas@gmx.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Lots of HDMI TVs overscan the incoming image by default.
The underscan option was added as a way to compensate for
that by underscanning the image so that the edges would
not be cut off on an overscanning TV.  However, the TV
provides no way of knowing whether it is overscanning or
not.  If the user has disabled overscan on their TV or has a
TV that does not overscan, you will get black bars around the
edges of your screen.  Prior to the patch we got complaints
and bug reports from users with overscanning TVs, now with
the patch, we get lots of complaints and bug reports from
users with non-overscanning TVs.  There's no good default,
but on average there have been more users complaining about
it being on by default than off, so change it to off.  This
will probably result in a new deluge of overscanning TV user
complaints.  There's no winning.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This avoids some issues in the current hdmi audio code for monitors
without audio.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... or else we may end up disabling the wrong framebuffer, leading to an
OOPS, e.g:

[ 6033.229012] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:3271!
[ 6033.229012] invalid opcode: 0000 [#1] SMP
[ 6033.229012] last sysfs file:
/sys/devices/virtual/backlight/acpi_video0/uevent
[ 6033.229012] Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq
mperf snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep snd_seq
snd_seq_device snd_pcm snd_timer thinkpad_acpi ppdev snd r852 sm_common
iTCO_wdt uvcvideo i2c_i801 iTCO_vendor_support microcode wmi nand
videodev nand_ids nand_ecc snd_page_alloc parport_pc parport mtd
soundcore joydev v4l1_compat pcspkr uinput ipv6 sdhci_pci sdhci mmc_core
yenta_socket i915 drm_kms_helper drm i2c_algo_bit i2c_core video output
[last unloaded: scsi_wait_scan]
[ 6033.229012]
[ 6033.229012] Pid: 4834, comm: Xorg Not tainted 2.6.37-rc8+ #25 7661BL5/7661BL5
[ 6033.229012] EIP: 0060:[<f86fda5e>] EFLAGS: 00013246 CPU: 0
[ 6033.229012] EIP is at i915_gem_object_unpin+0x23/0x76 [i915]
[ 6033.229012] EAX: f68a4000 EBX: f6831f00 ECX: 000600fa EDX: f68a8000
[ 6033.229012] ESI: f68a4014 EDI: f68a42b8 EBP: f2169c44 ESP: f2169c3c
[ 6033.229012]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 6033.229012] Process Xorg (pid: 4834, ti=f2168000 task=f21c8000 task.ti=f2168000)
[ 6033.229012] Stack:
[ 6033.229012]  f3a84800 f68a4014 f2169c54 f87045d8 f3a84800 f872d9a8 f2169c68 f7fd8091
[ 6033.229012]  f3b952a4 00000000 f68a414c f2169cf0 f7fd9377 00000000 00000000 f7fd98b0
[ 6033.229012]  f7fd9f4e 0000000f f7f328a0 00000000 00000000 00000000 f2169ca4 f68a414c
[ 6033.229012] Call Trace:
[ 6033.229012]  [<f87045d8>] ? intel_crtc_disable+0x36/0x41 [i915]
[ 6033.229012]  [<f7fd8091>] ?  drm_helper_disable_unused_functions+0xcd/0xf9 [drm_kms_helper]
[ 6033.229012]  [<f7fd9377>] ? drm_crtc_helper_set_config+0x62a/0x7f7 [drm_kms_helper]
[ 6033.229012]  [<c04daa10>] ? __slab_free+0x1b/0xa4
[ 6033.229012]  [<f7fd7e62>] ? drm_fb_helper_initial_config+0x466/0x497 [drm_kms_helper]
[ 6033.229012]  [<f7fd7ea3>] ? drm_fb_helper_restore+0x10/0x2a [drm_kms_helper]
[ 6033.229012]  [<f86f2577>] ? i915_driver_lastclose+0x2a/0x57 [i915]
[ 6033.229012]  [<f7f1989f>] ? drm_lastclose+0x45/0x23e [drm]
[ 6033.229012]  [<f7f1a0b4>] ? drm_release+0x462/0x4d7 [drm]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Bind the hwmon structs to nouveau device kobj. This makes sure
the hwmon files are created in the device subdir in line with
all other hwmon drivers.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Move them to radeon_asic.h together with the other asic
specific stuff.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Still needs to be implemented.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The vbios only partially initializes the memory controller on
NI, so now we need to load the MC ucode in the driver and set
the default clocks once the ucode is loaded.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The MC ucode is no longer loaded by the vbios
tables as on previous asics.  It now must be loaded
by the driver.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The hardware supports advanced user defined color management
but at the moment, there is no infrastructure in place to take
advantage of it so for now we just support the legacy LUTs.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds some new NI (northern islands) specific display
register defines.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

NI chips no longer load the MC ucode in the asic_init sequence so
the asic comes up in a basic mode with low engine/memory clocks and
a voltage.  Once the MC ucode is loaded by the driver the card
can be programmed to it's proper default clocks and voltage.  As such
the default clocks in the firmware info table as the post clocks, not
the default running clocks.  Track the default post clocks and default
running clocks separately to handle this.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Same as Cypress.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some systems disable the vbios on secondary cards or cards that
have been posted.  This code re-enabled the vbios so the driver
can load it.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Needed to tell which DIG encoders are HBR2 capable for DP 1.2.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DVOOutputControl table was removed for DCE5.
DVOEncoderControl now handles everything.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DAC1OutputControl table was removed for DCE5.
DAC1EncoderControl now handles everything.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>