summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-01-25i915: remove pm_qos request on errorStanislaw Gruszka
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>
2014-01-24drm/i915: fix WRPLL clock calculationJesse Barnes
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>
2014-01-24drm/i915: Remove incorrect comment about struct mutexBen Widawsky
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>
2014-01-24drm/i915: always check clocks when comparing pipe configsJesse Barnes
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>
2014-01-24drm/i915: clock readout support for DDI v3Jesse Barnes
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>
2014-01-24drm/i915: Introduce a get_aux_send_ctl() vfuncDamien Lespiau
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>
2014-01-24drm/i915: Reorder the AUX_CTL bits in descending orderDamien Lespiau
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>
2014-01-24drm/i915: Factor out a function returning the AUX_CTL value to start a sendDamien Lespiau
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>
2014-01-24drm/i915: Turn get_aux_clock_divider() into per-platform vfuncsDamien Lespiau
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>
2014-01-24drm/i915: quirk invert brightness for Acer Aspire 5336Jani Nikula
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>
2014-01-24drm/i915: drop the i915.fbpercrtc module parameterJani Nikula
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>
2014-01-24drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devicesTodd Previte
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>
2014-01-24drm/i915: Shuffle sprite register writes into a tighter groupVille Syrjälä
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>
2014-01-24drm/i915: Shuffle modeset reset handling aroundDaniel Vetter
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>
2014-01-24drm/i915: set the backlight panel delays registers to 1Paulo Zanoni
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>
2014-01-24drm/i915: Fix new_config and new_enabled for load detectVille Syrjälä
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>
2014-01-24drm/i915: Kill dev_priv->irq_receivedVille Syrjälä
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>
2014-01-24drm/i915: Make irq_received boolVille Syrjälä
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>
2014-01-24drm/i915: Add intel_hpd_irq_uninstall()Ville Syrjälä
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>
2014-01-24drm/i915: don't wait for power cycle when waiting for power offPaulo Zanoni
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>
2014-01-24drm/i915: remove a column of zeros from the eDP wait definitionsPaulo Zanoni
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>
2014-01-24drm/i915: drop ironlake_ prefix from edp panel/backlight functionsDaniel Vetter
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>
2014-01-24drm/i915: save some time when waiting the eDP timingsPaulo Zanoni
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>
2014-01-24drm/i915: init the DP panel power seq variables earlierPaulo Zanoni
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>
2014-01-24drm/i915: Only restore backlight combination mode reg for umsDaniel Vetter
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>
2014-01-24drm/i915: clean up HPD IRQ debug printingImre Deak
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>
2014-01-24drm/i915: Don't use i915_preliminary_hw_support to mean pre-productionDamien Lespiau
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>
2014-01-24drm/i915: Set crtc->new_config to NULL for pipes that are about to be disabledVille Syrjälä
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>
2014-01-24drm/i915: Don't oops if the initial modeset failsVille Syrjälä
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>
2014-01-24drm/i915: Use new_config and new_enabled to simplify the VLV cdclk codeVille Syrjälä
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>
2014-01-24drm/i915: Prepare to track new pipe config per pipeVille Syrjälä
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>
2014-01-24drm/i915: Pre-compute pipe enabled stateVille Syrjälä
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>
2014-01-24Revert "drm/i915: Mask reserved bits in display/sprite address registers"Daniel Vetter
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>
2014-01-23drm/tegra: Obtain head number from DTThierry Reding
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>
2014-01-23drm/i915: VLV2 - Fix hotplug detect bitsTodd Previte
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>
2014-01-23Merge branch 'drm-nouveau-next' of ↵Dave Airlie
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 ...
2014-01-23drm/nouveau: call drm_vblank_cleanup() earlierBen Skeggs
Fixes a NULL-ptr deref seen on module unload sometimes. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau: create base display from common codeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nv50/gr: print mpc trap name when it's not an mp trapIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
2014-01-23drm/nv50/gr: update list of mp errors, make it a bitfieldIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
2014-01-23drm/nv50/gr: add more trap names to print on errorIlia Mirkin
Also avoids printing the errors bitfield if that information has already been shown. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
2014-01-23drm/nouveau/devinit: lock/unlock crtc regs for all devices, not just pre-nv50Ilia Mirkin
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>
2014-01-23drm/nouveau: hold mutex while syncing to kernel channelMaarten Lankhorst
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>
2014-01-23drm/nv50-/devinit: prevent use of engines marked as disabled by hw/vbiosIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/device: provide a way for devinit to mark engines as disabledIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/devinit: tidy up the subdev class definitionBen Skeggs
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/bar: tidy up the subdev and object class definitionsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/instmem: tidy up the object class definitionBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/instmem: tidy up the subdev class definitionBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-01-23drm/nouveau/pwr: implement a simple i2c stackBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>