summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)Author
2014-11-07drm/i915: Use a consistent order between IIR, IER, IMR writes on vlv/chvVille Syrjälä
Follow the same ordering rules for the IIR,IER,IMR writes on vlv/chv that we do on other gen5+ platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Drop the extra GEN8_PCU_IIR posting read from ↵Ville Syrjälä
cherryview_irq_preinstall() Looks like a leftover POSTING_READ(GEN8_PCU_IIR) in cherryview_irq_preinstall() from some earlier age. GEN5_IRQ_RESET() already does the posting read so this changes nothing, so kill it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Use gen8_gt_irq_reset() in cherryview_irq_uninstall()Ville Syrjälä
Replace the hand rolled macros with gen8_gt_irq_reset() and GEN5_IRQ_RESET() in cherryview_irq_uninstall(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Use DPINVGTT_STATUS_MASKVille Syrjälä
Some has given a name for the DPINVGTT status bitmask, so let's use it instead of the magic number. Looks more like the chv code now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Apply some ocd for IMR vs. IER order during irq enableVille Syrjälä
When disabling interrupts we do the writes in this order: IMR,IER,IIR,IIR. But when enabling interrupts we don't do use the mirrored order, and instead do IIR,IIR,IMR,IER. I like consistency unless there's a good reason against it, which I can't think of here, so change the enable order to IIR,IIR,IER,IMR. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Make intel_pin_and_fence_fb_obj take plane and framebufferTvrtko Ursulin
It will help future code if this function knows something about of the context of the display setup object is being pinned for. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915/bdw: Setup global hardware status page in execlists modeThomas Daniel
Write HWS_PGA address even in execlists mode as the global hardware status page is still required. This address was previously uninitialized and HWSP writes would clobber whatever buffer happened to reside at GGTT address 0. v2: Break out hardware status page setup into a separate function. Issue: VIZ-2020 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Remove orphaned prototype gen6_set_pm_mask()Damien Lespiau
The function was removed in: commit 037bde19a43e299d30f0490bba9be32ab355975c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 27 08:24:19 2014 +0000 Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq." Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Removed orphaned prototype intel_dp_handle_hpd_irq()Damien Lespiau
The function was removed in: commit 0e32b39ceed665bfa4a77a4bc307b6652b991632 Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915/dp: Don't stop the link when retrainingDaniel Vetter
On pre-ddi platforms we don't shut down the link when changing link training parameters. Except when clock recovery fails too hard and we restart with channel eq training. Which doesn't make a lot of sense really, since just stopping/restarting the DP port at this point violates the modeset sequence documented in the Bspec. So let's tempt fate and try this. This patch is motivated by a WARN_ON triggered by commit bc76e320f21f8bd790a72bd5dc06909617432352 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue May 20 22:46:50 2014 +0200 drm/i915: Drop now misleading DDI comment from dp_link_down References: https://bugs.freedesktop.org/show_bug.cgi?id=85670 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Remove unused WATCH_GTT defineDamien Lespiau
Chris removed the code using it in: commit be2d599b5da3936ca92e0187ff50b34b6b8ff997 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Sep 10 19:52:18 2014 +0100 drm/i915: Remove dead code, i915_gem_verify_gtt Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Make intel_pipe_has_type() take an output type enumDamien Lespiau
As Paulo said when introducing the enum, having more types is really good to document what should go where (int foo(int, int, bool, bool). 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>
2014-11-07drm/i915: Move pll state commit into intel_modeset_update_stateDaniel Vetter
It's really part of the "push all new_* state into current state pointers" done in that function. So let's move it there to make this clear. Also, with the conversion done the num_shared_dpll check the function does in it's loop is enough, so we can drop the check for the dpll compute callback, too. Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-07drm/i915: Don't store current shared DPLL in the new pipe_configAnder Conselvan de Oliveira
Now that shared DPLLs configuration is staged, there's no need to track the current ones in the new pipe_config since those are released before making the new pipe_config effective. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Remove crtc_mode_set() hookAnder Conselvan de Oliveira
There's no users left after the conversion to calculate clocks before disabling crtcs during mode set. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Covert remaining platforms to choose DPLLS before disabling CRTCsAnder Conselvan de Oliveira
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Covert ILK-IVB to choose DPLLS before disabling CRTCsAnder Conselvan de Oliveira
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Covert HSW+ to choose DPLLS before disabling CRTCsAnder Conselvan de Oliveira
Use the infrastructure added in a previous patch to choose shared DPLLs and calculate clocks before touching the hardware. v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Add infrastructure for choosing DPLLs before disabling crtcsAnder Conselvan de Oliveira
It is possible for a mode set to fail if there aren't shared DPLLS that match the new configuration requirement or other errors in clock computation. If that step is executed after disabling crtcs, in the failure case the hardware configuration is changed and needs to be restored. Doing those things early will allow the mode set to fail before actually touching the hardware. Follow up patches will convert different platforms to use the new infrastructure. v2: Keep pll->new_config valid only during mode set (Ville) Use kmemdup() in i915_shared_dpll_start_config() (Ville) Restore old pll config if something fails before commit (Ville) Don't set compute_clock hooks since dev_priv is kzalloc()'d (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Move dpll crtc_mask and hw_state fields into separate structAnder Conselvan de Oliveira
The new struct will be used in a follow up patch to allow a current and a staged config to exist for the same shared DPLL. v2: Rebase on by mask_to_refcount()->hweight32() change. (Damien) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Convert shared dpll reference count to a crtc maskAnder Conselvan de Oliveira
This will be used in a follow up patch to properly release shared DPLLs without relying on the shared_dpll field in pipe_config. v2: Fix white space error (Ville) Use hweight32() (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-07drm/i915: Check pipe_config.has_dp_encoder instead of encoder typesDaniel Vetter
More concise. Noticed while reviewing Ander's patch which touched a lot of the pipe_has_type checks. v2: Use new_config in one place Ander spotted. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-07Merge tag 'topic/core-stuff-2014-11-05' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next Just various stuff all over from a bunch of people. Shortlog gives a beter overview, it's really all misc drm patches. * tag 'topic/core-stuff-2014-11-05' of git://anongit.freedesktop.org/drm-intel: drm/edid: add #defines and helpers for ELD drm/dp: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs drm: Remove compiler BUG_ON() test drm: Fix DRM_FORCE_ON_DIGITAL use drm/gma500: Don't destroy DRM properties in the driver drm/i915: Don't destroy DRM properties in the driver drm: Add a note to drm_property_create() about property lifetime gpu: drm: Fix warning caused by a parameter description in drm_crtc.c drm/dp-helper: Move the legacy helpers to gma500 drm/crtc: Remove duplicated ioctl code drm/crtc: Fix two typos gpu:drm: Fix typo in Documentation/DocBook/drm.xml gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat drm: drm_err: Remove unnecessary __func__ argument drm: Implement O_NONBLOCK support on /dev/dri/cardN
2014-11-06drm/i915: safeguard against too high minimum brightnessJani Nikula
Never trust (your interpretation of) the VBT. Regression from commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness causing div by zero if VBT minimum brightness equals maximum brightness. Despite my attempts I've failed in my detective work to figure out what the root cause is. This is not the real fix, but we have to do something. Reported-by: Mike Auty <mike.auty@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86551 Cc: stable@vger.kernel.org (v3.17+) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-06drm/i915: vlv: fix gunit HW state corruption during S4 suspendImre Deak
During S4 freeze we don't call intel_suspend_complete(), which would save the gunit HW state, but during S4 thaw/restore events we call intel_resume_prepare() which restores it, thus ending up in a corrupted HW state. Fix this by calling intel_suspend_complete() from the corresponding freeze_late event handler. The issue was introduced in commit 016970beb05da6285c2f3ed2bee1c676cb75972e Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-06drm/i915: Disable caches for Global GTT.Rodrigo Vivi
Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000; So the only way to avoid screen corruptions is setting PAT 0 to Uncached. MOCS can still be used though. But if userspace is trusting PTE for cache selection the safest thing to do is to let caches disabled. BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry, so RTL will always use the value corresponding to pat_sel = 000" - System agent ggtt writes (i.e. cpu gtt mmaps) already work before this patch, i.e. the same uncached + snooping access like on gen6/7 seems to be in effect. - So this just fixes blitter/render access. Again it looks like it's not just uncached access, but uncached + snooping. So we can still hold onto all our assumptions wrt cpu clflushing on LLC machines. v2: Cleaner patch as suggested by Chris. v3: Add Daniel's comment Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: James Ausmus <james.ausmus@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Stable@vger.kernel.org Tested-by: James Ausmus <james.ausmus@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-11-04drm/i915: Make *_crtc_mode_set work on new_configAnder Conselvan de Oliveira
This shouldn't change the behavior of those functions, since they are called after the new_config is made effective and that points to the current config. In a follow up patch, the mode set sequence will be changed so this is called before disabling crtcs, and in that case those functions should work on the staged config. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> [danvet: Flatten if by moving the check into the WARN.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Remove redundant return value and WARN_ONDave Gordon
execlists_submit_context() always returns 0, which is redundant. And its name is inaccurate, since it actually submits (up to) TWO contextS. So we rename it, change it to "void", and remove the WARN_ON() testing its return value. Change-Id: Ie225b0eca7754c6093c8b8bd15550b251b6feb82 Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Fix null pointer dereference in ring cleanup codeJohn Harrison
If a ring failed to initialise for any reason then the error path would try to clean up all rings including those that had not yet been allocated. The ring clean up code did a check that the ring was valid before starting its work. Unfortunately, that was after it had already dereferenced the ring to obtain a dev_private pointer. Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Redefine WARN_ON to include the conditionMika Kuoppala
When looking at the bug report logs with triggered WARN_ON, the person doing bug triaging will have to find exact kernel source and match file/line. Attach the condition that triggered the WARN_ON to kernel log. In most cases the context is self evident and this way we can save developer time. The drawback is ~16kbytes bigger i915.ko Signed-off-by: Mika Kuoppala <miku@iki.fi> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Read out the power sequencer port assignment on resume on vlv/chvVille Syrjälä
When we suspend we turn everything off so the pps should be idle, and we also (or at least should) disable all power wells which will reset the power sequencer port assignment. So when we resume all power sequencers should be in their reset state. However it's at least theoretically possible that the BIOS would touch the power seuqencer(s), so to be safe we ought to read out the current port assignment like we do at driver init time. To do that we can simply call vlv_initial_power_sequencer_setup() from the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize(). There's no danger or clobbering the pps delays since we now have those stored within intel_dp and we don't change them once initialized. This will make sure that the vdd state gets correctly tracked post-resume in case the BIOS enabled it. We need to shuffle things around a bit to get the locking right, and while at it, make intel_edp_panel_vdd_sanitize() static and move it around a bit to avoid a forward declaration. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Initialize PPS timestamps on vlv/chvVille Syrjälä
The pps timestamp initialization was accidentally lost on vlv/chv in commit a4a5d2f8a96e09844a91469e889f15bd5e927399 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:20 2014 +0300 drm/i915: Track which port is using which pipe's power sequencer Restore it so that we avoid introducing random delays into the pps operations during/after driver init time. Cc: Imre Deak <imre.deak@intel.com> Reported-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/audio: remove misleading checks for !eld[0]Jani Nikula
We'll never end up in the hooks with eld[0] unset, as that's checked by drm_select_eld(). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: introduce intel_audio_codec_{enable, disable}Jani Nikula
Introduce functions to enable/disable the audio codec, incorporating the ELD setup within enable. The disable is initially limited to HSW, covering exactly what was done previously. The only functional difference is that ELD valid is no longer set if there is no connector with ELD, which should be the right thing to do anyway. Otherwise the sequence remains the same, with warts and all, in preparation for applying more sanity. v2: add kernel doc. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/ddi: write ELD where it's supposed to be doneJani Nikula
The audio programming sequence states that the ELD must be written and enabled after the pipe is ready. Indeed, this should clarify the situation with commit c79057922ed6c2c6df1214e6ab4414fea1b23db2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 16 16:56:09 2014 +0200 drm/i915: Remove vblank wait from haswell_write_eld and Ville's review of it [1]. Moreover, we should not touch the relevant registers before we get the audio power domain. [1] http://mid.gmane.org/20140416155309.GK18465@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915/audio: set ELD Conn_Type at one placeJani Nikula
Keep the driver modifications to ELD together. This also sets the Conn_Type for G4X DP which wasn't done before. Clean up the debugs while at it; this is all obvious from the connector name. v3: add missing ~ (Rodrigo) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Enable pipe-a power well on chvVille Syrjälä
It seems that the pipe-a power well has replaced the disp2d power well on chv. At least that's the case with the current punit firmware. So enable the pipe-a power and expand its domains to cover everything the disp2d well ought to cover. The other power wells (apart from the cmnlane wells) still seem awol in the current punit firmware. So leave them disabled in the code. This fixes a hilarious oops during resume on bsw where intel_hdmi_get_config() would read the port register and get back 0xffffffff and thus think the port is enabled on pipe D. It would then go and index the pipe_to_crtc_mapping[] array with PIPE_D and blow up when intel_hdmi_get_config() tries to write to crtc->config. Someone really ought to replace all naked pipe_to_crtc_mapping[] uses with the appropriate function call so we could add a warning there if the pipe doesn't actually exist... We must also call the power seqeuencer state reset function from the pipe-a well disable just like we do from disp2d on vlv. Otherwise the eDP panel won't recover at resume time since the PPS has lost its hold on the port. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84903 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Add support for CHV pipe B sprite CSCVille Syrjälä
CHV has a programmable CSC unit on the pipe B sprites. Program the unit appropriately for BT.601 limited range YCbCr to full range RGB color conversion. This matches the programming we currently do for sprites on the other pipes and on other platforms. It seems the CSC only works when the input data is YCbCr. For RGB pixel formats it doesn't matter what we program into the CSC registers. Doesn't make much sense to me especially since the register names give the impression that RGB input data would also work. But that's how it behaves here. In the review discussions there's been some nice math to explain the values obtained here. First about the YCbCr->RGB matrix: "I had the RGB->YCbCr matrix, inverted it and the values came out. But they should match the wikipedia article. Also keep in mind that the coefficients are in .12 in fixed point format, hence we need a 1<<12 factor. So let's try it: Kb=.114 Kr=.299 (1<<12) * 255/219 ~= 4769 -(1<<12) * 255/112*(1-Kb)*Kb/(1-Kb-Kr) ~= -1605 -(1<<12) * 255/112*(1-Kr)*Kr/(1-Kb-Kr) ~= -3330 (1<<12) * 255/112*(1-Kr) ~= 6537 (1<<12) * 255/112*(1-Kb) ~= 8263 "Looks like the same values to me." And then about the limits used for clamping: "> where did you get these min/max? "The hardware apparently deals in 10bit values, so we need to multiply everything by 4 when we start with the 8bit min/max values. Y = [16:235] * 4 = [64:940] CbCr = ([16:240] - 128) * 4 = [-112:112] * 4 = [-448:448] "The -128 being the -0.5 bias that the hardware already applied before the data entered the CSC unit." Raw data is also supplied in 10bpc in the registers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Copypaste explanations&math from the review discussion.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: run hsw_disable_pc8() later on resumePaulo Zanoni
We want to run intel_uncore_early_sanitize() before we touch any registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit is set, so we need to clear it - through intel_uncore_early_sanitize() - before we do anything else. With the current code, we don't clear the bit before our first register access, so we print a WARN complaining about an unclaimed register error. v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume" v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV" v3: This one, on top of the intel_resume_prepare() rework. v4: Rebase. 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>
2014-11-04drm/i915: kill intel_resume_prepare()Paulo Zanoni
Because, really, the abstraction is not working for us. It is nice for VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change this code due to a recently-discovered bug, but we can't seem to find a nice solution that repects the current abstraction. So let's kill intel_resume_prepare() and its friends, and add an equivalent implementation to both its callers. Also, look at the diffstat! v2: - Rebase. 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>
2014-11-04drm/i915: Initialize new chv primary plane and pipe blender registersVille Syrjälä
CHV adds a bunch of new registers for primary plane size/position and pipe blender setup. Initialize all those registers to avoid nasty surprises. PRIMSIZE is especially important as without programming it the outout will be garbled whenever the primary plane size would not match what the BIOS set up. Also program the sprite constant alpha register to disable the constant alpha blending factor. This applies to vlv as well as chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Do vlv cmnlane toggle w/a in more casesVille Syrjälä
In case the cmnlane power well is down but cmnreset isn't asserted we would currently skip the off+on toggle for the power well. That could leave cmnreset deasserted while cmnlane is powered down which might lead to problems with the PHY. To avoid such issues skip the cmnlane toggle only if both cmnlane and disp2d wells are up and cmnreset is already deasserted. In all other cases power down the cmnlane well which will also make sure cmnreset gets asserted correctly while cmnlane is powered down. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: use intel_fb_obj() macros to assign gem objectsGustavo Padovan
Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: create a prepare phase for sprite plane updatesGustavo Padovan
take out pin_fb code so the commit phase can't fail anymore. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: create a prepare step for primary planes updatesGustavo Padovan
Take out the pin_fb code so commit phase can't fail anymore. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Make sure DPLL is enabled when kicking the power sequencer on VLV/CHVVille Syrjälä
The power seqeuencer kick procedure requires the DPLL to be running in order to complete successfully. In case the DPLL isn't currently running when we need to kick the power seqeuncer enable it temporarily. This can happen eg. during ->detect() when the pipe is not already active. To avoid needlessly duplicating the DPLL programming re-use the already existing functions by passing a temporary pipe config to them instead of having them consult the current pipe config at crtc->config. v2: Introduce vlv_force_pll_{on,off}() (Daniel) v3: Rebase due to drm_crtc vs. intel_crtc changes Fix a typo in commit msg (checkpatch) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Warn if stealing power sequencer from an active eDP portVille Syrjälä
eDP ports need the power seqeuncer whenever the port is active. Warn if we accidentally steal the power sequener from an active eDP port. This should not happen unless there's a bug somewhere else, but it's best to scream loudly if it happens to help with debugging. Note that this only checks for active pipes and not for enabled pipes which are turned off with dpms. Which means we might run the risk that the pps might get stolen and we can't reacquire one when enabling the pipe again with dpms on. But on current platforms that's impossible since we only support two edp ports with just two panel power sequencers. So a more elaborate scheme which reserves the pps even when the pipe is inactive isn't required. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Summarize my discussion with Ville about dpms on/off issues.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Warn if panel power is already on when enabling itVille Syrjälä
We should never enable the panel power twice. That would indicate a bug somewhere else as we would need to enable the port twice without disabling it in between. Also print the port name. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Improve VDD/PPS debugsVille Syrjälä
Print the port name in the VDD/PPS debugs messages. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-04drm/i915: Steal power sequencer in vlv_power_sequencer_pipe()Ville Syrjälä
In case we fumble something and end up picking an already used power seqeuencer in vlv_power_sequencer_pipe() at least try to steal it gracefully. In theory this should never happen though. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>