drm/i915: drop i915_ prefix from enable_rc6, enable_fbc, enable_ppgtt parameters

Having to use i915.i915_foo is inconsistent and a bit on the verbose
side. Drop the prefix per Daniel's request, who also says this is not
ABI we need to maintain.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: GEN7_MSG_CONTROL is ivb-only

At least I couldn't find it in the Haswell Bspec any more and we've
tried to test-boot a Haswell machine with num_pipes forced to 0 (i.e.
hit the PCH_NOP path) and the unclaimed register logic complained.

So restrict this dance to just ivb platforms.

v2: Art pointed out that the bits simply moved on hsw+

v3: Buy code terseneness with a notch of sublety as suggested by
Chris.

v4: Frob the right bit, spotted by Art.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Constify the drm_i915_private pointer a bit more

A lot of the WM functions are only reading from that structure and are
already using const. While converting the code to use dev_priv instead
of dev, I noticed a few places where we can give that hint.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move module parameters into a struct, in a new file

With 20+ module parameters, I think referring to them via a struct
improves clarity over just having a bunch of globals. While at it, move
the parameter initialization and definitions into a new file
i915_params.c to reduce clutter in i915_drv.c.

Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
internally, the module parameters now look the same both on the kernel
command line and in code. For example, "i915.modeset".

The downsides of the change are losing static on a couple of variables
and not having the initialization and module_param_named() right next to
each other. On the other hand, all module parameters are now defined in
one place at i915_params.c. Plus you can do this to find all module
parameter references:

$ git grep "i915\." -- drivers/gpu/drm/i915

v2:
- move the definitions into a new file
- s/i915_params/i915/
- make i915_try_reset i915.reset, for consistency

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaMiSetContext_Hang

WaMiSetContext_Hang tells us that a MI_NOOP must follow MI_SET_CONTEXT.

The other thing WaMiSetContext_Hang seems to say is that URB_FENCE isn't
allowed to straddle two cachelines. But we don't issue those from the
kernel so we don't care.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableRCCUnitClockGating:snb

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaApplyL3ControlAndL3ChickenMode isn't applicable for VLV

WaApplyL3ControlAndL3ChickenMode is only listed for IVB and HSW in
W/A database and BSpec.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableL3CacheAging:vlv

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: WaPsdDispatchEnable seems to be another name for WaDisablePSDDualDispatchEnable

The w/a database lists both WaPsdDispatchEnable and
WaDisablePSDDualDispatchEnable for VLV. They appear to be the same
thing, so list both names.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaEnableVGAAccessThroughIOPort:ctg, elk, ilk, snb, ivb, vlv, hsw

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: We implement WaDisableL3Bank2xClockGate:vlv

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Include HW status page in error capture

Many times in the past we have concluded that the cause of the GPU hang
has been that the hw status page was stale, usually because the GPU and
CPU disagreed over the address of the page. Having stumbled across yet
another issue that seems to be related to the HWSP, it is time to
include that information in the GPU error dump.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always pin the default context

Through a twisty and circuituous path it is possible to currently trick
the code into creating a default context and forgetting to pin it
immediately into the GGTT. (This requires a system using contexts without
an aliasing ppgtt, which is currently restricted to Baytrails machines
manually specifying a module parameter to force enable contexts, or
on Sandybridge and later that manually disable the aliasing ppgtt.) The
consequence is that during module unload we attempt to unpin the default
context twice and encounter a BUG remonstrating that we attempt to unpin
an unbound object.

[  161.002869] Kernel BUG at f84861f8 [verbose debug info unavailable]
[  161.002875] invalid opcode: 0000 [#1] SMP
[  161.002882] Modules linked in: coretemp kvm_intel kvm crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul ablk_helper cryptd hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_magn_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio hid_sensor_iio_common snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event dm_multipath scsi_dh asix ppdev usbnet snd_rawmidi mii hid_sensor_hub microcode snd_seq rfcomm bnep snd_seq_device bluetooth snd_timer snd parport_pc binfmt_misc soundcore dw_dmac_pci dw_dmac_core mac_hid lp parport dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915(O-) drm_kms_helper(O) igb dca ptp pps_core i2c_algo_bit drm(O) ahci libahci video
[  161.002991] CPU: 0 PID: 2114 Comm: rmmod Tainted: G        W  O 3.13.0-rc8+ #2
[  161.002997] Hardware name: NEXCOM VTC1010/Aptio CRB, BIOS 5.6.5 09/24/2013
[  161.003004] task: dbdd6800 ti: dbe0e000 task.ti: dbe0e000
[  161.003010] EIP: 0060:[<f84861f8>] EFLAGS: 00010246 CPU: 0
[  161.003044] EIP is at i915_gem_object_ggtt_unpin+0x88/0x90 [i915]
[  161.003050] EAX: dfce3840 EBX: 00000000 ECX: dfafd690 EDX: dfce3874
[  161.003056] ESI: c0086b40 EDI: df962e00 EBP: dbe0fe1c ESP: dbe0fe0c
[  161.003062]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.003068] CR0: 8005003b CR2: b7718000 CR3: 1bec0000 CR4: 001007f0
[  161.003076] Stack:
[  161.003081]  00afc014 00000004 c0086b40 dfafc000 dbe0fe38 f8487e5a dfaa5400 c0086b40
[  161.003099]  dfafc000 dfaa5400 dfaa5414 dbe0fe58 f84741aa 00000000 f89c34b9 dfaa5414
[  161.003117]  dfaa5400 dfaa5400 f644b000 dbe0fe6c f89a5443 dfaa5400 f8505000 f644b000
[  161.003134] Call Trace:
[  161.003169]  [<f8487e5a>] i915_gem_context_fini+0xba/0x1c0 [i915]
[  161.003202]  [<f84741aa>] i915_driver_unload+0x1fa/0x2f0 [i915]
[  161.003232]  [<f89a5443>] drm_dev_unregister+0x23/0x90 [drm]
[  161.003259]  [<f89a54ed>] drm_put_dev+0x3d/0x70 [drm]
[  161.003294]  [<f8470615>] i915_pci_remove+0x15/0x20 [i915]
[  161.003306]  [<c1338a6f>] pci_device_remove+0x2f/0xa0
[  161.003317]  [<c140c871>] __device_release_driver+0x61/0xc0
[  161.003328]  [<c140d12f>] driver_detach+0x8f/0xa0
[  161.003341]  [<c140c54f>] bus_remove_driver+0x4f/0xc0
[  161.003353]  [<c140d708>] driver_unregister+0x28/0x60
[  161.003362]  [<c10cee42>] ? stop_cpus+0x32/0x40
[  161.003372]  [<c10bd510>] ? module_refcount+0x90/0x90
[  161.003383]  [<c13378c5>] pci_unregister_driver+0x15/0x60
[  161.003413]  [<f89a739f>] drm_pci_exit+0x9f/0xb0 [drm]
[  161.003458]  [<f84e624a>] i915_exit+0x1b/0x1d [i915]
[  161.003468]  [<c10bf8a8>] SyS_delete_module+0x158/0x1f0
[  161.003480]  [<c1173d5d>] ? ____fput+0xd/0x10
[  161.003488]  [<c106f0fe>] ? task_work_run+0x7e/0xb0
[  161.003499]  [<c165a68d>] sysenter_do_call+0x12/0x28
[  161.003505] Code: 0f b6 4d f3 8d 51 0f 83 e1 f0 83 e2 0f 09 d1 84 d2 88 48 54 75 07 80 a7 91 00 00 00 7f 83 c4 04 5b 5e 5f 5d c3 8d b6 00 00 00 00 <0f> 0b 8d b6 00 00 00 00 55 89 e5 57 56 53 83 ec 64 3e 8d 74 26
[  161.003586] EIP: [<f84861f8>] i915_gem_object_ggtt_unpin+0x88/0x90 [i915] SS:ESP 0068:dbe0fe0c

v2: Rename the local variable (is_default_ctx) to avoid confusion with
the function is_default_ctx(). And correct Jesse's email address.

Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73985
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com>
[danvet: Fix up the rebase fail from my first attempt, thankfully
pointed out by Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Decouple GPU error reporting from ring initialisation

Currently we report through our error state only the rings that have
been initialised (as detected by ring->obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print out any of the vital information for debugging the hang.

This (and the implied object leak) is a regression from

commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Mon Oct 14 10:01:36 2013 -0700

    drm/i915: Do a fuller init after reset

Note that we are already starting to get bug reports with incomplete
error states from 3.13, which also hampers debugging userspace driver
issues.

v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
    the scratch obj may be NULL.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
Cc: stable@vger.kernel.org # please don't delay since it's a
vital support/debug feature for the intel gfx stack in general
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a bit of fluff to make it clear we need this expedited in
stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: debugfs: Add support for probing DP sink CRC.

This debugfs interface will allow intel-gpu-tools test case
to verify if screen has been updated properly on cases like PSR.

v2: Accepted all Daniel's suggestions:
    * grab modeset lock
    * loop over connector and check DPMS on
    * return errors
    * use _eDP1 suffix for easy future extension
    * don't cache crc_supported neither latest crc
    * return crc as a full array and read it at once with aux.
    * use 0 to turn TEST_SINK off.
    * split the drm_helpers definitions in another patch.

v3: Accepted 2 Damien's suggestion: remove h from printf hexa
    and return ENODEV when eDP not present instead of EAGAIN.

v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove
    _retry from aux read.

v5: removing last missing useless _retry (by Damien)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: dp helper: Add DP test sink CRC definition.

This address will be used to verify panel CRC for test and
validation purposes.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Fix whitespace fail.]
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix FBC_FENCE_OFF

Having a 4 byte register at 0x321b seems unlikely as that's not
4 byte aligned. Since later platforms have more or less the same FBC
registers with new names, assume that FBC_FENCE_OFF is at 0x3218 just
like DPFC_FENCE_YOFF.

This feels like a simple typo in BSpec. 321Bh looks a lot like 3218h
after all.

Should still be tested on real hardware of course. But I don't have
any mobile gen4 systems.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix FBC1 enable message

The debug message telling FBC1 has been enabled is missing a newline.
Add it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't preserve DPFC_CONTROL bits ILK/SNB

On CTG and IVB+ we don't try to preserve any bits from the
DPFC_CONTROL register. Follow suit on ILK/SNB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill most of the FBC register save/restore

We will anyway re-enable FBC normally after resume, so trying to save
and restore the register makes little sense.

We do need to preserve the FBC1 interval bits in FBC_CONTROL since
we only initialize them during driver load, and try to preserve them
after that.

v2: s/I915_HAS_FBC/HAS_FBC/ and fix the check for gen4

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Actually write the correct bits to DPFC_CONTROL on CTG

We set up all the bits for DPFC_CONTROL but forgot to actually
write them to the register. Oops.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use 1/2 compression ratio limit for 16bpp on FBC2

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Improve FBC plane defines a bit

Make the FBC plane macros take the plane as a parameter.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't set DPFC_HT_MODIFY bit on CTG/ILK/SNB

The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit.
CTG docs clearly state that it should be set only when tracking
back buffer modification in persistent mode. The bit is supposed
to be set by software after the first CPU modification to the
back buffer, and it would get automagically cleared by the hardware
on the next page flip.

Since we only track front buffer modification we don't need to set
this bit. GTT modification tracking still appears to work on ILK
and SNB with the bit unset. I don't have a CTG to verify how that
behaves.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't set persistent FBC mode on ILK/SNB

The ILK/SNB docs are a bit unclear what the persistent mode does, but
the CTG docs clearly state that it was meant to be used when we're
tracking back buffer modifications. We never do that, so leave it in
non-persistent mode.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't write IVB_FBC_RT_BASE

We use nuking instead of render tracking on IVB+, so there's
no point in writing IVB_FBC_RT_BASE.

v2: Drop the IVB_FBC_RT_BASE write too
v3: Move the SNB stuff elsewhere, leaving only IVB+ here

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge branch 'topic/ppgtt' into drm-intel-next-queued

Because whatever.*

* This should contain a fairly long list of issues and still
unresolved resgressions, but I didn't really get a vote.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make underruns DRM_ERROR

I want to see these without having full debugs enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fix the gen8 irq handler as spotted by Paulo in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Limit FIFO underrun reports on GMCH platforms

Currently we print all pipe underruns on GMCH platforms. Hook up the
same logic we use on PCH platforms where we disable the underrun
reporting after the first underrun.

Underruns don't actually generate interrupts themselves on GMCH
platforms, we just can detect them whenever we service other
interrupts. So we don't have any enable bits to worry about. We just
need to remember to clear the underrun status when enabling underrun
reporting.

Note that the underrun handling needs to be moved to the non-locked
pipe_stats[] loop in the interrupt handlers to avoid having to rework
the locking in intel_set_cpu_fifo_underrun_reporting().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Place the Global GTT VM first in the list of VM

This is useful for debugging as we then know that the first entry is
always the global GTT, and all later entries the per-process GTT VM.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915: remove pm_qos request on error

Not removing pm qos request and free memory for it can cause crash,
when some other driver use pm qos. For example, this oops:

BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff81307a6b>] plist_add+0x5b/0xd0
Call Trace:
 [<ffffffff810acf25>] pm_qos_update_target+0x125/0x1e0
 [<ffffffff810ad071>] pm_qos_add_request+0x91/0x100
 [<ffffffffa053ec14>] e1000_open+0xe4/0x5b0 [e1000e]

was caused by earlier i915 probe failure:

[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 00003004 tail 00000000 start 00003000
[drm:i915_driver_load] *ERROR* failed to init modeset
i915: probe of 0000:00:02.0 failed with error -5

Bug report:
http://bugzilla.redhat.com/show_bug.cgi?id=1057533

Reported-by: Giandomenico De Tullio <ghisha@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
[danvet: Drop unnecessary code movement.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix WRPLL clock calculation

Forgot to convert to using the refclk variable when I added refclk
readout support, and Paulo noticed the resulting calculation was off due
to the way p & r are stored.

Reported-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Remove incorrect comment about struct mutex

This statenment became false here:

commit 4fc688ce79772496503d22263d61b071a8fb596e
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Nov 2 11:14:01 2012 -0700

    drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: always check clocks when comparing pipe configs

Now that we have DDI support, we can check these all the time.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clock readout support for DDI v3

Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.

v2: do the work from ddi_get_config (Ville)
v3: check WRPLL reference clock (Ville)
    add additional SPLL freqs (Ville)
    clean up port/crtc clock calc (Ville)
    fix up crtc_clock conditionals (Ville)
    drop superfluous dp_get_m_n from get_config (Ville)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Introduce a get_aux_send_ctl() vfunc

We need a bit more flexibility here in the future, bits get shuffled
around.

v2: more descriptive commit message (Jani Nikula)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Reorder the AUX_CTL bits in descending order

So it's easier to compare what we program with the documentation, not
having to jump at all.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Factor out a function returning the AUX_CTL value to start a send

Also, move that computation outside of the for loop that tries 5 times,
this value doesn't change between tries.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Turn get_aux_clock_divider() into per-platform vfuncs

A tiny clean-up to allow better code separation between platforms.

v2: Fix comment placement (put in in i9xx_get_aux_clock_divider()) and
    nuke the outdated PCH eDP comment (Jani Nikula)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: quirk invert brightness for Acer Aspire 5336

Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Sep 20 15:05:30 2013 +0300

    drm/i915: assume all GM45 Acer laptops use inverted backlight PWM

failed and was later reverted in
commit be505f643925e257087247b996cd8ece787c12af
Author: Alexander van Heukelum <heukelum@fastmail.fm>
Date:   Sat Dec 28 21:00:39 2013 +0100

    Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"

fix the individual broken machine instead.

Note to backporters:

http://patchwork.freedesktop.org/patch/17837/

is the patch you want for 3.13 and older.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop the i915.fbpercrtc module parameter

It's unused, and nowadays specifying unknown parameters no longer
prevents modules from being loaded.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices

For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support it. The
sink device must report that is supports Displayport 1.2 and the HBR2 bit rate in the
DPCD in order to use HBR2.

Signed-off-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Shuffle sprite register writes into a tighter group

Group the sprite register writes a bit tighter. We want to write
the registers atomically, and so doing the base address/offset
artihmetic within the critical section is pointless when it can
all be done beforehand.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Shuffle modeset reset handling around

Currently we're doing the reset handling a bit late, and we're doing
it both in the driver load code and on resume. This makes it unusable
for e.g. resetting the panel power sequence state like Paulo wants to.

Instead of adding yet another single-use callback shuffle things
around:
- Output handling code is responsible to reset/init all state on its
  own at driver load time.
- We call the reset functions much earlier, before we start using any
  of the modeset code.

Compared to Paulo's new ->resume callback the only difference in
placement is that ->reset is still called without dev->struct_mutex
held. Which is imo a feature.

v2: Rebase on top of the now merge dinq.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set the backlight panel delays registers to 1

Because we already do the wait in software: see
ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off.

For the "backlight on" delay, even BSpec says we need to program 0x1
to PP_ON_DELAYS 12:0.

For the "backlight off" delay, if we don't do the same thing, when we
call ironlake_wait_panel_off we'll end up waiting for the it again.

On my machine the off delay is 200ms, so we save this amount of time
whenever we disable the panel (e.g, suspend).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix new_config and new_enabled for load detect

I forgot to set new_config and new_enabled appropriately in the load
detect code. Fix it up.

v2: Handle the other error path in intel_get_load_detect_pipe() too (Imre)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill dev_priv->irq_received

Not sure anyone cares about this information. I suppose most people
would just look at /proc/interrupts instead.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make irq_received bool

irq_received is used as a boolean in i965_irq_handler(), so make it
bool. This also makes i965_irq_handler() closer to i915_irq_handler().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewd-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add intel_hpd_irq_uninstall()

Add intel_hpd_irq_uninstall() which will cancel the hotplug re-enable
timer.

Also s/i915_reenable_hotplug_timer_func/intel_hpd_irq_reenable/

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't wait for power cycle when waiting for power off

Function ironlake_wait_panel_off should just wait for the power off
delay, while function ironlake_wait_panel_power_cycle should wait for
the panel cycle (that's required after we turn the panel off, before
we enable it again).

The problem is that, currently, ironlake_wait_panel_off is waiting not
just for the panel to be off, but also for the power cycle delay and
the backlight off delay. This function relies on the PP_STATUS bits
3:0, which are not documented and not supposed to be used. A quick
analysis of the values we get while waiting quickly shows that power
off is reached while bits 3:0 are still 0x1, and the time it takes to
become 0x0 is the power cycle delay.

On my system with backlight off delay of 200ms, power down delay of
50ms and power cycle delay of 500ms, this is what I get:
 - Start waiting with value 0x80000008, timestamp 6.429364.
 - Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996)
 - Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913)
 - Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894)
 - Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648)

As you can see, ironlake_wait_panel_off is sleeping 760ms instead of
the expected 50ms: the first 200ms matches the backlight off delay
(which we should already have waited for!), then the 50ms for the real
panel off delay, then the 500ms for the panel power cycle.

This patch makes is look just at bits 31 and 29:28, which will ignore
the panel power cycle.

And just to be clear: this saves 500ms on my system every time we
disable the panel. But we can still save 200ms more (the backlight off
delay) on the next patches.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuougseek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove a column of zeros from the eDP wait definitions

I like how the macros are nicely column-aligned, so we can properly
compare what each macro waits for, but a column full of zeroes doesn't
really help anything: it just makes the lines bigger, and they're
already way past 80 columns. I imagine this column was used in the
past, but IMHO now we can get rid of it.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop ironlake_ prefix from edp panel/backlight functions

They now also work on vlv, which has the regs somewhere else. And
daring a glance into the looking glass it seems like this
functionality will continue to work the same for the next few hardware
platforms.

So it's better to just remove that misleading prefix and have a bit
shorter code for better readability.

The only exceptions are the panel/backlight functions shared with
intel_ddi.c, those get an intel_ prefix.

While at it make the vdd_on/off functions static.

And one straggler was missing the edp_ in the name, so make everything
neatly OCD.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: save some time when waiting the eDP timings

The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch does is that we record the
timestamp of when action A happened, then, just before action B, we
look at how much time has passed and only sleep the remaining amount
needed.

With this change, I am able to save about 5-20ms (out of the total
200ms) of the backlight_off delay and completely skip the 1ms
backlight_on delay. The 600ms vdd_off delay doesn't happen during
normal usage anymore due to a previous patch.

v2: - Rename ironlake_wait_jiffies_delay to intel_wait_until_after and
      move it to intel_display.c
    - Fix the msleep call: diff is in jiffies
v3: - Use "tmp_jiffies" so we don't need to worry about the value of
      "jiffies" advancing while we're doing the math.
v4: - Rename function again.
    - Move function to i915_drv.h.
    - Store last_power_cycle at edp_panel_off too.
    - Use msecs_to_jiffies_timeout, then replace the msleep with an
      open-coded version that avoids the extra +1 jiffy.
    - Try to add units to every variable name so we don't confuse
      jiffies with milliseconds.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: init the DP panel power seq variables earlier

Our driver has two different ways of waiting for panel power
sequencing delays. One of these ways is through
ironlake_wait_panel_status, which implicitly uses the values written
to our registers. The other way is through the functions that call
intel_wait_until_after, and on this case we do direct msleep() calls
on the intel_dp->xxx_delay variables.

Function intel_dp_init_panel_power_sequencer is responsible for
initializing the _delay variables and deciding which values we need to
write to the registers, but it does not write these values to the
registers. Only at intel_dp_init_panel_power_sequencer_registers we
actually do this write.

Then problem is that when we call intel_dp_i2c_init, we will get some
I2C calls, which will trigger a VDD enable, which will make use of the
panel power sequencing registers and the _delay variables, so we need
to have both ready by this time. Today, when this happens, the _delay
variables are zero (because they were not computed) and the panel
power sequence registers contain whatever values were written by the
BIOS (which are usually correct).

What this patch does is to make sure that function
intel_dp_init_panel_power_sequencer is called earlier, so by the time
we call intel_dp_i2c_init, the _delay variables will already be
initialized. The actual registers won't contain their final values,
but at least they will contain the values set by the BIOS.

The good side is that we were reading the values, but were not using
them for anything (because we were just skipping the msleep(0) calls),
so this "fix" shouldn't fix any real existing bugs. I was only able to
identify the problem because I added some debug code to check how much
time time we were saving with my previous patch.

Regression introduced by:
    commit ed92f0b239ac971edc509169ae3d6955fbe0a188
    Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Date:   Wed Jun 12 17:27:24 2013 -0300
        drm/i915: extract intel_edp_init_connector

v2: - Rewrite commit message.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only restore backlight combination mode reg for ums

This was forgotten in

commit 565ee3897f0cb1e9b09905747b3784e6605767e8
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Nov 13 12:56:29 2013 +0200

    drm/i915: do not save/restore backlight registers in KMS

Since the confusion was likely due to the duplicated definition for
this pci config register, let's unify that, too.

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clean up HPD IRQ debug printing

Atm, we don't print these events for all platforms and for VLV/G4X we
also print them for DP AUX completion events which is unnecessary spam.
Fix both issues.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't use i915_preliminary_hw_support to mean pre-production

Those are two distinct concepts. Just use a comment to remind us to
remove that W/A at some point.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Set crtc->new_config to NULL for pipes that are about to be disabled

crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is stale.

v2: Clear new_config in disable_crtc_nofb() too (Imre)

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't oops if the initial modeset fails

If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lead to an oops within the modeset code.

Check for NULL fb when restoring the configuration, and instead of
oopsing simply disable the pipe.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use new_config and new_enabled to simplify the VLV cdclk code

On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Prepare to track new pipe config per pipe

Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute phase,
so that we can make accurate decisions about global resource usage.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pre-compute pipe enabled state

Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: Mask reserved bits in display/sprite address registers"

This reverts commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31.

I've left the masking in the pageflip code since that seems to be some
useful piece of preemptive robustness.

Iirc I've merged this patch under the assumption that the BIOS leaves
some random gunk in the lower bits and gets unhappy if we trample on
them. We have quite a few case like this, so this made sense.

Now I've just learned that there's actual hardware features bits in
the low 12 bits, and the kernel needs to preserve them to allow a
userspace blob to do its job. Given Dave Airlie's clear stance on
userspace blob drivers I've quickly chatted with him and he doesn't
seem too happy. So let's revert this.

If there are indeed bits that we must preserve in this range then we
can ressurrect this patch, but with proper documentation for those
bits supplied. And we probably also need to think a bit about
interactions with our driver.

Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/tegra: Obtain head number from DT

The head number of a given display controller is fixed in hardware and
required to program outputs appropriately. Relying on the driver probe
order to determine this number will not work, since that could yield a
situation where the second head was probed first and would be assigned
head number 0 instead of 1.

By explicitly specifying the head number in the device tree, it is no
longer necessary to rely on these assumptions. As a fallback, if the
property isn't available, derive the head number from the display
controller node's position in the device tree. That's somewhat more
reliable than the previous default but not a proper solution.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

drm/i915: VLV2 - Fix hotplug detect bits

Add new definitions for hotplug live status bits for VLV2 since they're
in reverse order from the gen4x ones.

Changelog:
- Restored gen4 bit definitions
- Added new definitions for VLV2
- Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct
  bit defintions
- Replaced a lost trailing brace for the added switch()

Signed-off-by: Todd Previte <tprevite@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951
[danvet: Switch to _VLV postfix instead of prefix and regroupg
comments again so that the g4x warning is right next to those defines.
Also add a _G4X suffix for those special ones. Also cc stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

Summary:
- GK110/GK208 acceleration
- loads more work towards pm, though, still behind a disable wall for now
- error reporting improvements from both Ilia and myself
- more old-school overlay improvements from Ilia
- misc other bits and pieces

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (68 commits)
  drm/nouveau: call drm_vblank_cleanup() earlier
  drm/nouveau: create base display from common code
  drm/nv50/gr: print mpc trap name when it's not an mp trap
  drm/nv50/gr: update list of mp errors, make it a bitfield
  drm/nv50/gr: add more trap names to print on error
  drm/nouveau/devinit: lock/unlock crtc regs for all devices, not just pre-nv50
  drm/nouveau: hold mutex while syncing to kernel channel
  drm/nv50-/devinit: prevent use of engines marked as disabled by hw/vbios
  drm/nouveau/device: provide a way for devinit to mark engines as disabled
  drm/nouveau/devinit: tidy up the subdev class definition
  drm/nouveau/bar: tidy up the subdev and object class definitions
  drm/nouveau/instmem: tidy up the object class definition
  drm/nouveau/instmem: tidy up the subdev class definition
  drm/nouveau/pwr: implement a simple i2c stack
  drm/nouveau/pwr: have rd/wr32 routines clobber data instead of addr
  drm/nve0/fb: turn off some bits in 10f584 at init
  drm/nve0/fb/gddr5: merge a fix from ddr3 for one of the timing settings
  drm/nve0/fb/gddr5: yet another random 10f200 bit
  drm/nvc0-/fb: hook up skeleton interrupt handler
  drm/nve0/fb/gddr5: more 10f200 stuff
  ...

drm/nouveau: call drm_vblank_cleanup() earlier

Fixes a NULL-ptr deref seen on module unload sometimes.

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

drm/nouveau: create base display from common code

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

drm/nv50/gr: print mpc trap name when it's not an mp trap

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

drm/nv50/gr: update list of mp errors, make it a bitfield

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

drm/nv50/gr: add more trap names to print on error

Also avoids printing the errors bitfield if that information has already
been shown.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>

drm/nouveau/devinit: lock/unlock crtc regs for all devices, not just pre-nv50

Also make nv_lockvgac work for nv50+ devices. This should fix
IO_CONDITION and related VBIOS opcodes that read/write the crtc regs.

See https://bugs.freedesktop.org/show_bug.cgi?id=60680

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: hold mutex while syncing to kernel channel

Not holding the mutex potentially causes corruption of the kernel
channel when page flipping.

Cc: stable@vger.kernel.org #3.13
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50-/devinit: prevent use of engines marked as disabled by hw/vbios

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/device: provide a way for devinit to mark engines as disabled

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/devinit: tidy up the subdev class definition

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/bar: tidy up the subdev and object class definitions

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

drm/nouveau/instmem: tidy up the object class definition

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

drm/nouveau/instmem: tidy up the subdev class definition

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

drm/nouveau/pwr: implement a simple i2c stack

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

drm/nouveau/pwr: have rd/wr32 routines clobber data instead of addr

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

drm/nve0/fb: turn off some bits in 10f584 at init

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

drm/nve0/fb/gddr5: merge a fix from ddr3 for one of the timing settings

Titan.

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

drm/nve0/fb/gddr5: yet another random 10f200 bit

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

drm/nvc0-/fb: hook up skeleton interrupt handler

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

drm/nve0/fb/gddr5: more 10f200 stuff

Seen on Titan.  NFI what the condition to switch this on is yet, and,
hardcoding it to on currently causes master to report unknown intr
with a mask of 0x08002000.

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

drm/nve0/clk: report ddr memory frequency

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

drm/nouveau/fb/gddr5: make sure we update mr7 when we're supposed to

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

drm/nve0/fb/gddr5: 10f698/69c

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

drm/nve0/fb: it's now safe to obey the memory voltage setting properly

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

drm/nve0/fb: multi-stage reclock is required for certain transitions

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

drm/nouveau/clk: allow fb to signal it needs to do a multi-stage reclock

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

drm/nve0/fb/gddr5: parse bios data into struct rather than using directly

Still essentially a struct of magic values with magic names and unknown
purposes.  But, we will shortly need to be able to mix and match bits of
the previous and next configurations to do a transition reclock, as such,
we can no longer directly use the vbios data with any ease.

This is probably nicer anyway in the long run, for a few reasons.

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

drm/nve0/fb/gddr5: found LP3 setting

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

drm/nve0/fb: note the memory voltage toggle, not using it yet

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

drm/nve0/fb/gddr5: somewhat better attempt at 100770/10f604/610/614

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
fb/gddr5/nve0: 100770 is like 10f604

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

drm/nve0/fb/gddr5: fixup delays a bit

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

drm/nouveau/bios: timing 2.0 entries can have subentries

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

drm/nve0/fb/gddr5: note another semi-unknown

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

drm/nouveau/fb/gddr5: modify mr8 with high bits of CL/WR

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