kernel.git/drivers/gpu/drm/i915/intel_fbdev.c, branch linux-4.7.y

drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

2016-05-17T13:42:35Z

During boot time, MST devices usually send a ton of hotplug events irregardless of whether or not any physical hotplugs actually occurred. Hotplugs mean connectors being created/destroyed, and the number of DRM connectors changing under us. This isn't a problem if we use fb_helper->connector_count since we only set it once in the code, however if we use num_connector from struct drm_mode_config we risk it's value changing under us. On top of that, there's even a chance that dev->mode_config.num_connector != fb_helper->connector_count. If the number of connectors happens to increase under us, we'll end up using the wrong array size for memcpy and start writing beyond the actual length of the array, occasionally resulting in kernel panics. Note: This is just polish for 4.7, Dave Airlie's drm_connector refcounting fixed these bugs for real. But it's good enough duct-tape for stable kernel backporting, since backporting the refcounting changes is way too invasive. Cc: stable@vger.kernel.org Signed-off-by: Lyude [danvet: Clarify why we need this.] Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1463065021-18280-2-git-send-email-cpaul@redhat.com

Revert "drm/i915: Fix races on fbdev"

2016-04-01T12:03:55Z

This reverts commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222. With the patch applied SNB, IVB and ILK are experiencing hard machine hangs. Original patch was to fix "just" kernel panics so it's not a good trade-off. Proper fix for the panic is on the way, lets revert until then. Fixes: a7442b93cf32 ("drm/i915: Fix races on fbdev") Cc: Lukas Wunner Cc: Daniel Vetter Cc: Chris Wilson Cc: Tomi Sarvela Cc: stable@vger.kernel.org Acked-by: Lukas Wunner Tested-by: Tomi Sarvela Suggested-by: Chris Wilson Signed-off-by: Joonas Lahtinen Link: http://patchwork.freedesktop.org/patch/msgid/1459510861-29035-1-git-send-email-joonas.lahtinen@linux.intel.com

drm/i915: Refer to GGTT {,VM} consistently

2016-03-31T14:55:43Z

Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt", "vm" or indirectly through other variables like "dev_priv->ggtt.base" to avoid confusion with the i915_ggtt object itself and PPGTT VMs. Refer to the GGTT as "ggtt" instead of indirectly through chaining. As a bonus gets rid of the long-standing i915_obj_to_ggtt vs. i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt! v2: - Added some more after grepping sources with Chris v3: - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm (Chris) v4: - Convert all dev_priv->ggtt->foo accesses to ggtt->foo. v5: - Make patch checker happy Cc: Tvrtko Ursulin Cc: Mika Kuoppala Cc: Chris Wilson Signed-off-by: Joonas Lahtinen Reviewed-by: Chris Wilson

drm/i915: Fix races on fbdev

2016-03-30T06:23:41Z

The ->lastclose callback invokes intel_fbdev_restore_mode() and has been witnessed to run before intel_fbdev_initial_config_async() has finished. We might likewise receive hotplug events before we've had a chance to fully set up the fbdev. Fix by waiting for the asynchronous thread to finish. v2: An async_synchronize_full() was also added to intel_fbdev_set_suspend() in v1 which turned out to be entirely gratuitous. It caused a deadlock on suspend (discovered by CI, thanks to Damien Lespiau and Tomi Sarvela for CI support) and was unnecessary since a device is never suspended until its ->probe callback (and all asynchronous tasks it scheduled) have finished. See dpm_prepare(), which calls wait_for_device_probe(), which calls async_synchronize_full(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580 Reported-by: Gustav Fägerlind Reported-by: "Li, Weinan Z" Cc: Chris Wilson Cc: stable@vger.kernel.org Signed-off-by: Lukas Wunner Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20160309115147.67B2B6E0D3@gabe.freedesktop.org

drm/i915: Implement color management on bdw/skl/bxt/kbl

2016-03-21T18:40:31Z

Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor degamma/gamma LUTs load into a single function v6: Fix missing intel_crtc variable (bisect issue) v7: Fix & simplify limited range matrix multiplication (Matt Roper's comment) Signed-off-by: Shashank Sharma Signed-off-by: Kumar, Kiran S Signed-off-by: Kausal Malladi Signed-off-by: Lionel Landwerlin Acknowledged-by: Matt Roper Signed-off-by: Matt Roper Link: http://patchwork.freedesktop.org/patch/msgid/1458125837-2576-4-git-send-email-lionel.g.landwerlin@intel.com

drm/i915: Rename dev_priv->gtt to dev_priv->ggtt

2016-03-18T13:18:15Z

Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt. Fix a couple of whitespace problems while at it. v2: - Fix a typo in commit message. Reviewed-by: Chris Wilson Signed-off-by: Joonas Lahtinen

drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

2016-03-01T10:48:09Z

intel_pin_and_fence_fb_obj() only needs the framebuffer, and the desird rotation (to find the right GTT view for it), so no need to pass all kinds of plane stuff. The main motivation is to get rid of the uggy NULL plane_state handling due to fbdev. v2: Add a note why I really want this Signed-off-by: Ville Syrjälä Grumpily-Reviewed-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1455569699-27905-6-git-send-email-ville.syrjala@linux.intel.com

drm/i915: Use atomic state in intel_fb_initial_config.

2016-02-18T09:41:54Z

This is another step in removing legacy state. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-6-git-send-email-maarten.lankhorst@linux.intel.com

drm/i915: Remove obsolete code from intelfb_alloc()

2015-12-21T16:03:25Z

Clean up after 0c82312f3f15 ("drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping"): At each of the remaining "goto out" in intelfb_alloc(), fb can only be either an ERR_PTR or NULL, so the call to drm_framebuffer_unreference() is now obsolete. Cc: Daniel Vetter Cc: Chris Wilson Signed-off-by: Lukas Wunner Link: http://patchwork.freedesktop.org/patch/msgid/56756c41.c306c20a.d0602.1830SMTPIN_ADDED_MISSING@mx.google.com Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

2015-12-17T15:59:24Z

A long time ago (before 3.14) we relied on a permanent pinning of the ifbdev to lock the fb in place inside the GGTT. However, the introduction of stealing the BIOS framebuffer and reusing its address in the GGTT for the fbdev has muddied waters and we use an inherited fb. However, the inherited fb is only pinned whilst it is active and we no longer have an explicit pin for the info->system_base mmapping used by the fbdev. The result is that after some aperture pressure the fbdev may be evicted, but we continue to write the fbcon into the same GGTT address - overwriting anything else that may be put into that offset. The effect is most pronounced across suspend/resume as intel_fbdev_set_suspend() does a full clear over the whole scanout. v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from the BIOS, we do not own the pinned vma (except for the reference we add in this patch for our access via info->screen_base). v3: Finish balancing the vma pinning for the normal !preallocated case. v4: Try to simplify the pinning even further. v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths. Signed-off-by: Chris Wilson Cc: "Goel, Akash" Cc: Daniel Vetter Cc: Jesse Barnes Cc: Lukas Wunner Cc: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1449245126-26158-1-git-send-email-chris@chris-wilson.co.uk Tested-by: Ville Syrjälä Signed-off-by: Daniel Vetter