summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_drv.h
Commit message (Collapse)AuthorAgeFilesLines
...
* | drm/i915: use pipe_config for lvds ditheringDaniel Vetter2013-04-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up to now we've relied on the bios to get this right for us. Let's try out whether our code has improved a bit, since we should dither always when the output bpp doesn't match the plane bpp. - gen5+ should be fine, since we only use the bios hint as an upgrade. - gen4 changes, since here dithering is still controlled in the lvds register. - gen2/3 has implicit dithering depeding upon whether you use 2 or 3 lvds pairs (which makes sense, since it only supports 8bpc pipe outpu configurations). - hsw doesn't support lvds. v2: Remove redudant dither setting. v3: Completly drop reliance on dev_priv->lvds_dither. v4: Enable dithering on gen2/3 only when we have a 18bpp panel, since up-dithering to a 24bpp panel is not supported by the hw. Spotted by Ville. v5: Also only enable lvds port dithering on gen4 for 18bpp modes. In practice this only excludes dithering a 10bpc plane down for a 24bpp lvds panel. Not something we truly care about. Again noticed by Ville. v6: Actually git add. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: keep max backlight internal to intel_panel.cJani Nikula2013-04-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation of adding locking to backlight, make max backlight value (the modulation frequency the PWM duty cycle value must not exceed) internal to intel_panel.c. Have intel_panel_set_backlight() accept a caller defined range for level, and scale input to max backlight value internally. Clean up intel_panel_get_max_backlight() and usage internally. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Make struct dpll == intel_clock_tVille Syrjälä2013-04-201-5/+13
| | | | | | | | | | | | | | This allows unifying a bunch of the PLL calculations and whatnot. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: report Gen5+ CPU and PCH FIFO underrunsPaulo Zanoni2013-04-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this commit we enable both CPU and PCH FIFO underrun reporting and start reporting them. We follow a few rules: - after we receive one of these errors, we mask the interrupt, so we won't get an "interrupt storm" and we also won't flood dmesg; - at each mode set we enable the interrupts again, so we'll see each message at most once per mode set; - in the specific places where we need to ignore the errors, we completely mask the interrupts. The downside of this patch is that since we're completely disabling (masking) the interrupts instead of just not printing error messages, we will mask more than just what we want on IVB/HSW CPU interrupts (due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll also be masking PCH FIFO underruns for pipe B, because both are reported by SERR_INT, which has to be either completely enabled or completely disabled (in othe words, there's no way to disable/enable specific bits of GEN7_ERR_INT and SERR_INT). V2: Rename some functions and variables, downgrade messages to DRM_DEBUG_DRIVER and 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>
* | drm/i915: update VLV PLL and DPIO code v11Jesse Barnes2013-04-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Valleyview voltage swing, pre-emphasis and lane control registers can be programmed only through the h/w side band fabric. Update vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the appropriate programming. We need to make sure that the tx lane reset occurs in both the full mode set and DPMS paths, so factor things out to allow that. v2: use different DPIO_DIVISOR values for VGA and DisplayPort v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values for all display interfaces v4: collapse with various updates v5: squash with crtc enable/pll enable bits v6: split out DP code (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) remove unneeded check in 9xx pll div update (Jani) wrap VLV pll update call in IS_VALLEYVIEW (Jani) move port enable back to end of crtc enable (jbarnes) put phyready check under IS_VALLEYVIEW (jbarnes) v7: fix up conflicts against latest drm-intel-next-queued v8: use DPIO reg names, fix pipes (Jani) from mPhy_registers_VLV2_ww20p5 doc v9: update to latest info from driver enabling notes doc driver_vbios_notes_9 v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work simultaneously (Jesse) v11: use pll/port callbacks for DPIO port activity (Daniel) use separate VLV CRTC enable function (Daniel) move around port ready checks (Jesse) Signed-off-by: Pallavi G <pallavi.g@intel.com> Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Drop pfit changes and add a little comment explaining that vlv has a different enable sequence and so needs it's own crtc_enable callback. Also apply a fixup patch from Wu Fengguang to shut up some compiler warnings.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/dp: program VSwing and Preemphasis control settings on VLV v2Pallavi G2013-04-181-0/+2
|/ | | | | | | | | | | | | | | Program few Tx buffer Swing control settings through DPIO. v2: fix up codingstyle (Daniel) call from set_signal_levels (Ville, Daniel) use proper port numbers (Jesse) Signed-off-by: Pallavi G <pallavi.g@intel.com> Signed-off-by: Yogesh M <yogesh.mohan.marimuthu@intel.com> Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2 changes) [danvet: Reorder if-ladder to avoid two IS_VLV checks.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move cpu_transcoder to the pipe configurationDaniel Vetter2013-04-181-1/+4
| | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: (re)init HPD interrupt storm statisticsEgbert Eich2013-04-181-0/+4
| | | | | | | | | | | | | | | | | | | | When an encoder is shared on several connectors there is only one hotplug line, thus this line needs to be shared among these connectors. If HPD detect only works reliably on a subset of those connectors, we want to poll the others. Thus we need to make sure that storm detection doesn't mess up the settings for those connectors. Therefore we store the settings in the intel_connector struct and restore them from there. If nothing is set but the encoder has a hpd_pin set we assume this connector is hotplug capable. On init/reset we make sure the polled state of the connectors is (re)set to the default value, the HPD interrupts are marked enabled. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add intel_using_power_wellPaulo Zanoni2013-04-181-0/+1
| | | | | | | | | | It returns true if we've requested to turn the power well on and it's really on. It also returns true for all the previous gens. For now there's just one caller, but I'm going to add more. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: create pipe_config->dpll for clock stateDaniel Vetter2013-04-031-0/+12
| | | | | | | | | | | | | | | | | | | | | Clock computations and handling are highly encoder specific, both in the optimal clock selection and also in which clocks to use and when sharing of clocks is possible. So the best place to do this is somewhere in the encoders, with a generic fallback for those encoders without special needs. To facility this, add a pipe_config->clocks_set boolean. This patch here is only prep work, it simply sets the computed clock values in pipe_config->dpll, and uses that data in the hw clock setting functions. Haswell code isn't touched, simply because Haswell clocks work much different and need their own infrastructure (with probably a Haswell-specific config->ddi_clock substruct). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove leaky eDP functionsDaniel Vetter2013-04-031-3/+0
| | | | | | | | | | | | | | | | | | | Jesse Barnes noticed in his review of my DP cleanup series that intel_edp_target_clock is now unused. Checking related code I've noticed that also intel_edp_link_config is long unused. Kill them both. Wrt leaky eDP functions used in the common crtc code, the only thing still left is intel_encoder_is_pch_edp. That one is just due to the massive confusion between eDP vs. DP and port A vs. port D. Crtc code should at most concern itself with the later, never with the former. But that's material for another patch series. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: track dp target_clock in pipe_configDaniel Vetter2013-04-031-1/+6
| | | | | | | | | | | | | | | | | | | We need it in the fdi m_n computation, which nicely kills almost all ugly special cases in there. It looks like we also need this to handle 12bpc hdmi correctly. Eventually it might be better to switch things around and put the target clock into adjusted_mode->clock and create a new pipe_config parameter for the port link clock. v2: Add a massive comment in the code to explain this mess. v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi use-case. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move dp_m_n computation to dp_encoder->compute_configDaniel Vetter2013-04-031-3/+3
| | | | | | | | | | | | | | | | We need a flag to designate dp encoders and the dp link m_n parameters in the pipe config for that. And now that the pipe bpp computations have been moved up and stored in the pipe config, too, we can do this without losing our sanity. v2: Rebased on top of Takashi Iwai's fix to (again) fix the target clock handling for eDP. Luckily the new code is sane enough and just does the right thing! v3: Move ->has_dp_encoder to this patch (Jesse). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clear up the fdi/dp set_m_n confusionDaniel Vetter2013-04-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a rather decent confusion going on around transcoder m_n values. So let's clarify: - All dp encoders need this, either on the pch transcoder if it's a pch port, or on the cpu transcoder/pipe if it's a cpu port. - fdi links need to have the right m_n values for the fdi link set in the cpu transcoder. To handle the pch vs transcoder stuff a bit better, extract transcoder set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n registers are all at the same offset) can use it. Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs. edp works exactly the same as dp (since there's no pch dp any more), so use that as a check. And only set up the fdi m_n values if we really have a pch encoder present (which means we have a VGA encoder). On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch encoders. Now that dp_set_m_n handles all dp links (thanks to the pch encoder check), we can ditch the cpu_edp stuff from the fdi_set_m_n function. Since the dp_m_n values are not readily available, we need to carefully coax the edp values out of the encoder. Hence we can't (yet) kill this superflous complexity. v2: Rebase on top of the ivb fdi B/C check patch - we need to properly clear intel_crtc->fdi_lane, otherwise those checks will misfire. v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni. v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: sprite support for ValleyView v4Jesse Barnes2013-04-021-1/+2
| | | | | | | | | | | | | | | | | | | No constant alpha yet though, that needs a new ioctl and/or property to get/set. v2: use drm_plane_format_cpp (Ville) fix up vlv_disable_plane, remove IVB bits (Ville) remove error path rework (Ville) fix component order confusion (Ville) clean up platform init (Ville) use compute_offset_xtiled (Ville) v3: fix up more format confusion (Ville) update to new page offset function (Ville) v4: remove incorrect formats from framebuffer_init (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix up _wait_for macroDaniel Vetter2013-03-281-2/+11
| | | | | | | | | | | | | | As Thomas Gleixner spotted, it's rather horrible racy: - We can miss almost a full tick, so need to compensate by 1 jiffy. - We need to re-check the condition when having timed-out, since a the last check could have been before the timeout expired. E.g. when we've been preempted or a long irq happened. Cc: Thomas Gleixner <tglx@linutronix.de> Reported-by: Jack Winter <jbh@alchemy.lu> Cc: Jack Winter <jbh@alchemy.lu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fold wait_for_atomic_us into wait_for_atomicDaniel Vetter2013-03-281-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit bcf9dcc1e6269fac674e41f25d007ff75f76e840 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jul 15 09:42:38 2012 +0100 drm/i915: Workaround hang with BSD and forcewake on SandyBridge and commit 0cc2764cc4a4bd73df55f8893c871778cf7ddd0f Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Sep 1 22:59:48 2012 -0700 drm/i915: use cpu_relax() in wait_for_atomic these two macros are essentially the same, so unify them. We keep the _us version since it's a nice documentation for smaller timeouts. v2: Fixup time unit conversion, _wait_for takes ms (Ville). Cc: Jack Winter <jbh@alchemy.lu> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: convert DP autodither code to new infrastructureDaniel Vetter2013-03-281-3/+0
| | | | | | | | | | | | | | The old code only handled either 6bpc or 8bpc. Since it's easy to do, reorganize the code to be a bit more generic so that it can also handle 10bpc and 12bpc. Note that we still start with 8bpc, so there's no functional change. Also, since we no don't need to compute the 6BPC flag in the mode_valid callback, we can consolidate things a bit. That requires though that the link bw computation is moved up in the compute_config callback. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: introduce pipe_config->dither|pipe_bppDaniel Vetter2013-03-281-1/+3
| | | | | | | | | 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>
* drm/i915: add pipe_config->limited_color_rangeDaniel Vetter2013-03-281-5/+7
| | | | | | | | | | Now that we have a useful struct for this, let's use it. Some neat pointer-chasing required, but it's all there already. v2: Rebased on top of the added Haswell limited color range support. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add pipe_config->has_pch_encoderDaniel Vetter2013-03-281-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/i915: add pipe_config->pixel_multiplierDaniel Vetter2013-03-281-16/+3
| | | | | | | | | | | Used by SDVO (and hopefully, eventually HDMI, if we ever get around to fixing up the low dotclock CEA modes ...). This required adding a new encoder->mode_set callback to be able to pass around the intel_crtc_config. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add pipe_config->timings_setDaniel Vetter2013-03-281-4/+6
| | | | | | | | | | | | | | | | | | | | Only used by the lvds encoder. Note that we shouldn't do the same simple conversion with the FORCE_6BPC flag, since that's much better handled by moving all the pipe_bpc computation around. This requires that we pass the pipe config around to encoders, so that they can set special attributes and set constraints. To do so introduce a new ->compute_config encoder callback, which is called in stead of the drm crtc helper's ->mode_fixup. To avoid massive churn all over the codebase we don't want to convert all existing ->mode_fixup functions. Instead I've opted to convert them on an as-needed basis (mostly to cut down on rebase conflicts and to have more freedom to experiment around while developing the patches). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: introduce struct intel_crtc_configDaniel Vetter2013-03-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently only containing the requested and the adjusted mode. And only crtc callbacks are converted somewhat to it, encoders will be done on a as-needed basis (simply too much churn in one patch otherwise). Future patches will add tons more useful stuff to this struct, starting with the very simple. v2: Store the pipe_config in the intel_crtc, so that the ->mode-set, ->enable and also ->disable have easy access to it. v3: Store the pipe config in the right crtc ... v4: Rebased. v5: Fixup an OOPS when trying to kfree an ERR_PTR. v6: Used drm_moode_copy and some other small cleanups as suggested by Ville Syrjälä. v7: drm_mode_copy preserves the mode id of the destination, so no need to clear it again (Ville). v8: Break a long line spotted by Paulo. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* DRM/I915: Add enum hpd_pin to intel_encoder.Egbert Eich2013-03-261-0/+1
| | | | | | | | | | | | | | To clean up hotplug support we add a new enum to intel_encoder: enum hpd_pin. It allows the encoder to request a hpd line but leave the details which IRQ is responsible on which chipset generation to i915_irq.c. This way requesting hotplug support will become really simple on the encoder/connector level. Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add sprite restore function v3Jesse Barnes2013-03-261-0/+5
| | | | | | | | | | | To be used to restore sprite state on resume. v2: move sprite tracking bits up so we don't track modified sprite state v3: use src_x/y in sprite suspend/resume code (Ville) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename intel_ddi_enable_pipe_func() to transcoder_func()Damien Lespiau2013-03-231-1/+1
| | | | | | | | | | 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>
* Merge tag 'v3.9-rc3' into drm-intel-next-queuedDaniel Vetter2013-03-191-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge so that I can merge Imre Deak's coalesced sg entries fixes, which depend upon the new for_each_sg_page introduce in commit a321e91b6d73ed011ffceed384c40d2785cf723b Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 27 17:02:56 2013 -0800 lib/scatterlist: add simple page iterator The merge itself is just two trivial conflicts: Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-241-3/+4
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Two regressions fixes from snowboarding land * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Revert hdmi HDP pin checks drm/i915: Handle untiled planes when computing their offsets
| | * drm/i915: Handle untiled planes when computing their offsetsChris Wilson2013-02-211-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We trim the fb to fit the CRTC by computing the offset of that CRTC to its nearest tile_row origin. This allows us to use framebuffers that are larger than the CRTC limits without additional work. However, we failed to compute the offset for a linear framebuffer correctly as we treated its x-advance in whole tiles (instead of the linear increment expected), leaving the CRTC misaligned with its contents. Fixes regression from commit c2c75131244507c93f812862fdbd4f3a37139401 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 5 12:17:30 2012 +0200 drm/i915: adjust framebuffer base address on gen4+ v2: Adjust relative x-coordinate after linear alignment (vsyrjala) v3: Repaint with pokadots (vsyrjala) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-02-201-0/+4
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's my promised pile of fixes for 3.9. I've dropped the core prep patches for vt-switchless suspend/resume as discussed on irc. Highlights: - Fix dmar on g4x. Not really gfx related, but I'm fed up with getting blamed for dmar crapouts. - Disable wc ptes updates on ilk when dmar is enabled (Chris). So again, dmar, but this time gfx related :( - Reduced range support for hsw, using the pipe CSC (Ville). - Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is already confirmed to fix 2 bug reports, so added cc: stable on that one. - Regression fix for 8bit fb console (Ville). - Preserve lane reversal bits on DDI/FDI ports (Damien). - Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of them, need to decide what to do with the currently still in-flight ones. - Panel fitter regression fix from Mika Kuoppala (was accidentally left on on some pipes with the new modset code since 3.7). This also improves the modeset sequence and might help a few other unrelated issues with lvds. - Write backlight regs even harder ... another installement in our eternal fight against the BIOS and backlights. - Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for new ACPI stuff, but closing the race itself seems worthwile on its own. - A few other small fixes and tiny cleanups all over. Lots of the patches are cc: stable since I've stalled on a few not-so-important fixes for 3.8 due to the grumpy noise Linus made. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits) intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK drm/i915: Implement pipe CSC based limited range RGB output drm/i915: inverted brightness quirk for Acer Aspire 4736Z drm/i915: Print the hw context status is debugfs drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+ drm/i915: Set i9xx sdvo clock limits according to specifications drm/i915: Set i9xx lvds clock limits according to specifications drm/i915: Preserve the DDI link reversal configuration drm/i915: Preserve the FDI line reversal override bit on CPT drm/i915: add missing \n to UTS_RELEASE in the error_state drm: Use C8 instead of RGB332 when determining the format from depth/bpp drm: Fill depth/bits_per_pixel for C8 format drm/i915: don't clflush gem objects in stolen memory drm/i915: Don't wait for page flips if there was GPU reset drm/i915: Kill obj->pending_flip drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment drm/i915: remove bogus mutex_unlock from error-path drm/i915: Print the pipe control page GTT address ...
| * | drm/i915: rip out helper->disable noop functionsDaniel Vetter2013-02-141-1/+0
| | | | | | | | | | | | | | | | | | | | | 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>
* | | drm/i915: rename sdvox_reg to hdmi_reg on HDMI contextPaulo Zanoni2013-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | drm/i915: add aux_ch_ctl_reg to struct intel_dpPaulo Zanoni2013-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | This way we can remove some duplicated code and avoid more mistakes and regressions with these registers in the future. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/i915: Finish page flips and update primary planes after a GPU resetVille Syrjälä2013-02-201-0/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GPU reset will drop all flips that are still in the ring. So after the reset, call update_plane() for all CRTCs to make sure the primary planes are scanning out from the correct buffer. Also finish all pending flips. That means user space will get its page flip events and won't get stuck waiting for them. v2: Explicitly finish page flips instead of relying on FLIP_DONE interrupt being generated by the base address update. v3: Make two loops over crtcs to avoid deadlocks with the crtc mutex Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup long line complaint from checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Preserve the DDI link reversal configurationDamien Lespiau2013-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't wait for page flips if there was GPU resetVille Syrjälä2013-02-201-0/+3
|/ | | | | | | | | | | | | | | | If a GPU reset occurs while a page flip has been submitted to the ring, the flip will never complete once the ring has been reset. The GPU reset can be detected by sampling the reset_counter before the flip is submitted, and then while waiting for the flip, the sampled counter is compared with the current reset_counter value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Move the reset_counter assignment to an earlier place in common code as discussed on the mailing list.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Only run idle processing from i915_gem_retire_requests_workerChris Wilson2013-01-311-2/+1
| | | | | | | | | | | | | | | | When adding the fb idle detection to mark-inactive, it was forgotten that userspace can drive the processing of retire-requests. We assumed that it would be principally driven by the retire requests worker, running once every second whilst active and so we would get the deferred timer for free. Instead we spend too many CPU cycles reclocking the LVDS preventing real work from being done. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Alexander Lam <lambchop468@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843 Cc: stable@vger.kernel.org Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: turn on the power well before suspendingPaulo Zanoni2013-01-281-0/+1
| | | | | | | | | | | Our suspend code touches a lot of registers all over the place, so we need to enable the power well before suspending. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Fixup compilation by stealing the header decl from the dynamic power wells patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix intel_init_power_wellsPaulo Zanoni2013-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code was wrong in many different ways, so this is a full rewrite. We don't have "different power wells for different parts of the GPU", we have a single power well, but we have multiple registers that can be used to request enabling/disabling the power well. So let's be a good citizen and only use the register we're suppose to use, except when we're loading the driver, where we clear the request made by the BIOS. If any of the registers is requesting the power well to be enabled, it will be enabled. If none of the registers is requesting the power well to be enabled, it will be disabled. For now we're just forcing the power well to be enabled, but in the next commits we'll change this. V2: - Remove debug messages that could be misleading due to possible race conditions with KVMr, Debug and BIOS. - Don't wait on disabling: after a conversaion with a hardware engineer we discovered that the "restriction" on bit 31 is just for the "enable" case, and we don't even need to wait on the "disable" case. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: HDMI/DP - ELD info refresh support for HaswellWang Xingchao2013-01-221-0/+1
| | | | | | | | | | | 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>
* drm/i915: Provide the quantization range in the AVI infoframeVille Syrjälä2013-01-201-0/+4
| | | | | | | | | | | | | | | | | The AVI infoframe is able to inform the display whether the source is sending full or limited range RGB data. As per CEA-861 [1] we must first check whether the display reports the quantization range as selectable, and if so we can set the approriate bits in the AVI inforframe. [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame v2: Give the Q bits better names, add spec chapter information Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add "Automatic" mode for the "Broadcast RGB" propertyVille Syrjälä2013-01-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new "Automatic" mode to the "Broadcast RGB" range property. When selected the driver automagically selects between full range and limited range output. Based on CEA-861 [1] guidelines, limited range output is selected if the mode is a CEA mode, except 640x480. Otherwise full range output is used. Additionally DVI monitors should most likely default to full range always. As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and otherwise will follow CEA-861 rules. NOTE: The default value for the property will now be "Automatic" so some people may be affected in case they're relying on the current full range default. [1] CEA-861-E - 5.1 Default Encoding Parameters [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry v2: Use has_hdmi_sink to check if a HDMI monitor is present v3: Add information about relevant spec chapters Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix RGB color range property for PCH platformsVille Syrjälä2013-01-201-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RGB color range select bit on the DP/SDVO/HDMI registers disappeared when PCH was introduced, and instead a new PIPECONF bit was added that performs the same function. Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set it in the encoder mode_fixup if limited color range is requested. Set the the PIPECONF bit 13 based on the flag. Experimentation showed that simply toggling the bit while the pipe is active doesn't work. We need to restart the pipe, which luckily already happens. The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it, although it doesn't seem to do any harm in practice. TODO: - the PIPECONF bit too seems to have disappeared from HSW. Need a volunteer to test if it's just a documentation issue or if it's really gone. If the bit is gone and no easy replacement is found, then I suppose we may need to use the pipe CSC unit to perform the range compression. v2: Use mode private_flags instead of intel_encoder virtual functions v3: Moved the intel_dp color_range handling after bpc check to help later patches Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800 Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2012-12-21' of ↵Dave Airlie2013-01-171-2/+9
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: - seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris Wilson - some leftover kill-agp on gen6+ patches from Ben - hotplug improvements from Damien - clear fb when allocated from stolen, avoids dirt on the fbcon (Chris) - Stolen mem support from Chris Wilson, one of the many steps to get to real fastboot support. - Some DDI code cleanups from Paulo. - Some refactorings around lvds and dp code. - some random little bits&pieces * tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel: (93 commits) drm/i915: Return the real error code from intel_set_mode() drm/i915: Make GSM void drm/i915: Move GSM mapping into dev_priv drm/i915: Move even more gtt code to i915_gem_gtt drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno drm/i915: Introduce i915_gem_set_seqno() drm/i915: Always clear semaphore mboxes on seqno wrap drm/i915: Initialize hardware semaphore state on ring init drm/i915: Introduce ring set_seqno drm/i915: Missed conversion to gtt_pte_t drm/i915: Bug on unsupported swizzled platforms drm/i915: BUG() if fences are used on unsupported platform drm/i915: fixup overlay stolen memory leak drm/i915: clean up PIPECONF bpc #defines drm/i915: add intel_dp_set_signal_levels drm/i915: remove leftover display.update_wm assignment drm/i915: check for the PCH when setting pch_transcoder drm/i915: Clear the stolen fb before enabling drm/i915: Access to snooped system memory through the GTT is incoherent drm/i915: Remove stale comment about intel_dp_detect() ... Conflicts: drivers/gpu/drm/i915/intel_display.c
| * drm/i915: Return the real error code from intel_set_mode()Chris Wilson2012-12-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | Note: This patch also adds a little helper intel_crtc_restore_mode for the common case where we do a full modeset but with the same parameters, e.g. to undo bios damage or update a property. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Added note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/hdmi: Read the HPD status before trying to read the EDIDDamien Lespiau2012-12-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you unplug the hdmi connector slowly enough, the hotplug interrupt fires but then the kernel code tries to read the EDID and succeeds (because the connector is still half connected, the HPD pin is shorter than the others, and DDC works). Since EDID succeeds it thinks the monitor is still connected. To prevent that, read the live HPD status in the hotplug handler before trying to read the EDID. v2: Rename the function to ibx_ (Chris Wilson) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55372 Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fixup hpd irq register setup orderingDaniel Vetter2012-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For GMCH platforms we set up the hpd irq registers in the irq postinstall hook. But since we only enable the irq sources we actually need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask into account, no hpd interrupt sources is enabled since commit 52d7ecedac3f96fb562cb482c139015372728638 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup Wrongly set-up interrupts also lead to broken hw-based load-detection on at least GM45, resulting in ghost VGA/TV-out outputs. To fix this, delay the hotplug register setup until after all outputs are set up, by moving it into a new dev_priv->display.hpd_irq_callback. We might also move the PCH_SPLIT platforms to such a setup eventually. Another funny part is that we need to delay the fbdev initial config probing until after the hpd regs are setup, for otherwise it'll detect ghost outputs. But we can only enable the hpd interrupt handling itself (and the output polling) _after_ that initial scan, due to massive locking brain-damage in the fbdev setup code. Add a big comment to explain this cute little dragon lair. v2: Encapsulate all the fbdev handling by wrapping the move call into intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson. v3: Applied bikeshed from Jesse Barnes. v4: Imre Deak noticed that we also need to call intel_hpd_init after the drm_irqinstall calls in the gpu reset and resume paths - otherwise hotplug will be broken. Also improve the comment a bit about why hpd_init needs to be called before we set up the initial fbdev config. Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943 Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: move is_dual_link_lvds to intel_lvds.cDaniel Vetter2012-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Just a prep patch to make this a property of intel_lvds. Makes more sense, removes clutter from intel_display.c and eventually I want to move all the encoder special cases wrt clock handling to encoders anyway. v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static now. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: add encoder->pre_pll_enable callbackDaniel Vetter2012-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have two encoder specific bits in the common mode_set functions: - lvds pin pair enabling - dp m/n setting and computation Now the lvds stuff needs to happen before the pll is enabled. Since that is done in the crtc_mode_set functions, we need to add a new callback to be able to move them to the encoder code (where they belong). The dp m/n stuff is a giant mess anyway (since it also confuses itself with the fdi link m/n handling), so that needs to be handled separately. I think that we can move the pll enabling down quite a bit, which might allow us to eventually merge encoder->pre_enable with this new pre_pll_enable callback. But for now this will allow us to clean things up a bit. Note that vlv doesn't support lvds, hence we don't need to change anything in there. v2: Fixup commit message, both suggested from Paulo Zanoni. - dp m/n doesn't need to happen before pll enabling - lvds doesn't exist on vlv, hence no changes required in the vlv pll function. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud