Skip to content
  1. Mar 31, 2015
  3. Mar 30, 2015
  5. Mar 29, 2015
  7. Mar 28, 2015
  9. Mar 27, 2015
  11. Mar 26, 2015
    • Daniel Vetter's avatar
      drm/i915: Fixup legacy plane->crtc link for initial fb config · 5f407751
      Daniel Vetter authored 
      This is a very similar bug in the load detect code fixed in

commit 9128b040


Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Mar 3 17:31:21 2015 +0100

    drm/i915: Fix modeset state confusion in the load detect code

But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-and-tested-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com


Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5f407751
    • Damien Lespiau's avatar
      drm/i915: Fix atomic state when reusing the firmware fb · 3164a803
      Damien Lespiau authored 
      

Right now, we get a warning when taking over the firmware fb:

  [drm:drm_atomic_plane_check] FB set but no CRTC

with the following backtrace:

  [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm]
  [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm]
  [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
  [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
  [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
  [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
  [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
  [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915]
  [<ffffffff813ad444>] fbcon_init+0x4f4/0x580

That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.

We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.

v2: Fix the state on which we set the CRTC in the case we're sharing the
    initial fb with another pipe. (Matt)

Signed-off-by: default avatarDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com


Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      3164a803
    • Hui Wang's avatar
      ALSA: hda - Add one more node in the EAPD supporting candidate list · af95b414
      Hui Wang authored 
      We have a HP machine which use the codec node 0x17 connecting the
internal speaker, and from the node capability, we saw the EAPD,
if we don't set the EAPD on for this node, the internal speaker
can't output any sound.

Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1436745


Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      af95b414
    • Maxime Ripard's avatar
      clocksource/drivers/sun5i: Fix cpufreq interaction with sched_clock() · 6e206020
      Maxime Ripard authored 
      

The sun5i timer is used as the sched-clock on certain systems, and ever
since we started using cpufreq, the cpu clock (that is one of the
timer's clock indirect parent) now changes as well, along with the
actual sched_clock() rate.

This is not accurate and not desirable.

We can safely remove the sun5i sched-clock on those systems, since we
have other reliable sched_clock() sources in the system.

Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
[ Improved the changelog. ]
Cc: richard@nod.at
Link: http://lkml.kernel.org/r/1427362029-6511-4-git-send-email-daniel.lezcano@linaro.org


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6e206020
    • Richard Weinberger's avatar
      clocksource/drivers: Fix various !CONFIG_HAS_IOMEM build errors · 11bc26fe
      Richard Weinberger authored 
      

Fix !CONFIG_HAS_IOMEM related build failures in three clocksource drivers.

The build failures have the pattern of:

  drivers/clocksource/sh_cmt.c: In function ‘sh_cmt_map_memory’: drivers/clocksource/sh_cmt.c:920:2:
  error: implicit declaration of function ‘ioremap_nocache’ [-Werror=implicit-function-declaration]   cmt->mapbase = ioremap_nocache(mem->start, resource_size(mem));

Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
Signed-off-by: default avatarDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Cc: maxime.ripard@free-electrons.com
Link: http://lkml.kernel.org/r/1427362029-6511-1-git-send-email-daniel.lezcano@linaro.org


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      11bc26fe
    • Chris Wilson's avatar
      drm/i915: Keep ring->active_list and ring->requests_list consistent · 832a3aad
      Chris Wilson authored 
      If we retire requests last, we may use a later seqno and so clear
the requests lists without clearing the active list, leading to
confusion. Hence we should retire requests first for consistency with
the early return. The order used to be important as the lifecycle for
the object on the active list was determined by request->seqno. However,
the requests themselves are now reference counted removing the
constraint from the order of retirement.

Fixes regression from

commit 1b5a433a


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

    drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed
'

and a

	WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140()
	WARN_ON(!list_empty(&vm->active_list))

Identified by updating WATCH_LISTS:

	[drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests
	WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230()
	WARN_ON(i915_verify_lists(ring->dev))

Note that this is only a problem in evict_vm where the following happens
after a retire_request has cleaned out all requests, but not all active
bo:
- intel_ring_idle called from i915_gpu_idle notices that no requests are
  outstanding and immediately returns.
- i915_gem_retire_requests_ring called from i915_gem_retire_requests also
  immediately returns when there's no request, still leaving the bo on the
  active list.
- evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting
  all active objects that there's still stuff left that shouldn't be
  there.

Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      832a3aad
    • Libin Yang's avatar
      ALSA: hda_intel: apply the Seperate stream_tag for Sunrise Point · db48abf4
      Libin Yang authored 
      

The total stream number of Sunrise Point's input and output stream
exceeds 15, which will cause some streams do not work because
of the overflow on SDxCTL.STRM field if using the legacy
stream tag allocation method.

This patch uses the new stream tag allocation method by add
the flag AZX_DCAPS_SEPARATE_STREAM_TAG for Skylake platform.

Signed-off-by: default avatarLibin Yang <libin.yang@intel.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      db48abf4
    • Vineet Gupta's avatar
      ARC: signal handling robustify · e4140819
      Vineet Gupta authored 
      

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------

Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      e4140819
    • Vineet Gupta's avatar
      ARC: SA_SIGINFO ucontext regs off-by-one · 6914e1e3
      Vineet Gupta authored 
      The regfile provided to SA_SIGINFO signal handler as ucontext was off by
one due to pt_regs gutter cleanups in 2013.

Before handling signal, user pt_regs are copied onto user_regs_struct and copied
back later. Both structs are binary compatible. This was all fine until
commit 2fa91904 (ARC: pt_regs update #2) which removed the empty stack slot
at top of pt_regs (corresponding to first pad) and made the corresponding
fixup in struct user_regs_struct (the pad in there was moved out of
@scratch - not removed altogether as it is part of ptrace ABI)

 struct user_regs_struct {
+       long pad;
        struct {
-               long pad;
                long bta, lp_start, lp_end,....
        } scratch;
 ...
 }

This meant that now user_regs_struct was off by 1 reg w.r.t pt_regs and
signal code needs to user_regs_struct.scratch to reflect it as pt_regs,
which is what this commit does.

This problem was hidden for 2 years, because both save/restore, despite
using wrong location, were using the same location. Only an interim
inspection (reproducer below) exposed the issue.

     void handle_segv(int signo, siginfo_t *info, void *context)
     {
 	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	printf("regs %x %x\n",               <=== prints 7 8 (vs. 8 9)
               regs->scratch.r8, regs->scratch.r9);
     }

     int main()
     {
	struct sigaction sa;

	sa.sa_sigaction = handle_segv;
	sa.sa_flags = SA_SIGINFO;
	sigemptyset(&sa.sa_mask);
	sigaction(SIGSEGV, &sa, NULL);

	asm volatile(
	"mov	r7, 7	\n"
	"mov	r8, 8	\n"
	"mov	r9, 9	\n"
	"mov	r10, 10	\n"
	:::"r7","r8","r9","r10");

	*((unsigned int*)0x10) = 0;
     }

Fixes: 2fa91904

 "ARC: pt_regs update #2: Remove unused gutter at start of pt_regs"
CC: <stable@vger.kernel.org>
Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      6914e1e3