aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_display.c
Commit message (Collapse)AuthorAge
...
* | drm/i915: Ensure plane->state->fb stays in sync with plane->fbMatt Roper2015-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. In commit commit db068420560511de80ac59222644f2bdf278c3d5 Author: Matt Roper <matthew.d.roper@intel.com> Date: Fri Jan 30 16:22:36 2015 -0800 drm/i915: Keep plane->state updated on pageflip we already fixed one case where these two pointers could get out of sync. However it turns out there are a few other places (mainly dealing with initial FB setup at boot) that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb (and update reference counts accordingly) and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Track old framebuffer instead of objectTvrtko Ursulin2015-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Daniel Vetter spotted a bug while reviewing some of my refactoring in this are of the code. I'll quote: """ > @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, > work->event = event; > work->crtc = crtc; > work->old_fb_obj = intel_fb_obj(old_fb); > + work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode; Hm, that's actually an interesting bugfix - currently userspace could be sneaky and destroy the old fb immediately after the flip completes and the change the tiling of the underlying object before the unpin work had a chance to run (needs some fudgin with rt prios to starve workers to make this work though). Imo the right fix is to hold a reference onto the fb and not the underlying gem object. With that tiling is guaranteed not to change. """ This patch tries to implement the above proposed change. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Switch planes from transitional helpers to full atomic helpersMatt Roper2015-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two sets of helper functions provided by the DRM core that can implement the .update_plane() and .disable_plane() hooks in terms of a driver's atomic entrypoints. The transitional helpers (which we have been using so far) create a plane state and then use the plane's atomic entrypoints to perform the atomic begin/check/prepare/commit/finish sequence on that single plane only. The full atomic helpers create a top-level atomic state (which is capable of holding multiple object states for planes, crtc's, and/or connectors) and then passes the top-level atomic state through the full "atomic modeset" pipeline. Switching from the transitional to full helpers here shouldn't result in any functional change, but will enable us to exercise/test more of the internal atomic pipeline with the legacy API's used by existing applications. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Keep plane->state updated on pageflipMatt Roper2015-02-13
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Until all drivers have transitioned to atomic, the framebuffer associated with a plane is tracked in both plane->fb (for legacy) and plane->state->fb (for all the new atomic codeflow). All of our modeset and plane updates use drm_plane->update_plane(), so in theory plane->fb and plane->state->fb should always stay in sync and point at the same thing for i915. However we forgot about the pageflip ioctl case, which currently only updates plane->fb and leaves plane->state->fb at a stale value. Surprisingly, this doesn't cause any real problems at the moment since internally we use the plane->fb pointer in most of the places that matter, and on the next .update_plane() call, we use plane->fb to figure out which framebuffer to cleanup. However when we switch to the full atomic helpers for update_plane()/disable_plane(), those helpers use plane->state->fb to figure out which framebuffer to cleanup, so not having updated the plane->state->fb pointer causes things to blow up following a pageflip ioctl. The fix here is to just make sure we update plane->state->fb at the same time we update plane->fb in the pageflip ioctl. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Split shared dpll setup out of __intel_set_mode()Ander Conselvan de Oliveira2015-01-30
| | | | | | | This simplifies __intel_set_mode() a little. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Switch plane properties to full atomic helper.Matt Roper2015-01-27
| | | | | | | | This will exercise our atomic pipeline for legacy property updates. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add crtc state duplication/destruction functionsMatt Roper2015-01-27
| | | | | | | | | The atomic helpers need these to prepare a new state object when starting a new atomic operation. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Setup dummy atomic state for connectors (v3)Matt Roper2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add main atomic entrypoints (v2)Matt Roper2015-01-27
| | | | | | | | | | | | | | | | | Add the top-level atomic entrypoints for check/commit. These won't get called yet; we still need to either enable the atomic ioctl or switch to using the non-transitional atomic helpers for legacy operations. v2: - Use plane->pipe rather than plane->possible_crtcs while ensuring that only a single CRTC is in use. Either way will work fine since i915 drm_plane's are always tied to a single CRTC, but plane->pipe is slightly more intuitive. (Ander) - Simplify crtc/connector checking logic. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add .atomic_{get, set}_property() entrypoints to planesMatt Roper2015-01-27
| | | | | | | | | | | | | | | When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling this entrypoint to set and lookup driver-specific plane property values, rather than maintaining a shadow copy in object->properties. Note that although we add these functions to the plane vtable, they will not yet be called. Future patches that switch our .set_property() handler and/or enable full atomic functionality are required before these code paths will be executed. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Consolidate plane handler vtablesMatt Roper2015-01-27
| | | | | | | | | | | All of the previous refactoring/consolidation of plane code has resulted in intel_primary_plane_funcs, intel_cursor_plane_funcs, and intel_sprite_plane_funcs being identical. Replace all of these with a single 'intel_plane_funcs' vtable for simplicity. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Move rotation from intel_plane to drm_plane_stateMatt Roper2015-01-27
| | | | | | | | | | | | | | | | | | | | Runtime state that can be manipulated via properties should now go in intel_plane_state/drm_plane_state so that it can be tracked as part of an atomic transaction. We add a new 'intel_create_plane_state' function so that the proper initial value for this property (and future properties) doesn't have to be repeated at each plane initialization site. v2: - Stick rotation in common drm_plane_state rather than intel_plane_state. (Daniel) - Add intel_create_plane_state() to consolidate the places where we have to set initial state values. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use sizeof(*fb) not sizeof(struct ...) in get_initial_plane_config()Damien Lespiau2015-01-27
| | | | | | Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix kzalloc() smatch warnings in get_initial_plane_config()Damien Lespiau2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | Smatch doesn't like: struct drm_framebuffer *fb; fb = kzalloc(sizeof(struct intel_framebuffer), GFP_KERNEL); and warns with: warn: struct type mismatch 'drm_framebuffer vs intel_framebuffer' This implicit cast was correct as struct intel_framebuffer has struct drm_framebuffer as its first member, but in case someone want to reorder the fields for some reason, it's slightly safer to access the underlying drm_framebuffer through intel_fb->base. Also, having fewer static analysis warnings is a worthy goal. Cc: kbuild@01.org Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename plane_config to initial_plane_configDamien Lespiau2015-01-27
| | | | | | | | | | | | This vfunc and related structure are only used for fast boot, so let's rename them to not take them as general purpose ones. v2: Fix conflicts caused by the introduction of struct intel_crtc_state Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Provide a Skylake version of get_plane_config()Damien Lespiau2015-01-27
| | | | | | | | | | | | | | | Universal planes have changed a bit the register organization. v2: Rebase on top of the latest drm-intel-nightly v3: Use PLANE_SIZE to retrieve the fb size (Tvrtko) Don't use BUG() (Tvrtko) v4: Use MISSING_CASE (Daniel) Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: intel_format_to_fourcc() doesn't work for SKL planesDamien Lespiau2015-01-27
| | | | | | | | We will have a skl_ version shortly! Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make intel_format_to_fourcc() staticDamien Lespiau2015-01-27
| | | | | | | | v2: Fix conflict caused by the introduction of struct intel_crtc_state Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use pipe_name() in the get_plane_config() functionsDamien Lespiau2015-01-27
| | | | | | | | | We may as well try to be consistent everywhere and know the pipes by their name. Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't use crtc->plane in ILK+ get_config()Damien Lespiau2015-01-27
| | | | | | | | | crtc->plane can only be different from crtc->pipe pre-Gen4. Don't use it in new-ish code. Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Unclutter the get_plane() functionsDamien Lespiau2015-01-27
| | | | | | | | | | | crtc->base.primary->fb was used everywhere. Use fb to temporarily point there and don't forget to assign fb to its final destination at the end. v2: Rebase on top of misc changes (mask of DSPSURF, PAGE_ALIGN) Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use a common function for computing the fb height alignmentDamien Lespiau2015-01-27
| | | | | | | | | | | If we need to change the fb height constraints, it sounds like a good idea to have to do it in one place only. v2: v2: Rebase on top of Ander's "Make intel_crtc->config a pointer" Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Change plane_config to store a tiling_modeDamien Lespiau2015-01-27
| | | | | | | | | | | | | | | Rather than having "tiled" meaning "is it X-tiled?" convert the field to explicitely store the tiling mode. The code doesn't have to change much as 1 is conveniently I915_TILING_X. This is to accommodate future changes around tiling modes and scannout buffers. v2: Rebase on top of Ander's "Make intel_crtc->config a pointer" Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename the forcewake get/put functionsMika Kuoppala2015-01-27
| | | | | | | | | | | | | | We have multiple forcewake domains now on recent gens. Change the function naming to reflect this. v2: More verbose names (Chris) v3: Rebase v4: Rebase v5: Add documentation for forcewake_get/put Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Assert that runtime pm is active on user fw accessChris Wilson2015-01-27
| | | | | | | | | | | | | | | On user forcewake access, assert that runtime pm reference is held. Fix and cleanup the callsites accordingly. v2: Remove intel_runtime_pm_get() rebasehap (Deepak) v3: use drivers own runtime state tracking as pm_runtime_active() will return wrong results when we are in resume callchain (Mika) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Keep drm_crtc->state in sync with intel_crtc->configAnder Conselvan de Oliveira2015-01-27
| | | | | | | | So that atomic operations will reference the right crtc state. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Improve how the memory for crtc state is allocatedAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | | | | | | | | | | The previous patch changed the config field in intel_crtc to a pointer, but to keep the mechanical changes (done with spatch) separate from the new code, the pointer was made to point to a new _config field with type struct intel_crtc_state added to that struct. This patch improves that code by getting rid of that field, allocating a state struct in intel_crtc_init() a keeping it properly updated when a mode set happens. v2: Manual changes split from previous patch. (Matt) Don't leak the current state when the crtc is destroyed (Matt) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> [danvet: Squash in fixup from Matt Roper for driver unload.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use local pipe_config varariable when availableAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | | | In functions that define a local pipe_config variable to point to crtc->config, replace remaining references to crtc->config with the local variable. This makes the code more consistent and easier to change in an automated manner. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass new_config down do crtc_compute_clockAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | This reduces the number of direct users of crtc->new_config, opening up the possibilty of removing it altogether. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Embedded struct drm_crtc_state in intel_crtc_stateAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename struct intel_crtc_config to intel_crtc_stateAnder Conselvan de Oliveira2015-01-27
| | | | | | | | | | | | | | | | | | | | The objective is to make this structure usable with the atomic helpers, so let's start with the rename. Patch generated with coccinelle: @@ @@ -struct intel_crtc_config { +struct intel_crtc_state { ... } @@ @@ -struct intel_crtc_config +struct intel_crtc_state v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't cleanup plane state in intel_plane_destroy()Matt Roper2015-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we transitioned to the atomic plane helpers in commit: commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) one of the changes was to call intel_plane_destroy_state() while tearing down a plane to prevent leaks when unloading the driver. That made sense when the patches were first written, but before they were merged, commit 3009c0377f25c29852b218a6933a969d02cbdc5d Author: Thierry Reding <treding@nvidia.com> Date: Tue Nov 25 12:09:49 2014 +0100 drm: Free atomic state during cleanup had already landed, which made this the responsibility of the DRM core. The result was that we were kfree()'ing the state twice, and also possibly double-unref'ing a framebuffer, leading to memory corruption when the driver was unloaded. The fix is to simply not try to cleanup the state in the i915 teardown code now that the core handles this for us. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88433 Testcase: igt/drv_module_reload Root-cause-analysis-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2015-01-17' of ↵Dave Airlie2015-01-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - refactor i915/snd-hda interaction to use the component framework (Imre) - psr cleanups and small fixes (Rodrigo) - a few perf w/a from Ken Graunke - switch to atomic plane helpers (Matt Roper) - wc mmap support (Chris Wilson & Akash Goel) - smaller things all over * tag 'drm-intel-next-2015-01-17' of git://anongit.freedesktop.org/drm-intel: (40 commits) drm/i915: Update DRIVER_DATE to 20150117 i915: reuse %ph to dump small buffers drm/i915: Ensure the HiZ RAW Stall Optimization is on for Cherryview. drm/i915: Enable the HiZ RAW Stall Optimization on Broadwell. drm/i915: PSR link standby at debugfs drm/i915: group link_standby setup and let this info visible everywhere. drm/i915: Add missing vbt check. drm/i915: PSR HSW/BDW: Fix inverted logic at sink main_link_active bit. drm/i915: PSR VLV/CHV: Remove condition checks that only applies to Haswell. drm/i915: VLV/CHV PSR needs to exit PSR on every flush. drm/i915: Fix kerneldoc for i915 atomic plane code drm/i915: Don't pretend SDVO hotplug works on 915 drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV drm/i915: Remove I915_HAS_HOTPLUG() check from i915_hpd_irq_setup() drm/i915: Make hpd arrays big enough to avoid out of bounds access Revert "drm/i915/chv: Use timeout mode for RC6 on chv" drm/i915: Improve HiZ throughput on Cherryview. drm/i915: Reset CSB read pointer in ring init drm/i915: Drop unused position fields (v2) drm/i915: Move to atomic plane helpers (v9) ...
| * drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHVVille Syrjälä2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | If we determine that a specific port is eDP, don't register the HDMI connector/encoder for it. The reason being that we want to disable HPD interrupts for eDP ports when the display is off, but the presence of the extra HDMI connector would demand the HPD interrupt to remain enabled all the time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Drop unused position fields (v2)Matt Roper2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The userspace-requested plane coordinates are now always available via plane->state.base (and the i915-adjusted values are stored in plane->state), so we no longer use the coordinate fields in intel_plane and can drop them. Also, note that the error case for pageflip calls update_plane() to program the values from plane->state; it's simpler to just call intel_plane_restore() which does the same thing. v2: Replace manual update_plane() with intel_plane_restore() in pageflip error handler. Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move to atomic plane helpers (v9)Matt Roper2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch plane handling to use the atomic plane helpers. This means that rather than provide our own implementations of .update_plane() and .disable_plane(), we expose the lower-level check/prepare/commit/cleanup entrypoints and let the DRM core implement update/disable for us using those entrypoints. The other main change that falls out of this patch is that our drm_plane's will now always have a valid plane->state that contains the relevant plane state (initial state is allocated at plane creation). The base drm_plane_state pointed to holds the requested source/dest coordinates, and the subclassed intel_plane_state holds the adjusted values that our driver actually uses. v2: - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel) - Fix a copy/paste comment mistake (Bob) v3: - Use prepare/cleanup functions that we've already factored out - Use newly refactored pre_commit/commit/post_commit to avoid sleeping during vblank evasion v4: - Rebase to latest di-nightly requires adding an 'old_state' parameter to atomic_update; v5: - Must have botched a rebase somewhere and lost some work. Restore state 'dirty' flag to let begin/end code know which planes to run the pre_commit/post_commit hooks for. This would have actually shown up as broken in the next commit rather than this one. v6: - Squash kerneldoc patch into this one. - Previous patches have now already taken care of most of the infrastructure that used to be in this patch. All we're adding here now is some thin wrappers. v7: - Check return of intel_plane_duplicate_state() for allocation failures. v8: - Drop unused drm_plane_state -> intel_plane_state cast. (Ander) - Squash in actual transition to plane helpers. Significant refactoring earlier in the patchset has made the combined prep+transition much easier to swallow than it was in earlier iterations. (Ander) v9: - s/track_fbs/disabled_planes/ in the atomic crtc flags. The only fb's we need to update frontbuffer tracking for are those on a plane about to be disabled (since the atomic helpers never call prepare_fb() when disabling a plane), so the new name more accurately describes what we're actually tracking. Testcase: igt/kms_plane Testcase: igt/kms_universal_plane Testcase: igt/kms_cursor_crc Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Clarify sprite plane function names (v4)Matt Roper2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few of the sprite-related function names in i915 are very similar (e.g., intel_enable_planes() vs intel_crtc_enable_planes()) and don't make it clear whether they only operate on sprite planes, or whether they also apply to all universal plane types. Rename a few functions to be more consistent with our function naming for primary/cursor planes or to clarify that they apply specifically to sprite planes: - s/intel_disable_planes/intel_disable_sprite_planes/ - s/intel_enable_planes/intel_enable_sprite_planes/ Also, drop the sprite-specific intel_destroy_plane() and just use the type-agnostic intel_plane_destroy() function. The extra 'disable' call that intel_destroy_plane() did is unnecessary since the plane will already be disabled due to framebuffer destruction by the point it gets called. v2: Earlier consolidation patches have reduced the number of functions we need to rename here. v3: Also rename intel_plane_funcs vtable to intel_sprite_plane_funcs for consistency with primary/cursor. (Ander) v4: Convert comment for intel_plane_destroy() to kerneldoc now that it is no longer a static function. (Ander) Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Move vblank evasion to commit (v4)Matt Roper2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the vblank evasion up from the low-level, hw-specific update_plane() handlers to the general plane commit operation. Everything inside commit should now be non-sleeping, so this brings us closer to how vblank evasion will behave once we move over to atomic. v2: - Restore lost intel_crtc->active check on vblank evasion v3: - Replace assert_pipe_enabled() in intel_disable_primary_hw_plane() with an intel_crtc->active test; it turns out assert_pipe_enabled() grabs some mutexes and can sleep, which we can't do with interrupts disabled. v4: - Equivalent to v2; v3 change is now squashed into an earlier patch of the series. (Ander). Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Refactor work that can sleep out of commit (v7)Matt Roper2015-01-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once we integrate our work into the atomic pipeline, plane commit operations will need to happen with interrupts disabled, due to vblank evasion. Our commit functions today include sleepable work, so those operations need to be split out and run either before or after the atomic register programming. The solution here calculates which of those operations will need to be performed during the 'check' phase and sets flags in an intel_crtc sub-struct. New intel_begin_crtc_commit() and intel_finish_crtc_commit() functions are added before and after the actual register programming; these will eventually be called from the atomic plane helper's .atomic_begin() and .atomic_end() entrypoints. v2: Fix broken sprite code split v3: Make the pre/post commit work crtc-based to match how we eventually want this to be called from the atomic plane helpers. v4: Some platforms that haven't had their watermark code reworked were waiting for vblank, then calling update_sprite_watermarks in their platform-specific disable code. These also need to be flagged out of the critical section. v5: Sprite plane test for primary show/hide should just set the flag to wait for pending flips, not actually perform the wait. (Ander) v6: - Rebase onto latest di-nightly; picks up an important runtime PM fix. - Handle 'wait_for_flips' flag in intel_begin_crtc_commit(). (Ander) - Use wait_for_flips flag for primary plane update rather than performing the wait in the check routine. - Added kerneldoc to pre_disable/post_enable functions that are no longer static. (Ander) - Replace assert_pipe_enabled() in intel_disable_primary_hw_plane() with an intel_crtc->active test; it turns out assert_pipe_enabled() grabs some mutexes and can sleep, which we can't do with interrupts disabled. v7: - Check for fb != NULL when deciding whether the sprite plane hides the primary plane during a sprite update. (PRTS) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Merge tag 'topic/i915-hda-componentized-2015-01-12' into drm-intel-next-queuedDaniel Vetter2015-01-12
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/gpu/drm/i915/intel_runtime_pm.c Separate branch so that Takashi can also pull just this refactoring into sound-next. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * | drm/i915: Push vblank enable/disable past encoder->enable/disableDaniel Vetter2015-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is platform/output depenedent when exactly the pipe will start running. Sometimes we just need the (cpu) pipe enabled, in other cases the pch transcoder is enough and in yet other cases the (DP) port is sending the frame start signal. In a perfect world we'd put the drm_crtc_vblank_on call exactly where the pipe starts running, but due to cloning and similar things this will get messy. And the current approach of picking the most conservative place for all combinations also doesn't work since that results in legit vblank waits (in encoder->enable hooks, e.g. the 2 vblank waits for sdvo) failing. Completely going back to the old world before commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait isn't great either since screaming when the vblank wait work because the pipe is off is kinda nice. Pick a compromise and move the drm_crtc_vblank_on right before the encoder->enable call. This is a lie on some outputs/platforms, but after the ->enable callback the pipe is guaranteed to run everywhere. So not that bad really. Suggested by Ville. v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've missed the ibx pipe B select w/a, which also has a vblank wait in the disable function (while the pipe is obviously still running). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* | | Merge remote-tracking branch 'origin/master' into drm-nextDave Airlie2015-01-21
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linus tree after rc5 + drm-fixes went in. There were a few amdkfd conflicts I wanted to avoid, and Ben requested this for nouveau also. Conflicts: drivers/gpu/drm/amd/amdkfd/Makefile drivers/gpu/drm/amd/amdkfd/kfd_chardev.c drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c drivers/gpu/drm/amd/amdkfd/kfd_priv.h drivers/gpu/drm/amd/include/kgd_kfd_interface.h drivers/gpu/drm/i915/intel_runtime_pm.c drivers/gpu/drm/radeon/radeon_kfd.c
| * | | drm/i915: Ban Haswell from using RCS flipsChris Wilson2015-01-12
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like Ivybridge, we have reports that we get random hangs when flipping with multiple pipes. Extend commit 2a92d5bca1999b69c78f3c3e97b5484985b094b9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 8 10:40:29 2014 +0100 drm/i915: Disable RCS flips on Ivybridge to also apply to Haswell. Reported-and-tested-by: Scott Tsai <scottt.tw@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org # 2a92d5bca199 drm/i915: Disable RCS flips on Ivybridge Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | Merge tag 'drm-intel-next-fixes-2014-12-30' of ↵Dave Airlie2015-01-04
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into linus I've had these since before -rc1, but they missed my last pull request. Real bug fixes and mostly cc: stable material. * tag 'drm-intel-next-fixes-2014-12-30' of git://anongit.freedesktop.org/drm-intel: drm/i915: add missing rpm ref to i915_gem_pwrite_ioctl Revert "drm/i915: Preserve VGACNTR bits from the BIOS" drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4 drm/i915: Kill check_power_well() calls
| | * | Revert "drm/i915: Preserve VGACNTR bits from the BIOS"Ville Syrjälä2014-12-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VGA_2X_MODE bit apparently affects the display even when the VGA plane is disabled. The bit will set by the BIOS when the panel width is at least 1280 pixels. So by preserving the bit from the BIOS we end up with corrupted display on machines with such high res panels. I only have 1024x768 panels on my gen2 machines so never ran into this problem. The original reason for preserving the VGACNTR register was to make my 830 survive S3 with acpi_sleep=s3_bios option. However after further 830 fixes that option is no longer needed to make S3 work and preserving VGACNTR doesn't seem to be necessary without it, so we can just revert the entire patch. This reverts commit 69769f9a422bfc62e17399da3590c5e31ac37f24 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Aug 15 01:22:08 2014 +0300 drm/i915: Preserve VGACNTR bits from the BIOS Cc: Bruno Prémont <bonbons@linux-vserver.org> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87171 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | | | Merge tag 'drm-intel-next-2014-12-19' of ↵Dave Airlie2015-01-09
|\ \ \ \ | |/ / / |/| | / | | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - plane handling refactoring from Matt Roper and Gustavo Padovan in prep for atomic updates - fixes and more patches for the seqno to request transformation from John - docbook for fbc from Rodrigo - prep work for dual-link dsi from Gaurav Signh - crc fixes from Ville - special ggtt views infrastructure from Tvrtko Ursulin - shadow patch copying for the cmd parser from Brad Volkin - execlist and full ppgtt by default on gen8, for testing for now * tag 'drm-intel-next-2014-12-19' of git://anongit.freedesktop.org/drm-intel: (131 commits) drm/i915: Update DRIVER_DATE to 20141219 drm/i915: Hold runtime PM during plane commit drm/i915: Organize bind_vma funcs drm/i915: Organize INSTDONE report for future. drm/i915: Organize PDP regs report for future. drm/i915: Organize PPGTT init drm/i915: Organize Fence registers for future enablement. drm/i915: tame the chattermouth (v2) drm/i915: Warn about missing context state workarounds only once drm/i915: Use true PPGTT in Gen8+ when execlists are enabled drm/i915: Skip gunit save/restore for cherryview drm/i915/chv: Use timeout mode for RC6 on chv drm/i915: Add GPGPU_THREADS_DISPATCHED to the register whitelist drm/i915: Tidy up execbuffer command parsing code drm/i915: Mark shadow batch buffers as purgeable drm/i915: Use batch length instead of object size in command parser drm/i915: Use batch pools with the command parser drm/i915: Implement a framework for batch buffer pools drm/i915: fix use after free during eDP encoder destroying drm/i915/skl: Skylake also supports DP MST ...
| * | drm/i915: Hold runtime PM during plane commitMatt Roper2014-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During plane operations, we read/write some registers that only operate properly if we're not runtime suspended. At the moment we're not holding the runtime PM reference across the whole plane operation, so there's a potential for problems. This issue was already partially addressed by commit commit d6dd6843ff4a57c662dbc378b9f99a9c034b0956 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Aug 15 15:59:32 2014 -0300 drm/i915: fix plane/cursor handling when runtime suspended which took care of holding the runtime PM reference during the pin and fence operations for plane updates. However there are still a few actual plane registers that we also need to hold the runtime PM reference for. Recent refactoring patches in preparation for atomic have rearranged the code and made it increasingly likely that the hardware will have time to suspend between the pin/fence operation and the actual register writes. Examples of such registers are the stuff touched by ivb_get_colorkey. The solution here grabs the runtime PM reference around the 'commit' operation for planes, which should cover all the relevant register reads/writes. Note that this has only been exposed with commit 6beb8c23ebcc3d3287d8a247d11b73d7d0eaa475 Author: Matt Roper <matthew.d.roper@intel.com> Date: Mon Dec 1 15:40:14 2014 -0800 drm/i915: Consolidate plane 'prepare' functions (v2) so doesn't need to be ported to 3.19. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87180 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Testcase: igt/pm-rpm/legacy-planes Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Augment commit message with information Paulo supplied.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: tame the chattermouth (v2)Rob Clark2014-12-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many distro's have mechanism in place to collect and automatically file bugs for failed WARN()s. And since i915 has a lot of hw state sanity checks which result in WARN(), it generates quite a lot of noise which is somewhat disconcerting to the end user. Separate out the internal hw-is-in-the-state-I-expected checks into I915_STATE_WARN()s and allow configuration via i915.verbose_checks module param about whether this will generate a full blown stacktrace or just DRM_ERROR(). The new moduleparam defaults to true, so by default there is no change in behavior. And even when disabled, you will still get an error message logged. v2: paint the macro names blue, clarify that the default behavior remains the same as before Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Use BUILD_BUG if possible in the i915 WARN_ONDaniel Vetter2014-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Faster feedback to errors is always better. This is inspired by the addition to WARN_ONs to mask/enable helpers for registers to make sure callers have the arguments ordered correctly: Pretty much always the arguments are static. We use WARN_ON(1) a lot in default switch statements though where we should always handle all cases. So add a new macro specifically for that. The idea to use __builtin_constant_p is from Chris Wilson. v2: Use the ({}) gcc-ism to avoid the static inline, suggested by Dave. My first attempt used __cond as the temp var, which is the same used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so sprinkle i915 into the name. Also use a temporary variable to only evaluate the condition once, suggested by Damien. v3: It's crazy but apparently 32bit gcc can't compile out the BUILD_BUG_ON in a lot of cases and just falls over. I have no idea why, but until clue grows just disable this nifty idea on 32bit builds. Reported by 0-day builder. v4: Got it all wrong, apparently its the gcc version. We need 4.9+. Now reported by Imre. v5: Chris suggested to add the case to MISSING_CASE for speedier debug. v6: Even some gcc 4.9 versions don't see through the maze, so give up for now. Keep the skeleton and MISSING_CASE stuff though. Cc: Imre Deak <imre.deak@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-07-29 01:48:31 -0400