Skip to content
  1. Nov 12, 2014
  2. Nov 11, 2014
  3. Nov 04, 2014
    • Tony Lindgren's avatar
      ARM: dts: Fix missing GPMC NAND device width for omap3 boards · 24f284af
      Tony Lindgren authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      24f284af
    • Tony Lindgren's avatar
      ARM: dts: Use better omap GPMC timings for LAN9220 · 13aec8e4
      Tony Lindgren authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      13aec8e4
  4. Oct 30, 2014
    • Tony Lindgren's avatar
      ARM: dts: Add GPMC timings for omap zoom serial port · b5399ea8
      Tony Lindgren authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      b5399ea8
    • Tony Lindgren's avatar
      ARM: dts: Add smc91x GPMC configuration for 2430sdp · 1bb37404
      Tony Lindgren authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      1bb37404
    • Tony Lindgren's avatar
      ARM: dts: Fix wrong GPMC size mappings for omaps · e2c5eb78
      Tony Lindgren authored
      
      
      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: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e2c5eb78
    • Tony Lindgren's avatar
      ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins · 9a894953
      Tony Lindgren authored
      
      
      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: default avatarTony Lindgren <tony@atomide.com>
      9a894953
  5. Oct 25, 2014
  6. Oct 24, 2014
  7. Oct 23, 2014
  8. Oct 22, 2014
    • Boris Brezillon's avatar
      ARM: at91/dt: sam9263: fix PLLB frequencies · 106c67af
      Boris Brezillon authored
      
      
      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: default avatarAndreas Henriksson <andreas.henriksson@endian.se>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Tested-by: default avatarAndreas Henriksson <andreas.henriksson@endian.se>
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      106c67af
    • Dinh Nguyen's avatar
      arm: socfpga: fix fetching cpu1start_addr for SMP · 3a4356c0
      Dinh Nguyen authored
      
      
      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: default avatarDinh 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