aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2016-05-23drm/i915: Store BXT DE PLL vco and ref clocks in dev_privVille Syrjälä1-1/+26
We have need to know the DE PLL refclk and output frequency in various cdclk calculations, so let's store those in dev_priv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-17-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()Ville Syrjälä1-14/+27
Enabling and disalbing the DE PLL are two nice self contained operations, so let's move them into a few small helper functions. Makes it easier to see the forest from the trees in broxton_set_cdclk(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-16-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Store cdclk PLL reference clock under dev_privVille Syrjälä2-7/+9
Future platforms will have multiple options for the cdclk PLL reference clock, so let's start tracking that under dev_priv alreday on SKL, although on SKL it's always 24 MHz. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Rename skl_vco_freq to cdclk_pll.vcoVille Syrjälä3-29/+31
We'll want to store the cdclk PLL (whatever PLL that is in reality) vco frequency somewhere on other platforms too, so let's rename the skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz to match most of the other clocks. v2: Drop the spurious > vs != change (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-14-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Make 308 and 671 MHz cdclks more accurate on SKLVille Syrjälä1-9/+9
The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz. Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz. Let's use the slightly more accurate numbers. Potentially we might change to computing all of these based on dividers, but let's stick to the current theme for now.. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Move SKL+ DBUF enable/disable to display core init/uninitVille Syrjälä2-52/+38
SKL and BXT have the same snippets of code for enabling disabling the DBUF. Extract those into helpers and move the calls from init/unit_cdclk() to the display core init/init since this stuff isn't really about cdclk. Also doing the enable twice shouldn't hurt since you're just setting the request bit again when it was already set. We can also toss in a few WARNs about the register values into skl_get_dpll0_vco() now that we know that things should always be sane there. Flatten skl_init_cdclk() while at it. v2: s/skl/gen9/ in function names (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Unify SKL cdclk init pathsVille Syrjälä4-23/+34
Currently we initialize cdclk on SKL from two different places, depending on whether it's during driver init or resume. Let's unify it to happen from the same place always, and that place will be the display core init function. To do this we first run through the cdclk sanitation code, which will first verify that the PLL is programmed correctly, after which we can read out the current cdclk frequency, and once the cdclk is known we verify that the cdclk "decimal" frequency is programmed correctly. If any of these fail we will force a cdclk change, and to be safe we also force the PLL to be turned off and on again. If the sanitation step didn't notice anything amiss, we'll skip the cdclk programming which will prevent cdclk reprogramming when the displays might be active. We can also toss in a few WARNs about the register values into skl_update_dpll0() since we now know that the PLL state should always be sane when that function is called. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Beef up skl_sanitize_cdclk() a bitVille Syrjälä1-5/+13
Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw out a few unneeded variables, and write the CDCLK_CTL check a bit more legible way. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Keep track of preferred cdclk vco frequency on SKLVille Syrjälä4-8/+47
Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need something that keeps track of which vco frequency we want to use in case the current vco is 0. This would be important across supend/resume since we'll disable DPLL0 around those parts. We'll also update our idea of max cdclk/dotclock when the preferred vco changes. That could happen if out initial guess was wrong, and later eDP would force us to change it. One issue here could be that changing the max dotclock could cause our mode list to change during next time the displays get probed. But I don't see a good way to avoid that, except perhaps by allowing either vco frequency to be used as needed. But the docs suggest that such usage wasn't really inteded. Also need to make sure we don't update our max_cdclk value before we have a preferred vco value, which means moving that to happen after the cdclk sanitation. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKLVille Syrjälä1-25/+29
In case we originally guessed wrong which lcpll vco frequency to use, we will need to shut down the pll and restart it when reprogamming the cdclk. This also allows us to track the actual vco frequency in dev_priv instead of just a guess. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Report the current DPLL0 vco on SKL/KBLVille Syrjälä1-2/+7
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Actually read out DPLL0 vco on skl from hardwareVille Syrjälä2-42/+37
Currently we're trying to guess which lcpll vco frequency is used use based on the cdclk. That doesn't work for cdclk==540 since both vco frequencies can generate a 540 Mhz output. Let's stop guessing and just read the actual vco frequency from the hardware. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Extract skl_calc_cdclk()Ville Syrjälä1-33/+30
We have many places where we want to pick a suitable cdclk frequency for skl based on the dotclock and lcpll vco. Split that code into a small helper and call it from all over. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config()Ville Syrjälä2-4/+21
Shared plls won't get assigned until the .compute_clocks() hook gets called, which happens from the crtc .atomic_check hook. That's too late as the cdclk computation has already happened. So let's move the DPLL0 VCO computation into intel_dp_compute_config() so that it's done when the cdclk computation happens. Also only do it for eDP since we only pick DPLL0 for eDP. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915/skl: SKL CDCLK change on modeset tracking VCOClint Taylor4-20/+104
WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected to DDI1 the system will hard hang during a cold boot. Occurs when DDI1 is enabled when the cdclk is less then required. DP connected to DDI2 and HPD on either port works correctly. Set cdclk based on the max required pixel clock based on VCO selected. Track boot vco instead of boot cdclk. The vco is now tracked at the atomic level and all CRTCs updated if the required vco is changed. Not tested with eDP v1.4 panels that require 8640 vco due to availability. V1: initial version V2: add vco tracking in intel_dp_compute_config(), rename skl_boot_cdclk. V3: rebase, V2 feedback not possible as encoders are not aware of atomic. V4: track target vco is atomic state. modeset all CRTCs if vco changes V5: rename atomic variable, cleaner if/else logic, use existing vco if encoder does not return a new vco value. check_patch.pl cleanup V6: simplify logic in intel_modeset_checks. V7: reorder an IF for readability and whitespace fix. V8: use dev_cdclk for tracking new cdclk during atomic V9: correctly handle vco 8640 when crtcs==0 V10: Clean up if else in crtcs==0 V11: Rebase for new intel_dpll_mgr.c Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> [vsyrjala: rebased due to churn] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-3-git-send-email-ville.syrjala@linux.intel.com
2016-05-23drm/i915: Fix BXT min_pixclk after state readoutVille Syrjälä1-8/+6
commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation") tried to change BXT to use ilk_max_pixel_rate() to compute the pipe pixel rate. I failed to notice that there was another place in the state readout code that needs the same treatment. So let's change that one too. Should probably just change things to always compuyte the pipe pixel rates, instead of just doing on platforms that can change cdclk dynamically. But for now let's just move BXT fully over to the side that uses ilk_pipe_pixel_rate(). Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-05-23drm/i915/opregion: Rename init/fini functions to register/unregisterChris Wilson4-8/+8
Current intel_opregion_init is called during the driver registration phase and intel_opregion_fini from the unregistration phase. Rename the functions so that this is clear from their names. The phases tell us what we expect the existing hw state to be, e.g. whether interrupts are still enabled etc. It should be noted that the opregion init/fini routines are asymmetric and this is carried across into their new names. Indeed, their new names make it even clearer that perhaps all is not well in the opregion suspend/resume sequence (as well in the module unload). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-2-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
2016-05-23drm/i915/opregion: Convert to using native drm_i915_privateChris Wilson5-77/+74
Prefer passing struct drm_i915_private to internal interfaces as this saves us having to dance between drm_device and our native struct. The savings hare are small (only 70 bytes of unrequired dancing), but progressive! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
2016-05-23drm/i915: Enable GSE interrupt on BDW+Ville Syrjälä1-0/+2
We've never actually enabled or unmasked the GSE interrupt on BDW+, even though the interrupt handler was always prepared for it. Let's enable it and see what happens. Credit to Mark Kettenis who fixed this in the OpenBSD fork of the driver. He reports that it fixed the "ACPI _BCM/_BCQ-based brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1 Carbon" for them. Mark says: "FWIW, this *is* needed if you want ACPI-based backlight control to work. On Linux you probably don't notice, since "hardware" backlight control is preferred over "firmware" or "platform" backlight control. It would help me if this did land in the Linux tree though, as it will make future imports of the i915 driver into OpenBSD easier." So even though we don't really need this, let's put it in to help Mark with future porting efforts. Should be harmless to have it enabled in any case. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463649283-28698-1-git-send-email-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-05-23drm/i915/guc: rework guc_add_workqueue_item()Dave Gordon3-38/+38
Mostly little optimisations and future-proofing against code breakage. For instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development and less impact in end-user systems. Similarly we can make alignment checking more stringent and replace other WARN_ON() conditions that don't relate to the runtime hardware state with either BUILD_BUG_ON() for compile-time-detectable issues, or GEM_BUG_ON() for logical "can't happen" errors. With those changes, we can convert it to void, as suggested by Chris Wilson, and update the calling code appropriately. v2: Note that we're now putting the request seqno in the "fence_id" field of each GuC-work-item, in case it turns up somewhere useful (e.g. in a GuC log) [Tvrtko Ursulin]. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-23drm/i915/guc: don't spinwait if the GuC's workqueue is fullDave Gordon3-17/+24
Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see how often we find the WQ full. v2: Flag the likely() code path (Tvtrko Ursulin). v4: Add/update comments about failure counters (Tvtrko Ursulin). Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-23drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()Dave Gordon3-18/+42
The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable from) the request. v2: GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin). Add/update kerneldoc explaining check_space/submit protocol Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-23drm/i915/guc: add enable_guc_loading parameterDave Gordon5-60/+89
Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In addition, the degree of control has been refined from a simple bool to an integer key, allowing several options: -1 (default) whatever the platform default is 0 DISABLE don't load/use the GuC 1 BEST EFFORT try to load/use the GuC, fallback if not available 2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. v4: Changed some error-message levels, mostly ERROR->INFO, per review comments by Tvrtko Ursulin. v5: Dropped one more error message, disabled GuC submission on hypothetical firmware-free devices [Tvrtko Ursulin]. v6: Logging tidy by Tvrtko Ursulin: * Do not log falling back to execlists when wedging the GPU. * Do not log fw load errors when load was disabled by user. * Pass down some error code from fw load for log message to make more sense. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Tested-by: Fiedorowicz, Lukasz <lukasz.fiedorowicz@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> (v6)
2016-05-23drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHEDDave Gordon4-5/+11
For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, various tests should use this new macro rather than HAS_GUC_UCODE() or testing enable_guc_submission. v4: Added a couple more uses of the new macro. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-23drm/i915/guc: rename loader entry pointsDave Gordon4-16/+17
The GuC initialisation code could do other things apart from loading firmware, so here we rename the three primary entry points to remove any specific reference to "ucode" (no functional changes, just renaming). Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-05-22drm/i915: Update DRIVER_DATE to 20160522Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-05-20drm/i915: Inline sg_next() for the optimised SGL iteratorDave Gordon1-2/+21
Avoiding the out-of-line call to sg_next() reduces the kernel execution overhead by 10% in some workloads (for example the Unreal Engine 4 demo Atlantis on 2GiB GTTs) which are dominated by the cost of inserting PTEs due to texture thrashing. We can demonstrate this in a microbenchmark that forces us to rebind the object on every execbuf, where we can measure a 25% improvement, in the time required to execute an execbuf requiring a texture to be rebound, for inlining the sg_next() for large texture sizes. Benchmark: igt/benchmarks/gem_exec_fault Benchmark: igt/benchmarks/gem_exec_trace/Atlantis Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-5-git-send-email-chris@chris-wilson.co.uk
2016-05-20drm/i915: Introduce & use new lightweight SGL iteratorsDave Gordon5-63/+112
The existing for_each_sg_page() iterator is somewhat heavyweight, and is limiting i915 driver performance in a few benchmarks. So here we introduce somewhat lighter weight iterators, primarily for use with GEM objects or other case where we need only deal with whole aligned pages. Unlike the old iterator, the new iterators use an internal state structure which is not intended to be accessed by the caller; instead each takes as a parameter an output variable which is set before each iteration. This makes them particularly simple to use :) One of the new iterators provides the caller with the DMA address of each page in turn; the other provides the 'struct page' pointer required by many memory management operations. Various uses of for_each_sg_page() are then converted to the new macros. v2: Force inlining of the sg_iter constructor and make the union anonymous. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-4-git-send-email-chris@chris-wilson.co.uk
2016-05-20drm/i915: optimise i915_gem_object_map() for small objectsDave Gordon1-5/+10
We're using this function for ringbuffers and other "small" objects, so it's worth avoiding an extra malloc()/free() cycle if the page array is small enough to put on the stack. Here we've chosen an arbitrary cutoff of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-3-git-send-email-chris@chris-wilson.co.uk
2016-05-20drm/i915: refactor i915_gem_object_pin_map()Dave Gordon1-23/+35
The recently-added i915_gem_object_pin_map() can be further optimised for "small" objects. To facilitate this, and simplify the error paths before adding the new code, this patch pulls out the "mapping" part of the operation (involving local allocations which must be undone before return) into its own subfunction. The next patch will then insert the new optimisation into the middle of the now-separated subfunction. This reorganisation will probably not affect the generated code, as the compiler will most likely inline it anyway, but it makes the logical structure a bit clearer and easier to modify. v2: Restructure loop-over-pages & error check [Chris Wilson] v3: Add page count to debug messages [Chris Wilson] Convert WARN_ON() to GEM_BUG_ON() v4: Drop the DEBUG messages [Tvrtko Ursulin] Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-2-git-send-email-chris@chris-wilson.co.uk
2016-05-20drm/i915/psr: Implement PSR2 w/a for gen9Daniel Vetter2-2/+16
Found this while browsing Bspec. Looks like it applies to both skl and kbl. v2: Also for bxt (Art). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com> Reviewed-by: Sonika Jindal<sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463642060-30728-1-git-send-email-daniel.vetter@ffwll.ch
2016-05-20drm/i915/psr: Use ->get_aux_send_ctl functionsDaniel Vetter2-21/+5
I just wanted to get rid of the rmw cycle for gen9, but this also fixes some bugs we haven't carried over, like using recommended precharge and timeout values. Also I noticed that we don't set the fastwake sync length on skl, and that's used by PSR2 selective updates. Fix that. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-6-git-send-email-daniel.vetter@ffwll.ch
2016-05-20drm/i915/psr: Order DP aux transactions correctlyDaniel Vetter1-7/+7
On bdw/hsw we have a separate psr dp aux registers to set up, but on bdw it's shared with the main dp aux thing. Which means any subsequent dp aux transaction will trample over it, and hence must be done beforehand. Also this means we can't do any dp aux transactions while PSR is active, or at least we must restore the old state. Probably need a psr disable/enable pair around dp aux transactions in general. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-5-git-send-email-daniel.vetter@ffwll.ch
2016-05-20drm/i915/psr: Make idle_frames sensible againDaniel Vetter1-7/+7
This reverts commit dfaf37baa07513d2c37afff79978807d2d10221a Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Mon Dec 7 14:45:20 2015 -0800 drm/i915: Fix idle_frames counter. and commit 97173eaf5f33b1e85efdb06d593d333480b60bf3 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Tue Jul 7 16:28:55 2015 -0700 drm/i915: PSR: Increase idle_frames and implements commit d44b4dcbd1b44737462b77971d216d21a9413341 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Fri Nov 14 08:52:31 2014 -0800 drm/i915: HSW/BDW PSR Set idle_frames = VBT + 1 without the hack to use 2 idle frames when VBT says 1. We keep the + 1 just for safety, although I haven't really figured out why that one exists. It's nonsense. idle_frames = number of frames where the screen is entirely idle before we think about entering PSR. idle_patter = part of link training, and we probably totally butchered link training because we told the hw to entirely skip it. No wonder PSR occasionally just fell over. I suspect the reason we've increased idle frames is that it makes PSR entry slightly less likely, and more likely to happen in a quite system, which probably increased the changes the panel came back up without link training. The proper fix is to implement link training for PSR. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-3-git-send-email-daniel.vetter@ffwll.ch
2016-05-20drm/i915/psr: Try to program link training times correctlyDaniel Vetter1-8/+47
The default of 0 is 500us of link training, but that's not enough for some platforms. Decoding this correctly means we're using 2.5ms of link training on these platforms, which fixes flickering issues associated with enabling PSR. v2: Unbotch the math a bit. v3: Drop debug hunk. v4: Improve commit message. Tested-by: Lyude <cpaul@redhat.com> Cc: Lyude <cpaul@redhat.com> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: fritsch@kodi.tv Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-2-git-send-email-daniel.vetter@ffwll.ch
2016-05-19drm/i915/userptr: Convert to drm_i915_privateChris Wilson3-9/+3
userptr directly only uses drm_device in a single interface where it meant to use drm_i915_private (everywhere else we have to derive it from the drm_i915_gem_object and so require going from drm_device). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463671036-3235-1-git-send-email-chris@chris-wilson.co.uk
2016-05-19drm/i915: Allow nonblocking update of pageflips.Maarten Lankhorst1-266/+84
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-22-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Check for unpin correctness.Maarten Lankhorst1-0/+9
If planes are added to the state after the call to drm_atomic_helper_check_planes planes_changed may not be set and we will not unpin the old framebuffer. This results in a pin leak long after the framebuffer is destroyed, so to find this add some checks when it happens. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-21-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"Maarten Lankhorst1-5/+7
This reapplies commit acf4e84d6167317ff21be5c03e1ea76ea5783701. With async unpin this should no longer break. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-20-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Make unpin async.Maarten Lankhorst3-132/+228
All of intel_post_plane_update is handled there now, so move it over. This is run after the hw state checker because it can't handle checking crtc's separately yet. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-19-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Prepare connectors for nonblocking checks.Maarten Lankhorst2-14/+43
intel_unpin_work may not take the list lock because it requires the connector_mutex. To prevent taking locks we add an array of old and new state. The old state to free, the new state to commit and verify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-18-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Pass atomic states to fbc update functions.Maarten Lankhorst3-26/+29
This is required to let fbc updates run async. It has a lot of checks whether certain locks are taken, which can be removed when the relevant states are passed in as pointers. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-17-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Remove reset_counter from intel_crtc.Maarten Lankhorst2-12/+0
With the removal of cs-based flips all mmio waits will finish without requiring the reset counter, because the waits will complete during gpu reset. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-16-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Remove queue_flip pointer.Maarten Lankhorst2-264/+0
With the removal of cs support this is no longer reachable. Can be revived if needed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-15-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Remove use_mmio_flip kernel parameter.Maarten Lankhorst3-9/+1
With the removal of cs flips this is always force enabled. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-14-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Remove cs based page flip support.Maarten Lankhorst4-507/+33
With mmio flips now available on all platforms it's time to remove support for cs flips. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-13-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.Maarten Lankhorst3-280/+441
Create a work structure that will be used for all changes. This will be used later on in the atomic commit function. Changes since v1: - Free old_crtc_state from unpin_work_fn properly. Changes since v2: - Add hunk for calling hw state verifier. - Add missing support for color spaces. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-12-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Add the exclusive fence to plane_state.Maarten Lankhorst2-13/+42
Set plane_state->base.fence to the dma_buf exclusive fence, and add a wait to the mmio function. This will make it easier to unify plane updates later on. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-11-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Convert flip_work to a list.Maarten Lankhorst4-100/+142
This will be required to allow more than 1 update in the future. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-10-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
2016-05-19drm/i915: Allow mmio updates on all platforms, v2.Maarten Lankhorst2-93/+7
With intel_pipe_update begin/end we ensure that the mmio updates don't run during vblank interrupt, using the hw counter we can be sure that when current vblank count != vblank count at the time of pipe_update_end the mmio update is complete. This allows us to use mmio updates on all platforms, using the update_plane call. With Chris Wilson's patch to skip waiting for vblanks for legacy_cursor_update this potentially leaves a small race condition, in which update_plane can be called with a freed crtc_state. Because of this commit acf4e84d61673 ("drm/i915: Avoid stalling on pending flips for legacy cursor updates") is temporarily reverted. Changes since v1: - Split out the flip_work rename. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-9-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.