summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2013-10-21drm/i915: Fix PIPE_CRC_CTL for vlvDaniel Vetter1-2/+1
The PIPE_B #define was missing the display mmio offset. Use the _PIPE_INC macro instead, it's simpler. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: Enable CRC interrupts on pre-gen5/vlvDaniel Vetter1-1/+20
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: Wire up CRC interrupts for pre-gen5/vlvDaniel Vetter1-6/+16
And throw in a tiny for_each_pipe refactoring for gen2. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: CRC source selection #defines for gmch/vlv chipsDaniel Vetter1-0/+22
A bit a mess, since with DP/TV outputs we can't use the pipe CRC. Also, no plane CRCs, so we need to update the basic testcases. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: Adjust CRC capture for pre-gen5/vlvDaniel Vetter2-24/+34
Should work down to gen2. The #defines for the interrupt sources are already there in PIPESTAT and are the same on all gmch platforms for gen2 up to vlv. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: Whitespace alignment fix for block header in display error stateChris Wilson1-1/+1
The current output looks like: Num Pipes: 2 Pipe [0]: SRC: 027f01df Plane [0]: CNTR: d9000000 STRIDE: 00001400 SIZE: 031f04ff POS: 00000000 ADDR: 00020000 Cursor [0]: CNTR: 00000000 POS: 00000000 BASE: 00000000 Pipe [1]: SRC: 04ff031f Plane [1]: CNTR: 01000000 STRIDE: 00000000 SIZE: 018f02cf POS: 00000000 ADDR: 00000000 Cursor [1]: CNTR: 00000000 POS: 00000000 BASE: 00000000 CPU transcoder: A CONF: 00000000 HTOTAL: 031f027f HBLANK: 03170287 HSYNC: 02ef028f VTOTAL: 020c01df VBLANK: 020401e7 VSYNC: 01eb01e9 CPU transcoder: B CONF: 80000000 HTOTAL: 059f04ff HBLANK: 059f04ff HSYNC: 054f052f VTOTAL: 0336031f VBLANK: 0336031f VSYNC: 03280322 which lacks the important visual clue to demarque the transcoder blocks from the last cursor. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: fix open-coded DIV_ROUND_UPPaulo Zanoni2-3/+3
Use the nice Kernel macro, it makes the code much more readable. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: Print RC6 info less oftenBen Widawsky2-32/+43
Since we use intel_enable_rc6() now for more than just when we're enabling RC6, we'll see this message many times, and it is just confusing. As an example, calc_residency calls this function whenever poked via sysfs. This leaves the impression in dmesg that we're constantly re-enabling RC6. While at it, move the defines and description from drv.h to intel_pm.c, since these are only ever used in that code. 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>
2013-10-18drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bppJani Nikula1-2/+3
This is useful with the follow-up patch that frobs dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: Disable GGTT PTEs on GEN6+ suspendBen Widawsky4-12/+78
Once the machine gets to a certain point in the suspend process, we expect the GPU to be idle. If it is not, we might corrupt memory. Empirically (with an early version of this patch) we have seen this is not the case. We cannot currently explain why the latent GPU writes occur. In the technical sense, this patch is a workaround in that we have an issue we can't explain, and the patch indirectly solves the issue. However, it's really better than a workaround because we understand why it works, and it really should be a safe thing to do in all cases. The noticeable effect other than the debug messages would be an increase in the suspend time. I have not measure how expensive it actually is. I think it would be good to spend further time to root cause why we're seeing these latent writes, but it shouldn't preclude preventing the fallout. NOTE: It should be safe (and makes some sense IMO) to also keep the VALID bit unset on resume when we clear_range(). I've opted not to do this as properly clearing those bits at some later point would be extra work. v2: Fix bugzilla link Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321 Tested-by: Takashi Iwai <tiwai@suse.de> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Tested-By: Todd Previte <tprevite@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: Make PTE valid encoding optionalBen Widawsky2-16/+22
We need this to work around a corruption when the boot kernel image loads the hibernated kernel image from swap on Haswell systems - somehow not everything is properly shut off. This is just the prep work, the next patch will implement the actual workaround. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a commit message suitable for -fixes and add cc: stable] Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: remove dead code in ironlake_crtc_mode_setDaniel Vetter1-5/+0
In Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 5 13:34:23 2013 +0200 drm/i915: consolidate pch pll enable sequence I've removed all the code from this if block, but somehow forgotten to kill the block itself. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: crc support for hswDaniel Vetter3-20/+27
hw designers decided to change the CRC registers and coalesce them all into one. Otherwise nothing changed. I've opted for a new hsw_ version to grab the crc sample since hsw+1 will have the same crc registers, but different interrupt source registers. So this little helper function will come handy there. Also refactor the display error handler with a neat pipe loop. v2: Use for_each_pipe. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: fix CRC debugfs setupDaniel Vetter1-2/+1
We've set up all files, but removed only those for which we have a pipe. Which leaves the one for pipe C on machines with less than 2 pipes, breaking module reload. v2: We can't get at the drm device this early (wtf), so just register all the files and also remove them all again. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: wait one vblank when disabling CRCsDaniel Vetter1-0/+2
This avoids a spurious spurious interrupt warning. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: use ->get_vblank_counter for the crc frame counterDaniel Vetter1-6/+4
Suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: wire up CRC interrupt for ilk/snbDaniel Vetter4-19/+84
We enable the interrupt unconditionally and only control it through the enable bit in the CRC control register. v2: Extract per-platform helpers to compute the register values. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: add CRC #defines for ilk/snbDaniel Vetter1-11/+35
Also add a new _PIPE_INC macro which takes an base plus increment. Much less likely to botch the job by missing an s/A/B/ somewhere. v2: They've moved the bitfield. Argh! Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: extract display_pipe_crc_updateDaniel Vetter1-7/+23
The ringbuffer update logic should always be the same, but different platforms have different amounts of CRC registers. Hence extract it. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: don't Oops in debugfs for I915_FBDEV=nDaniel Vetter1-1/+1
Failed to properly test this. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: set HDMI pixel clock in audio configurationJani Nikula2-5/+55
The HDMI audio expects HDMI pixel clock to be set in the audio configuration. We've currently just set 0, using 25.2 / 1.001 kHz frequency, which fails with some modes. v2: Now with a commit message. Reference: http://mid.gmane.org/CAGpEb3Ep1LRZETPxHGRfBDqr5Ts2tAc8gCukWwugUf1U5NYv1g@mail.gmail.com Reference: http://mid.gmane.org/20130206213533.GA16367@hardeman.nu Reported-by: David Härdeman <david@hardeman.nu> Reported-by: Jasper Smet <josbeir@gmail.com> Tested-by: Jasper Smet <josbeir@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: pass mode to ELD write vfuncsJani Nikula2-5/+9
This will be needed for setting the HDMI pixel clock for audio config. No functional changes. v2: Now with a commit message. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-18drm/i915: check gem bo size when creating framebuffersDaniel Vetter1-0/+8
It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb->heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. v2: Take tiling into account, requested by Ville. v3: Fix tile height on gen2, spotted by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-17drm/i915: Use unsigned long for obj->user_pin_countDaniel Vetter2-1/+6
At least on linux sizeof(long) == sizeof(void*) and the thinking is that you can grab about as many references as there's memory. Doesn't really matter, just a bit of OCD since the fixed size data type in a pure in-kernel datastructure look off. v2: Ville asked for an overflow check since no one prevents userspace from incrementing the pin count forever. v3: s/INT/LONG/, noticed by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-17drm/i915: prevent tiling changes on framebuffer backing storageDaniel Vetter3-5/+7
Assuming that all framebuffer related metadata is invariant simplifies our userspace input data checking. And current userspace always first updates the tiling of an object before creating a framebuffer with it. This allows us to upconvert a check in pin_and_fence to a WARN. In the future it should also be helpful to know which buffer objects are potential scanout targets for e.g. frontbuffer rendering tracking and similar things. Note that SNA shipped for one prerelease with code which will be broken through this patch. But users shouldn't notice since it's purely an optimization and will transparently fall back to allocating a new fb. i-g-t also had offending code (now fixed), but we don't really care about breaking the test-suite. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Grumpily-reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-17drm/i915: grab dev->struct_mutex around framebuffer_initDaniel Vetter1-5/+14
We look at gem state (like obj->tiling/obj->stride), we better have the relevant locks. Right now this doesn't matter much since most of these checks are a curtesy to safe buggy userspace, but I'd like to freeze the tiling once we have framebuffer objects attached. And then locking matters. 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>
2013-10-17drm/i915: vlv: fix VGA hotplug after modesetImre Deak1-1/+1
Since commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 11 20:08:23 2012 +0200 drm/i915/crt: don't set HOTPLUG bits on !PCH on VLV we don't detect any VGA unplug event after a modeset, since there we reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as well. Signed-off-by: Imre Deak <imre.deak@intel.com> [danvet: For consistency use gen >= 5 like in Chris' exact same fix in intel_crt_reset.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: preserve dispaly init order on ByTArtem Bityutskiy1-8/+7
This patch changes HDMI port registration order for the BayTrail platform. The story is that in kernel version 3.11 i915 supported only one HDMI port - the HDMIB port. So this port ended up being HDMI-1 in user-space. But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT' introduced HDMIC port support. And added HDMIC registration prior to HDMIB, so HDMIB became HDMI-2 and HDMIC became HDMI-1. Well, this is fine as far as the kernel is concerned. i915 does not give any guarantees to the numbering, and has never given them. However, this breaks wayland setup in Tizen IVI. We have only one single HDMI port on our hardware, and it is connected to HDMIB. Our configuration relies on the fact that it is HDMI-1. Well, certainly this is user-space problem which was exposed with Jesse's patch. However, there is a reason why we have to do this assumption - we use touchscreen monitors and we have to associate event devices with the monitors, and this is not easy to do dynamically, so we just have a static setup. Anyway, while the user-space setup will have to be fixed regardless, let's chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it was in 3.11. Simply because there is no strong reason for changing the order in the kernel, and it'll help setups like ours in sense that we'll have more time for fixing the issue properly. Also amend the commentary which looks a bit out-of-date. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> [danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC define now.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Use pipe_name() instead of the pipe numberDamien Lespiau3-4/+4
Yet other direct usages of the pipe number instead of pipe_name(). We've been tracking them lately but managed to miss these last ones. v2: Catch them all! (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Disable all GEM timers and work on unloadChris Wilson4-36/+23
We have two once very similar functions, i915_gpu_idle() and i915_gem_idle(). The former is used as the lower level operation to flush work on the GPU, whereas the latter is the high level interface to flush the GEM bookkeeping in addition to flushing the GPU. As such i915_gem_idle() also clears out the request and activity lists and cancels the delayed work. This is what we need for unloading the driver, unfortunately we called i915_gpu_idle() instead. In the process, make sure that when cancelling the delayed work and timer, which is synchronous, that we do not hold any locks to prevent a deadlock if the work item is already waiting upon the mutex. This requires us to push the mutex down from the caller to i915_gem_idle(). v2: s/i915_gem_idle/i915_gem_suspend/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: xunx.fang@intel.com [danvet: Only set ums.suspended for !kms as discussed earlier. Chris noticed that this slipped through.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Move some hdmi enable function name to vlv specific.Chon Ming Lee1-6/+6
There is no functional change on this patch. Only rename several hdmi encoder function name which suppose to use only by valleyview from intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: constify harderDaniel Vetter1-2/+2
We not only want const strings, but a const array of them. Reported by checkpatch.pl Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: static inline for dummy crc functionsDaniel Vetter2-3/+3
Also use #ifdef to keep consistent with all other such cases. Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Enable pipe CRCsDamien Lespiau1-3/+0
It's time to declare them ready. Unleash the beast. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Only one open() allowed on pipe CRC result filesDamien Lespiau2-0/+17
It doesn't really make sense to have two processes dequeueing the CRC values at the same time. Forbid that usage. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Implement blocking read for pipe CRC filesDamien Lespiau4-19/+155
seq_file is not quite the right interface for these ones. We have a circular buffer with a new entry per vblank on one side and a process wanting to dequeue the CRC with a read(). It's quite racy to wait for vblank in user land and then try to read a pipe_crc file, sometimes the CRC interrupt hasn't been fired and we end up with an EOF. So, let's have the read on the pipe_crc file block until the interrupt gives us a new entry. At that point we can wake the reading process. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Move drm_add_fake_info_node() higher in the fileDamien Lespiau1-26/+26
Following commit needs drm_add_fake_info_node() higher in the file to avoid having a forward declaration. Move this helper near the top of the file. This also makes the next commit diff a bit easier to review. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Add log messages when CRCs collection is started/stoppedDamien Lespiau1-0/+6
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Warn if we receive an interrupt after freeing the bufferDamien Lespiau1-0/+5
This shouldn't happen as the buffer is freed after disable pipe CRCs, but better be safe than sorry. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Rename i915_pipe_crc_ctl to i915_display_crc_ctlDamien Lespiau1-21/+21
In the same spirit than: drm/i915: Generalize the CRC command format for future work Let's move from writing 'A plane1' to 'pipe A plane1' to i915_pipe_crc_ctl. This will allow us to extend the interface to transcoders or DDIs in the future. Let's rename the CRC control file to be more generic. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Generalize the CRC command format for future workDamien Lespiau1-13/+43
Let's move from writing 'A plane1' to 'pipe A plane1' to i915_pipe_crc_ctl. This will allow us to extend the interface to transcoders or DDIs in the future. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Dynamically allocate the CRC circular bufferDamien Lespiau2-1/+13
So we don't eat that memory when not needed. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Empty the circular buffer when asked for a new sourceDamien Lespiau1-0/+6
So we don't read out stale CRCs from a previous run left in the buffer. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Enforce going back to none before changing CRC sourceDamien Lespiau1-0/+4
This way we can have some init/fini code on those transitions. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Make switching to the same CRC source a no-opDamien Lespiau1-1/+5
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Sample the frame counter instead of a timestamp for CRCsDamien Lespiau3-9/+5
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Keep the CRC values into a circular bufferDamien Lespiau3-14/+29
There are a few good properties to a circular buffer, for instance it has a number of entries (before we were always dumping the full buffer). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Add a control file for pipe CRCsDaniel Vetter2-2/+224
Note the "return -ENODEV;" in pipe_crc_set_source(). The ctl file is disabled until the end of the series to be able to do incremental improvements. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Expose latest 200 CRC value for pipe through debugfsShuang He4-1/+118
There are several points in the display pipeline where CRCs can be computed on the bits flowing there. For instance, it's usually possible to compute the CRCs of the primary plane, the sprite plane or the CRCs of the bits after the panel fitter (collectively called pipe CRCs). v2: Quite a bit of rework here and there (Damien) Signed-off-by: Shuang He <shuang.he@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Fix intermediate compile file reported by Wu Fengguang's kernel builder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-16drm/i915: Replace has_bsd/blt/vebox with a maskBen Widawsky2-18/+28
I've sent this patch several times for various reasons. It essentially cleans up a lot of code where we need to do something per ring, and want to query whether or not the ring exists on that hardware. It has various uses coming up, but for now it shouldn't be too offensive. v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff v3: Resolved vebox addition v4: Rebased after months of disuse. Also made failed ringbuffer init cleaner. v5: Remove the init cleaner from v4. There is a better way to do it. (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 19:09:03 +0300