1. 02 7月, 2008 3 次提交
    • H
      avr32: Power Management support ("standby" and "mem" modes) · 02a00cf6
      Haavard Skinnemoen 提交于
      Implement Standby support. In this mode, we'll suspend all drivers,
      put the SDRAM in self-refresh mode and switch off the HSB bus
      ("frozen" mode.)
      
      Implement Suspend-to-mem support. In this mode, we suspend all
      drivers, put the SDRAM into self-refresh mode and switch off all
      internal clocks except the 32 kHz oscillator ("stop" mode.)
      
      The lowest-level suspend code runs from a small portion of SRAM
      allocated at startup time. This gets rid of a small potential race
      with the SDRAM where we might try to enter self-refresh mode in the
      middle of an icache burst. We also relocate all interrupt and
      exception handlers to SRAM during the small window when we enter and
      exit the low-power modes.
      
      We don't need to do any special tricks to start and stop the PLL. The
      main clock is automatically gated by hardware until the PLL is stable.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      02a00cf6
    • H
      avr32: Add simple SRAM allocator · b83d6ee1
      Haavard Skinnemoen 提交于
      Add SRAM allocator for avr32, which is just a thin wrapper around
      genalloc.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      b83d6ee1
    • H
      avr32: Use a quicklist for PGD allocation · 5a4d5292
      Haavard Skinnemoen 提交于
      Use a quicklist to allocate process PGDs. This is expected to be
      slightly faster since we need to copy entries from swapper_pg_dir,
      which can stay around for pages on the PGD quick list.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      5a4d5292
  2. 20 4月, 2008 1 次提交
    • D
      avr32: Generic clockevents support · e723ff66
      David Brownell 提交于
      This combines three patches from David Brownell:
        * avr32: tclib support
        * avr32: simplify clocksources
        * avr32: Turn count/compare into a oneshot clockevent device
      
      Register both TC blocks (instead of just the first one) so that
      the AT32/AT91 tclib code will pick them up (instead of just the
      avr32-only PIT-style clocksource).
      
      Rename the first one and its resources appropriately.
      
      More cleanups to the cycle counter clocksource code
      
       - Disable all the weak symbol magic; remove the AVR32-only TCB-based
         clocksource code (source and header).
      
       - Mark the __init code properly.
      
       - Don't forget to report IRQF_TIMER.
      
       - Make the system work properly with this clocksource, by preventing
         use of the CPU "idle" sleep state in the idle loop when it's used.
      
      Package the avr32 count/compare timekeeping support as a oneshot
      clockevent device, so it supports NO_HZ and high res timers.
      This means it also supports plugging in other clockevent devices
      and clocksources.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      e723ff66
  3. 17 4月, 2008 1 次提交
    • A
      avr32 mustn't select HAVE_IDE · 71fc4c0c
      Adrian Bunk 提交于
      There's a libata based PATA driver for avr32, but no support for 
      drivers/ide/ on avr32.
      
      This patch fixes the following compile error:
      
      <--  snip  -->
      
      ...
        CC [M]  drivers/ide/ide-cd.o
      In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/ide-cd.c:37:
      /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/ide.h:209:21: error: asm/ide.h: No such file or directory
      make[3]: *** [drivers/ide/ide-cd.o] Error 1
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      71fc4c0c
  4. 09 2月, 2008 1 次提交
  5. 06 2月, 2008 1 次提交
    • D
      gpiolib: avr32 at32ap platform support · b98348bd
      David Brownell 提交于
      Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that signals
      on external chips (like GPIO expanders) can easily be used.
      
      This mostly reorganizes some existing logic, with two minor changes in
      behavior:
      
       - The PSR registers are used instead of the previous "gpio_mask" values,
         matching AT91 behavior and removing some duplication between that role
         and that of "pinmux_mask".
      
       - NR_IRQs grew to acommodate a bank of external GPIOs.  Eventually this
         number should probably become a board-specific config option.
      
      There's a debugfs dump of status for the built-in GPIOs, showing which pins
      have deglitching, pullups, or open drain drive enabled, as well as the ID
      string used when requesting each IRQ.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Eric Miao <eric.miao@marvell.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ben Gardner <bgardner@wabtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b98348bd
  6. 04 2月, 2008 1 次提交
  7. 03 2月, 2008 2 次提交
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  8. 25 1月, 2008 6 次提交
  9. 07 12月, 2007 3 次提交
  10. 15 11月, 2007 1 次提交
  11. 20 10月, 2007 1 次提交
  12. 19 7月, 2007 2 次提交
  13. 27 4月, 2007 4 次提交
  14. 05 3月, 2007 1 次提交
    • D
      [PATCH] add CONFIG_GENERIC_GPIO · 0a938b97
      David Brownell 提交于
      Most drivers using GPIOs already know they are running on a system that
      supports the generic GPIO calls, because of other platform dependencies.
      But the generic GPIO-based LED and input button drivers can't know that.
      
      So this patch adds a Kconfig hook, GENERIC_GPIO, to mark the platforms
      where <asm/gpio.h> will do the right thing.  Currently that's a bunch of
      ARMs, and AVR32; more are on the way.
      
      It also fixes a dependency bug for the gpio button input driver; it was
      wrong to start with, now it covers all platforms with GENERIC_GPIO.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NRichard Purdie <rpurdie@rpsys.net>
      Cc: Arnaud Patard <arnaud.patard@rtp-net.org>
      Cc: <raph@8d.com>
      Cc: <msvoboda@ra.rockwell.com>
      Cc: pHilipp Zabel <philipp.zabel@gmail.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a938b97
  15. 09 12月, 2006 1 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
  16. 26 9月, 2006 1 次提交