1. 27 Apr, 2009 3 commits
    • David Brownell's avatar
      davinci: gpio bugfixes · 474dad54
      David Brownell authored
      Update the DaVinci GPIO code to work better on non-dm6446 parts,
      notably the dm355:
      
       - Only handle the number of GPIOs the chip actually has.  So
         for example on dm6467, GPIO-42 is the last GPIO, and trying
         to use GPIO-43 now fails cleanly; or GPIO-72 on dm6446.
      
       - Enable GPIO interrupts on each 16-bit GPIO-irq bank ...
         previously, only the first five were enabled, so GPIO-80
         and above (on dm355) wouldn't trigger IRQs.
      
       - Use the right IRQ for each GPIO bank.  The wrong values were
         used for dm355 chips, so GPIO IRQs got routed incorrectly.
      
       - Handle up to four pairs of 16-bit GPIO banks ... previously
         only three were handled, so accessing GPIO-96 and up (e.g. on
         dm355) would oops.
      
       - Update several comments that were dm6446-specific.
      
      Verified by receiving GPIO-1 (dm9000) and GPIO-5 (msp430) IRQs
      on the DM355 EVM.
      
      One thing this doesn't do is handle the way some of the GPIO
      numbers on dm6467 are reserved but aren't valid as GPIOs.  Some
      bitmap logic could fix that if needed.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      474dad54
    • Kevin Hilman's avatar
      davinci: add EDMA driver · a4768d22
      Kevin Hilman authored
      Original code for 2.6.10 and 2.6.28 series done by Texas Instruments
      and MontaVista, but major updates and rework done by Troy Kisky and
      David Brownell.
      
      Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
      Cc: Troy Kisky <troy.kisky@boundarydevices.com>
      Cc: David Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      a4768d22
    • Kevin Hilman's avatar
      davinci: timers: use clk_get_rate() · e6099002
      Kevin Hilman authored
      Use clock framework instead of hard-coded CLOCK_TICK_RATE for
      determining timer tick frequencies.
      Signed-off-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      e6099002
  2. 23 Apr, 2009 4 commits
  3. 22 Apr, 2009 5 commits
    • Linus Torvalds's avatar
      Linux 2.6.30-rc3 · 09106974
      Linus Torvalds authored
      09106974
    • Arjan van de Ven's avatar
      driver synchronization: make scsi_wait_scan more advanced · d4d5291c
      Arjan van de Ven authored
      There is currently only one way for userspace to say "wait for my storage
      device to get ready for the modules I just loaded": to load the
      scsi_wait_scan module. Expectations of userspace are that once this
      module is loaded, all the (storage) devices for which the drivers
      were loaded before the module load are present.
      
      Now, there are some issues with the implementation, and the async
      stuff got caught in the middle of this: The existing code only
      waits for the scsy async probing to finish, but it did not take
      into account at all that probing might not have begun yet.
      (Russell ran into this problem on his computer and the fix works for him)
      
      This patch fixes this more thoroughly than the previous "fix", which
      had some bad side effects (namely, for kernel code that wanted to wait for
      the scsi scan it would also do an async sync, which would deadlock if you did
      it from async context already.. there's a report about that on lkml):
      The patch makes the module first wait for all device driver probes, and then it
      will wait for the scsi parallel scan to finish.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Tested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d4d5291c
    • Jonathan Corbet's avatar
      Trivial: fix a typo in slow-work.h · 5dd559f0
      Jonathan Corbet authored
      Fix a comment typo in slow-work.h
      
      ...a trivial mistake, but it will mess up kerneldoc if nothing else.
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5dd559f0
    • David Howells's avatar
      PERCPU: Collect the DECLARE/DEFINE declarations together · 5028eaa9
      David Howells authored
      Collect the DECLARE/DEFINE declarations together in linux/percpu-defs.h so
      that they're in one place, and give them descriptive comments, particularly
      the SHARED_ALIGNED variant.
      
      It would be nice to collect these in linux/percpu.h, but that's not possible
      without sorting out the severe #include recursion between the x86 arch headers
      and the general headers (and possibly other arches too).
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5028eaa9
    • David Howells's avatar
      FRV: Fix the section attribute on UP DECLARE_PER_CPU() · 9b8de747
      David Howells authored
      In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU()
      does not agree with that specified by DEFINE_PER_CPU().  This means that
      architectures that have a small data section references relative to a base
      register may throw up linkage errors due to too great a displacement between
      where the base register points and the per-CPU variable.
      
      On FRV, the .h declaration says that the variable is in the .sdata section, but
      the .c definition says it's actually in the .data section.  The linker throws
      up the following errors:
      
      kernel/built-in.o: In function `release_task':
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      
      To fix this, DECLARE_PER_CPU() should simply apply the same section attribute
      as does DEFINE_PER_CPU().  However, this is made slightly more complex by
      virtue of the fact that there are several variants on DEFINE, so these need to
      be matched by variants on DECLARE.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b8de747
  4. 21 Apr, 2009 28 commits