2789339044fb6dfbee0c8cd77e26438b80e333ee |
|
04-Sep-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Rewrite ABS_DIFF() in a safer manner The new version of the macro does a few things better: - protect the arguments, - only evaluate the arguments once, - check that the arguments are of the same type, Change LC_FREQ_2K to be a unsigned 64bit constant and removed the '()' from the caller as a result. 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>
|
1012205182fb9470a1bd1620872103a09f566225 |
|
27-Aug-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/ddi: use struct for ddi buf translation tables Try to avoid confusion with ARRAY_SIZE()/2 and hdmi_level*2. Signed-off-by: Jani Nikula <jani.nikula@intel.com> [danvet: Resolve silent patch conflict (didn't even fail to build) with with Sonika's preceding patch to use the hsw_ddi_translations_fdi table to driver the fdi link training iteration loop. Also drop the double-write loop Damien spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
c5fe6a0637e8a9f407a87b78be6955067f01a4cd |
|
11-Aug-2014 |
Sonika Jindal <sonika.jindal@intel.com> |
drm/i915: Rename defines for selection of ddi buffer translation slot Renaming the HSW-specific macros for ddi buffer translation slot to denote the slot and not the vswing/pre-emph values as they are platform-dependent. This patch is based on top of the patch series for renaming the DP training vswing/pre-emph defines: http://lists.freedesktop.org/archives/intel-gfx/2014-August/050407.html v2: Creating single macro with argument for slot number (Damien) v3: Adding macro for num of translation entries (Damien) Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
d6699dd3a7f696a80a5f8e5bb6ecf6ff6dd7c998 |
|
09-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix wrong number of HDMI translation entries I keep telling myself that those tables aren't great because their size is the number of dwords we need to program and not the number of entries (number of dwords = number of entries * 2). And... I got it wrong when I refactored the code. Fortunately, it was only wrong when the VBT table (or the code parsing it) is itself erroneous. Long story short, it shouldn't matter, but still, there's a potential array overflow and random programming of the DDI translation tables. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> 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>
|
ac921bdde92a354e8c59ea185dff26dc2611ee81 |
|
01-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Remove now useless comments about the translation values We used to carry a default HDMI value in entry 9, but this entry got removed for both HSW and BDW. 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>
|
156ae28c9f327d2c026e91cfacb5e224bb760d66 |
|
01-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables We always write entries 0 to 8 from the DDI translation tables and then entry 9 for HDMI/DVI with the help of the VBT. We then don't need the failsafe HDMI entry in the DP/eDP/FDI tables. 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>
|
a26aa8baee6c274fc23efccf46e891e63c8d0a30 |
|
01-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/bdw: Provide the BDW specific HDMI buffer translation table Among the changes, the tables has only 10 entries instead of 12 on HSW and the index the the 800mV/0dB entry has changed. 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>
|
ce4dd49e97813740bd2b03ecdc51521be10f3bf1 |
|
01-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Gather the HDMI level shifter logic into one place The knowledge about the HDMI/DVI DDI translation table was scattered around. - info->hdmi_level_shift was initialized with 6, the index of the 800 mV, 0dB translation - A check on the VBT value was done to ensure it wasn't overflowing the translation table (< 0xC) - The actual programming was done in intel_ddi.c As we need to change that knowledge for Broadwell, let's gather everything into one place. 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>
|
3d51278af91f8e96077dad3a4c1cc0b19fa8ca25 |
|
29-Jul-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Make ddi_clock_gate() HSW/BDW specific Turns out we were again way too naive and optimistic, of course things will change. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
ad13d6048f5002f1c5ab21c71a5ee136a2d8e889 |
|
29-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Split the CDCLK retrieval per-platform This is only going to get worse, so split it now to avoid adding more cases to the if/else ladder. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
d664c0cece2dd410d8134aa820112e471e3592dd |
|
29-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0220ab6e00785da008bb3736737b877d45858608 |
|
29-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Split the BDW/HSW specific shared pll selection We'll need a different algorithm to select the shared DPLL. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
bf9584bd0e99bd284e115ea8eba9b02a5a2d7b4d |
|
29-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix stale comment for intel_ddi_pll_select() Since the run-time PM on DPMS series, this function has an outdated comment. Refresh it a bit. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
143b307c43dcfeae41a3b6c24a29fae4c70884f4 |
|
29-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Extract the HSW/BDW shared dpll init code So we can easily provide an alternate implementation in the future. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
f68d697eaf3278200a7fc3c8b1d95d72837b84d8 |
|
04-Aug-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: only hook up hpd pulse for DP outputs On HSW+, the digital encoders are shared between HDMI and DP outputs, with one encoder masquerading as both. The VBT should tell us if we need to have DP or HDMI support on a particular port, but if we don't have DP support and we enable the DP hpd pulse handler then we cause an oops. Don't hook up the DP hpd handling if we don't have a DP port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856 Reported-by: Intel QA Team. Signed-off-by: Dave Airlie <airlied@redhat.com> # v1 [ickle: Fix the error handling after a malloc failure] Reviewed-by: Dave Airlie <airlied@redhat.com> Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
ca1381b55b715ae3435a0d600a345bad90233a9b |
|
15-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Make the WRPLL names const Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0e32b39ceed665bfa4a77a4bc307b6652b991632 |
|
02-May-2014 |
Dave Airlie <airlied@redhat.com> |
drm/i915: add DP 1.2 MST support (v0.7) This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
44905a27dd01f2bddd96664d0ab7da43a07f4d5a |
|
02-May-2014 |
Dave Airlie <airlied@redhat.com> |
i915: split some DP modesetting code into a separate function this is just prep work for mst support. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
df8ad70ca34f9bdf7e070d1a430bbdcac6acee12 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Only touch WRPLL hw state in enable/disable hooks To be able to do this we need to separately keep track of how many crtcs need a given WRPLL and how many actually actively use it. The common shared dpll framework already has all this, including massive state readout and cross checking. Which allows us to do this switch in a fairly small patch. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
716c2e55100ff5588bd2bbca14951ef11624cba2 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Switch to common shared dpll framework for WRPLLs Mostly this patch is one big excersize in deleting code and asserts which are no longer needed. Note that we still abuse the shared dpll framework a bit since we call the enable/disable functions from the crtc mode_set and off hooks. But changing the actual hardware sequence will be done in the next step. Note that besides the massive amount of changes in this patch the places and order in which the low-level WRPLL code is called is absolutely unchanged. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
e0b01be41dcdfd28c6855f605983a61b29f65692 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: ->enable hook for WRPLLs This time around another cute hack to pre-fill the pll->hw_state with the right values. And also remove a bunch of checks which will be replaced by lots more checks in the common framework. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
12030431e9ba407b8c35b3c3bf70b67d609447f3 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: ->disable hook for WRPLLs Currently still with a redudant WARN_ON in there, the common shared dpll code will take care of this in the future. Also we need to flip the switch for the transitional hack now to make sure that we disable the right pll. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
d452c5b67a6e2ae9f94df223919c107a8950910a |
|
04-Jul-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: State readout support for WRPLLs Still tacked onto the side, but slowly getting there. v2: Don't forget the debugfs file. v3 (from Paulo): Don't forget to check the power domains. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> 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>
|
9cd86933fe250fd3e698b62505dfe2d43326baaa |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Basic shared dpll support for WRPLLs Just filing in names and ids, but not yet officially registering them so that the hw state cross checker doesn't completely freak out about them. Still since we do already read out and cross check config->shared_dpll the basics are now there to flesh out the wrpll shared dpll implementation. The idea is now to roll out all the callbacks step-by-step and then at the end switch to the shared dpll framework. This way hw and sw changes are clearly separated. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [imre: added const to hsw_ddi_pll_names (Damien)] Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0e50338cf0f0009a5c9bc847a4c86a1d4438af66 |
|
04-Jul-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Precompute static ddi_pll_sel values in encoders This way only the dynamic WRPLL selection for hdmi ddi mode is done in intel_ddi_pll_select. v2: Don't clobber the precomputed values when selecting clocks fro hdmi encoders. v3 (from Paulo): Rebase on top of the s/IS_HASWELL/HAS_DDI/ patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
26804afd4b3c7a1ff577db4d70df8055c7901ff4 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: State readout and cross-checking for ddi_pll_sel To make things a bit more manageable extract a new function for reading out common ddi port state. This means a bit of duplication between encoders and the core since both look at the same registers, but doesn't seem worth to make a fuzz about. We can also remove the state readout code in intel_ddi_setup_hw_pll_state. That code is only called from the hardware take over and not the cross check code, and only after the crtc state is reconstructed. So we can rely on an accurate value of crtc->config.ddi_pll_sel already. Compared to the old code also trust the hw state more and don't special-case port A - we want to cross-check the actual-state, not bake in our own assumptions about how this is supposed to all be linked up. v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
de7cfc635e4ce20ded5ca4e40328386d9ba81922 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Move ddi_pll_sel into the pipe config Just boring sed job for preparation. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
abfdc1e375aefb3945cdd9b408059b35f4f4f4ec |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Move SPLL disabling into hsw_crt_post_disable Similar to how the ->crtc_mode_set hook should touch the hardware to enable anything the ->crtc_off hook should disable anything in the hardware. Otherwise runtime pm for dpms will not work. Currently the only things left int the haswell_crtc_off hook is disabling the ddi plls. We can't move the WRPLL enabling out yet because the current ddi pll sharing code used by the haswell code doesn't separately track active users and overall users. This must be fixed by porting it to the generic shared display pll framework, which is powerful enough. But the SPLL source is only used by the crt encoder and so can be moved already. We only need to make sure that the ddi port E is already off, which hsw_fdi_disable does by calling intel_ddi_post_disable. With this the code reorg to shuffle hsw fdi/lpt specific code into a new hsw-specific crt encoder type is now finally complete. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
082717ead9f5836fac1b2757aad38f652cc63636 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Move the SPLL enabling into hsw_crt_pre_enable The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only function that still touches the hardware state from the crtc mode_set callback on hsw. Since the SPLL isn't ever shared we can easily take it out into the hsw crt encoder functions. Temporarily we'll loose a bit of WARN_ON coverage with this, but once the WRPLLs are switched over that will be restored. For the SPLL selection add a WARN in the hsw fdi link training code. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [imre: rebased on patchset version w/o pch/crt/fdi refactoring] Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
114fe4885721d985907fbfb0d1a0c1c6676b4543 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Clean up WRPLL/SPLL #defines Luckily the bit definitions match, but it's still confusing to use one when handling the other. So sprinkle some OCD over the #defines to make them match and use the right version in each place. Maybe we should unify these definitions completely, but that can always be done sometime in the future. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
7ca1ac135bc4d566e460230133ff959bb1bfcf88 |
|
25-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Remove spll_refcount for hsw SPLL would be a reference clock we could potentially share, especially if we want to use the SSC mode. But currently we don't, so let's rip out this complexity for a simpler conversion to the new display pll framework. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
fabf6e513f640dac89645e1a98376eb8064394ee |
|
29-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Support pf CRC source on haswell transcoder edp The always-on power well pixel path on haswell is routed such that it bypasses the panel fitter when we use is. Which means the pfit CRC source won't work in that configuration. Add a new disallow-bypass flags to the pfit pipe config state and set it when we want to use the pf CRC. Results in a bit of flicker, but should get the job done. We'll also undo do it afterwards to make sure other tests arent' negatively affected. Totally untested due to lack of hsw laptops around here. v2: s/disallow_bypass/force_power_well_on/ to avoid a double negative (Damien). v3: force_thru because roadsigns. v4: Don't forget the power wells! Also note that until the runtime pm for DPMS series is fully merged the simple disable/enable trick won't work since the ->crtc_mode_set callback is still required to do nasty things. This stuff is tricky, but I think by both fixing up get_crtc_power_domains and the debugfs wa code we should always grab/drop the additional power well correctly. v5: Wrap in () as suggested by Damien to avoid setting reserved values for the edp transcoder path on bdw+ References: https://bugs.freedesktop.org/show_bug.cgi?id=72864 Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Tested-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
13cf550448b58abf8f44f5d6a560f2d20871c965 |
|
18-Jun-2014 |
Dave Airlie <airlied@redhat.com> |
drm/i915: rework digital port IRQ handling (v2) The digital ports from Ironlake and up have the ability to distinguish between long and short HPD pulses. Displayport 1.1 only uses the short form to request link retraining usually, so we haven't really needed support for it until now. However with DP 1.2 MST we need to handle the short irqs on their own outside the modesetting locking the long hpd's involve. This patch adds the framework to distinguish between short/long to the current code base, to lay the basis for future DP 1.2 MST work. This should mean we get better bisectability in case of regression due to the new irq handling. v2: add GM45 support (untested, due to lack of hw) Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Todd Previte <tprevite@gmail.com> [danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling race fixes and a trivial one in intel_drv.h with the psr code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
9576c27f5287f873505583350049100896a48299 |
|
13-Jun-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: update BDW DDI buffer translations Two BSpec updates changed the recommended values for BDW eDP and DP DDI buffer translations. Now the signal levels also match the HSW signal levels, which simplify things a little bit. It seems some DP sinks don't work properly without voltage level 0 and pre-emphasis level 3, so this patch may fix some bugs on panels/monitors that happen on BDW but not on HSW. 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>
|
d45a0bf549cda7ab77f3ffce6db1b27b7b435316 |
|
21-May-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: grab the audio power domain when enabling audio on HSW+ With the current code, we unconditionally touch HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power well is off, and that will trigger an "Unclaimed register" message. Just adding the intel_crtc->config.has_audio should already avoid the unclaimed register messsages, but since we actually need the power well to make the Audio code work, it makes sense to also grab the audio power domain reference, and release it when it's not needed anymore. I used IGT's pm_rpm to reproduce this bug, but it can probably be reproduced on other tests that do modesets. I'm using a machine with eDP+HDMI connected. Regression introduced by: commit acfa75b02e72bad7c93564ac379712e29c001432 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:51 2014 +0200 drm/i915: Simplify audio handling on DDI ports Credits to Daniel for suggesting this implementation. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
a60551b1c9478dc2aaef9e87d6dc7e54e76714b5 |
|
21-May-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't read HSW_AUD_PIN_ELD_CP_VLD when the power well is off Because this will trigger "Unclaimed register" messages. All I need to reproduce this problem is to boot my HSW machine with eDP+HDMI connected. Regression introduced by: commit 9ed109a7b445e3f073d8ea72f888ec80c0532465 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
30cf6db8b242e6bc7a660403471d2d78445f4860 |
|
24-Apr-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915/ddi: Remove ->mode_set callback A bit more care required here since there are some very few things between the call to encoder->mode_set and encoder->pre_enable. But they're either book-keeping or only matter for the vga port on the pch. So of no concern. Note that with the new sequence we write the infoframes after selecting the clock source, but that shouldn't matter. I've simply opted for this to have simpler code. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
9ed109a7b445e3f073d8ea72f888ec80c0532465 |
|
24-Apr-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Track has_audio in the pipe config Including state readout and cross-checking. This allows us to get rid of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy if the BIOS hasn't set up the audio routing like we want it too. Wrt fastboot and external screens I see a few options: - Don't. - Try to fix up eld, infoframes and audio settings after the fact. But that means some pretty extensive reworking of our code which currently does all this while the pipe/port is still off. I won't bother with converting SDVO over to this because the audio support for SDVO is very lacking: - We don't update the eld. - We don't update the audio state on the sdvo encoder. - We don't check whether the platform can even feed audio to the sdvo encoder. I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi and dp converted and so doing it step-by-step would have required a few intermediate hacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
acfa75b02e72bad7c93564ac379712e29c001432 |
|
24-Apr-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Simplify audio handling on DDI ports There's no need to check whether audio is enabled (which for ddi ports is done through the crtc->eld_vld flag) since at the cost of a potentially unecessary register rmw cycle we can unconditionally do this. Note that the edp check is just paranoia since we won't ever call the write_eld function for an edp panel. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
6897b4b5d3336a0a02d94225de971985c7ad42fe |
|
24-Apr-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Track hdmi mode in the pipe config Also add state readout and cross-check support. The only invasive change is wiring up the new flag to the ->set_infoframes callbacks. Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
882244a3404088113f1add19d2d029f83e69efeb |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix WARNs when reading DDI state while suspended If runtime PM is enabled and we unset all modes, we will runtime suspend after __intel_set_mode() , then function intel_modeset_check_state() will try to read the HW state while it is suspended and trigger lots of WARNs because it shouldn't be reading registers. So on this patch we make intel_ddi_connector_get_hw_state() return false in case the power domain is disabled, and we also make intel_display_power_enabled() return false in case the device is suspended. Notice that we can't just use intel_display_power_enabled_sw() because while the driver is being initialized the power domain refcounts are not reflecting the real state of the hardware. Just for reference, I have previously published an alternate patch for this problem, called "drm/i915: get runtime PM at intel_set_mode". Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
825938307f812c7cbfe064c7884bd8bdb27c2144 |
|
17-Mar-2014 |
Jani Nikula <jani.nikula@intel.com> |
Revert "drm/i915: don't touch the VDD when disabling the panel" This reverts commit dff392dbd258381a6c3164f38420593f2d291e3b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel which didn't take into account commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel and commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air Unsurprisingly, various MacBooks failed. Effectively the same has already been done in drm-intel-next-queued. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628 Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
24f3e092b8e2939365e2105c2eed3e3db2813aa6 |
|
17-Mar-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: finish off reverting eDP VDD changes This is a small follow-up fix to the series of eDP VDD back and forth we've had recently. This is effectively a combined revert of three commits: commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 7 20:05:20 2014 -0300 drm/i915: properly disable the VDD when disabling the panel commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd commit dff392dbd258381a6c3164f38420593f2d291e3b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel which shows that we're pretty close back to where we started already. The first two were basically reverting the last, but missing the WARN. Add that back. We also OCD the intel_ prefix back to intel_edp_panel_vdd_on() which was lost somewhere in between. The circle closes. For future reference, "drm/i915: don't touch the VDD when disabling the panel" failed to take into account commit 6cb49835da0426f69a2931bc2a0a8156344b0e41 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel and commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
849e39f5d7e52eb44d37bbd5ce695f7cdcbe923c |
|
08-Mar-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: properly disable the VDD when disabling the panel Commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 tried to revert commit dff392dbd258381a6c3164f38420593f2d291e3b, but wasn't complete, which resulted in regressions on Haswell. So this commit should fix b3064154dfd37deb386b1e459c54e1ca2460b3d5 by undoing what it did and providing an actual complete revert of dff392dbd258381a6c3164f38420593f2d291e3b. Fixes regression introduced by: commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
bc079e8b1684e1de505ec06f8c2339ae60a329e8 |
|
03-Mar-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make encoder cloning more flexible Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
6d129beac7099bddad368b6a02e8e0a67f59e9b8 |
|
05-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: check port power domain when reading the encoder hw state Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
e3589908592cae966fa00dd9ef48a208705d3365 |
|
07-Feb-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Consolidate FUSE_STRAP in one set of defines We had 2 set of defines for the same register, so make it one. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
20f0ec16ca5c51accdb9a7631411b39aa6b4256e |
|
22-Jan-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
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>
|
11578553d354f3408e5eff5ca87c44a0296a5e80 |
|
21-Jan-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
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>
|
4be7378004a0bfb75adfacd0a943547e18bfa688 |
|
17-Jan-2014 |
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>
|
0882dae983707455e97479e5e904e37673517ebc |
|
08-Jan-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix DDI PLLs HW state readout code Properly zero the refcounts and crtc->ddi_pll_set so the previous HW state doesn't affect the result of reading the current HW state. This fixes WARNs about WRPLL refcount if we have an HDMI monitor on HSW and then suspend/resume. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379 Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
566b734a190766f25f21c8c44633c14a122e61fa |
|
25-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: split intel_ddi_pll_mode_set in 2 pieces The first piece, intel_ddi_pll_select, finds a PLL and assigns it to the CRTC, but doesn't write any register. It can also fail in case it doesn't find a PLL. The second piece, intel_ddi_pll_enable, uses the information stored by intel_ddi_pll_select to actually enable the PLL by writing to its register. This function can't fail. We also have some refcount sanity checks here. The idea is that one day we'll remove all the functions that touch registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll call intel_ddi_pll_select at haswell_crtc_mode_set and then call intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already touching this code, let's take care of this particular split today. v2: - Clock on the debug message is in KHz - Add missing POSTING_READ Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Bikeshed comments.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
dff392dbd258381a6c3164f38420593f2d291e3b |
|
06-Dec-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't touch the VDD when disabling the panel I don't see a reason to touch VDD when we're disabling the panel: since the panel is enabled, we don't need VDD. This saves a few sleep calls from the vdd_on and vdd_off functions at every modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo. Also drop the runtime_pm_put call which now has to go due to different patch ordering. Also from Paul.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
9b33600d52fab54df1aa82ea0d70c113060c293a |
|
06-Dec-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't enable VDD just to enable the panel We just don't need this. This saves 250ms from every modeset on my machine. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
e1b22732485396dda9b8eab90cdd1c636efc0a3e |
|
03-Dec-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix copy/paste DP vs eDP error in comment It's all about tiny details. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
5d8a77529bd6864361005117c3a611b6d810aa77 |
|
01-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Check VBT for eDP ports on VLV VLV can have eDP on either port B or C, or even both. Based on the VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we check the correct ports. So instead of hardcoding port D, rename the function to intel_dp_is_edp() and pass the port as a parameter, and use it on VLV ports B and C. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051 Tested-by: Robert Hooker <robert.hooker@canonical.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Wrestle the patch to apply and compile properly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
76bb80ed3027fc51af24a378a5986672dc01398f |
|
15-Nov-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/ddi: set sink to power down mode on dp disable Similar to commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Nov 12 17:10:13 2013 +0200 drm/i915/dp: set sink to power down mode on dp disable but for DDI, where we've never done this. 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>
|
1021442098ee9328fdd4d113d63a3a7f2f40c37b |
|
18-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Replicate BIOS eDP bpp clamping hack for hsw Haswell's DDI encoders have their own ->get_config callback and in commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Oct 21 10:52:07 2013 +0300 drm/i915/dp: workaround BIOS eDP bpp clamping issue we've forgotten to replicate this hack. So let's do it that. Note for backporters: The above commit and all it's depencies need to be backported first. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049 Cc: stable@vger.kernel.org Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0694001b27efe5878ba5bd273e39b384821d865e |
|
30-Oct-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: reuse WRPLL when possible It seems we do have machines with 3 HDMI/DVI outputs, so sharing WRPLLs is the only way to get 3 pipes working. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68485 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>
|
77d8d00944dd5a0a2f4f67809819df927ee23030 |
|
03-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/bdw: check DPD on port D when setting the DDI buffers Use the eDP values on platforms where port D is eDP. This doesn't affect Haswell since it uses the same DDI buffer values for eDP and DP. Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
300644c7dc4699fe9afb61b280aa5ed7109a4d93 |
|
03-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/bdw: add BDW DDI buf translations for eDP Broadwell has different DDI buffer translations for eDP and DP, so add support for the missing eDP and keep Haswell the same. A future patch addresses the suggestion from Art to check for eDP on port D and use the eDP values there, too. v2: Make checkpatch happy. Reviewed-by: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
e58623cb65dfa40f0ed9f6f9ddbca91aee3c9bd2 |
|
03-Nov-2013 |
Art Runyan <arthur.j.runyan@intel.com> |
drm/i915/bdw: Add BDW DDI buffer translation values Many of the DDI buffer translation values have changed for BDW. Add new translation tables and selection between HSW and BDW. v2: s/BUG/WARN/ to avoid breaking future GENs. v3: Rebase on top of the hdmi translation table changes. v4: Fix up the multiline comment while at it. Signed-off-by: Art Runyan <arthur.j.runyan@intel.com> (v2) Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
e39bf98a91abd5c8fb290f139521dddc3db3c37d |
|
03-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/bdw: get the correct LCPLL frequency on Broadwell v2: Rebased onto Paulo's MHz->kHz change. v3: Rebased on top of the Haswell pc8+ adjustements. v4: Use the exact 337.5MHz clock, should have been done as part of v2. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
c7670b1098b1a05c5266a7d3d2f07165621e7de9 |
|
03-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915/bdw: on Broadwell, the panel fitter is on the pipe So you can use the panel fitter while the power well is disabled and you also don't need to set the "pipe" bit. v2: Rebased on top of Jesse's pfit refactor, which moved pfit state into the pipe_config. v3: Rebase on top of the latest Haswell/panel fitter rework, which neatly resolves a FIXME we have in this patch here: v4: Rebase on top of the new power domain framework. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
7195a50b5c7e00cc3312934fd022c3006b533d12 |
|
24-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add HSW CRT output readout support Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. Note: This is already merged in drm-intel-next-queued as commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Sep 24 14:24:05 2013 +0300 drm/i915: Add HSW CRT output readout support but is required for the following edp bpp bugfix. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691 Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4f56d12ebb28fceac4c6e60c8993fbfc122e1399 |
|
21-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add support for pipe_bpp readout On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Note: This is already in drm-intel-next-queued as commit 42571aefafb1d330ef84eb29418832f72e7dfb4c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 6 23:29:00 2013 +0300 drm/i915: Add support for pipe_bpp readout but is needed for the following bugfix. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4a28ae58c0abad2d45a45db21e86c7166b2b4462 |
|
09-Oct-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't leak dp_connector at intel_ddi_init Regression introduced by: commit 311a20949f047a70935d6591010f42336f5402e7 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't init DP or HDMI when not supported by DDI port Since the commit above it is possible to have a DDI encoder that has the HDMI connector but not the DP connector (in case the port doesn't support DP). In this case, we must properly free the DP connector. We just leak this once, so it's not a big deal. Reported by kmemleak. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
6aba5b6cf098ba305fc31b23cc14114a16768d22 |
|
04-Oct-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: get rid of intel_dp->link_configuration It's not really needed, rather just adds another place to hold intermediate values that could go wrong, and it's not clear that the training pattern set or training lane set should be written at this point at all. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
6801c18c0a43386bb44712cbc028a7e05adb9f0d |
|
24-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add HSW CRT output readout support Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691 Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
311a20949f047a70935d6591010f42336f5402e7 |
|
12-Sep-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't init DP or HDMI when not supported by DDI port There's no reason to init a DP connector if the encoder just supports HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP AUX transactions to detect if there's something there. Same goes for a DP connector that doesn't support HDMI, but I'm not sure these actually exist. v2: - Use bit fields - Remove useless identation level - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
6acab15a7b0d2722924c5d671cb29974791beece |
|
12-Sep-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: use the HDMI DDI buffer translations from VBT We currently use the recommended values from BSpec, but the VBT specifies the correct value to use for the hardware we have, so use it. We also fall back to the recommended value in case we can't find the VBT. In addition, this code also provides some infrastructure to parse more information about the DDI ports. There's a lot more information we could extract and use in the future. v2: - Move some code to init_vbt_defaults. v3: - Rebase - Clarify the "DVO Port" matching code v4: - Use I915_MAX_PORTS - Change the HAS_DDI checks - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
b14c5679dd2c87b5bd14c49c5bdd1962be2ab209 |
|
19-Sep-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) pattern Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
eb14cb747bc53465cbc93e54d9f19f49eed2c0c7 |
|
10-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add state readout and checking for has_dp_encoder and dp_m_n Add functions to read out the CPU and PCH transcoder M/N values, and use them to fill out the pipe config dp_m_n information. And while at it populate has_dp_encoder too. Also refactor ironlake_get_fdi_m_n_config() to simply call the new intel_cpu_transcoder_get_m_n() function. v2: Remember the DDI Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
42571aefafb1d330ef84eb29418832f72e7dfb4c |
|
06-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add support for pipe_bpp readout On CTG+ read out the pipe bpp setting from hardware and fill it into pipe config. Also check it appropriately. v2: Don't do the pipe_bpp extraction inside the PCH only code block on ILK+. Avoid the PIPECONF read as we already have read it for the PIPECONF_EANBLE check. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
a666283e9061c58fc888ddf1d9fc552123f1f014 |
|
10-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix HSW sync flags to use pipe config adjusted_mode intel_ddi_enable_transcoder_func() picked the sync flags from crtc->mode instead of the pipe config adjusted_mode. Fix the problem and hopefully rid my HSW machine of the remaining pipe config warnings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
fd4daa9cea025ddf8623db289e79d264e9fa66f6 |
|
27-Aug-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track pfit enable state separately from size Detangle the additional state of whether or not the hw has the pfit enabled from whether it has zero size. This allows us to cleanly distinguish in the code when we expect the pfit to be enabled (for Haswell pc8), and when the BIOS is confused and needs sanitizing. Reported-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251 Tested-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
20f4dbe45950e462aa7c3243f95c0d8bcc369ca0 |
|
30-Aug-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: expose intel_ddi_get_encoder_port() In preparation for followup work. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
a40066412cc2ace1c1299e7a4d7a81dc33395b6f |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq We already have code to disable LCPLL and switch to FCLK, so we need this too. We still don't call the code to disable LCPLL, but we'll call it when we add support for Package C8+. 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>
|
ad8d270c21aa2f57f0cd578b1737f65c44c34b80 |
|
05-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: remove use_fdi_mode argument from intel_prepare_ddi_buffers We set the mode based on the port, and we already pass the port as an argument. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
f72d19f069f8efaa535aacc719d23d469b0d9f18 |
|
05-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: silence useless messages about DDI buffer translation These messages are not really useful since it's very easy to check which mode is used for each port: The values programmed are based on the port type, then assigned to the ddi_translations variable. Currently we use DP mode for ports A-D and FDI mode for port E. Also, when we add the code to enable/disable PC8+, intel_prepare_ddi_buffers will be called more often and will eat your dmesg buffers. While at it, fix the coding style of the "for" statement above. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp commit message with Paulo's more detailed explanation of how the ddi translation buffer settings are computed, to answer a question from Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
c7d8be305aa28dd809dedd401adcd4da8e4f9144 |
|
21-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915/ddi: use the native encoder ->mode_set callback Same conversion as for hdmi/dp. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4906557eb37b7fef84fad4304acef6dedf919880 |
|
11-Jul-2013 |
Rodrigo Vivi <rodrigo.vivi@gmail.com> |
drm/i915: Hook PSR functionality PSR must be enabled after transcoder and port are running. And it is only available for HSW. v2: move enable/disable to intel_ddi v3: The spec suggests PSR should be disabled even before backlight (by pzanoni) v4: also disabling and enabling whenever panel is disabled/enabled. v5: make it last patch to avoid breaking whenever bisecting. So calling for update and force exit came to this patch along with enable/disable calls. v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo. CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Drop the psr exit code in the busy ioctl since I didn't merge that part of the infrastructure yet - it needs more thought.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
bcf53de4e60d9000b82f541d654529e2902a4c2c |
|
12-Jul-2013 |
Stéphane Marchesin <marcheu@chromium.org> |
drm/i915: Preserve the DDI_A_4_LANES bit from the bios Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes on eDP. This fixes eDP on hsw with > 2 lanes. Also s/port_reversal/saved_port_bits/ since the current name is confusing. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
15b1d171d87e86366266255462e6b11d21b61c1c |
|
12-Jun-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix the "ghost eDP" encoder unwind path Because calling intel_dp_encoder_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_encoder_destroy function we do the following: 1 - Call i2c_del_adapter 2 - Call drm_encoder_cleanup 3 - If edp: 3.1 - Cancel panel_vdd_work 3.2 - Call ironlake_panel_vdd_of_sync 4 - Free the encoder And here is how we unwind each specific step: 1 - We have intel_dp_init_connector -> intel_dp_i2c_init -> i2c_dp_aux_add_bus -> i2c_add_adapter, so we call i2c_del_dapter at intel_dp_init_connector 2 - Call it in the same function that called drm_encoder_init 3 - Call it in the same function that called INIT_DELAYED_WORK 4 - Free it in the same function that allocated it Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
b2f246a8998ccf9e00477c8829a62139804e9857 |
|
12-Jun-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix the "ghost eDP" connector unwind path Because calling intel_dp_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_destroy function we do the following: 1 - Free edid if it exists 2 - Call intel_panel_fini in case it's eDP 3 - Call drm_sysfs_connector_remove 4 - Call drm_connector_cleanup 5 - Free the connector And here is how we unwind each specific step: 1 - No need as we still didn't assign anything 2 - No need as we still didn't call intel_panel_init 3 - Call it in the same function that called drm_sysfs_connector_add 4 - Call it in the same function that called drm_connector_init 5 - Free it in the same function that allocated it Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
16c255335b0ec39b4e5e976f4b260978aeed5a68 |
|
12-Jun-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: propagate errors from intel_dp_init_connector In case we detect a "ghost eDP", intel_edp_init_connector frees both the connector and encoder and then returns. On Haswell, intel_ddi_init then tries to use the freed encoder on the HDMI initialization path since the following commit: commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 10 23:28:35 2013 +0200 drm/i915: don't setup hdmi for port D edp in ddi_init So now on intel_ddi_init we check for the "ghost eDP" case and return without trying to initialize HDMI. This way we won't try to read the freed "intel_encoder" struct in the next "if" statement. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
ef1b460d1bab7e5b04c34f88c3dfa042528e7c27 |
|
01-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: set default value for config->pixel_multiplier This way we can simplify the code quite a bit. Also add a WARN in the sdvo code to complain about a bogus value and kill the readout code in intel_ddi.c that Jesse sneaked in. HW state readout for the pixel multiplier will work a bit differently in the end. v2: Rebase on top of the fdi pixel mutliplier handling fix. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
ff9a6750aca3553c78385a9aa89b678b2b9be7df |
|
01-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: store adjusted dotclock in adjusted_mode->clock ... not the port clock. This allows us to kill the funny semantics around pixel_target_clock. Since the dpll code still needs the real port clock, add a new port_clock field to the pipe configuration. Handling the default case for that one is a bit tricky, since encoders might not consistently overwrite it when retrying the crtc/encoder bw arbitrage step in the compute config stage. Hence we need to always clear port_clock and update it again if the encoder hasn't put in something more specific. This can't be done in one step since the encoder might want to adjust the mode first. I was a bit on the fence whether I should subsume the pixel multiplier handling into the port_clock, too. But then I decided against this since it's on an abstract level still the dotclock of the adjusted mode, and only our hw makes it a bit special due to the separate pixel mulitplier setting (which requires that the dpll runs at the non-multiplied dotclock). So after this patch the adjusted_mode accurately describes the mode we feed into the port, after the panel fitter and pixel multiplier (or line doubling, if we ever bother with that) have done their job. Since the fdi link is between the pfit and the pixel multiplier steps we need to be careful with calculating the fdi link config. v2: Fix up ilk cpu pll handling. v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config to make it clearer that we transmit the adjusted_mode without the pixel multiplier taken into account. The old code multiplied the the available link bw with the pixel multiplier, which results in the same fdi configuration, but is much more confusing. v4: Rebase on top of Imre's is_cpu_edp removal. v5: Rebase on top of Paulo's haswell watermark fixes, which introduce a new place which looked at the pixel_clock and so needed conversion. v6: Split out prep patches as requested by Paulo Zanoni. Also rebase on top of the fdi dotclock handling fix in the fdi lanes/bw computation code. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
eccb140bca6727f2ef849e8811d5fe4c9fbfd5dd |
|
22-May-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: hw state readout&check support for cpu_transcoder This allows us to drop a bunch of ugly hacks and finally implement what commit cc464b2a17c59adedbdc02cc54341d630354edc3 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Jan 25 16:59:16 2013 -0200 drm/i915: set TRANSCODER_EDP even earlier tried to achieve, but that was reverted again in commit bba2181c49f1dddf8b592804a1b53cc1a3cf408a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Mar 22 10:53:40 2013 +0100 Revert "drm/i915: set TRANSCODER_EDP even earlier" Now we should always have a consistent cpu_transcoder in the pipe_config. v2: Fix up the code as spotted by Paulo: - read the register for real - assign the right pipes - break out if the hw state doesn't make sense v3: Shut up gcc. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
b2b877ffe37d699f77f45e993590b66010491c52 |
|
03-May-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: make intel_ddi_get_cdclk_freq return values in KHz With this, that 338 can finally become the correct 337500. Due to the change we need to adjust the intel_dp_aux_ch function to set the correct value, so adjust the division and also use DIV_ROUND_CLOSEST instead of the old "round down" behavior because the spec says the value "should be programmed to get as close as possible to the ideal rate of 2MHz". Quoting Paulo's follow-up to a question from Chris Wilson to explain what exactly will change: I use the 337500 value on the next patch, when setting the ips_linetime value. The correct frequency is 337500, not 338000. ips_linetime = DIV_ROUND_CLOSEST(mode->htotal * 1000 * 8, intel_ddi_get_cdclk_freq); For a mode with htotal of 2640 [0] we'll have: (i) (2640 * 1000 * 8) / 338000 = 62.48, resulting in 62 and (ii) (2640 * 1000 * 8) / 337500 = 62.57 resulting in 63. For the case inside intel_dp.c: Previously we were using 338. So with the old formula we were writing 338/2 = 169 to the register. And 337500 / 169 = 1997.04 (we use 337500 here because it's the real clock value). With the new value of 337500/2000 we'll have 168.75, which is 168 on the round-down case and 169 on the round-closest case. If we write 168 to the register, 337500 / 168 = 2008.92, and 2008.92 is more distant from 2000 than 1997.04. So with this patch we're changing the formula but still writing the same correct value to the DP AUX register. [0]: That's 1920x1080@50Hz on my DP monitor. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp the commit message with Paulo's follow-up.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
045ac3b5629d9711531a408e92f9074db6afe7ce |
|
15-May-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add encoder get_config function v5 We can use this for fetching encoder specific pipe_config state, like mode flags, adjusted clock, etc. Just used for mode flags atm, so we can check the pipe config state at mode set time. v2: get_config when checking hw state too v3: fix DVO and LVDS mode flags (Ville) get SDVO DTD for flag fetch (Ville) v4: use input timings (Ville) correct command used (Ville) remove gen4 check (Ville) v5: get DDI flag config too Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4) Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
1c0b85c566b7a5a5cdabb767a39b445ce271a4fa |
|
10-May-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Compute WR PLL dividers dynamically Up to now, we were using a static table to match the clock frequency with a (r2,n2,p) triplet. Despite this table being big, it's by no mean comprehensive and we had to fall back to the closest frequency when the requested TMDS clock wasn't in the table. This patch computes (r2,n2,p) dynamically and get rid of The Big Table. v2: Replace the floating point constant 1e6 by 1000000 Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497 Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) [danvet: s/ /^T/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
8693a824873a0a97be77c1d5f1e98777f06f7305 |
|
03-May-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Add references to some workaround we implement We did not mention the workaround name when implementing those. This should help us track what we already implement. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
c77bf5659deb9405ef61080c148e47d2c8ee31e5 |
|
03-May-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: only disable DDI sound if intel_crtc->eld_vld We already have the same check on intel_enable_ddi. This patch prevents "unclaimed register" messages when the power well is disabled. V2: Reset intel_crtc->eld_vld to false after the mode_set function. V3: Add both "type != INTEL_OUTPUT_EDP" requested. 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>
|
21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 |
|
10-Apr-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: don't setup hdmi for port D edp in ddi_init dp_init_connector adjusts the encoder type if it is a eDP panel. Use that to decide whether we should set up a hdmi connector or not. To do so reorder the hdmi connector setup sequence in ddi_init a bit. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9 |
|
02-May-2013 |
Imre Deak <imre.deak@intel.com> |
drm/i915: hsw: fix link training for eDP on port-A According to BSpec the link training sequence for eDP on HSW port-A should be as follows: 1. link training: clock recovery 2. link training: equalization 3. link training: set idle transmission mode 4. display pipe enable 5. link training: disable (set normal mode) Contrary to this at the moment we don't do step 3. and we do step 5. before step 4. Fix this by setting idle transmission mode for eDP at the end of intel_dp_complete_link_train and adding a new intel_dp_stop_link_training function to disable link training. With these changes we'll end up with the following functions corresponding to the above steps: intel_dp_start_link_train -> step 1. intel_dp_complete_link_train -> step 2., step 3. intel_dp_stop_link_train -> step 5. For port-A we'll call intel_dp_stop_link_train only after enabling the pipe, for everything else we'll call it right after intel_dp_complete_link_train to preserve the current behavior. Tested on HSW/HSW-ULT. In v2: - Due to a HW issue we must set idle transmission mode for port-A too before enabling the pipe. Thanks for Arthur Runyan for explaining this. - Update the patch subject to make it clear that it's an eDP fix, DP is not affected. v3: - rename intel_dp_link_train() to intel_dp_set_link_train(), use 'val' instead 'l' as var name. (Paulo) Signed-off-by: Imre Deak <imre.deak@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>
|
17aa6be9579eb204b426eeae146a43bf3dd05078 |
|
30-Apr-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: simplify DP/DDI port width macros If we ever leak a non-DP compliant port width through here, we have a pretty serious issue. So just rip out all these WARNs - if we need them it's probably better to have them at a central place where we compute the dp lane count. Also use the new DDI width macro for FDI mode. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fixup the embarrassing s/intel_dp->DP/temp/ mistake Paulo spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
627eb5a318a6caca2145d3c7195b084c59b291d9 |
|
29-Apr-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: hw state readout support for pipe_config->fdi_lanes v2: Introduce some nice #defines for the FDI lane width fields and put them to good use. Suggested by Ville. v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and use the shift #define also in the mask. Cc: Imre Deak <imre.deak@intel.com> Cc: 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>
|
33d29b145305641f2c693b759cac468e0c87ab4d |
|
13-Feb-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move intel_crtc->fdi_lanes to pipe_config We need this for two reasons: - Correct handling of shared fdi lanes on ivb with fastboot. - Handling fdi link bw limits when we only have two fdi lanes by dithering down a bit. Just search&replace in this patch, no functional change at all. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
b074cec8c652f2d273907a4b35239b4766c894ac |
|
25-Apr-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: move PCH pfit controls into pipe_config And put the pfit stuff into substructs while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
bf98a72650c9272e70e7f0e904f85c025c0bb421 |
|
19-Apr-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Remove mention of Haswell in DDI code We are trying to have more platform-orthogonal pieces of code. The DDI code shouldn't mention Haswell. v2: Fix the email address Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
84f44ce795b3da9a08dc2041ecd60550d34c123e |
|
17-Apr-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Print plane, pipe, port names as alphabetical insted of decimal Alway use the alphabetical names in debug/error messages for planes, pipes and ports, instead of using decimal numbers occasionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
3b117c8f2815bc4dd36b0b2c4b6490ad7d10b758 |
|
17-Apr-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move cpu_transcoder to the pipe configuration For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) [danvet: Removed rough whitespace that Chris spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
22f9fe50597094970a9bcdf2464fc3b356fbedb6 |
|
02-Apr-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: fix DDI get_hw_state return value If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4e53c2e010e531b4a014692199e978482d471c7e |
|
27-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: precompute pipe bpp before touching the hw The procedure has now 3 steps: 1. Compute the bpp that the plane will output, this is done in pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also, this function clamps the pipe_bpp to whatever limit the EDID of any connected output specifies. 2. Adjust the pipe_bpp in the encoder and crtc functions, according to whatever constraints there are. 3. Decide whether to use dither by comparing the stored plane bpp with computed pipe_bpp. There are a few slight functional changes in this patch: - LVDS connector are now also going through the EDID clamping. But in a 2nd change we now unconditionally force the lvds bpc value - this shouldn't matter in reality when the panel setup is consistent, but better safe than sorry. - HDMI now forces the pipe_bpp to the selected value - I think that's what we actually want, since otherwise at least the pixelclock computations are wrong (I'm not sure whether the port would accept e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick the next higher bpc value, since otherwise there's no way to make use of the 12 bpc mode (since the next patch will remove the 12bpc plane format, it doesn't exist). Both of these changes are due to the removal of the pipe_bpp = min(display_bpp, plane_bpp); statement. Another slight change is the reworking of the dp bpc code: - For the mode_valid callback it's sufficient to only check whether the mode would fit at the lowest bpc. - The bandwidth computation code is a bit restructured: It now walks all available bpp values in an outer loop and the codeblock that computes derived values (once a good configuration is found) has been moved out of the for loop maze. This is prep work to allow us to successively fall back on bpc values, and also correctly support bpc values != 8 or 6. v2: Rebased on top of Paulo Zanoni's little refactoring to use more drm dp helper functions. v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color range work. v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed. v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked in a later patch though again. v6: Fix spelling in a comment. v7: Debug output improvements for the bpp computation. v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different things! v9: Reinstate the fix to properly ignore the firmware edp bpp ... this was lost in a rebase. v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have that. Still unsure whether this is the way to go, but at least 6bpc for a 8bpc hdmi output seems to work. v11: And g4x/vlv also lack 12bpc hdmi support, so only support high depth on DP. Adjust the code. v12: Rebased. v13: Split out the introduction of pipe_config->dither|pipe_bpp, as requested from Jesse Barnes. v14: Split out the special 6BPC handling for DP, as requested by Jesse Barnes. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
965e0c489f360df1beeb567e4540777a09b8896e |
|
27-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: introduce pipe_config->dither|pipe_bpp We want to compute this earlier. To avoid a big complicated patch, this patch here just does the big search&replace and still calls the old functions at the same places. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
5bfe2ac00395ca37219b7187299cd9d23ae06682 |
|
27-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: add pipe_config->has_pch_encoder This is used way too often in the enable/disable paths. And will be even more useful in the future. Note that correct semantics of this change highly depend upon correct updating of intel_crtc->config: Like with all other modeset state, we need to call ->disable with the old config, but ->mode_set and ->enable with the new config. v2: Do not yet use the flag in the ->disable callbacks - atm we don't yet have support for the information stored in the pipe_config in the hw state readout code, so this will be wrong at boot-up/resume. v3: Rebased on top of the hdmi/dp ddi encoder merging. v4: Fixup stupid rebase error which lead to a NULL vfunc deref. v5: On haswell the VGA port is on the PCH! v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing parameter name in a function declaration. v7: Don't forget to git add ... Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
a42f704b71b252705f34fbe60ea6f4a76f891a78 |
|
25-Mar-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Warn if a pipe is enabled with a bogus port If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect port, we are currently trying to read PORT_CLK_SEL(port) with an uninitialized value. Handle that case by returning PORT_CLK_SEL_NONE and warning about it. v2: Move the warning inside intel_ddi_get_crtc_pll (Paulo Zanoni) 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>
|
8228c251ba5eda4c74aa1c6306f0057a419ec1c7 |
|
07-Mar-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Rename intel_ddi_enable_pipe_func() to transcoder_func() We are really talking about the transcoder function here and the disable version uses trancoder in its name already, so let's try to be consistent. 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>
|
00037c2e95618c8a598ff41e2fc4d34367b0eb91 |
|
07-Mar-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Error out if we are trying to use VGA with SPLL already in use Our static analysis tool noticed that 'reg' could be used uninitialized if we are trying to get a PLL to drive VGA and SPLL is already in use (plls->spll_refcoung != 0). In the (error) case above, let's return false to the caller and emit an error. 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>
|
2831d8427cace563767cb802de05db28c4c6f894 |
|
07-Mar-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: disable sound first on intel_disable_ddi Our mode set sequence documentation says audio must be disabled first. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Resolve conflict since the first patch in this series isn't applied yet. Also bikeshed commit message as suggested by Ben.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
f3e227df8235fc0bf8ba08304aa135066ec9b9b0 |
|
24-Feb-2013 |
Syam Sidhardhan <syamsidhardh@gmail.com> |
drm/i915: Fix missing variable initilization Need to initialize the variable wait to false. Signed-off-by: Syam Sidhardhan <s.syam@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
b242b7f745650832f445dca3e19efc3dd2d65a66 |
|
18-Feb-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: rename sdvox_reg to hdmi_reg on HDMI context Some (but not all) of the HDMI registers can be used to control sDVO, so those registers have two names. IMHO, when we're talking about HDMI, we really should call the HDMI control register "hdmi_reg" instead of "sdvox_reg", otherwise we'll just confuse people reading our code (we now have platforms with HDMI but without SDVO). So now "struct intel_hdmi" has a member called "hdmi_reg" instead of "sdvox_reg". Also, don't worry: "struct intel_sdvo" still has a member called "sdvo_reg". v2: Rebase (v1 was sent in May 2012). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
876a8cdf92b23d268275cdce4397df0c37dac3fe |
|
11-Dec-2012 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Preserve the DDI link reversal configuration Similarly to: commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Dec 11 15:18:28 2012 +0000 drm/i915: Preserve the FDI line reversal override bit on CPT DDI port support lane reversal to easy the PCB layouting work. Let's preserve the bit configured by the BIOS (until we find how to correctly retrieve the information from the VBT, but this does sound more fragile then just relying on the BIOS that has, hopefully, been validated already. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
3e68320ef84528604d971afc3cadfbe208bef001 |
|
11-Dec-2012 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Preserve the FDI line reversal override bit on CPT The FDI link has supported link reversal to make the PCB layout engineer's life easier for quite a while and we have always presered this bit as we programmed FDI_RX_CTL with a read/modify/write sequence. We're trying to take a bit more control over what the BIOS leaves in various register and with the introduction of DDI, started to program FDI_RX_CTL fully. There's a fused bit to indicate DMI link reversal and FDI defaults to mirroring that configuration. We have a bit to override that behaviour that we need to preserve from the BIOS. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
af5676f1f91585cabe811b8f697e32015e2be826 |
|
20-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out helper->disable noop functions Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 |
|
29-Jan-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: dynamic Haswell display power well support We can disable (almost) all the display hw if we only use pipe A, with the integrated edp transcoder on port A. Because we don't set the cpu transcoder that early (yet), we need to help us with a trick to simply check for any edp encoders. v2: Paulo Zanoni pointed out that we also need to configure the eDP cpu transcoder correctly. v3: Made by Paulo Zanoni - Rebase patch to be on top of "fix intel_init_power_wells" patch - Fix typos - Fix a small bug by adding a "connectors_active" check - Restore the initial code that unconditionally enables the power well when taking over from the BIOS v4: Made by Paulo Zanoni - One more typo spotted by Jani Nikula v5: Made by Paulo Zanoni - Rebase 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>
|
7b9f35a6dd72f89452c58bbdbaf063027bf857ec |
|
22-Jan-2013 |
Wang Xingchao <xingchao.wang@intel.com> |
drm/i915: HDMI/DP - ELD info refresh support for Haswell ELD info should be updated dynamically according to hot plug event. For haswell chip, clear/set the eld valid bit and output enable bit from callback intel_disable/eanble_ddi(). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
68d18ad7fbc16288aa230ec0ffb4416fd4363c87 |
|
01-Dec-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: set the LPT FDI RX polarity reversal bit when needed If we fail to set the bit when needed we get some nice FDI link training failures (AKA "black screen on VGA output"). While we don't really know how to properly choose whether we need to set the bit or not (VBT?), just read the initial value set by the BIOS and store it for later usage. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
248138b59880a3cc69e9b7f0e06fb0caedd58305 |
|
29-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix hsw_fdi_link_train "retry" code We were previously doing exactly what the "mode set sequence for CRT" document mandates, but whenever we failed to train the link in the first tentative, all the other subsequent retries always failed. In one of my monitors that has 47 modes, I was usually getting around 3 failures when running "testdisplay -a". After this patch, even if we fail in the first tentative, we can succeed in the next ones. So now when running "testdisplay -a" I see around 3 times the message "FDI link training done on step 1" and no failures. Notice that now the "retry" code looks a lot like the DP retry code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
1a240d4de2ccf40de5796a4d1dbb3a0236051fc9 |
|
29-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fixup sparse warnings - __iomem where there is none (I love how we mix these things up). - Use gfp_t instead of an other plain type. - Unconfuse one place about enum pipe vs enum transcoder - for the pch transcoder we actually use the pipe enum. Fixup the other cases where we assign the pipe to the cpu transcoder with explicit casts. - Declare the mch_lock properly in a header. There is still a decent mess in intel_bios.c about __iomem, but heck, this is x86 and we're allowed to do that. Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Use a space after the cast consistently and fix up the newly-added cast in i915_irq.c to properly use __iomem.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0d536cb4e911c2496073f268e9730a9badaafa55 |
|
23-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: invert the log inside intel_prepare_ddi Do an early return in case we don't have DDI instead of having the whole function inside an "if" statement. 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>
|
affa935440733a79c5a9eb0e5357e2564ca4b355 |
|
23-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add HAS_DDI check 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>
|
c1f63f9d688e68088ef743a48a3aa8e0dc01a160 |
|
23-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: intel_prepare_ddi_buffers should be static It's not even declared on header files. 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>
|
d567b07fce8f55f82e2cfe040cd74f7b4997ff38 |
|
20-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix intel_ddi_get_cdclk_freq for ULT machines For now, this code is just used by the eDP AUX channel frequency. 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>
|
8fed6193736bf22e0e44c03ee783761e9cc37238 |
|
19-Nov-2012 |
Takashi Iwai <tiwai@suse.de> |
drm/i915: Enable DP audio for Haswell This patch adds the missing code to send ELD for Haswell DisplayPort, based on Xingchao's original patch. A test was performed with HSW-D machine and NEC EA232Wmi DP monitor. Cc: Xingchao Wang <xingchao.wang@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
1ad960f25ca419ca337284b369cf78d84b6a439e |
|
02-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix Haswell FDI link disable path This covers the "Disable FDI" section from the CRT mode set sequence. This disables the FDI receiver and also the FDI pll. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
049456416f74a4a66d058cf9a46075f0051c6383 |
|
02-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix Haswell FDI link training code This commit makes hsw_fdi_link_train responsible for implementing everything described in the "Enable and train FDI" section from the Hawell CRT mode set sequence documentation. We completely rewrite hsw_fdi_link_train to match the documentation and we also call it in the right place. This patch was initially sent as a series of tiny patches fixing every little problem of the function, but since there were too many patches fixing the same function it got a little difficult to get the "big picture" of how the function would be in the end, so here we amended all the patches into a single big patch fixing the whole function. Problems we fixed: 1 - Train Haswell FDI at the right time. We need to train the FDI before enabling the pipes and planes, so we're moving the call from lpt_pch_enable to haswell_crtc_enable directly. We are also removing ironlake_fdi_pll_enable since the PLL enablement on Haswell is completely different and is also done during the link training steps. 2 - Use the right FDI_RX_CTL register on Haswell There is only one PCH transcoder, so it's always _FDI_RXA_CTL. Using "pipe" here is wrong. 3 - Don't rely on DDI_BUF_CTL previous values Just set the bits we want, everything else is zero. Also POSTING_READ the register before sleeping. 4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train According to the mode set sequence documentation, this is the right place. According to the FDI_RX_TUSIZE register description, this is the value we should set. Also remove the code that sets this register from the old location: lpt_pch_enable. 5 - Properly program FDI_RX_MISC pwrdn lane values on HSW 6 - Wait only 35us for the FDI link training First we wait 30us for the FDI receiver lane calibration, then we wait 5us for the FDI auto training time. 7 - Remove an useless indentation level on hsw_fdi_link_train We already "break" when the link training succeeds. 8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE When we fail the training. 9 - Change Haswell FDI link training error messages We shouldn't call DRM_ERROR when still looping through voltage levels since this is expected and not really a failure. So in this commit we adjust the error path to only DRM_ERROR when we really fail after trying everything. While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since it's what we use everywhere. 10 - Try each voltage twice at hsw_fdi_link_train Now with Daniel Vetter's suggestion to use "/2" instead of ">>1". Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Applied tiny bikesheds: - mention in comment that we test each voltage/emphasis level twice - realing arguments of the only untouched reg write, it spilled over the 80 char limit ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
349d7e5d7b27ee7b0b596ef1047e5c63908597fa |
|
01-Nov-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: set the correct number of FDI lanes on Haswell We had 2 places using X2 and one place using X1. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
00c09d70df6b30c980f20facc1db3def3f5a637e |
|
26-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: create the DDI encoder 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>
|
bcbc889bc44a781577479939490f6b7452d5b808 |
|
26-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add intel_ddi_connector_get_hw_state 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>
|
174edf1f867dc573439675f9b4c2211012d4b563 |
|
26-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add port field to intel_digital_port 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>
|
5de8bbf5536fe79c1353c5476c31409531b5393f |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: enable DDI eDP Now that all the eDP enablement bits are there, we can actually try to use the eDP. 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>
|
82a4d9c0a82a59c1f214ab1f9ce6b34d0736a54a |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: turn the eDP DDI panel on/off 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>
|
d6c50ff8cae880f20969556698a3246ac401144c |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: set/unset the DDI eDP backlight 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>
|
b8fc2f6a18052194c486b407765a4f5e4dca692d |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: set the correct eDP aux channel clock divider on DDI 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>
|
e6f0bfc4fb963da9e945ebc6330db9a4d756ba78 |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: select the correct pipe when using TRANSCODER_EDP 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>
|
c9809791ae0ae3e5792fc6ad3d4a5d9658aadc62 |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert PIPE_MSA_MISC to transcoder Same as the other registers. This one also appeared on Haswell for the first time, so that's why we are renaming it. 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>
|
ad80a810ec3ffa96450ce3b40128d55fede7a825 |
|
24-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert DDI_FUNC_CTL to transcoder Because there's one instance of the register per CPU transcoder and not per CPU pipe. This is another register that appeared for the first time on Haswell, and even though its Haswell name is PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's just use the new naming scheme before it confuses more people. Notice that there's a big improvement on intel_ddi_get_hw_state due to the new TRANSCODER_EDP. V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by Damien Lespiau. 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>
|
bb523fc08d4a4a726c7555be7800735685888b3c |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert PIPE_CLK_SEL to transcoder This register appeared in Haswell. It does not have an EDP version because the EDP transcoder is always tied to the DDIA clock. Notice that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder is TRANSCODER_EDP we might introduce a bug, that's why this is a transcoder register even though it does not have an EDP version. Even though Haswell names this register PIPE_CLK_SEL, it will be renamed to TRANS_CLK_SEL in the future, so let's just start using the real name that makes more sense and avoids misusage. 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>
|
c19b0669925cb00dc1c7b2362bfa85128afba882 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: implement Haswell DP link train sequence 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>
|
a836bdf9ae5aa3b100c8cdd04aae5bb9c0340145 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_disable_port Just a missing register. There is no problem to run this code when the output is HDMI. 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>
|
247d89f62230f3369aeaab85dca34978f79dcb86 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_mode_set 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>
|
6547fef887b057ee860f4266fa2923b7bbbf1850 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_enable_ddi We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For DP we need to do this earlier, and the values written to the register are also different. 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>
|
fe43d3f5a38e5b7db27f79cb8447cb25a884dfc7 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_get_hw_state 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>
|
0bdee30ed351d437cc24bb0ec51dfd02f60273fb |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_get_encoder_port 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>
|
068759bd6ee26b5c69977d99611cc72b43280ab5 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_pll_mode_set Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
dae847991a4327b8883a2a4e7b0440a42d528b77 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add intel_ddi_set_pipe_settings In theory, all the DDI pipe settings should be set here, including timing and M/N registers. For now, let's just set the DP MSA attributes. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fixed up the unused typo in a #define, spotted by Jani Nikula.] Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
7739c33ba48174204b24c1b867b455318e752787 |
|
15-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add DP support to intel_ddi_enable_pipe_func 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>
|
39bc66c9371fa6cdb1029e6c1768824f068be913 |
|
11-Oct-2012 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix the SCC/SSC typo in the SPLL bits definition We're talking about Spread Spectrum Clocks here, thus SSC. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
2886e93f5d28c559b3de9c4f75547af31e14504e |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: disable DDI_BUF_CTL at the correct time And also properly wait for its idle bit. You may notice that DDI_BUF_CTL is enabled in .enable but disabled in .post_disable instead of .disable. Yes, the mode set sequence is not exactly symmetrical, but let's assume the spec is correct unless we can prove it's wrong. 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>
|
1e6210f45d95f1db7831072b7be64f9562280df1 |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't rely on previous values set on DDI_BUF_CTL Just set the only bit we need, everything else is either ignored on HDMI or should be set to zero. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
6441ab5f8ffdf7e99eefe0fb747858e0c12b567e |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: completely rewrite the Haswell PLL handling code Problems with the previous code: - HDMI just uses WRPLL1 for everything, so dual head cases might not work sometimes. - At encoder->mode_set we just write the PLL register without doing any kind of check (e.g., check if the PLL is already being used). - There is no way to fail and return error codes at encoder->mode_set. - We write to PORT_CLK_SEL at mode_set and we never disable it. - Machines hang due to wrong clock enable/disable sequence. So here we rewrite the code, making it a little more like the pre-Haswell PLL mode set code: - Check PLL availability at ironlake_crtc_mode_set. - Try to use both WRPLLs. - Check if PLLs are used before actually trying to use them, and properly fail with error messages. - Enable/disable PORT_CLK_SEL at the right place. - Add some WARNs to check for bugs. The next improvement will be to try to reuse PLLs if the timings match, but this is content for another patch and it's already documented with a TODO comment. 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>
|
fc914639b12054c930fe75a2ff4221311699e9c2 |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: enable and disable PIPE_CLK_SEL at the right time Previously we were enabling it at mode_set but never disabling. Let's follow the mode set sequence. 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>
|
8d9ddbcbd0e3fc9368a5972346dc726493d31c9c |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: enable and disable DDI_FUNC_CTL at the right time And the right time is exactly after/before changing PIPE_CONF. See the documentation about the mode set sequence. This code is not inside any encoder-specific callback because DDI_FUNC_CTL is part of the pipe, so it is used by all encoders. 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>
|
79f689aa6b14e058d4effd734e9920ed9531401d |
|
05-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: rewrite the LCPLL code Right now, we're trying to enable LCPLL at every mode set, but we're never disabling it. Also, we really don't want to be disabling LCPLL since it requires a very complex disable/enable sequence. This register should really be set by the BIOS and we shouldn't be touching it. Still, let's try to check its value and print some errors in case we find something wrong. We're also adding intel_ddi_get_cdclk_freq which will be used later in other places. 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>
|
85234cdc28f622dc94d8bb0089635113e2aa5609 |
|
02-Jul-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915/hdmi: implement get_hw_state Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
5ab432ef4997ce32c9406721b37ef6e97e57dae1 |
|
30-Jun-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915/hdmi: convert to encoder->disable/enable I've picked hdmi as the first encoder to convert because it's rather simple: - no cloning possible - no differences between prepare/commit and dpms off/on switching. A few changes are required to do so: - Split up the dpms code into an enable/disable function and wire it up with the intel encoder. - Noop out the existing encoder prepare/commit functions used by the crtc helper - our crtc enable/disable code now calls back into the encoder enable/disable code at the right spot. - Create new helper functions to handle dpms changes. - Add intel_encoder->connectors_active to better track dpms state. Atm this is unused, but it will be useful to correctly disable the entire display pipe for cloned configurations. Also note that for now this is only useful in the dpms code - thanks to the crtc helper's dpms confusion across a modeset operation we can't (yet) rely on this having a sensible value in all circumstances. - Rip out the encoder helper dpms callback, if this is still getting called somewhere we have a bug. The slight issue with that is that the crtc helper abuses dpms off to disable unused functions. Hence we also need to implement a default encoder disable function to do just that with the new encoder->disable callback. - Note that we drop the cpt modeset verification in the commit callback, too. The right place to do this would be in the crtc's enable function, _after_ all the encoders are set up. But because not all encoders are converted yet, we can't do that. Hence disable this check temporarily as a minor concession to bisectability. v2: Squash the dpms mode to only the supported values - connector->dpms is for internal tracking only, we can hence avoid needless state-changes a bit whithout causing harm. v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4f07854dd7fc197d9ea2bd83c26736baabb0b981 |
|
09-Aug-2012 |
Wang Xingchao <xingchao.wang@intel.com> |
drm/i915: write eld info for HDMI audio HDMI audio related registers will be configured in write_eld callback. Signed-off-by: Wang Xingchao <xingchao.wang@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
126e9be816e7c0322f5dac994f94d65a8fabcc56 |
|
10-Aug-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: try harder to find WR PLL clock settings If we don't find the exact refresh rate, go with the next one. This makes some modes work for me. They won't have the best settings, but will at least have something. Just returning from this function when we don't find the perfect settings does not help us at all. Version 2: - Remove duplicate lines on the clock table. - Add back debug message with refresh, p, n2 and r2. 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>
|
602c43d34dcd46b0349b31c9b53b19cd5063ae3f |
|
08-Aug-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: completely reset the value of DDI_FUNC_CTL Don't rely on previous values already set on the register. Everything we're not explicitly setting should be zero for now. 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>
|
dfcef252e024b4ca6fe5be9e1d656ac1929ce894 |
|
08-Aug-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: correctly set the DDI_FUNC_CTL bpc field Correctly erase the values previously set and also check for 6bpc and 10bpc. 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>
|
f63eb7c4528060e54688baafb7a499e9391eefe6 |
|
08-Aug-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: set the DDI sync polarity bits During my tests, everything worked even if the wrong polarity was set. Still, we should try to set the correct values. 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>
|
3f7c447faab3e750b0b2f94edad605ba8eb28a7f |
|
08-Aug-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix pipe DDI mode select Mask the value before changing it and also select DVI when needed. DVI was working in cases where the BIOS was setting the correct value because we were not masking the value before changing it. 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>
|
08d644add0e5f799a47dbe7849401606c522e59e |
|
12-Jul-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: add port parameter to intel_hdmi_init Instead of having a giant if cascade to figure this out according to the passed-in register. We could do quite a bit more cleaning up and all by using the port at more places, but I think this should be part of a bigger rework to introduce a struct intel_digital_port which would keep track of all these things. I guess this will be part of some haswell-DP-induced refactoring. For now this rips out the big cascade, which is what annoyed me so much. v2: Add port variable name back for the func decl (I've tried to trick myself below the 80 char limit). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
4acf518626cdad5bbf7aac9869bd4accbbfb4ad3 |
|
05-Jul-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: program FDI_RX TP and FDI delays This is required for a stable FDI connection. v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni. CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
687f4d06dbb1cf3c8f9f6050cd7aad24dc0ce978 |
|
28-May-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add set_infoframes to struct intel_hdmi We need a function that is able to fully 'set' the state of the DIP registers to a known state. Currently, we have the write_infoframe function that is called twice: once for AVI and once for SPD. The problem is that write_infoframe tries to keep the state of the DIP register as it is, changing only the minimum necessary bits. The second problem is that write_infoframe does twice (once for each time it is called) some work that should be done only once (like waiting for vblank and setting the port). If we add even more DIPs, it will do even more repeated work. This patch only adds the infrastructure keeping the code behavior the same as before. v2: add static keywords Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
72662e103c7dd305725dcf4aabcbd8f69483dfbc |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: prepare HDMI link for Haswell On Haswell, we need to properly train the DDI buffers prior to enabling HDMI, and enable the required clocks with correct dividers for the desired frequency. Also, we cannot simple reuse HDMI routines from previous generations of GPU, as most of HDMI-specific stuff is being done via the DDI port programming instead of HDMI-specific registers. This commit take advantage of the WR PLL clock table which is in a separate (previous) commit to select the right divisors for each mode. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
12a13a3389716009db8deb64094656f946e8950d |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: add WR PLL programming table This table is used for programming WR PLL clocks, used by HDMI and DVI outputs. I split it into a separate patch to simplify the HDMI enabling patch which was getting huge. Note that this table is a temporary solution for WR PLL programming. It will be reworked into a more exact algorithm at a later stage. But for now, it provides the most accurate clock setting solution, so we use it here. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
0e72a5b55e706dafa3402611f6f9e082a810673d |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: detect digital outputs on Haswell Digital port detection on Haswell is indicated by the presence of a bit in DDI_BUF_CTL for port A, and by a different register for ports B, C and D. So we check for those bits during the initialization time and let the hdmi function know about those. Note that this bit does not indicates whether the output is DP or HDMI. However, the DDI buffers can be programmed in a way that is shared between DP/HDMI and FDI/HDMI except for PORT E. So for now, we detect those digital outputs as being HDMI, but proper DP support is still pending. Note that DDI A can only drive eDP, so we do not handle it here for hdmi initialization. v2: simplify Haswell handling logic v3: use generic function for handling digital outputs. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
c82e4d265d98aed94547435605b5e05f8aae9676 |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: support DDI training in FDI mode Starting with Haswell, DDI ports can work in FDI mode to support connectivity with the outputs located on the PCH. This commit adds support for such connections in the intel_ddi module, and provides Haswell-specific functionality to make it work. v2: simplify the commit as per Daniel Vetter suggestion. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
45244b87943b1173353b48854352bb9f4b065867 |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: initialize DDI buffer translations DDI is introduced starting with Haswell GPU generation. So to simplify its management in the future, we also add intel_ddi.c to hold all the DDI-related items. Buffer translations for DDI links must be initialized prior to enablement. For FDI and DP, first 9 pairs of values are used to select the connection parameters. HDMI uses the last pair of values and ignores the first 9 pairs. So we program HDMI values in both cases, which allows HDMI to work over both FDI and DP-friendly buffers. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|