1. 28 6月, 2013 1 次提交
  2. 25 6月, 2013 2 次提交
    • K
      drm/i915: make compact dma scatter lists creation work with SWIOTLB backend. · 426729dc
      Konrad Rzeszutek Wilk 提交于
      Git commit 90797e6d
      ("drm/i915: create compact dma scatter lists for gem objects") makes
      certain assumptions about the under laying DMA API that are not always
      correct.
      
      On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup
      I see:
      
      [drm:intel_pipe_set_base] *ERROR* pin & fence failed
      [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28
      
      Bit of debugging traced it down to dma_map_sg failing (in
      i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB).
      
      That unfortunately are sizes that the SWIOTLB is incapable of handling -
      the maximum it can handle is a an entry of 512KB of virtual contiguous
      memory for its bounce buffer. (See IO_TLB_SEGSIZE).
      
      Previous to the above mention git commit the SG entries were of 4KB, and
      the code introduced by above git commit squashed the CPU contiguous PFNs
      in one big virtual address provided to DMA API.
      
      This patch is a simple semi-revert - were we emulate the old behavior
      if we detect that SWIOTLB is online. If it is not online then we continue
      on with the new compact scatter gather mechanism.
      
      An alternative solution would be for the the '.get_pages' and the
      i915_gem_gtt_prepare_object to retry with smaller max gap of the
      amount of PFNs that can be combined together - but with this issue
      discovered during rc7 that might be too risky.
      Reported-and-Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Imre Deak <imre.deak@intel.com>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>
      CC: David Airlie <airlied@linux.ie>
      CC: <dri-devel@lists.freedesktop.org>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      426729dc
    • D
      Merge tag 'drm-intel-fixes-2013-06-24' of... · 0d20299d
      Dave Airlie 提交于
      Merge tag 'drm-intel-fixes-2013-06-24' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
      
      One remaining regression fix for i915. I've left it in -fixes for more
      than a week since it's in tricky code, and it took us a few kernel
      releases to notice the regression at all. The fence leak is especially
      annoying on gen2/3 and will kill userspace there quickly. For extra
      paranoia we've added a WARN in -next to catch this, things seem to be
      solid now.
      
      * tag 'drm-intel-fixes-2013-06-24' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/i915: Restore fences after resume and GPU resets
      0d20299d
  3. 24 6月, 2013 2 次提交
  4. 23 6月, 2013 8 次提交
  5. 22 6月, 2013 7 次提交
  6. 21 6月, 2013 13 次提交
  7. 20 6月, 2013 7 次提交
    • A
      splice: don't pass the address of ->f_pos to methods · 7995bd28
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      7995bd28
    • M
      [media] Fix build when drivers are builtin and frontend modules · bb69ee27
      Mauro Carvalho Chehab 提交于
      There are a large number of reports that the media build is
      not compiling when some drivers are compiled as builtin, while
      the needed frontends are compiled as module.
      
      On the last one of such reports:
      	From: kbuild test robot <fengguang.wu@intel.com>
      	Subject: saa7134-dvb.c:undefined reference to `zl10039_attach'
      
      The .config file has:
      
      	CONFIG_VIDEO_SAA7134=y
      	CONFIG_VIDEO_SAA7134_DVB=y
      	# CONFIG_MEDIA_ATTACH is not set
      	CONFIG_DVB_ZL10039=m
      
      And it produces all those errors:
      
         drivers/built-in.o: In function `set_type':
         tuner-core.c:(.text+0x2f263e): undefined reference to `tea5767_attach'
         tuner-core.c:(.text+0x2f273e): undefined reference to `tda9887_attach'
         drivers/built-in.o: In function `tuner_probe':
         tuner-core.c:(.text+0x2f2d20): undefined reference to `tea5767_autodetection'
         drivers/built-in.o: In function `av7110_attach':
         av7110.c:(.text+0x330bda): undefined reference to `ves1x93_attach'
         av7110.c:(.text+0x330bf7): undefined reference to `stv0299_attach'
         av7110.c:(.text+0x330c63): undefined reference to `tda8083_attach'
         av7110.c:(.text+0x330d09): undefined reference to `ves1x93_attach'
         av7110.c:(.text+0x330d33): undefined reference to `tda8083_attach'
         av7110.c:(.text+0x330d5d): undefined reference to `stv0297_attach'
         av7110.c:(.text+0x330dbe): undefined reference to `stv0299_attach'
         drivers/built-in.o: In function `tuner_attach_dtt7520x':
         ngene-cards.c:(.text+0x3381cb): undefined reference to `dvb_pll_attach'
         drivers/built-in.o: In function `demod_attach_lg330x':
         ngene-cards.c:(.text+0x33828a): undefined reference to `lgdt330x_attach'
         drivers/built-in.o: In function `demod_attach_stv0900':
         ngene-cards.c:(.text+0x3383d5): undefined reference to `stv090x_attach'
         drivers/built-in.o: In function `cineS2_probe':
         ngene-cards.c:(.text+0x338b7f): undefined reference to `drxk_attach'
         drivers/built-in.o: In function `configure_tda827x_fe':
         saa7134-dvb.c:(.text+0x346ae7): undefined reference to `tda10046_attach'
         drivers/built-in.o: In function `dvb_init':
         saa7134-dvb.c:(.text+0x347283): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x3472cd): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x34731c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x34733c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x34735c): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x347378): undefined reference to `tda10046_attach'
         saa7134-dvb.c:(.text+0x3473db): undefined reference to `tda10046_attach'
         drivers/built-in.o:saa7134-dvb.c:(.text+0x347502): more undefined references to `tda10046_attach' follow
         drivers/built-in.o: In function `dvb_init':
         saa7134-dvb.c:(.text+0x347812): undefined reference to `mt352_attach'
         saa7134-dvb.c:(.text+0x347951): undefined reference to `mt312_attach'
         saa7134-dvb.c:(.text+0x3479a9): undefined reference to `mt312_attach'
      >> saa7134-dvb.c:(.text+0x3479c1): undefined reference to `zl10039_attach'
      
      This is happening because a builtin module can't use directly a symbol
      found on a module. By enabling CONFIG_MEDIA_ATTACH, the configuration
      becomes valid, as dvb_attach() macro loads the module if needed, making
      the symbol available to the builtin module.
      
      While this bug started to appear after the patches that use IS_DEFINED
      macro (like changeset 7b34be71), this
      bug is a way ancient than that.
      
      The thing is that, before the IS_DEFINED() patches, the logic used to be:
      
             && defined(MODULE))
      struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
      					u8 i2c_addr,
      					struct i2c_adapter *i2c);
      static inline struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
      					u8 i2c_addr,
      					struct i2c_adapter *i2c)
      {
      	printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
      	return NULL;
      }
      
      The above code, with the .config file used, was evoluting to FALSE
      (instead of TRUE as it should be, as CONFIG_DVB_ZL10039 is 'm'),
      and were adding the static inline code at saa7134-dvb, instead
      of the external call. So, while it weren't producing any compilation
      error, the code weren't working either.
      
      So, as the overhead for using CONFIG_MEDIA_ATTACH is minimal, just
      enable it, if MODULES is defined.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      bb69ee27
    • S
      irqchip: gic: call gic_cpu_init() as well in CPU_STARTING_FROZEN case · 8b6fd652
      Shawn Guo 提交于
      Commit c0114709 (irqchip: gic: Perform the gic_secondary_init() call via
      CPU notifier) moves gic_secondary_init() that used to be called in
      .smp_secondary_init hook into a notifier call.  But it changes the
      system behavior a little bit.  Before the commit, gic_cpu_init()
      is called not only when kernel brings up the secondary cores but also
      when system resuming procedure hot-plugs the cores back to kernel.
      While after the commit, the function will not be called in the latter
      case, where the 'action' will not be CPU_STARTING but
      CPU_STARTING_FROZEN.  This behavior difference at least causes the
      following suspend/resume regression on imx6q.
      
      $ echo mem > /sys/power/state
      PM: Syncing filesystems ... done.
      PM: Preparing system for mem sleep
      mmc1: card e624 removed
      Freezing user space processes ... (elapsed 0.01 seconds) done.
      Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
      PM: Entering mem sleep
      PM: suspend of devices complete after 5.930 msecs
      PM: suspend devices took 0.010 seconds
      PM: late suspend of devices complete after 0.343 msecs
      PM: noirq suspend of devices complete after 0.828 msecs
      Disabling non-boot CPUs ...
      CPU1: shutdown
      CPU2: shutdown
      CPU3: shutdown
      Enabling non-boot CPUs ...
      CPU1: Booted secondary processor
      INFO: rcu_sched detected stalls on CPUs/tasks: { 1 2 3} (detected by 0, t=2102 jiffies, g=4294967169, c=4294967168, q=17)
      Task dump for CPU 1:
      swapper/1       R running      0     0      1 0x00000000
      Backtrace:
      [<bf895ff4>] (0xbf895ff4) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <8007ccdc>
      Task dump for CPU 2:
      swapper/2       R running      0     0      1 0x00000000
      Backtrace:
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      Backtrace aborted due to bad frame pointer <00000002>
      Task dump for CPU 3:
      swapper/3       R running      0     0      1 0x00000000
      Backtrace:
      [<8075dbdc>] (0x8075dbdc) from [<00000000>] (  (null))
      
      Fix the regression by checking 'action' being CPU_STARTING_FROZEN to
      have gic_cpu_init() called for secondary cores when system resumes.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Tested-by: NJoseph Lo <josephl@nvidia.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      8b6fd652
    • M
      x86: Fix trigger_all_cpu_backtrace() implementation · b52e0a7c
      Michel Lespinasse 提交于
      The following change fixes the x86 implementation of
      trigger_all_cpu_backtrace(), which was previously (accidentally,
      as far as I can tell) disabled to always return false as on
      architectures that do not implement this function.
      
      trigger_all_cpu_backtrace(), as defined in include/linux/nmi.h,
      should call arch_trigger_all_cpu_backtrace() if available, or
      return false if the underlying arch doesn't implement this
      function.
      
      x86 did provide a suitable arch_trigger_all_cpu_backtrace()
      implementation, but it wasn't actually being used because it was
      declared in asm/nmi.h, which linux/nmi.h doesn't include. Also,
      linux/nmi.h couldn't easily be fixed by including asm/nmi.h,
      because that file is not available on all architectures.
      
      I am proposing to fix this by moving the x86 definition of
      arch_trigger_all_cpu_backtrace() to asm/irq.h.
      
      Tested via: echo l > /proc/sysrq-trigger
      
      Before the change, this uses a fallback implementation which
      shows backtraces on active CPUs (using
      smp_call_function_interrupt() )
      
      After the change, this shows NMI backtraces on all CPUs
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1370518875-1346-1-git-send-email-walken@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b52e0a7c
    • J
      perf: arm64: Record the user-mode PC in the call chain. · abc41254
      Jed Davis 提交于
      With this change, we no longer lose the innermost entry in the user-mode
      part of the call chain.  See also the x86 port, which includes the ip,
      and the corresponding change in arch/arm.
      Signed-off-by: NJed Davis <jld@mozilla.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      abc41254
    • M
      [media] s5p makefiles: don't override other selections on obj-[ym] · 5f63adbb
      Mauro Carvalho Chehab 提交于
      The $obj-m/$obj-y vars should be adding new modules to build, not
      overriding it. So, it should never use
      	$obj-y := foo.o
      instead, it should use:
      	$obj-y += foo.o
      
      Failing to do that is very bad, as it will suppress needed modules.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5f63adbb
    • A
      powerpc: Fix bad pmd error with book3E config · 8bbd9f04
      Aneesh Kumar K.V 提交于
      Book3E uses the hugepd at PMD level and don't encode pte directly
      at the pmd level. So it will find the lower bits of pmd set
      and the pmd_bad check throws error. Infact the current code
      will never take the free_hugepd_range call at all because it will
      clear the pmd if it find a hugepd pointer. Fix this by clearing
      bad pmd only if it is not a hugepd pointer.
      
      This is regression introduced by e2b3d202
      "powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format"
      Reported-by: NScott Wood <scottwood@freescale.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8bbd9f04