1. 22 11月, 2014 9 次提交
  2. 01 11月, 2014 1 次提交
  3. 30 10月, 2014 3 次提交
    • T
      ARM: 8180/1: mm: implement no-highmem fast path in kmap_atomic_pfn() · 9ff0bb5b
      Thomas Petazzoni 提交于
      Since CONFIG_HIGHMEM got enabled on ARMv5 Kirkwood, we have noticed a
      very significant drop in networking performance. The test were
      conducted on an OpenBlocks A7 board. Without this patch, the outgoing
      performance measured with iperf are:
      
       - highmem OFF, TSO OFF   544 Mbit/s
       - highmem OFF, TSO ON	  942 Mbit/s
       - highmem ON,  TSO OFF   306 Mbit/s
       - highmem ON,  TSO ON    246 Mbit/s
      
      On this Kirkwood platform, the L2 cache is a Feroceon cache, and with
      this cache, all the range operations have to be done on virtual
      addresses and not physical addresses. Therefore, whenever
      CONFIG_HIGHMEM is enabled, the cache maintenance operations call
      kmap_atomic_pfn() and kunmap_atomic().
      
      However, kmap_atomic_pfn() does not implement the same fast path for
      non-highmem pages as the one implemented in kmap_atomic(), and this is
      one of the reason for the performance drop. While this patch does not
      fully restore the performances, it clearly improves them a lot:
      
            	      	        without patch  with patch
      
       - highmem ON, TSO OFF   306 Mbit/s     387 Mbit/s
       - highmem ON, TSO ON    246 Mbit/s     434 Mbit/s
      
      We're still far from the !CONFIG_HIGHMEM performances, but it does
      improve a bit the situation.
      
      Thanks a lot to Ezequiel Garcia and Gregory Clement for all the
      testing work around this topic.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9ff0bb5b
    • F
      ARM: 8183/1: l2c: Improve l2c310_of_parse() error message · 6d0ec1dd
      Fabio Estevam 提交于
      Russell King suggested [1]:
      
      "I'd ask for one change.  Please make all these messages start with
      "L2C-310 OF" not "PL310 OF:".  The device is described in ARM
      documentation as a L2C-310 not PL310.  (Also note the : is dropped
      too - most of the other messages don't have the : either.)
      
      The:
      
      "PL310 OF: cache setting yield illegal associativity
      PL310 OF: -1073346556 calculated, only 8 and 16 legal"
      
      message could also be changed to something like:
      
      "L2C-310 OF cache associativity %d invalid, only 8 or 16 permittedn"
      
      [1] http://www.spinics.net/lists/arm-kernel/msg372776.htmlSigned-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6d0ec1dd
    • L
      ARM: 8181/1: Drop extra return statement · 00575729
      Laura Abbott 提交于
      Commit 513510dd
      (common: dma-mapping: introduce common remapping functions)
      managed to end up with an extra return statement from the
      original patch. Drop it.
      Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      00575729
  4. 29 10月, 2014 2 次提交
  5. 25 10月, 2014 2 次提交
  6. 24 10月, 2014 2 次提交
  7. 23 10月, 2014 3 次提交
  8. 22 10月, 2014 2 次提交
    • B
      ARM: at91/dt: sam9263: fix PLLB frequencies · 106c67af
      Boris Brezillon 提交于
      PLLB input and output ranges were wrongly copied from at91sam9261 as the
      datasheet didn't mention explicitly PLLB. Correct their values.
      
      This fixes USB.
      Reported-by: NAndreas Henriksson <andreas.henriksson@endian.se>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Tested-by: NAndreas Henriksson <andreas.henriksson@endian.se>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      106c67af
    • D
      arm: socfpga: fix fetching cpu1start_addr for SMP · 3a4356c0
      Dinh Nguyen 提交于
      When CPU1 is brought out of reset, it's MMU is not turned on yet, so it will
      only be able to use physical addresses. For systems with that have the
      MMU page configured for 0xC0000000, 0x80000000, or 0x40000000
      "BIC 0x40000000" will work just fine, as it was just converting the
      virtual address of &cpu1start_addr into a physical address, ie. 0xC0000000
      became 0x80000000. So for systems where the SDRAM controller was able to do a
      wrap-around access, this was working fine, as it was just dropping the MSB,
      but for systems where out of bounds memory access is not allowed, this would
      not allow CPU1 to correctly fetch &cpu1start_addr.
      
      This patch fixes the secondary_trampoline code to correctly fetch the
      physical address of cpu1start_addr directly. The patch will subtract the
      correct PAGE_OFFSET from &cpu1start_addr. And since on this platform, the
      physical memory will always start at 0x0, subtracting PAGE_OFFSET from
      &cpu1start_addr will allow CPU1 to correctly fetch the value of cpu1start_addr.
      
      While at it, change the name of cpu1start_addr to socfpga_cpu1start_addr
      to avoid any future naming collisions for multiplatform image.
      Signed-off-by: NDinh Nguyen <dinguyen@opensource.altera.com>
      ---
      v4: Updated commit log to correctly lay out the usage of PAGE_OFFSET and
          add comments to the same effect.
      v3: Used PAGE_OFFSET to get the physical address
      v2: Correctly get the physical address instead of just a BIC hack.
      3a4356c0
  9. 21 10月, 2014 2 次提交
  10. 20 10月, 2014 7 次提交
  11. 19 10月, 2014 1 次提交
    • R
      ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854 · 7fc15054
      Russell King 提交于
      These stock GCC versions miscompile the kernel by incorrectly optimising
      the function epilogue code - by first increasing the stack pointer, and
      then loading entries from below the stack.  This means that an opportune
      interrupt or exception will corrupt the current function's saved state,
      which may result in the parent function seeing different register
      values.
      
      As this bug has been known to result in corrupted filesystems, and these
      buggy compiler versions seem to be frequently used, we have little
      option but to blacklist these compiler versions.
      
      Distributions may have fixed PR58854, but as their compilers are totally
      indistinguishable from the buggy versions, it is unfortunate that this
      also results in those also being blacklisted.  Given the filesystem
      corruption potential of the original, this is the lesser evil.  People
      who want to build with their fixed compiler versions will need to adjust
      the kernel source.  (Distros need to think about the implications of
      fixing such a compiler bug, and consider how to ensure that their fixed
      compiler versions can be detected if they wish to avoid this.)
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7fc15054
  12. 17 10月, 2014 2 次提交
  13. 16 10月, 2014 4 次提交