aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_dp.c
Commit message (Collapse)AuthorAge
* drm/i915: extract common link_m_n helpersDaniel Vetter2012-12-06
| | | | | | | | | | | | | Both the dp and fdi code use the exact same computations (ignore minor differences in conversion between bits and bytes). This makes it even more apparent that we have a _massive_ mess between cpu transcoder/fdi link/pch transcoder and pch link settings. And also that we have hilarious amounts of confusion between edp and dp (despite that they're identical at a link level). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: WARN on !crtc in intel_dp_link_downDaniel Vetter2012-12-06
| | | | | | | | | | | | This could have happened with the old crtc helper based modeset code, but can't happen any longer with the new code. Hence put in a WARN and adjust the comment. If no one hits this, we can eventually remove it (like a few other such cases across our code). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use wait_for_vblank instead of msleep(17)Daniel Vetter2012-12-06
| | | | | | | | | | | | | | | | | | | | 17 ms is eerily close to 60 Hz ^-1 Unfortunately this goes back to the original DP enabling for ilk, and unfortunately does not come with a reason for it's existance attached. Some closer inspection of the code and DP specs shows that we set the idle link pattern before we disable the port. And it seems like that the DP spec (or at least our hw) only switch to the idle pattern on the next vblank. Hence a vblank wait at this spot makes _much_ more sense than a really long wait. v2: Rebase fixup. v3: Add comment requested by Paulo Zanoni saying that we don't really know what this wait is for. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rip out pre-production ilk cpu edp w/aDaniel Vetter2012-12-06
| | | | | | | | | | | | | | | | | | While reading docs I've noticed that this special workaround to select the 1.6 GHz DP clock only applies to pre-production ilk machines. Since the registers we're touching here are rather undocumented and might be harmful on later chips, rip it out. For the Bspec reference of this w/a look in "vol4g CPU Display Registers [DevILK]", Section 4.1.7.1 "DP_A—DisplayPort A Control Register", "DP_PLL_Frequency_Select". v2: Keep a debug message as a hint in case something regresses. Requested by Chris Wilson. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move set_pll_edp to intel_dp.cDaniel Vetter2012-12-06
| | | | | | | | | | | | | Now that we enable the cpu edp pll in intel_dp->pre_enable and no longer in crtc_mode_set, we can also move the modeset part to the intel_dp->mode_set callback. Previously this was not possible because the encoder ->mode_set callbacks are called after the crtc mode set callback. v2: Rebase on top of copy&pasted hsw crtc_mode_set. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use _NOTRACE for gmbus/dp aux wait loopsDaniel Vetter2012-12-06
| | | | | | | | | | | | | | Less clutter in the traces. And in both cases we yell rather loud into the logs if we time out. Patch suggested by Chris Wilson. v2: Annotate another I915_READ in dp_aux to be consistent - we filter out all register io in wait_for and similar loops. Chris also suggested to mark all dp_aux register access as _NOTRACE, but I think we should keep all functionally relevant access around, and filter unneeded bits in userspace after the trace is captured. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: irq-drive the dp aux communicationDaniel Vetter2012-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least on the platforms that have a dp aux irq and also have it enabled - vlvhsw should have one, too. But I don't have a machine to test this on. Judging from docs there's no dp aux interrupt for gm45. Also, I only have an ivb cpu edp machine, so the dp aux A code for snb/ilk is untested. For dpcd probing when nothing is connected it slashes about 5ms of cpu time (cpu time is now negligible), which agrees with 3 * 5 400 usec timeouts. A previous version of this patch increases the time required to go through the dp_detect cycle (which includes reading the edid) from around 33 ms to around 40 ms. Experiments indicated that this is purely due to the irq latency - the hw doesn't allow us to queue up dp aux transactions and hence irq latency directly affects throughput. gmbus is much better, there we have a 8 byte buffer, and we get the irq once another 4 bytes can be queued up. But by using the pm_qos interface to request the lowest possible cpu wake-up latency this slowdown completely disappeared. Since all our output detection logic is single-threaded with the mode_config mutex right now anyway, I've decide not ot play fancy and to just reuse the gmbus wait queue. But this would definitely prep the way to run dp detection on different ports in parallel v2: Add a timeout for dp aux transfers when using interrupts - the hw _does_ prevent this with the hw-based 400 usec timeout, but if the irq somehow doesn't arrive we're screwed. Lesson learned while developing this ;-) v3: While at it also convert the busy-loop to wait_for_atomic, so that we don't run the risk of an infinite loop any more. v4: Ensure we have the smallest possible irq latency by using the pm_qos interface. v5: Add a comment to the code to explain why we frob pm_qos. Suggested by Chris Wilson. v6: Disable dp irq for vlv, that's easier than trying to get at docs and hw. v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the dp aux registers aren't at a fixed offset any more, but can be on the PCH while the DP port is on the cpu die. Reviewed-by: Imre Deak <imre.deak@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: kill intel_dp_link_clock()Paulo Zanoni2012-11-29
| | | | | | | | Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but supports DP_LINK_BW_5_4 and is also used by the other drivers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add HAS_DDI checkPaulo Zanoni2012-11-29
| | | | | | | | | | | And use it whenever we call code that uses the DDIs. We already have intel_ddi.c and prefix every function with intel_ddi_something instead of haswell_something, so I think replacing the checks with HAS_DDI makes more sense. Just a cosmetical change, yes I know, but I have this OCD... Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: drm_connector_property -> drm_object_propertyRob Clark2012-11-21
| | | | | | | | | v2: Rebased. Signed-off-by: Rob Clark <rob@ti.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v1) [danvet: Pimp commit message a bit.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie2012-11-19
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Daniel writes: Highlights of this -next round: - ivb fdi B/C fixes - hsw sprite/plane offset fixes from Damien - unified dp/hdmi encoder for hsw, finally external dp support on hsw (Paulo) - kill-agp and some other prep work in the gtt code from Ben - some fb handling fixes from Ville - massive pile of patches to align hsw VGA with the spec and make it actually work (Paulo) - pile of workarounds from Jesse, mostly for vlv, but also some other related platforms - start of a dev_priv reorg, that thing grew out of bounds and chaotic - small bits&pieces all over the place, down to better error handling for load-detect on gen2 (Chris, Jani, Mika, Zhenyu, ...) On top of the previous pile (just copypasta): - tons of hsw dp prep patches form Paulo - round scheduled work items and timers to nearest second (Chris) - some hw workarounds (Jesse&Damien) - vlv dp support and related fixups (Vijay et al.) - basic haswell dp support, not yet wired up for external ports (Paulo) - edp support (Paulo) - tons of refactorings to prepare for the above (Paulo) - panel rework, unifiying code between lvds and edp panels (Jani) - panel fitter scaling modes (Jani + Yuly Novikov) - panel power improvements, should now work without the BIOS setting it up - extracting some dp helpers from radeon/i915 and move them to drm_dp_helper.c - randome pile of workarounds (Damien, Ben, ...) - some cleanups for the register restore code for suspend/resume - secure batchbuffer support, should enable tear-free blits on gen6+ Chris) - random smaller fixlets and cleanups. * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (231 commits) drm/i915: Restore physical HWS_PGA after resume drm/i915: Report amount of usable graphics memory in MiB drm/i915/i2c: Track users of GMBUS force-bit drm/i915: Allocate the proper size for contexts. drm/i915: Update load-detect failure paths for modeset-rework drm/i915: Clear unused fields of mode for framebuffer creation drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer drm/i915: Fix sparse warnings in from AGP kill code drm/i915: Missed lock change with rps lock drm/i915: Move the remaining gtt code drm/i915: flush system agent TLBs on SNB drm/i915: Kill off now unused gen6+ AGP code drm/i915: Calculate correct stolen size for GEN7+ drm/i915: Stop using AGP layer for GEN6+ drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush drm/i915: don't rewrite the GTT on resume v4 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex drm/i915: put ring frequency and turbo setup into a work queue v5 drm/i915: don't block resume on fb console resume v2 drm/i915: extract l3_parity substruct from dev_priv ...
| * drm/i915: create the DDI encoderPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it inits the encoder and then calls the proper init_connector functions. Notice that for non-eDP ports we call both HDMI and DP connector init, so we have 2 connectors attached to each DDI encoder. After this change, intel_hdmi_init and intel_dp_init are only called by Ivy Bridge and earlier, while hardware containing DDI outputs should call intel_ddi_init. Also added/removed quite a few "static" keywords due to the fact that some function pointers were moved from intel_dp.c and intel_hdmi.c to intel_ddi.c. DP finally works on Haswell now! \o/ Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add intel_ddi_connector_get_hw_statePaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | We need this since now on DDI we will have 2 connectors on each encoder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add port field to intel_digital_portPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | Both "intel_dp" and "intel_hdmi" structs had a "port" field, which always had the same value. It makes more sense to move this to intel_digital_port, so we can know the port independently of the connector type. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: reset intel_encoder->type when DP or HDMI is detectedPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When intel_hdmi_detect detects a monitor, set intel_encoder->type with INTEL_OUTPUT_HDMI. Same for DP. This should not break the current code because these variables never change. This will be used after we create the DDI encoder because it will have both DP and HDMI connectors. We won't support eDP+HDMI on the same port, so if an encoder is eDP we should expect it to always remain eDP and never change. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: split intel_dp_init into encoder and connector piecesPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | Same reason as the previous HDMI commit: the DDI code will have its own encoder init function but still use the DP and HDMI connectors. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: kill the unnecessarily added line that Damien spotted in review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: create intel_digital_port and use itPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to have one single encoder capable of controlling both DP and HDMI outputs. This patch just adds the initial infrastructure, no functional changes. Previously, both intel_dp and intel_hdmi were intel_encoders. Now, these 2 structs do not have intel_encoder as members anymore. The new struct intel_digital_port has intel_encoder as a member, and it also includes intel_dp and intel_hdmi as members. In other words: see the changes inside intel_drv.h: it's the most important change, everything else is only to make it compile and work. For now, each intel_digital_port is still only able to control one of HDMI or DP, but not both together. In the future we should also try to merge the common fields from intel_dp and intel_hdmi (e.g., port). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Add the missing ' ' spotted by Damien Lespiau.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add intel_dp_to_dev and intel_hdmi_to_devPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we add struct intel_digital_port, there will be no direct way of going from intel_{dp,hdmi} to drm_device: we will need to call container_of(). This patch adds functions to go from intel_{dp,hdmi} to drm_device. The main goal here is to greatly reduce the size of the next patch, where we will change the implementation of the functions we just added here (among other things). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: simplify assignments inside intel_dp.cPaulo Zanoni2012-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Replace container_of with enc_to_intel_dp. - Walk through less structures when making assignments. - Rename some variables to keep our naming standards. As a bonus, this will reduce the usage of "struct intel_dp", making the future patch that introduces intel_digital_port smaller and easier to review. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: shut up spurious message in intel_dp_get_hw_stateDaniel Vetter2012-11-11
| | | | | | | | | | | | | | | | The debug message is only relevant on CPT/PPT PCH ports, so move it into the correct if clause. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: change eDP default scaling mode to respect aspect ratioYuly Novikov2012-10-26
| | | | | | | | | | | | | | | | | | Signed-off-by: Yuly Novikov <ynovikov@chromium.org> [Jani: ripped this change separate from the scaling mode change support] Signed-off-by: Jani Nikula <jani.nikula@intel.com> 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/dp: allow configuring eDP panel fitting scaling modeYuly Novikov2012-10-26
| | | | | | | | | | | | | | | | | | | | | | | | LVDS allowed changing panel fitting scaling mode, while eDP didn't. Copied relevant code from LVDS to eDP. Signed-off-by: Yuly Novikov <ynovikov@chromium.org> [Jani: use fitting mode in intel_panel, remove default mode change] Signed-off-by: Jani Nikula <jani.nikula@intel.com> 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: debug print all of the DPCD we haveJani Nikula2012-10-26
| | | | | | | | | | | | | | | | | | | | At some point the DPCD size was increased, but the debug print not. While at it, switch to using hex dump. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: turn the eDP DDI panel on/offPaulo Zanoni2012-10-26
| | | | | | | | | | | | | | | | It's an important step :) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: set/unset the DDI eDP backlightPaulo Zanoni2012-10-26
| | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: set the correct eDP aux channel clock divider on DDIPaulo Zanoni2012-10-26
| | | | | | | | | | | | | | | | | | | | | | | | The cdclk frequency is not always the same, so the value here should be adjusted to match it. Version 2: call intel_ddi_get_cdclk_freq instead of reading CDCLK_FREQ, because the register is just for earlier HW steppings. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: convert CPU M/N timings to transcoderPaulo Zanoni2012-10-26
| | | | | | | | | | | | | | | | | | Same thing as the previous commits. Not renaming this one since it exists since way before Haswell. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: extract intel_dp_init_panel_power_sequencerDaniel Vetter2012-10-24
| | | | | | | | | | | | | | | | | | | | That thing has grown way too big already. Also move around a comment to the right spot. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: compute the pch dp aux divider from the rawclkDaniel Vetter2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | Otherwise dp aux won't work on some hsw platforms, since they use a different rawclk than the 125MHz clock used thus far. To absolutely not change anything, round up: That way we get the old 63 divider for the default 125MHz clock. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/eDP: compute the panel power clock divisor from the pch rawclockDaniel Vetter2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need this when the bios forgets even to set that bit up. Most seem to do that, even when they don't set up anything else in the panel power sequencer. Note that on IBX the rawclk is variable according to Bspec, but everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but luckily we still have the same register available. On hsw, different variants have different clocks, hence we need to check the register. Since other pieces are driven by the rawclock, too, keep the little helper in a central place. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: enable/disable backlight for eDPDaniel Vetter2012-10-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Like we already do for the LVDS panels. This seems to help greatly in setting up the backlight, since the BIOS might refuse to cooperate. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> v2: Move the backlight_off call from panel_off to edp_backlight_off, noticed by Paulo Zanoni. Reviewed-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: make edp panel power sequence setup more robustDaniel Vetter2012-10-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3 changes: - If a given value is unset, use the maximal limits from the eDP spec. - Write back the new values, since otherwise the panel power sequencing hw will not dtrt. - Revert the early bail-out in case the register values are unset. The last change reverts commit bfa3384a9a84aaaa59443bbd776c142e7dba4b0f Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Apr 10 11:58:04 2012 -0700 drm/i915: check PPS regs for sanity when using eDP v2: - Unlock the PP regs as the very first thing. This is a required w/a for cpu eDP on port A, and generally a good idea. - Fixup the panel power control port selection bits. v3: Paulo Zanoni noticed that I've fumbled the computation of the spec limit values. Fix them up. We've also noticed that the t8/t9 values in the vbt/bios-programmed pp are much larger than any limits. My guess is that this is to conceal any backlight enable/disable delays. So by using the much shorter limits from the spec, which only concerns the sink, we risk that we might display before the backlight is fully on, or disable the output while the backlight still has afterglow. I've figured I don't care too much, since this will only happen when both the pp regs are not programmed, and the vbt tables don't contain anything useful. v4: Don't set the port selection bits on hsw/LPT, they don't exist any more. v5: Fixup spelling issues in comments, as noticed by Jesse Barnes. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: actually nack test requestDaniel Vetter2012-10-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... like the comment says. No idea whether this has any effect, but I guess it's better to not lie to the display by acking a test request and never following through with it. This goes back to the commit that originally introduced this code: commit a60f0e38d72a5e24085d6e7e27a4cadc20ae268a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 20 15:09:17 2011 -0700 drm/i915: add DP test request handling Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Meh'ed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: extract drm_dp_max_lane_count helperDaniel Vetter2012-10-22
| | | | | | | | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: extract dp link bw helpersDaniel Vetter2012-10-22
| | | | | | | | | | | | Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: use the new dp train delay helpersDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | Only really required for dp 1.2. I've hoped this would help with some link training woes I'm fighting, but alas those are only dp 1.1 devices. Also move a comment that went misplaced in the recent refactorings to the right spot again. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: extract dp link train delay functions from radeonDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a few changes since that dpcd value is above the range currently cached by radeon. I've check the dp specs, and above 0xf there's a big gap and nothing that looks like we should cache it while a given device is plugged in. It's also the same value that i915.ko uses. Hence extend the various dpcd arrays in the radeon driver, use proper symbolic constants where applicable (one place overallocated the dpcd array to 25 bytes). Then also drop the rd_interval cache - radeon_dp_link_train_init re-reads the dpcd block, so the values we'll consume in train_cr and train_ce will always be fresh. To avoid needless diff-churn, #define the old size of dpcd as the new one and keep it around. v2: Alex Deucher noticed one place where I've forgotten to replace 8 with DP_RECEIVER_CAP_SIZE. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: extract helpers to compute new training values from sink requestDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | Safe for the minor difference that the intel versions get an offset into the link_status as an argument, both are the same again. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: dp helper: extract drm_dp_clock_recovery_okDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | | | | | | | radeon and intel use the exact same definition. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> v2: Kill 2 more helpers in intel_dp.c that I've missed. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm: dp helper: extract drm_dp_channel_eq_okDaniel Vetter2012-10-22
| | | | | | | | | | | | | | | | radeon and intel use the exact same definition. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move cached EDID to intel_connectorJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | Move the cached EDID from intel_dp and intel_lvds_connector to intel_connector. Unify cached EDID handling for LVDS and eDP, in preparation for adding more generic EDID caching later. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move the fixed mode to intel_panelJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | Pave the way for sharing some logic between eDP and LVDS. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Create generic intel_panel for LVDS and eDPJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a generic struct intel_panel for sharing a data structure and code between eDP and LVDS panels. Add the new struct to intel_connector so that later on we can have generic EDID and mode reading functions with EDID caching that transparently fallback to fixed mode when EDID is not available. Add intel_panel as a dummy first, and move data (such as the mentioned fixed mode) to it in later patches. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup tiny conflict in intel_dp_destroy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/dp: Initialize eDP fixed mode in intel_dp_initJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we do EDID caching in intel_dp_init, we can do the fixed mode initialization there too. This should not change the functionality apart from initializing fixed mode earlier. Particularly retain the behaviour of only falling back to VBT if EDID is not available to not regress commit 47f0eb2234a2a1c790825393bbaccfadf82463d3 Author: Keith Packard <keithp@keithp.com> Date: Mon Sep 19 14:33:26 2011 -0700 drm/i915: Only use VBT panel mode on eDP if no EDID is found Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Backlight setup requires connector so pass it as parameterJani Nikula2012-10-22
| | | | | | | | | | | | | | | | | | | | Get rid of saved int_lvds_connector and int_edp_connector in drm_i915_private. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'v3.7-rc2' into drm-intel-next-queuedDaniel Vetter2012-10-22
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.7-rc2 Backmerge to solve two ugly conflicts: - uapi. We've already added new ioctl definitions for -next. Do I need to say more? - wc support gtt ptes. We've had to revert this for snb+ for 3.7 and also fix a few other things in the code. Now we know how to make it work on snb+, but to avoid losing the other fixes do the backmerge first before re-enabling wc gtt ptes on snb+. And a few other minor things, among them git getting confused in intel_dp.c and seemingly causing a conflict out of nothing ... Conflicts: drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_modes.c include/drm/i915_drm.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: set the correct function pointers for Haswell DPPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the final remaining piece of Haswell DP enablement. After this patch, just calling intel_dp_init on any port will make DP work. We still do not do this because we're currently initializing HDMI on all the ports, so if we replace intel_hdmi_init with intel_dp_init, we will break HDMI, and we can't call both because they share the same registers. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: implement Haswell DP link train sequencePaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previous patch "drm/i915: add basic Haswell DP link train bits" implemented the basic structure to set the voltage levels and training patterns. This patch adds the higher-level bits that are part of the mode set sequence and hot plug. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: fix Haswell DP M/N registersPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to write the correct values inside intel_dp_set_m_n and then prevent these values from being overwritten later. V2: Unconfuse double negation. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: add DP support to intel_ddi_mode_setPaulo Zanoni2012-10-18
| | | | | | | | | | | | | | | | | | Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>