- 22 Jun, 2016 8 commits
-
-
Ville Syrjälä authored
During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Fixes: 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463162036-27931-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Imre Deak authored
The wait for panel status helper will only function correctly if the HW panel timings are programmed correctly. Returning prematurely from this helper may lead to obscure bugs later, so sanity check the HW timing registers. v2: - Check the T8, T9 fields too, we do program them (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
This will be needed by the next patch too so factor it out. No functional change. Signed-off-by:
-
Imre Deak authored
No functional change. Signed-off-by:
-
Imre Deak authored
The PPS registers are backed by power well #0 and as such may be reset after system or runtime suspend (both implying a possible DC9 transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment logic. The difference on BXT is that the PPS instances are not pipe but port (or more accurately pin) specific, so we only need to care about the lost HW state. As opposed to VLV/CHV the SW state is fixed and initialized during connector init. This also paves the way towards using the actual port->PPS instance mapping based on VBT. This fixes eDP link training errors on BXT after suspend, where we started the link training too early due to an incorrect T3 (panel power on) register value. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96436Signed-off-by:
-
Imre Deak authored
Move the early PPS initialization calls next to the rest of PPS initialization steps. This allows us to forgo a duplicated call to intel_dp_init_panel_power_sequencer_registers() on VLV/CHV. This will swap the order of DP AUX registration wrt. PPS initialization. There is an existing race here in case of a user space access via the DPAUX device node after DP AUX registration and before calling intel_dp_init_panel_power_sequencer_registers(), but this change won't make this worse. The fix for this is to separate DP AUX initialization and registration, that's a separate work already underway. The order of MST wrt. PPS init as well as the order of intel_dp_init_panel_power_sequencer_registers() wrt. intel_edp_panel_vdd_sanitize() also swap, which is ok, there are no dependencies between these steps. Suggested by Ville. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The initial DPCD read for eDP detection involves using the PPS, but so far we only initialized the PPS registers after the DPCD read. The reason this was done so far is to preserve a possible LVDS PPS HW setup if LVDS is detected but eDP is not. This is not an issue any more after the previous patch, so we can move the init earlier now. This was caught by CI with the PPS sanity checks in place and the initial eDP DPCD readout waiting for the panel power cycle timeout without the PPS registers being initialized. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Imre Deak authored
Atm on IBX/CPT we attempt to detect if eDP is present even if LVDS was already detected and an encoder for it was registered. This involves trying to read out the eDP DPCD, which in turn needs the same power sequencer that LVDS uses. Poking at the VDD line at an unexpected time may or may not interfere with the LVDS panel, but it's probably safer to prevent this. Registering both an LVDS and an eDP connector would also present a similar problem accessing the shared PPS at any point later in an unexpected way. We also need this to be able fix PPS initialization before its first use in the next patch. For that we want to be sure that PPS is not in use by LVDS. v2: - Split out the PPS init fix to a separate patch. (Chris) - Add comment about eDP init depending on LVDS init. (Chris) - Make the use of the intel_encoder ptr less error prone. v3: - Use IBX/CPT reference instead of the incorrect ILK, add a WARN about this. (Ville) v4: - Use a helper to get the lvds encoder instead of opencoding the same. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 21 Jun, 2016 12 commits
-
-
Tvrtko Ursulin authored
No need for local struct drm_device * since dev_priv is the correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating anyway. Changed the macro definition for the latter to reflect that as well. v2: Alignment bikeshed. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466518034-24838-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
Maarten Lankhorst authored
Instead of looking at encoder->type, which may be set to UNKNOWN, use connector->connector_type. Info cannot be printed for MST connectors which may have a NULL encoder, return early in that case. Changes since v1: - Whitelist encoder types for HDMI and LVDS. - Fix oops on MST. - Do not list encoder types for eDP/DP, they're always valid. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
DPMS is unreliable, use crtc->state. Signed-off-by:
-
-
Maarten Lankhorst authored
This removes relying on intel_encoder->type, which may be set to unknown. Signed-off-by:
-
Chris Wilson authored
If we update the value of i915.enable_gvt should we fail to load GVT, userspace can easily detect when it fails to load as requested. Testcase: igt/gvt_basic Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466507234-23242-1-git-send-email-chris@chris-wilson.co.uk
-
Zhi Wang authored
The access right of kernel param "i915.enable_gvt" should be read-only as it only applies during module load (and is not *runtime* writable). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Michał Winiarski authored
If the GPU load is low enough, it's possible that we'll be stuck at idle frequency rather than transition into softmin frequency requested by userspace. v2: Use intel_set_rps, drop vlv_set_idle v3: Back to vlv_set_idle, clamp to valid range v4: Place intel_set_rps at the end References: https://bugs.freedesktop.org/show_bug.cgi?id=89728 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Dave Gordon authored
The ONLY places that guc_id (aka hw_id) should be used are those where the value or address is determined by and shared with the GuC firmware; specifically, when filling in the GuC-context-descriptor or the GuC addon data, or putting an entry in the GuC's work queue. It need not (and therefore should not) be used to index GuC statistics or similar host-managed tracking data. In particular, i915_guc_submit() produces (and debugfs decodes) GuC submission statistics which should be indexed by driver-engine-id rather then guc-engine-id. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Chris Wilson authored
During lastclose, we call intel_fbdev_restore_mode() to switch back to the fbcon configuration on return to VT. However, if we have not yet finished the asynchronous fbdev initialisation, the current mode will be invalid and trigger WARNs upon application. Serialise with the outstanding initialisation if the first application exits quickly. Note that to hit this in practice requires using an unregistered async_domain as otherwise modprobe will force a full synchronisation prior to init() completing. v2: Reuse comment explaining the +1 by refactoring the wait on fbdev sync in the previous patch. Reported-by:
Gustav Fägerlind <gustav.fagerlind@gmail.com> Reported-by:
"Li, Weinan Z" <weinan.z.li@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580Signed-off-by:
-
Chris Wilson authored
During cleanup we have to synchronise with the async task we are using to initialise and register our fbdev. Currently, we are using a full synchronisation on the global domain, but we can restrict this to just synchronising up to our task if we remember our cookie. Whilst there, streamline the function parameters. v2: async_synchronize_cookie() takes an exclusive upper bound, to synchronize with our task we have to pass in the next cookie. v3: Drop premature disregarding of the active cookie (we need to wait until the task is complete before continuing in the teardown). v4: Refactor waiting on async to incorporate a comment explaining why we need the +1. Signed-off-by:
-
Chris Wilson authored
Setting up fbdev requires everything ready and registered (in particular the connectors). In the forthcoming patches, we defer registration of the KMS objects and unless we defer setting off fbdev, it may run before they are registered and oops. Signed-off-by:
-
- 20 Jun, 2016 7 commits
-
-
Chris Wilson authored
... instead of the previous ORIGIN_GTT. This should actually invalidate FBC once something is written on the frontbuffer using WC mmaps. The problem with ORIGIN_GTT is that the automatic hardware tracking is not able to detect the WC writes as it can detect the GTT writes. This should help fix the SKL bug where nothing happens when you type your username/password on lightdm. This patch was originally pasted on an email by Chris and converted to an actual git patch by Paulo. v2 (from Paulo): - Make it a full variable instead of a bit-field (Daniel) - Use WRITE_ONCE (Chris) v3 (from Paulo): - Remove huge comment since now we have WRITE_ONCE (Chris) - Remove uneeded new line (Chris) - Add Chris' Signed-off-by, authorized via IRC Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466185599-26401-1-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
The DDX driver changes its behavior depending on the value it reads from i915.enable_fbc, so sanitize the value in order to allow it to know what's going on. It uses this in order to choose the defaults for the TearFree option. Before this patch, it would read -1 and always assume that FBC was disabled, so it wouldn't force TearFree. v2: Extract intel_sanitize_fbc_option() (Chris). v3: Rebase. Signed-off-by:
-
Paulo Zanoni authored
We ignore ORIGIN_GTT because the hardware tracking can recognize GTT writes and take care of them. We also ignore ORIGIN_FLIP because we deal with flips without relying on the frontbuffer tracking infrastructure. On the other hand, a flush is a flush and means we're good to go, so we need to update busy_bits in order to reflect that, even if we're not going to do anything else about it. How to reproduce the bug fixed by this patch: - boot SKL up to the desktop environment - stop the display manager - run any of the igt/kms_frontbuffer_tracking/*fbc*onoff* subtests - the tests will fail The steps above will create the right conditions for us to lose track of busy_bits. If you, for example, run the full set of FBC tests, the onoff subtests will succeed. Also notice that the "bug" is that we'll just keep FBC disabled on cases where it could be enabled, so it's not something the users can perceive, it just affects power consumption numbers on properly configured machines. Testcase: igt/kms_frontbuffer_tracking/*fbc*onoff* (see above) Reviewed-by:
-
Lyude authored
>From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : This was kind of a difficult bug to track down. If you're using a Haswell system running GNOME and you have fbc completely enabled and working, playing videos can result in video artifacts. Steps to reproduce: - Run GNOME - Ensure FBC is enabled and active - Download a movie, I used the ogg version of Big Buck Bunny for this - Run `gst-launch-1.0 filesrc location='some_movie.ogg' ! decodebin ! glimagesink` in a terminal - Watch for about over a minute, you'll see small horizontal lines go down the screen. For the time being, disable FBC for Haswell by default. Stefan Richter reported kernel freezes (no video artifacts) when fbc is on. (E3-1245 v3 with HD P4600; openbox and some KDE and LXDE applications, thread begins at https://lkml.org/lkml/2016/4/26/813). We also got reports from Steven Honeyman on openbox+roxterm. v2 (From Paulo): - Add extra information to the commit message - Add Fixes tag - Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96461 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96464 Fixes: a98ee793 ("drm/i915/fbc: enable FBC by default on HSW and BDW") Cc: stable@vger.kernel.org Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Chris Wilson authored
The idea behind relaxing the restriction for pread/pwrite was to handle !obj->base.flip, i.e. non-shmemfs backed objects, which only requires that the object provide struct pages. v2: Remove excess (). Note enough editing after copy'n'paste. v3: Use new i915_gem_object_has_struct_page() Testcase: igt/prime_vgem/read Signed-off-by:
-
Chris Wilson authored
Currently to see if an object is backed by struct pages (as opposed to being a simple pointer to stolen memory, for example) we do a manual check on the obj->ops->flags. This is quite shouty and before adding more checks in future, we should make it a bit calmer. Signed-off-by:
-
Mika Kahola authored
It has been found out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. This is a manual revert of commits 5fa836a9 ("drm/i915: DP link training optimization") and 4e96c977 ("drm/i915: eDP link training optimization"). Fixes: 5fa836a9 ("drm/i915: DP link training optimization") Fixes: 4e96c977 ("drm/i915: eDP link training optimization") Cc: <stable@vger.kernel.org> # v4.2+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
- 19 Jun, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 17 Jun, 2016 10 commits
-
-
Zhi Wang authored
GVT workload scheduler needs special host LRC contexts, the so called "shadow LRC context" to submit guest workload to host i915. During the guest workload submission, workload scheduler fills the shadow LRC context with the content of guest LRC context: engine context is copied without changes, ring context is mostly owned by host i915. v8: - Remove the graph temporarily. (Chris) - Use interruptible mutex_lock. (Chris) - Rename the function name of creating a GVT context. (Chris) - Add the missing declaration in i915_drv.h (Chris) v7: - Move chart to a better place. (Joonas) v6: - Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris) v5: - Only compile this feature when CONFIG_DRM_I915_GVT is enabled. (Tvrtko) - Rebase the code into new repo. - Add a comment about the ring buffer size. (Joonas) v2: Mostly based on Daniel's idea. Call the refactored core logic of GEM context creation service and LRC context creation service to create the GVT context. Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Zhi Wang authored
This patch introduces the support of LRC context single submission. As GVT context may come from different guests, which require different configuration of render registers. It can't be combined into a dual ELSP submission combo. Only GVT-g will create this kinds of GEM context currently. v8: - Rename the data member in struct i915_gem_context. (Chris) v7: - Fix typos in commit message. (Joonas) v6: - Make GVT code as dead code when !CONFIG_DRM_I915_GVT. (Chris) v5: - Only compile this feature when CONFIG_DRM_I915_GVT=y. (Tvrtko) Reviewed-by:
-
Zhi Wang authored
This patch introduces an approach to track the execlist context status change. GVT-g uses GVT context as the "shadow context". The content inside GVT context will be copied back to guest after the context is idle. And GVT-g has to know the status of the execlist context. This function is configurable when creating a new GEM context. Currently, Only GVT-g will create the "status-change-notification" enabled GEM context. v10: - Fix the identation. (Joonas) v8: - Remove the boolean flag in struct i915_gem_context. (Joonas) v7: - Remove per-engine ctx status notifiers. Use one status notifier for all engines. (Joonas) - Add prefix "INTEL_" for related definitions. (Joonas) - Refine the comments in execlists_context_status_change(). (Joonas) v6: - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler could automatically eliminate them for us. (Chris) - Always initialize the notifier header, so it could be switched on/off at runtime. (Chris) v5: - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v8) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Zhi Wang authored
Currently the addressing mode bit in context descriptor is statically generated from the configuration of system-wide PPGTT usage model. GVT-g will load the PPGTT shadow page table by itself and probably one guest is using a different addressing mode with i915 host. The addressing mode bits of a LRC context should be configurable under this case. v10: - Fix the identation. (Joonas) v9: - Rename the data member in struct i915_gem_context. (Chris) v8: - Rename the data member in struct i915_gem_context. (Chris) v7: - Move context addressing mode bit into i915_reg.h. (Joonas/Chris) - Add prefix "INTEL_" for related definitions. (Joonas) v6: - Directly save the addressing mode bits inside i915_gem_context. (Chris) - Move the LRC context addressing mode bits into intel_lrc.h. (Chris) v5: - Change USES_FULL_48BIT(dev) to USES_FULL_48BIT(dev_priv) (Tvrtko) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v9) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Zhi Wang authored
This patch introduces an option for configuring the ring buffer size of a LRC context after the context creation. v9: - Fix an identation issue. (Chris) v8: - Rename the data member in i915_gem_context. (Chris) Reviewed-by:
-
Zhi Wang authored
This patch introduces the very basic framework of GVT-g device model, includes basic prototypes, definitions, initialization. v12: - Call intel_gvt_init() in driver early initialization stage. (Chris) v8: - Remove the GVT idr and mutex in intel_gvt_host. (Joonas) v7: - Refine the URL link in Kconfig. (Joonas) - Refine the introduction of GVT-g host support in Kconfig. (Joonas) - Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas) - Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas) - Remove {alloc, free}_gvt_device() - Rename intel_gvt_{create, destroy}_gvt_device() - Expost intel_gvt_init_host() - Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas) v6: - Refine introduction in Kconfig. (Chris) - The exposed API functions will take struct intel_gvt * instead of void *. (Chris/Tvrtko) - Remove most memebers of strct intel_gvt_device_info. Will add them in the device model patches.(Chris) - Remove gvt_info() and gvt_err() in debug.h. (Chris) - Move GVT kernel parameter into i915_params. (Chris) - Remove include/drm/i915_gvt.h, as GVT-g will be built within i915. - Remove the redundant struct i915_gvt *, as the functions in i915 will directly take struct intel_gvt *. - Add more comments for reviewer. v5: Take Tvrtko's comments: - Fix the misspelled words in Kconfig - Let functions take drm_i915_private * instead of struct drm_device * - Remove redundant prints/local varible initialization v3: Take Joonas' comments: - Change file name i915_gvt.* to intel_gvt.* - Move GVT kernel parameter into intel_gvt.c - Remove redundant debug macros - Change error handling style - Add introductions for some stub functions - Introduce drm/i915_gvt.h. Take Kevin's comments: - Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c v2: - Introduce i915_gvt.c. It's necessary to introduce the stubs between i915 driver and GVT-g host, as GVT-g components is configurable in kernel config. When disabled, the stubs here do nothing. Take Joonas' comments: - Replace boolean return value with int. - Replace customized info/warn/debug macros with DRM macros. - Document all non-static functions like i915. - Remove empty and unused functions. - Replace magic number with marcos. - Set GVT-g in kernel config to "n" by default. Reviewed-by: -
Zhi Wang authored
v5: - Let functions take struct drm_i915_private *. (Tvrtko) - Fold vGPU related active check into the inner functions. (Kevin) Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Kevin Tian <kevin.tian@intel.com> Signed-off-by:
-
Zhi Wang authored
To get the offset of the members in PVINFO page, offsetof() looks much better than the tricky approach in current code. v7: - Move "offsetof()" modification into a dedicated patch. (Joonas) Suggested-by:
-
Zhi Wang authored
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g host (GVT-g kernel device model), factor it out for better code structure. v7: - Split the "offsetof" modification into a dedicated patch. (Joonas) v3: - Use offsetof to calculate the member offset of PVINFO structure (Joonas) Reviewed-by:
-
Chris Wilson authored
obj->base.dma_buf represents a dma-buf exported from this object (for use by others). On the contrary, obj->base.import_attach represents the source dma-buf that was used to create this object (if any). When serialising with third parties, we need to wait on their rendering via the import attachment as well as their rendering on our exported dma-buf. v2: Wait on both import and export. v3: Rebase Signed-off-by:
Alex Goins <agoins@nvidia.com> Reviewed-by:
-
- 16 Jun, 2016 2 commits
-
-
Daniel Vetter authored
Note that I didn't start garbage collecting all the legacy flip code yet, to make it easier to revert this. But there will be _lots_ of code that can be removed once this is tested on all platforms. v2: Use __maybe_unused (Maarten). Reviewed-by:
-
Daniel Vetter authored
Currently it's part of prepare_fb, still in the first phase of atomic_commit which might fail. Which means that we need to have some heuristics in cleanup_fb to figure out whether things failed, or whether we just clean up the old fbs. That's fragile, and worse, once we start pipelining commits gets confused: While the last commit is still getting cleanup up we already hammer in the new one, and fb_bits aren't refcounted, resulting in lost bits and WARN_ON galore. We could instead try to make cleanup_fb more clever, but a simpler fix is to postpone the fb_bits tracking past the point of no return, where we commit all the software state. That also makes conceptually more sense, since fb_bits must be updated synchronously from the ioctl (they track usage from userspace pov, not from the hw pov), right before we're fully committed to the updated. This fixes WARNING splats from track_fb with page_flip implemented through atomic_commit. Testcase: igt/kms_flip/flip-vs-rmfb Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1465827229-1704-4-git-send-email-daniel.vetter@ffwll.ch
-
