kernel/linux.git/drivers/gpu/drm/i915/intel_fbdev.c, branch v4.4.171

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

2016-06-08T01:14:36+00:00

commit 14a3842a1d5945067d1dd0788f314e14d5b18e5b upstream. 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. 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 Signed-off-by: Greg Kroah-Hartman

drm/i915: don't allocate fbcon from stolen memory if it's too big

2015-10-09T07:31:58+00:00

Technology has evolved and now we have eDP panels with 3200x1800 resolution. In the meantime, the BIOS guys didn't change the default 32mb for stolen memory. On top of that, we can't assume our users will be able to increase the default stolen memory size to more than 32mb - I'm not even sure all BIOSes allow that. So just the fbcon buffer alone eats 22mb of my stolen memroy, and due to the BDW/SKL restriction of not using the last 8mb of stolen memory, all that's left for FBC is 2mb! Since fbcon is not the coolest feature ever, I think it's better to save our precious stolen resource to FBC and the other guys. On the other hand, we really want to use as much stolen memory as possible, since on some older systems the stolen memory may be a considerable percentage of the total available memory. This patch tries to achieve a little balance using a simple heuristic: if the fbcon wants more than half of the available stolen memory, don't use stolen memory in order to leave some for FBC and the other features. The long term plan should be to implement a way to set priorities for stolen memory allocation and then evict low priority users when the high priority ones need the memory. While we still don't have that, let's try to make FBC usable with the simple solution. Cc: Chris Wilson Signed-off-by: Paulo Zanoni Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next

2015-09-30T06:47:41+00:00

Backmerge to catch up with 4.3. slightly more involved conflict in the irq code, but nothing beyond adjacent changes. Signed-off-by: Daniel Vetter

drm/i915: enable atomic fb-helper

2015-09-16T18:40:03+00:00

i915 supports enough atomic to have atomic fb-helper paths, even though it does not yet advertise DRIVER_ATOMIC. Signed-off-by: Rob Clark Signed-off-by: Daniel Vetter

drm/i915: Always try to inherit the initial fb.

2015-09-14T07:58:24+00:00

The initial state is read out correctly and the state is atomic, so it's safe to preserve the fb without any hacks if it's suitable. Signed-off-by: Maarten Lankhorst Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter

drm/i915: Remove references to crtc->active from intel_fbdev.c

2015-09-14T07:51:24+00:00

It should really use the atomic state. Signed-off-by: Maarten Lankhorst Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter

Merge tag 'drm-intel-next-fixes-2015-09-02' into drm-intel-next-queued

2015-09-02T12:33:42+00:00

Backmerge -fixes since there's more DDI-E related cleanups on top of the pile of -fixes for skl that just landed for 4.3. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i914/intel_dp.c drivers/gpu/drm/i915/intel_lrc.c Conflicts are all fairly harmless adjacent line stuff. Signed-off-by: Daniel Vetter

drm/i915/gtt: Allow >= 4GB offsets in X86_32

2015-08-14T16:16:30+00:00

Similar to commit c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9 ("drm/i915/gtt: Allow >= 4GB sizes for vm"), i915_gem_obj_offset and i915_gem_obj_ggtt_offset return an unsigned long, which in only 4-bytes long in 32-bit kernels. Change return type (and other related offset variables) to u64. Since Global GTT is always limited to 4GB, this change would not be required in i915_gem_obj_ggtt_offset, but this is done for consistency. v2: Remove unnecessary offset variable in do_pin, as we already have vma->node.start (Chris). Update GGTT offset too (Tvrtko). Cc: Chris Wilson Cc: Daniel Vetter Cc: Tvrtko Ursulin Signed-off-by: Michel Thierry Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: Use new drm_fb_helper functions

2015-08-06T12:13:05+00:00

Use the newly created wrapper drm_fb_helper functions instead of calling core fbdev functions directly. They also simplify the fb_info creation. v3: - Don't touch remove_conflicting_framebuffers v2: - No changes Cc: Daniel Vetter Cc: Jani Nikula Signed-off-by: Archit Taneja Signed-off-by: Daniel Vetter

drm/fbdev: Return -EBUSY when oopsing

2015-08-06T12:13:01+00:00

Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing. There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out. Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more). Cc: Dave Airlie Cc: Rodrigo Vivi Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter