1. 01 8月, 2012 1 次提交
  2. 19 7月, 2012 1 次提交
  3. 16 7月, 2012 3 次提交
  4. 14 7月, 2012 5 次提交
  5. 02 7月, 2012 1 次提交
  6. 29 6月, 2012 1 次提交
    • J
      ARM: OMAP2+: do not allow SmartReflex to be built as a module · bb0adf6c
      Jean Pihet 提交于
      Disable the module option for POWER_AVS since this is currently not
      supported.
      
      This patch fixes these error in the case POWER_AVS is set to 'm':
      
      arch/arm/mach-omap2/built-in.o: In function `sr_class3_configure':
      arch/arm/mach-omap2/smartreflex-class3.c:43: undefined reference to `sr_configure_errgen'
      arch/arm/mach-omap2/built-in.o: In function `sr_class3_disable':
      arch/arm/mach-omap2/smartreflex-class3.c:33: undefined reference to `sr_disable_errgen'
      arch/arm/mach-omap2/smartreflex-class3.c:35: undefined reference to `sr_disable'
      arch/arm/mach-omap2/built-in.o: In function `sr_class3_enable':
      arch/arm/mach-omap2/smartreflex-class3.c:28: undefined reference to `sr_enable'
      arch/arm/mach-omap2/built-in.o: In function `sr_class3_init':
      arch/arm/mach-omap2/smartreflex-class3.c:59: undefined reference to `sr_register_class'
      Reported-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NJean Pihet <j-pihet@ti.com>
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      [tony@atomide.com: updated to use relative paths for the build error]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      bb0adf6c
  7. 28 6月, 2012 1 次提交
  8. 25 6月, 2012 2 次提交
  9. 21 6月, 2012 2 次提交
  10. 20 6月, 2012 9 次提交
  11. 18 6月, 2012 3 次提交
  12. 14 6月, 2012 1 次提交
    • N
      W1: split master mutex to avoid deadlocks. · b02f8bed
      NeilBrown 提交于
      The 'mutex' in struct w1_master is use for two very different
      purposes.
      
      Firstly it protects various data structures such as the list of all
      slaves.
      
      Secondly it protects the w1 buss against concurrent accesses.
      
      This can lead to deadlocks when the ->probe code called while adding a
      slave needs to talk on the bus, as is the case for power_supply
      devices.
      ds2780 and ds2781 drivers contain a work around to track which
      process hold the lock simply to avoid this deadlock.  bq27000 doesn't
      have that work around and so deadlocks.
      
      There are other possible deadlocks involving sysfs.
      When removing a device the sysfs s_active lock is held, so the lock
      that protects the slave list must take precedence over s_active.
      However when access power_supply attributes via sysfs, the s_active
      lock must take precedence over the lock that protects accesses to
      the bus.
      
      So to avoid deadlocks between w1 slaves and sysfs, these must be
      two separate locks.  Making them separate means that the work around
      in ds2780 and ds2781 can be removed.
      
      So this patch:
       - adds a new mutex: "bus_mutex" which serialises access to the bus.
       - takes in mutex in w1_search and ds1wm_search while they access
         the bus for searching.  The mutex is dropped before calling the
         callback which adds the slave.
       - changes all slaves to use bus_mutex instead of mutex to
         protect access to the bus
       - removes w1_ds2790_io_nolock and w1_ds2781_io_nolock, and the
         related code from drivers/power/ds278[01]_battery.c which
         calls them.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b02f8bed
  13. 01 6月, 2012 1 次提交
  14. 20 5月, 2012 1 次提交
    • M
      mfd: Convert wm831x to irq_domain · cd99758b
      Mark Brown 提交于
      The modern idiom is to use irq_domain to allocate interrupts. This is
      useful partly to allow further infrastructure to be based on the domains
      and partly because it makes it much easier to allocate virtual interrupts
      to devices as we don't need to allocate a contiguous range of interrupt
      numbers.
      
      Convert the wm831x driver over to this infrastructure, using a legacy
      IRQ mapping if an irq_base is specified in platform data and otherwise
      using a linear mapping, always registering the interrupts even if they
      won't ever be used. Only boards which need to use the GPIOs as
      interrupts should need to use an irq_base.
      
      This means that we can't use the MFD irq_base management since the
      unless we're using an explicit irq_base from platform data we can't rely
      on a linear mapping of interrupts.  Instead we need to map things via
      the irq_domain - provide a conveniencem function wm831x_irq() to save a
      small amount of typing when doing so. Looking at this I couldn't clearly
      see anything the MFD core could do to make this nicer.
      
      Since we're not supporting device tree yet there's no meaningful
      advantage if we don't do this conversion in one, the fact that the
      interrupt resources are used for repeated IP blocks makes accessor
      functions for the irq_domain more trouble to do than they're worth.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      cd99758b
  15. 19 5月, 2012 1 次提交
  16. 06 5月, 2012 7 次提交
新手
引导
客服 返回
顶部