1. 05 Sep, 2014 2 commits
  2. 31 Aug, 2014 14 commits
  3. 30 Aug, 2014 7 commits
  4. 29 Aug, 2014 2 commits
  5. 25 Aug, 2014 3 commits
  6. 20 Aug, 2014 3 commits
  7. 19 Aug, 2014 1 commit
  8. 18 Aug, 2014 2 commits
  9. 12 Aug, 2014 6 commits
    • Siarhei Siamashka's avatar
      sunxi: dram: Autodetect DDR3 bus width and density · bf4ca384
      Siarhei Siamashka authored
      
      
      In the case if the 'dram_para' struct does not specify the exact bus
      width or chip density, just use a trial and error method to find a
      usable configuration.
      
      Because all the major bugs in the DRAM initialization sequence are
      now hopefully fixed, it should be safe to re-initialize the DRAM
      controller multiple times until we get it configured right. The
      original Allwinner's boot0 bootloader also used a similar
      autodetection trick.
      
      The DDR3 spec contains the package pinout and addressing table for
      different possible chip densities. It appears to be impossible to
      distinguish between a single chip with 16 I/O data lines and a pair
      of chips with 8 I/O data lines in the case if they provide the same
      storage capacity. Because a single 16-bit chip has a higher density
      than a pair of equivalent 8-bit chips, it has stricter refresh timings.
      So in the case of doubt, we assume that 16-bit chips are used.
      Additionally, only Allwinner A20 has all A0-A15 address lines and
      can support densities up to 8192. The older Allwinner A10 and
      Allwinner A13 can only support densities up to 4096.
      
      We deliberately leave out DDR2, dual-rank configurations and the
      special case of a 8-bit chip with density 8192. None of these
      configurations seem to have been ever used in real devices. And no
      new devices are likely to use these exotic configurations (because
      only up to 2GB of RAM can be populated in any case).
      
      This DRAM autodetection feature potentially allows to have a single
      low performance fail-safe DDR3 initialiazation for a universal single
      bootloader binary, which can be compatible with all Allwinner
      A10/A13/A20 based devices (if the ifdefs are replaced with a runtime
      SoC type detection).
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      bf4ca384
    • Siarhei Siamashka's avatar
      sunxi: dram: Derive write recovery delay from DRAM clock speed · 935758b1
      Siarhei Siamashka authored
      
      
      The write recovery time is 15ns for all JEDEC DDR3 speed bins. And
      instead of hardcoding it to 10 cycles, it is possible to set tighter
      timings based on accurate calculations. For example, DRAM clock
      frequencies up to 533MHz need only 8 cycles for write recovery.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      935758b1
    • Siarhei Siamashka's avatar
      sunxi: dram: Drop DDR2 support and assume only single rank DDR3 memory · b5c71f5f
      Siarhei Siamashka authored
      
      
      All the known Allwinner A10/A13/A20 devices are using just single rank
      DDR3 memory. So don't pretend that we support DDR2 or more than one
      rank, because nobody could ever test these configurations for real and
      they are likely broken. Support for these features can be added back
      in the case if such hardware actually exists.
      
      As part of this code cleanup, also replace division by 1024 with
      division by 1000 for the refresh timing calculations. This allows
      to use the original non-skewed tRFC timing table from the DRR3 spec
      and make code less confusing.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      b5c71f5f
    • Siarhei Siamashka's avatar
      sunxi: dram: Configurable DQS gating window mode and delay · d755a5fb
      Siarhei Siamashka authored
      
      
      The hardware DQS gate training is a bit unreliable and does not
      always find the best delay settings.
      
      So we introduce a 32-bit 'dqs_gating_delay' variable, where each
      byte encodes the DQS gating delay for each byte lane. The delay
      granularity is 1/4 cycle.
      
      Also we allow to enable the active DQS gating window mode, which
      works better than the passive mode in practice. The DDR3 spec
      says that there is a 0.9 cycles preamble and 0.3 cycle postamble.
      The DQS window has to be opened during preamble and closed during
      postamble. In the passive window mode, the gating window is opened
      and closed by just using the gating delay settings. And because
      of the 1/4 cycle delay granularity, accurately hitting the 0.3
      cycle long postamble is a bit tough. In the active window mode,
      the gating window is auto-closing with the help of monitoring
      the DQS line, which relaxes the gating delay accuracy requirements.
      
      But the hardware DQS gate training is still performed in the passive
      window mode. It is a more strict test, which is reducing the results
      variance compared to the training with active window mode.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      d755a5fb
    • Siarhei Siamashka's avatar
      sunxi: dram: Add a helper function 'mctl_get_number_of_lanes' · e044daa3
      Siarhei Siamashka authored
      
      
      It is going to be useful in more than one place.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      e044daa3
    • Siarhei Siamashka's avatar
      sunxi: dram: Improve DQS gate data training error handling · b8f7cb6a
      Siarhei Siamashka authored
      
      
      The stale error status should be cleared for all sun4i/sun5i/sun7i
      hardware and not just for sun7i. Also there are two types of DQS
      gate training errors ("found no result" and "found more than one
      possible result"). Both are handled now.
      Signed-off-by: default avatarSiarhei Siamashka <siarhei.siamashka@gmail.com>
      Acked-by: default avatarIan Campbell <ijc@hellion.org.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      b8f7cb6a