1. 12 11月, 2014 1 次提交
  2. 11 11月, 2014 18 次提交
  3. 04 11月, 2014 2 次提交
    • T
      ARM: dts: Fix missing GPMC NAND device width for omap3 boards · 24f284af
      Tony Lindgren 提交于
      Looks like we have some GPMC NAND timings missing device
      width. This fixes "gpmc_cs_program_settings: invalid width 0!"
      errors during boot.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      24f284af
    • T
      ARM: dts: Use better omap GPMC timings for LAN9220 · 13aec8e4
      Tony Lindgren 提交于
      With the GPMC warnings now enabled, I noticed the LAN9220 timings
      can overflow the GPMC registers with 200MHz L3 speed. Earlier we
      were just skipping the bad timings and would continue with the
      bootloader timings. Now we no longer allow to continue with bad
      timings as we have the timings in the .dts files.
      
      We could start using the GPMC clock divider, but let's instead
      use the u-boot timings that are known to be working and a bit
      faster. These are basically the u-boot NET_GPMC_CONFIG[1-6]
      defines deciphered. Except that we don't set gpmc,burst-length
      as that's only partially configured and does not seem to work
      if fully enabled.
      
      [tony@atomide.com: updated to remove gpmc,burst-length]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      13aec8e4
  4. 30 10月, 2014 4 次提交
    • T
      ARM: dts: Add GPMC timings for omap zoom serial port · b5399ea8
      Tony Lindgren 提交于
      The four port serial port on the zoom debug board uses a TL16CP754C
      with a single interrupt and GPMC chip select. The serial ports each
      use a 8 bytes for IO registers, and are 256 bytes apart on the GPMC
      line.
      
      Let's add timings for all four ports so we can remove the GPMC
      workarounds for using bootloader timings.
      
      Not caused by this patch, but looks like u-boot only properly
      initializes the fifo on the first serial port. Currently the other
      ports produce garbage at least with my version of u-boot. I suspect
      that TL16CP754C needs non-standard initialization added to 8250
      driver to properly fix this issue.
      
      Cc: Roger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b5399ea8
    • T
      ARM: dts: Add smc91x GPMC configuration for 2430sdp · 1bb37404
      Tony Lindgren 提交于
      Let's use the bootloader values except for the partially configured
      wait-pin that does not seem to work.
      
      Cc: Roger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      1bb37404
    • T
      ARM: dts: Fix wrong GPMC size mappings for omaps · e2c5eb78
      Tony Lindgren 提交于
      The GPMC binding is obviously very confusing as the values
      are all over the place. People seem to confuse the GPMC partition
      size for the chip select, and the device IO size within the GPMC
      partition easily.
      
      The ranges entry contains the GPMC partition size. And the
      reg entry contains the size of the IO registers of the
      device connected to the GPMC.
      
      Let's fix the issue according to the following table:
      
      Device          GPMC partition size     Device IO size
      connected       in the ranges entry     in the reg entry
      
      NAND            0x01000000 (16MB)       4
      16550           0x01000000 (16MB)       8
      smc91x          0x01000000 (16MB)       0xf
      smc911x         0x01000000 (16MB)       0xff
      OneNAND         0x01000000 (16MB)       0x20000 (128KB)
      16MB NOR        0x01000000 (16MB)       0x01000000 (16MB)
      32MB NOR        0x02000000 (32MB)       0x02000000 (32MB)
      64MB NOR        0x04000000 (64MB)       0x04000000 (64MB)
      128MB NOR       0x08000000 (128MB)      0x08000000 (128MB)
      256MB NOR       0x10000000 (256MB)      0x10000000 (256MB)
      
      Let's also add comments to the fixed entries while at it.
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e2c5eb78
    • T
      ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins · 9a894953
      Tony Lindgren 提交于
      Apparently some versions of nolo don't mux the all the necessary GPMC
      pins for the smc91x probe to work properly. Let's fix this issue
      by adding mux support for GPMC to the kernel.
      
      Note that GPMC clk needs input enabled for OnenNAND to work.
      
      Cc: Kevin Hilman <khilman@kernel.org>
      Cc: Roger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      9a894953
  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 1 次提交
  10. 20 10月, 2014 5 次提交