1. 01 Aug, 2017 32 commits
  2. 31 Jul, 2017 3 commits
    • Dave Airlie's avatar
      efifb: allow user to disable write combined mapping. · dd0c41f8
      Dave Airlie authored
      This patch allows the user to disable write combined mapping
      of the efifb framebuffer console using an nowc option.
      
      A customer noticed major slowdowns while logging to the console
      with write combining enabled, on other tasks running on the same
      CPU. (10x or greater slow down on all other cores on the same CPU
      as is doing the logging).
      
      I reproduced this on a machine with dual CPUs.
      Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz (6 core)
      
      I wrote a test that just mmaps the pci bar and writes to it in
      a loop, while this was running in the background one a single
      core with (taskset -c 1), building a kernel up to init/version.o
      (taskset -c 8) went from 13s to 133s or so. I've yet to explain
      why this occurs or what is going wrong I haven't managed to find
      a perf command that in any way gives insight into this.
      
          11,885,070,715      instructions              #    1.39  insns per cycle
      vs
          12,082,592,342      instructions              #    0.13  insns per cycle
      
      is the only thing I've spotted of interest, I've tried at least:
      dTLB-stores,dTLB-store-misses,L1-dcache-stores,LLC-store,LLC-store-misses,LLC-load-misses,LLC-loads,\mem-loads,mem-stores,iTLB-loads,iTLB-load-misses,cache-references,cache-misses
      
      For now it seems at least a good idea to allow a user to disable write
      combining if they see this until we can figure it out.
      
      Note also most users get a real framebuffer driver loaded when kms
      kicks in, it just happens on these machines the kernel didn't support
      the gpu specific driver.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Acked-by: default avatarPeter Jones <pjones@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      dd0c41f8
    • Arnd Bergmann's avatar
      fbdev: omapfb: remove unused variable · 7b4dfbe7
      Arnd Bergmann authored
      Removing the default display name left a harmless warning:
      
      fbdev/omap2/omapfb/dss/core.c: In function 'omap_dss_probe':
      fbdev/omap2/omapfb/dss/core.c:196:30: error: unused variable 'pdata' [-Werror=unused-variable]
      
      This removes the now-unused variable as well.
      
      Fixes: 278cba7e ("drm: omapdrm: Remove unused default display name support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      7b4dfbe7
    • Dan Carpenter's avatar
      video: fbdev: imxfb: use after free in imxfb_remove() · 5ae29649
      Dan Carpenter authored
      We free "info" then dereference it on the next line.  Really this whole
      function would be better if we wrote it to unwind in the mirror of how
      things are allocated in the probe.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Alexander Shiyan <shc_work@mail.ru>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      5ae29649
  3. 30 Jul, 2017 5 commits