1. 08 2月, 2007 3 次提交
    • A
      [ARM] 4143/1: AT91: Prepare for AT91SAM9263 support · d0760b3b
      Andrew Victor 提交于
      The Atmel AT91SAM9263 processor includes many more integrated
      peripherals than Atmel's previous ARM9-based AT91 processors, so this
      has necessitated a few changes to the core AT91 support.
      
      These changes are:
            * The system peripheral I/O region we remap has increased from
              0xFFFA0000..0xFFFFFFFF to 0xFFF78000..0xFFFFFFFF.
            * The increased I/O region forces changes to entry-macro.S and
              debug-macro.S due to ARM's limited immediate offset addressing
              modes.
            * Maximum number of GPIO banks increases to 5.
            * 2 MMC controllers so the board-setup code needs to specify which
              controller it wishes to use when calling at91_add_device_mmc().
      
      Original patch from Nicolas Ferre.
      Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d0760b3b
    • A
      [ARM] 4124/1: Rename mach-at91rm9200 and arch-at91rm9200 directories · 9d041268
      Andrew Victor 提交于
      Now that Linux includes support for the Atmel AT91SAM9260 and
      AT91SAM9261 processors in addition to the original Atmel AT91RM9200
      (with support for more AT91 processors pending), the "mach-at91rm9200"
      and "arch-at91rm9200" directories should be renamed to indicate their
      more generic nature.
      
      The following git commands should be run BEFORE applying this patch:
        git-mv arch/arm/mach-at91rm9200 arch/arm/mach-at91
        git-mv include/asm-arm/arch-at91rm9200 include/asm-arm/arch-at91
      Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9d041268
    • A
      [ARM] 4119/1: AT91: Fix build of AT91SAM9260 · a93d48cc
      Andrew Victor 提交于
      Fix build failure of AT91SAM9260.
      
      The AT91RM9200 ethernet driver (at91_ether.c) stores platform data in a
      "struct at91_eth_data" structure, but the AT91SAM9260 (and AT91SAM9263)
      ethernet driver (macb.c) [developed on the AVR32 architecture] expects a
      "struct eth_platform_data".
      
      Since the platform data of the two drivers is very similar, we continue
      to use the "struct at91_eth_data" for all AT91 processors but add a
          #define eth_platform_data      at91_eth_data
      in board.h to keep the MACB driver happy.
      
      Original patch by Jan Altenberg.
      Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a93d48cc
  2. 07 2月, 2007 3 次提交
  3. 26 1月, 2007 1 次提交
  4. 24 1月, 2007 4 次提交
  5. 09 1月, 2007 1 次提交
  6. 06 1月, 2007 1 次提交
  7. 03 1月, 2007 2 次提交
  8. 31 12月, 2006 5 次提交
  9. 18 12月, 2006 11 次提交
  10. 14 12月, 2006 5 次提交
    • P
      [ARM] 3992/1: i.MX/MX1 CPU Frequency scaling support · 3c8cd0cc
      Pavel Pisa 提交于
      Support to change MX1 CPU frequency at runtime.
      Tested on PiKRON's PiMX1 board and seems to be fully
      stable up to 200 MHz end even as low as 8 MHz.
      Signed-off-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3c8cd0cc
    • R
      [ARM] Provide a method to alter the control register · 47fd7052
      Russell King 提交于
      i.MX needs to tweak the control register to support CPU frequency
      scaling.  Rather than have folk blindly try and change the control
      register by writing to it and then wondering why it doesn't work,
      provide a method (which is safe for UP only, and therefore only
      available for UP) to achieve this.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      47fd7052
    • N
      [ARM] 4016/1: prefetch macro is wrong wrt gcc's "delete-null-pointer-checks" · 02828845
      Nicolas Pitre 提交于
       optimization
      
      The gcc manual says:
      
      |`-fdelete-null-pointer-checks'
      |     Use global dataflow analysis to identify and eliminate useless
      |     checks for null pointers.  The compiler assumes that dereferencing
      |     a null pointer would have halted the program.  If a pointer is
      |     checked after it has already been dereferenced, it cannot be null.
      |     Enabled at levels `-O2', `-O3', `-Os'.
      
      Now the problem can be seen with this test case:
      
      #include <linux/prefetch.h>
      extern void bar(char *x);
      void foo(char *x)
      {
      	prefetch(x);
      	if (x)
      		bar(x);
      }
      
      Because the constraint to the inline asm used in the prefetch() macro is
      a memory operand, gcc assumes that the asm code does dereference the
      pointer and the delete-null-pointer-checks optimization kicks in.
      Inspection of generated assembly for the above example shows that bar()
      is indeed called unconditionally without any test on the value of x.
      
      Of course in the prefetch case there is no real dereference and it
      cannot be assumed that a null pointer would have been caught at that
      point. This causes kernel oopses with constructs like
      hlist_for_each_entry() where the list's 'next' content is prefetched
      before the pointer is tested against NULL, and only when gcc feels like
      applying this optimization which doesn't happen all the time with more
      complex code.
      
      It appears that the way to prevent delete-null-pointer-checks
      optimization to occur in this case is to make prefetch() into a static
      inline function instead of a macro. At least this is what is done on
      x86_64 where a similar inline asm memory operand is used (I presume they
      would have seen the same problem if it didn't work) and resulting code
      for the above example confirms that.
      
      An alternative would consist of replacing the memory operand by a
      register operand containing the pointer, and use the addressing mode
      explicitly in the asm template. But that would be less optimal than an
      offsettable memory reference.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      02828845
    • R
      [PATCH] Optimize D-cache alias handling on fork · ec8c0446
      Ralf Baechle 提交于
      Virtually index, physically tagged cache architectures can get away
      without cache flushing when forking.  This patch adds a new cache
      flushing function flush_cache_dup_mm(struct mm_struct *) which for the
      moment I've implemented to do the same thing on all architectures
      except on MIPS where it's a no-op.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ec8c0446
    • R
      [PATCH] PM: Fix SMP races in the freezer · 8a102eed
      Rafael J. Wysocki 提交于
      Currently, to tell a task that it should go to the refrigerator, we set the
      PF_FREEZE flag for it and send a fake signal to it.  Unfortunately there
      are two SMP-related problems with this approach.  First, a task running on
      another CPU may be updating its flags while the freezer attempts to set
      PF_FREEZE for it and this may leave the task's flags in an inconsistent
      state.  Second, there is a potential race between freeze_process() and
      refrigerator() in which freeze_process() running on one CPU is reading a
      task's PF_FREEZE flag while refrigerator() running on another CPU has just
      set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it.  If
      the refrigerator wins the race, freeze_process() will state that PF_FREEZE
      hasn't been set for the task and will set it unnecessarily, so the task
      will go to the refrigerator once again after it's been thawed.
      
      To solve first of these problems we need to stop using PF_FREEZE to tell
      tasks that they should go to the refrigerator.  Instead, we can introduce a
      special TIF_*** flag and use it for this purpose, since it is allowed to
      change the other tasks' TIF_*** flags and there are special calls for it.
      
      To avoid the freeze_process()-refrigerator() race we can make
      freeze_process() to always check the task's PF_FROZEN flag after it's read
      its "freeze" flag.  We should also make sure that refrigerator() will
      always reset the task's "freeze" flag after it's set PF_FROZEN for it.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8a102eed
  11. 13 12月, 2006 1 次提交
    • R
      [ARM] Unuse another Linux PTE bit · ad1ae2fe
      Russell King 提交于
      L_PTE_ASID is not really required to be stored in every PTE, since we
      can identify it via the address passed to set_pte_at().  So, create
      set_pte_ext() which takes the address of the PTE to set, the Linux
      PTE value, and the additional CPU PTE bits which aren't encoded in
      the Linux PTE value.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ad1ae2fe
  12. 11 12月, 2006 2 次提交
    • V
      i2c: New Philips PNX bus driver · 41561f28
      Vitaly Wool 提交于
      New I2C bus driver for Philips ARM boards (Philips IP3204 I2C IP
      block). This I2C controller can be found on (at least) PNX010x,
      PNX52xx and PNX4008 Philips boards.
      Signed-off-by: NVitaly Wool <vitalywool@gmail.com>
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      41561f28
    • S
      [PATCH] spi: stabilize PIO mode transfers on PXA2xx systems · 8d94cc50
      Stephen Street 提交于
      Stabilize PIO mode transfers against a range of word sizes and FIFO
      thresholds and fixes word size setup/override issues.
      
      1) 16 and 32 bit DMA/PIO transfers broken due to timing differences.
      2) Potential for bad transfer counts due to transfer size assumptions.
      3) Setup function broken is multiple ways.
      4) Per transfer bit_per_word changes break DMA setup in pump_tranfers.
      5) False positive timeout are not errors.
      6) Changes in pxa2xx_spi_chip not effective in calls to setup.
      7) Timeout scaling wrong for PXA255 NSSP.
      8) Driver leaks memory while busy during unloading.
      
      Known issues:
      
      SPI_CS_HIGH and SPI_LSB_FIRST settings in struct spi_device are not handled.
      
      Testing:
      
      This patch has been test against the "random length, random bits/word,
      random data (verified on loopback) and stepped baud rate by octaves
      (3.6MHz to 115kHz)" test.  It is robust in PIO mode, using any
      combination of tx and rx thresholds, and also in DMA mode (which
      internally computes the thresholds).
      
      Much thanks to Ned Forrester for exhaustive reviews, fixes and testing.
      The driver is substantially better for his efforts.
      Signed-off-by: NStephen Street <stephen@streetfiresound.com>
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d94cc50
  13. 10 12月, 2006 1 次提交