Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 7月, 2015 3 次提交
  3. 23 7月, 2015 4 次提交
  5. 22 7月, 2015 1 次提交
  7. 21 7月, 2015 2 次提交
  9. 17 7月, 2015 15 次提交
  11. 15 7月, 2015 7 次提交
  13. 14 7月, 2015 8 次提交
    • M
      drm/i915: Do not call intel_crtc_disable if the crtc is already disabled. · ccfb8b2e
      由 Maarten Lankhorst 提交于 
      When resuming with dpms off, the following warn can happen:

[  118.334082] ------------[ cut here ]------------
[  118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]()
[  118.334106] WARN_ON(!crtc->state->enable)
[  118.334137] Modules linked in: i915
[  118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148
[  118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  118.334144] Workqueue: events_unbound async_run_entry_fn
[  118.334147]  ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001
[  118.334149]  ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8
[  118.334151]  ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668
[  118.334151] Call Trace:
[  118.334155]  [<ffffffff817aa62a>] dump_stack+0x4f/0x7b
[  118.334157]  [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0
[  118.334158]  [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50
[  118.334173]  [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915]
[  118.334188]  [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915]
[  118.334191]  [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80
[  118.334205]  [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915]
[  118.334219]  [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915]
[  118.334232]  [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915]
[  118.334246]  [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915]
[  118.334248]  [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90
[  118.334255]  [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915]
[  118.334262]  [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915]
[  118.334263]  [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0
[  118.334266]  [<ffffffff81467550>] dpm_run_callback+0x70/0x420
[  118.334267]  [<ffffffff81467cbd>] device_resume+0x9d/0x1c0
[  118.334269]  [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60
[  118.334270]  [<ffffffff81467dfc>] async_resume+0x1c/0x50
[  118.334271]  [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0
[  118.334273]  [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0
[  118.334275]  [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0
[  118.334276]  [<ffffffff8109daf9>] worker_thread+0x49/0x450
[  118.334278]  [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0
[  118.334280]  [<ffffffff810a3cb9>] kthread+0xf9/0x110
[  118.334282]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334284]  [<ffffffff817b414f>] ret_from_fork+0x3f/0x70
[  118.334286]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334287] ---[ end trace 01f2cf6371b82d7a ]---

This warn is harmless, and can be fixed by not calling intel_crtc_disable when
the crtc is already disabled.
Reported-and-Tested-by: NJörg Otte <jrg.otte@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ccfb8b2e
    • D
      Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations" · d82c0ba6
      由 Daniel Vetter 提交于 
      This reverts commit 19ee835c.

It breaks existing old userspace which doesn't handle UNKNOWN
swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably
still is on some other platforms, but it still pretty clearly broke
the testers machine. If we want this we need to extend the ioctl with
new paramters that only new userspace looks at.

Cc: Harald Arnesen <harald@skogtun.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NHarald Arnesen <harald@skogtun.org>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      d82c0ba6
    • T
      drm/i915: Forward all core DRM ioctls to core compat handling · ac7e7ab1
      由 Tvrtko Ursulin 提交于 
      Previously only core DRM ioctls under the DRM_COMMAND_BASE were being
forwarded, but the drm.h header suggests (and reality confirms) ones
after (and including) DRM_COMMAND_END should be forwarded as well.

We need this to correctly forward the compat ioctl for the botched-up
addfb2.1 extension.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: stable@vger.kernel.org # 4.1+
[danvet: Explain why this is suddenly needed and add cc: stable.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ac7e7ab1
    • D
      drm/i915: fix oops in primary_check_plane · bbf47020
      由 Daniel Vetter 提交于 
      On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote:
> On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote:
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
> > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb
>
> Ugh. Please enable KALLSYMS to get sane symbols.
>
> But yes, "crtc_state->base.active" is at offset 9 from "crtc_state",
> so it's pretty clearly just that change frm
>
> -       if (intel_crtc->active) {
> +       if (crtc_state->base.active) {
>
> and "crtc_state" is NULL.
>
> And the code very much knows that crtc_state can be NULL, since it's
> initialized with
>
>         crtc_state = state->base.state ?
>                 intel_atomic_get_crtc_state(state->base.state,
> intel_crtc) : NULL;
>
> Tssk. Daniel? Should I just revert that commit dec4f799
> ("drm/i915: Use crtc_state->active in primary check_plane func") for
> now, or is there a better fix? Like just checking crtc_state for NULL?

Indeed embarrassing. I've missed that we still have 1 caller left that's
using the transitional helpers, and those don't fill out
plane_state->state backpointers to the global atomic update since there is
no global atomic update for transitional helpers. Below diff should fix
this - we need to preferentially check crts_state->active and if that's
not set intel_crtc->active should yield the right result for the one
remaining caller (it's in the crtc_disable paths).

This fixes a regression introduced in

commit dec4f799
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jul 7 11:15:47 2015 +0200

    drm/i915: Use crtc_state->active in primary check_plane func

which was quickly reverted in

commit 01e2d062
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 12 15:00:20 2015 -0700

    Revert "drm/i915: Use crtc_state->active in primary check_plane func"

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jörg Otte <jrg.otte@gmail.com>
Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      bbf47020
    • I
      drm/i915: remove unused has_dma_mapping flag · 5ec5b516
      由 Imre Deak 提交于 
      After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Yeah this isn't really fixes but it's a nice cleanup to
clarify the code but not really worth the hassle of backmerging. So
just add to -fixes, we're still early in -rc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5ec5b516
    • D
      drm/i915: Fix missing return warning for !CONFIG_DEBUGFS · 101057fa
      由 Daniel Vetter 提交于 
      This broken code was introduced in

commit aa7471d2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Apr 1 11:15:21 2015 +0300

    drm/i915: add i915 specific connector debugfs file for DPCD

v2: Drop hunk that accidentally crept in.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: François Valenduc <francoisvalenduc@gmail.com>
Reported-by: NFrançois Valenduc <francoisvalenduc@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      101057fa
    • I
      drm/i915: avoid leaking DMA mappings · e2273302
      由 Imre Deak 提交于 
      We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
   memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects

For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the
corresponding backing pages and so in practice we create/release the
mapping in the object's get_pages/put_pages callback.

For 3. the lifetime of the mapping matches that of any existing GPU binding
of the object, so we'll create the mapping when the object is bound to
the first vma and release the mapping when the object is unbound from its
last vma.

Since the object can be bound to multiple vmas, we can end up creating a
new DMA mapping in the 3. case even if the object already had one. This
is not allowed by the DMA API and can lead to leaked mapping data and
IOMMU memory space starvation in certain cases. For example HW IOMMU
drivers (intel_iommu) allocate a new range from their memory space
whenever a mapping is created, silently overriding a pre-existing
mapping.

Fix this by moving the creation/removal of DMA mappings to the object's
get_pages/put_pages callbacks. These callbacks already check for and do
an early return in case of any nested calls. This way objects of the 3.
case also become more like the other object types.

I noticed this issue by enabling DMA debugging, which got disabled after
a while due to its internal mapping tables getting full. It also reported
errors in connection to random other drivers that did a DMA mapping for
an address that was previously mapped by i915 but was never released.
Besides these diagnostic messages and the memory space starvation
problem for IOMMUs, I'm not aware of this causing a real issue.

The fix is based on a patch from Chris.

v2:
- move the DMA mapping create/remove calls to the get_pages/put_pages
  callbacks instead of adding new callbacks for these (Chris)
v3:
- also fix the get_page cache logic on the userptr async path (Chris)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e2273302
    • T
      drm/i915: Snapshot seqno of most recently submitted request. · 94f7bbe1
      由 Tomas Elf 提交于 
      The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.

One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.

This fixes a regression introduced in

commit 44cdd6d2
Author: John Harrison <John.C.Harrison@Intel.com>
Date:   Mon Nov 24 18:49:40 2014 +0000

    drm/i915: Convert 'ring_idle()' to use requests not seqnos

v2 (Chris Wilson):
- Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather
than compute it over again.
- Remove extra whitespace.

Issue: VIZ-5998
Signed-off-by: NTomas Elf <tomas.elf@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regressing commit citation provided by Chris.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      94f7bbe1