summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/msm/mdp5: fix error return valueRob Clark2014-06-021-6/+16
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: remove redundant private plane cleanupRob Clark2014-06-022-4/+0
| | | | | | | Now that drm core knows about private planes, it cleans them up for us. Trying to do this twice results in badness. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add perf logging debugfsRob Clark2014-06-027-5/+436
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add rd logging debugfsRob Clark2014-06-027-1/+392
| | | | | | | | | | To ease debugging, add debugfs file which can be cat/tail'd to log submits, along with fence #. If GPU hangs, you can look at 'gpu' debugfs file to find last completed fence and current register state, and compare with logged rd file to narrow down the DRAW_INDX which triggered the GPU hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: update for ARCH_MSM -> ARCH_QCOMRob Clark2014-05-302-2/+2
| | | | | | | Architecture rename/split.. ARCH_QCOM is for the non-legacy platforms (ie. device-tree, multiplatform support, etc). Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/hdmi: use gpio and HPD pollingRob Clark2014-05-301-19/+33
| | | | | | | | | The hotplug detect and irq does not seem to be reliable on all devices for some reason. For now it is more reliable to use polling, and give preference to raw gpio status if it disagrees with the debounced hpd status. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/mdp5: fix crash in error/unload pathsRob Clark2014-05-301-1/+4
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm: add DP MST encoder typeDave Airlie2014-05-301-0/+1
| | | | | | | This adds an encoder type for DP MST encoders. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: store encoder name in encoder structJani Nikula2014-05-301-14/+17
| | | | | | | | | | This makes drm_get_encoder_name() thread safe. Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01\ .ptsecurity.ru Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: store connector name in connector struct (v2)Jani Nikula2014-05-301-16/+20
| | | | | | | | | | | This makes drm_get_connector_name() thread safe. [airlied: fix to build.] Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3@DC1-MBX-01.ptsecurity.ru Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/armada: use shmem helpers if possibleDavid Herrmann2014-05-271-3/+1
| | | | | | | | | | shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp mask. No reason to use shmem_read_mapping_page_gfp() directly if we want the default behavior. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/gem: replace misleading commentDavid Herrmann2014-05-271-15/+4
| | | | | | | | | | | | | | | | | | | shmem supports page-relocations during swapin since quite some time. It was implemented in: commit bde05d1ccd512696b09db9dd2e5f33ad19152605 Author: Hugh Dickins <hughd@google.com> Date: Tue May 29 15:06:38 2012 -0700 shmem: replace page if mapping excludes its zone The gem-comment about wrongly placed DMA32 pages is no longer valid. Replace it with a proper comment but keep the BUG_ON() to verify correct shmem behavior. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Use kmemdup instead of kmalloc + memcpyBenoit Taine2014-05-271-2/+1
| | | | | | | | This issue was reported by coccicheck using the semantic patch at scripts/coccinelle/api/memdup.cocci Signed-off-by: Benoit Taine <benoit.taine@lip6.fr> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/shmobile: Add run-time dependenciesJean Delvare2014-05-271-1/+2
| | | | | | | | | | | The shmobile DRM driver is only useful on SuperH and shmobile unless build testing. I am dropping the SuperH dependencies though because the driver doesn't even build there, so in practice it is an arm-only driver for now. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/rcar-du: Add run-time dependenciesJean Delvare2014-05-271-0/+2
| | | | | | | | | | The Renesas R-Car Display Unit driver is only useful on shmobile unless build testing. The LVDS output is useful on an even more reduced hardware set. Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDsDaniel Thompson2014-05-261-1/+20
| | | | | | | | | | | | | | | | | | | | | | | The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the existing users of the established timing bits forcing a rework of the ESTABLISHED_TIMINGS_BITS macro. Tested new EDID on an aged (and misbehaving) industrial LCD panel; existing EDIDs still pass edid-decode's checksum checks. Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: David Airlie <airlied@linux.ie> Cc: Carsten Emde <C.Emde@osadl.org> Cc: linux-doc@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: fix typoRob Clark2014-05-261-1/+1
| | | | | Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'ast-updates' of ssh://people.freedesktop.org/~/linux into drm-nextDave Airlie2014-05-197-552/+1046
|\ | | | | | | | | | | | | | | | | | | | | Pull in latest updates to AST driver. * 'ast-updates' of ssh://people.freedesktop.org/~/linux: drm/ast: initial DP501 support (v0.2) drm/ast: rename the mindwm/moutdwm and deinline them drm/ast: resync the dram post code with upstream drm/ast: add AST 2400 support. drm/ast: add widescreen + rb modes from X.org driver (v2)
| * drm/ast: initial DP501 support (v0.2)Dave Airlie2014-05-196-12/+505
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the initial attempt at porting the DP501 code from the userspace driver, the firmware file is in http://people.freedesktop.org/~airlied/ast_dp501_fw.bin this should really be exposed as another encoder/connector that is cloneable v0.2: init 3rd tx properly, add scratch reduction of VRAM size backup firmware properly. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/ast: rename the mindwm/moutdwm and deinline themDave Airlie2014-05-191-225/+225
| | | | | | | | | | | | we'll need these elsewhere for dp501. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/ast: resync the dram post code with upstreamDave Airlie2014-05-191-303/+173
| | | | | | | | | | | | | | This resyncs the dram post code with the upstream X.org driver where ast have improved the code for setting up the dram chips. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/ast: add AST 2400 support.Dave Airlie2014-05-194-14/+20
| | | | | | | | | | | | | | | | This is ported from the userspace driver. Untested on any ast2400 hw so far. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/ast: add widescreen + rb modes from X.org driver (v2)Dave Airlie2014-05-194-27/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This syncs up the mode code from the X.org driver upstream, and adds the mode validation step for hw that doesn't have widescreen. v2: (from Egbert Eich <eich@suse.de) squash drm/ast: Use correct structure member for mode validation to avoid bisect regression. In struct drm_display_mode crtc_hdisplay and crtc_vdisplay are holding the crtc parameters after mode fixup. For validation we need hdisplay and vdisplay. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge tag 'drm-intel-next-2014-05-06' of ↵Dave Airlie2014-05-1926-778/+1472
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - ring init improvements (Chris) - vebox2 support (Zhao Yakui) - more prep work for runtime pm on Baytrail (Imre) - eDram support for BDW (Ben) - prep work for userptr support (Chris) - first parts of the encoder->mode_set callback removal (Daniel) - 64b reloc fixes (Ben) - first part of atomic plane updates (Ville) * tag 'drm-intel-next-2014-05-06' of git://anongit.freedesktop.org/drm-intel: (75 commits) drm/i915: Remove useless checks from primary enable/disable drm/i915: Merge LP1+ watermarks in safer way drm/i915: Make sure computed watermarks never overflow the registers drm/i915: Add pipe update trace points drm/i915: Perform primary enable/disable atomically with sprite updates drm/i915: Make sprite updates atomic drm/i915: Support 64b relocations drm/i915: Support 64b execbuf drm/i915/sdvo: Remove ->mode_set callback drm/i915/crt: Remove ->mode_set callback drm/i915/tv: Remove ->mode_set callback drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_set drm/i915/tv: De-magic device check drm/i915/tv: extract set_color_conversion drm/i915/tv: extract set_tv_mode_timings drm/i915/dvo: Remove ->mode_set callback drm/i915: Make encoder->mode_set callbacks optional drm/i915: Make primary_enabled match the actual hardware state drm/i915: Move ring_begin to signal() drm/i915: Virtualize the ringbuffer signal func ...
| * | drm/i915: Remove useless checks from primary enable/disableVille Syrjälä2014-05-061-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We won't be calling intel_enable_primary_plane() or intel_disable_primary_plane() with the primary plane in the wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks. v2: Convert the checks to WARNs instead (Daniel,Paulo) 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>
| * | drm/i915: Merge LP1+ watermarks in safer wayVille Syrjälä2014-05-061-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On ILK when we disable a particular watermark level, we must maintain the actual watermark values for that level for some time (until the next vblank possibly). Otherwise we risk underruns. In order to achieve that result we must merge the LP1+ watermarks a bit differently since we must also merge levels that are to be disabled. We must also make sure we don't overflow the fields in the watermark registers in case the calculated watermarks come out too big to fit. As early as possbile we mark all computed watermark levels as disabled if they would exceed the register maximums. We make sure to leave the actual watermarks for such levels zeroed out. Then during merging, we take the maxium values for every level, regardless if they're disabled or not. That may seem a bit pointless since at the moment all the watermark levels we merge should have their values zeroed if the level is already disabled. However soon we will be dealing with intermediate watermarks that, in addition to the new watermark values, also contain the previous watermark values, and so levels that are disabled may no longer be zeroed out. v2: Split the patch in two (Paulo) Use if() instead of & when merging ->enable (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix commit message as noted by Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make sure computed watermarks never overflow the registersVille Syrjälä2014-05-061-7/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we calculate the watermarks for a pipe make sure we leave any level fully zeroed out if it would exceed any of the maximum values that fit in the registers. This will be important later when we start to use also disabled watermark levels during LP1+ merging. 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>
| * | drm/i915: Add pipe update trace pointsVille Syrjälä2014-05-062-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add trace points for observing the atomic pipe update mechanism. v2: Rebased due to earlier changes v3: Pass intel_crtc instead of drm_crtc (Daniel) v4: Pass frame counter from the caller to evaded/end since the caller now always has that ready Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Perform primary enable/disable atomically with sprite updatesVille Syrjälä2014-05-061-39/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the primary plane enable/disable to occur atomically with the sprite update that caused the primary plane visibility to change. FBC and IPS enable/disable is left to happen well before or after the primary plane change. v2: Pass intel_crtc instead of drm_crtc (Daniel) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make sprite updates atomicVille Syrjälä2014-05-064-6/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a mechanism by which we can evade the leading edge of vblank. This guarantees that no two sprite register writes will straddle on either side of the vblank start, and that means all the writes will be latched together in one atomic operation. We do the vblank evade by checking the scanline counter, and if it's too close to the start of vblank (too close has been hardcoded to 100usec for now), we will wait for the vblank start to pass. In order to eliminate random delayes from the rest of the system, we operate with interrupts disabled, except when waiting for the vblank obviously. Note that we now go digging through pipe_to_crtc_mapping[] in the vblank interrupt handler, which is a bit dangerous since we set up interrupts before the crtcs. However in this case since it's the vblank interrupt, we don't actually unmask it until some piece of code requests it. v2: preempt_check_resched() calls after local_irq_enable() (Jesse) Hook up the vblank irq stuff on BDW as well v3: Pass intel_crtc instead of drm_crtc (Daniel) Warn if crtc.mutex isn't locked (Daniel) Add an explicit compiler barrier and document the barriers (Daniel) Note the irq vs. modeset setup madness in the commit message (Daniel) v4: Use prepare_to_wait() & co. directly and eliminate vbl_received v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris) Check for min/max scanline <= 0 (Chris) Don't call intel_pipe_update_end() if start failed totally (Chris) Check that the vblank counters match on both sides of the critical section (Chris) v6: Fix atomic update for interlaced modes v7: Reorder code for better readability (Chris) v8: Drop preempt_check_resched(). It's not available to modules anymore and isn't even needed unless we ourselves cause a wakeup needing reschedule while interrupts are off Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Support 64b relocationsBen Widawsky2014-05-051-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the rest of the code to enable this is in my branch. Without my branch, hitting > 32b offsets is impossible. The code has always "supported" 64b, but it's never actually been run of tested. This change doesn't actually fix anything. [1] I am not sure why X won't work yet. I do not get hangs or obvious errors. There are 3 fixes grouped together here. First is to remove the hardcoded 0 for the upper dword of the relocation. The next fix is to use a 64b value for target_offset. The final fix is to not directly apply target_offset to reloc->delta. reloc->delta is part of ABI, and so we cannot change it. As it stands, 32b is enough to represent everything we're interested in representing anyway. The main problem is, we cannot add greater than 32b values to it directly. [1] Almost all of intel-gpu-tools is not yet ready to test 64b relocations. There are a few places that expect 32b values for offsets and these all won't work. Cc: Rafael Barbalho <rafael.barbalho@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Support 64b execbufBen Widawsky2014-05-053-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, our code only had a 32b offset value for where the batchbuffer starts. With full PPGTT, and 64b canonical GPU address space, that is an insufficient value. The code to expand is pretty straight forward, and only one platform needs to do anything with the extra bits. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/sdvo: Remove ->mode_set callbackDaniel Vetter2014-05-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SDVO is used by both crtcs using the i9xx_ and the ironlake_ functions. For both cases there is nothing between the encoder->mode_set and the encoder->pre_enable calls that touches the hardware. The vlv_ functions are different since they enable the pll before the ->pre_enable hook. But SDVO isn't supported on vlv platforms, so this doesn't matter. We've also already clean up all the sdvo state computation logic, all relevant parts are already in the ->compute_config hook. So we can just get rid of the ->mode_set hook by converting it to a ->pre_enable hook. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/crt: Remove ->mode_set callbackDaniel Vetter2014-05-051-46/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only set a few bits in the ADPA register, which we then read back in the enable/disable hooks. So we can just move that bit of state computation code to the place where we need it since setting these bits without enabling the CRT encoder has no effects. The only exceptions are the hotplug bits since they affect the hotplug detection logic, but we already set those in the ->reset function and then never touch them. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/tv: Remove ->mode_set callbackDaniel Vetter2014-05-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently for the i9xx crtc hooks there's nothing between the call to encoder->mode_set and encoder->pre_enable which touches the hardware. Therefore, since tv is only used on gen3/4, we can just move the hook. Yay for easy cases! The only other important thing to check is that the new ->pre_enable hook is idempotent wrt the sw state since now it can be called multiple times (due to DPMS). After a the bit of refactoring this is now easy to check: It only reads crtc->config and computes derived state but otherwise leaves it as-is, so we're good. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/tv: Rip out pipe-disabling nonsense from ->mode_setDaniel Vetter2014-05-051-41/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe and plane _are_ disabled when we call this. So replace it all with the corresponding assert (as self-documenting code) and rip out all the lore. Checking for a disabled plane would require us to export those macros from intel_display.c, but if the pipe is off the plane isn't working either. So this single check is good enough. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/tv: De-magic device checkDaniel Vetter2014-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We only support TV-out on gen3/4 mobile platforms, and i915gm is the only one that matches. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/tv: extract set_color_conversionDaniel Vetter2014-05-051-14/+21
| | | | | | | | | | | | | | | | | | | | | intel_tv_mode_set is still too bug. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/tv: extract set_tv_mode_timingsDaniel Vetter2014-05-051-50/+61
| | | | | | | | | | | | | | | | | | | | | intel_tv_mode_set is just too big. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/dvo: Remove ->mode_set callbackDaniel Vetter2014-05-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently for the i9xx crtc hooks there's nothing between the call to encoder->mode_set and encoder->pre_enable which touches the hardware. Therefore, since dvo is only used on gen2, we can just move the hook. Yay for easy cases! The only other important thing to check is that the new ->pre_enable hook is idempotent wrt the sw state since now it can be called multiple times (due to DPMS). It only reads crtc->config but otherwise leaves it as-is, so we're good. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make encoder->mode_set callbacks optionalDaniel Vetter2014-05-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a bunch of reasons we want to move away from the ->mode_set callbacks: All hw state setup needs to move into ->enable hooks (so that DOMS can do runtime pm) and all the configuration setup needs to move into the compute_config functions. To start with this make the enocer->mode_set callback optional. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Make primary_enabled match the actual hardware stateVille Syrjälä2014-05-051-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BIOS can enable a pipe but leave the primary plane disabled. This coflicts with out current idea of primary_enabled. Read the actual hardware plane state and set primary_enabled appropriately. We currently assume that primary_enabled is always true when we're about to disable a crtc. That needs to change now as the plane may not be enabled. So replace the relevant WARNs with early returns in intel_{enable,disable}_primary_hw_plane(). Fixes the following warning [ 3.831602] WARNING: CPU: 0 PID: 1112 at linux/drivers/gpu/drm/i915/intel_display.c:1918 intel_disable_primary_hw_plane+0xe4/0xf0 [i915]() which got introduced here by me: commit e9e39655c0c30cddc3f8c09a757678a24dd36737 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Apr 28 15:53:25 2014 +0300 drm/i915: Remove useless checks from primary enable/disable Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Move ring_begin to signal()Ben Widawsky2014-05-052-18/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add_request has always contained both the semaphore mailbox updates as well as the breadcrumb writes. Since the semaphore signal is the one which actually knows about the number of dwords it needs to emit to the ring, we move the ring_begin to that function. This allows us to remove the hideously shared #define On a related not, gen8 will use a different number of dwords for semaphores, but not for add request. v2: Make number of dwords an explicit part of signalling (via function argument). (Chris) v3: very slight comment change Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Virtualize the ringbuffer signal funcBen Widawsky2014-05-052-21/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This abstraction again is in preparation for gen8. Gen8 will bring new semantics for doing this operation. While here, make the writes of MI_NOOPs explicit for non-existent rings. This should have been implicit before. NOTE: This is going to be removed in a few patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Move semaphore specific ring members to structBen Widawsky2014-05-055-80/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will be helpful in abstracting some of the code in preparation for gen8 semaphores. v2: Move mbox stuff to a separate struct v3: Rebased over VCS2 work Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: vlv: init only needed state during early power well enablingImre Deak2014-05-052-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the initial power well enabling on the driver init/resume path we can avoid initialzing part of the HW/SW state that will be initialized anyway by the subsequent init/resume code. For some steps like HPD initialization this redundancy is not only an overhead but an actual problem, since they can't be run this early in the overall init sequence. Add a flag marking the init phase and skip reinitialzing state that is not strictly necessary based on that. This is also needed by the upcoming HPD init restructuring by Thierry and Daniel. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Avoid NULL ctx->obj dereference in debugfs/i915_context_infoChris Wilson2014-05-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 691e6415c891b8b2b082a120b896b443531c4d45 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 9 09:07:36 2014 +0100 drm/i915: Always use kref tracking for all contexts. we populated fake contexts on all platforms. These were identical to the full hardware context tracking structs, except for the ctx->obj used to store the hardware state. However, there remained one place where we assumed that if a context existed, it would have an object associated with it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77717 Testcase: igt/drv_suspend/debugfs-reader Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add intel_get_crtc_scanline()Ville Syrjälä2014-05-052-14/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new function intel_get_crtc_scanline() that returns the current scanline counter for the crtc. v2: Rebase after vblank timestamp changes. Use intel_ prefix instead of i915_ as is more customary for display related functions. Include DRM_SCANOUTPOS_INVBL in the return value even w/o adjustments, for a bit of extra consistency. v3: Change the implementation to be based on DSL on all gens, since that's enough for the needs of atomic updates, and it will avoid complicating the scanout position calculations for the vblank timestamps v4: Don't break scanline wraparound for interlaced modes Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Fix scanout position for realVille Syrjälä2014-05-051-79/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Seems I've been a bit dense with regards to the start of vblank vs. the scanline counter / pixel counter. After staring at the pixel counter on gen4 I came to the conclusion that the start of vblank interrupt and scanline counter increment happen at the same time. The scanline counter increment is documented to occur at start of hsync, which means that the start of vblank interrupt must also trigger there. Looking at the pixel counter value when the scanline wraps from vtotal-1 to 0 confirms that, as the pixel counter at that point reads hsync_start. This also clarifies why we see need the +1 adjustment to the scaline counter. The counter actually starts counting from vtotal-1 on the first active line. I also confirmed that the frame start interrupt happens ~1 line after the start of vblank, but the frame start occurs at hblank_start instead. We only use the frame start interrupt on gen2 where the start of vblank interrupt isn't available. The only important thing to note here is that frame start occurs after vblank start, so we don't have to play any additional tricks to fix up the scanline counter. The other thing to note is the fact that the pixel counter on gen3-4 starts counting from the start of horizontal active on the first active line. That means that when we get the start of vblank interrupt, the pixel counter reads (htotal*(vblank_start-1)+hsync_start). Since we consider vblank to start at (htotal*vblank_start) we need to add a constant (htotal-hsync_start) offset to the pixel counter, or else we risk misdetecting whether we're in vblank or not. I talked a bit with Art Runyan about these topics, and he confirmed my findings. And that the same rules should hold for platforms which don't have the pixel counter. That's good since without the pixel counter it's rather difficult to verify the timings to this accuracy. So the conclusion is that we can throw away all the ISR tricks I added, and just increment the scanline counter by one always. Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/bdw: Disable idle DOP clock gatingBen Widawsky2014-05-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems we need this at least for the current platforms we have, but probably not later. In any event, it should cause too much harm as we do the same thing on several other platforms. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
View Lorry Controller Status