1. 12 Jul, 2007 1 commit
    • Pavel Pisa's avatar
      [ARM] 4373/1: i.MX/MX1 GPIO support implementation · b3e6a508
      Pavel Pisa authored
      
      
      Support for generic input output for MX1 family.
      The implementation prevents allocation of one pin
      by two users, but does not store pointer to the user
      description permanently, because this solution
      would have bigger memory overhead.
      
      The simple way to integrate code with per BSP
      pins setup and allocation is required else all GPIO
      registration checking is useless. The function
      imx_gpio_setup_multiple_pins() can be used for this
      purpose in future.
      Signed-off-by: default avatarPavel Pisa <pisa@cmp.felk.cvut.cz>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b3e6a508
  2. 16 May, 2007 1 commit
  3. 12 May, 2007 1 commit
  4. 11 May, 2007 4 commits
  5. 09 May, 2007 1 commit
  6. 02 May, 2007 1 commit
  7. 28 Apr, 2007 1 commit
  8. 21 Apr, 2007 5 commits
  9. 05 Mar, 2007 1 commit
    • David Brownell's avatar
      [PATCH] add CONFIG_GENERIC_GPIO · 0a938b97
      David Brownell authored
      
      
      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: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: default avatarRichard 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0a938b97
  10. 03 Mar, 2007 1 commit
  11. 26 Feb, 2007 1 commit
  12. 17 Feb, 2007 2 commits
  13. 16 Feb, 2007 2 commits
  14. 14 Feb, 2007 1 commit
  15. 11 Feb, 2007 3 commits
    • Al Viro's avatar
      [PATCH] sort the devres mess out · 5ea81769
      Al Viro authored
      
      
      * Split the implementation-agnostic stuff in separate files.
      * Make sure that targets using non-default request_irq() pull
        kernel/irq/devres.o
      * Introduce new symbols (HAS_IOPORT and HAS_IOMEM) defaulting to positive;
        allow architectures to turn them off (we needed these symbols anyway for
        dependencies of quite a few drivers).
      * protect the ioport-related parts of lib/devres.o with CONFIG_HAS_IOPORT.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5ea81769
    • Christoph Lameter's avatar
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter authored
      
      
      As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA
      channel management.  Other functionality may still expect GFP_DMA to
      provide memory below 16M.  So we need to make sure that CONFIG_ZONE_DMA is
      set independent of CONFIG_GENERIC_ISA_DMA.  Undo the modifications to
      mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set
      theses explicitly in each arches Kconfig.
      
      Reviews must occur for each arch in order to determine if ZONE_DMA can be
      switched off.  It can only be switched off if we know that all devices
      supported by a platform are capable of performing DMA transfers to all of
      memory (Some arches already support this: uml, avr32, sh sh64, parisc and
      IA64/Altix).
      
      In order to switch ZONE_DMA off conditionally, one would have to establish
      a scheme by which one can assure that no drivers are enabled that are only
      capable of doing I/O to a part of memory, or one needs to provide an
      alternate means of performing an allocation from a specific range of memory
      (like provided by alloc_pages_range()) and insure that all drivers use that
      call.  In that case the arches alloc_dma_coherent() may need to be modified
      to call alloc_pages_range() instead of relying on GFP_DMA.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5ac6da66
    • Ben Dooks's avatar
      [ARM] 4157/2: S3C24XX: move arch/arch/mach-s3c2410 into cpu components · a21765a7
      Ben Dooks authored
      
      
      The following patch and script moves the arch/arm/mach-s3c2410
      directory into arch/arm/plat-s3c24xx for the generic core code
      and inti arch/arm/mach-s3c{cpu} for the cpu/machine support files
      
      Include directory include/asm-arm/plat-s3c24xx is added for the
      core include files.
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a21765a7
  16. 09 Feb, 2007 1 commit
  17. 08 Feb, 2007 2 commits
  18. 13 Dec, 2006 2 commits
  19. 08 Dec, 2006 1 commit
    • David Howells's avatar
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells authored
      
      
      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: default avatarDavid 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
  20. 07 Dec, 2006 1 commit
    • Dan Williams's avatar
      [ARM] 3995/1: iop13xx: add iop13xx support · 285f5fa7
      Dan Williams authored
      The iop348 processor integrates an Xscale (XSC3 512KB L2 Cache) core with a
      Serial Attached SCSI (SAS) controller, multi-ported DDR2 memory
      controller, 3 Application Direct Memory Access (DMA) controllers, a 133Mhz
      PCI-X interface, a x8 PCI-Express interface, and other peripherals to form
      a system-on-a-chip RAID subsystem engine.
      
      The iop342 processor replaces the SAS controller with a second Xscale core
      for dual core embedded applications.
      
      The iop341 processor is the single core version of iop342.
      
      This patch supports the two Intel customer reference platforms iq81340mc
      for external storage and iq81340sc for direct attach (HBA) development.
      
      The developer's manual is available here:
      ftp://download.intel.com/design/iio/docs/31503701.pdf
      
      
      
      Changelog:
      * removed virtual addresses from resource definitions
      * cleaned up some unnecessary #include's
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      285f5fa7
  21. 03 Dec, 2006 1 commit
    • Lennert Buytenhek's avatar
      [ARM] 3881/4: xscale: clean up cp0/cp1 handling · afe4b25e
      Lennert Buytenhek authored
      
      
      XScale cores either have a DSP coprocessor (which contains a single
      40 bit accumulator register), or an iWMMXt coprocessor (which contains
      eight 64 bit registers.)
      
      Because of the small amount of state in the DSP coprocessor, access to
      the DSP coprocessor (CP0) is always enabled, and DSP context switching
      is done unconditionally on every task switch.  Access to the iWMMXt
      coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
      first issued, and iWMMXt context switching is done lazily.
      
      CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
      have iWMMXt support', but boards are supposed to select this config
      symbol by hand, and at least one pxa27x board doesn't get this right,
      so on that board, proc-xscale.S will incorrectly assume that we have a
      DSP coprocessor, enable CP0 on boot, and we will then only save the
      first iWMMXt register (wR0) on context switches, which is Bad.
      
      This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
      might have iWMMXt support, and we will enable iWMMXt context switching
      if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
      kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
      state over context switches, and running a CONFIG_IWMMXT=y kernel on a
      non-iWMMXt capable CPU will still do DSP context save/restore.
      
      These changes should make iWMMXt work on PXA3xx, and as a side effect,
      enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
      as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
      as well as setting and using HWCAP_IWMMXT properly.
      Signed-off-by: default avatarLennert Buytenhek <buytenh@wantstofly.org>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      afe4b25e
  22. 01 Dec, 2006 1 commit
  23. 20 Nov, 2006 1 commit
  24. 03 Oct, 2006 1 commit
  25. 28 Sep, 2006 3 commits