1. 11 Oct, 2015 29 commits
  2. 10 Oct, 2015 2 commits
  3. 09 Oct, 2015 1 commit
  4. 08 Oct, 2015 3 commits
  5. 07 Oct, 2015 1 commit
    • Alexey Brodkin's avatar
      board: axs10x - cap max SDIO clock value to bus/2 · f6e27ba5
      Alexey Brodkin authored
      It turned out with some boards (FPGA firmwares?) and cards combos
      current clock settings doesn't work as expected leading to strange
      card freezes or corrupted data being read from the card.
      
      Especially this was seen with Transcend 2Gb cards shipped as a part of
      ARC SDP:
      ----------------->8---------------
      AXS# mmcinfo
      Device: Synopsys Mobile storage
      Manufacturer ID: 74
      OEM: 4a60
      Name: SDC
      Tran Speed: 50000000
      Rd Block Len: 512
      SD version 3.0
      High Capacity: No
      Capacity: 1.8 GiB
      Bus Width: 4-bit
      Erase Group Size: 512 Bytes
      AXS# fatload mmc 0
      ** Unrecognized filesystem type **
      ----------------->8---------------
      
      With this change that problem is fixed.
      Note "Tran Speed" above doesn't match clock value set in DW MMC.
      It is max value for card's speed class.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      f6e27ba5
  6. 05 Oct, 2015 3 commits
    • Simon Glass's avatar
      sandbox: Correct operaion of 'reset' command · 7bb91dd1
      Simon Glass authored
      Currently 'reset' only works with the test device tree. When run without a
      device tree, or with the normal device tree, the following error is
      displayed:
      
         Reset not supported on this platform
      
      Fix the driver and the standard device tree to avoid this.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reported-by: default avatarStephen Warren <swarren@nvidia.com>
      Tested-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      7bb91dd1
    • Simon Glass's avatar
      dm: test: Show the amount of leaked memory on error · cbfc2ff9
      Simon Glass authored
      Adjust the memory leak tests to show the amount of memory leaked. This can
      be a useful signal as to what is wrong.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      cbfc2ff9
    • Simon Glass's avatar
      dm: core: Don't use pinctrl for the root device · 84d26e29
      Simon Glass authored
      Currently when driver model starts up it finds the root uclass and the
      pinctrl uclass. This is because even the root node handles pinctrl
      processing.
      
      But this is not useful. The root node is not a real hardware device so
      cannot require any particular pinmux settings. Also it means that the
      memory leak tests fails, since they end up freeing more memory than
      they allocate: the marker it set after the root device and pinctrl
      uclass are allocated, and later once the pinctrl uclass is freed the memory
      used by driver model is less than when the marker was set.
      
      If a platform needs 'core' pin mulitplex settings it can do this with
      a driver that is probed on start-up. It would be an abuse of the root node
      to use this for pinctrl.
      
      To avoid this problem, only process pinctrl settings for non-root nodes.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      84d26e29
  7. 03 Oct, 2015 1 commit
    • Sjoerd Simons's avatar
      rockchip: Reconfigure the malloc based to point to system memory · b1f492ca
      Sjoerd Simons authored
      When malloc_base initially gets setup in the SPL it is based on the
      current (early) stack pointer, which for rockchip is pointing into SRAM.
      This means simple memory allocations happen in SRAM space, which is
      somewhat unfortunate. Specifically a bounce buffer for the mmc allocated
      in SRAM space seems to cause the mmc engine to stall/fail causing
      timeouts and a failure to load the main u-boot image.
      
      To resolve this, reconfigure the malloc_base to start at the relocated
      stack pointer after DRAM  has been setup.
      
      For reference, things did work fine on rockchip before 596380db was
      merged to fix memalign_simple due to a combination of rockchip SDRAM
      starting at address 0 and the dw_mmc driver not checking errors from
      bounce_buffer_start. As a result, when a bounce buffer needed to be
      allocated mem_align simple would fail and return NULL. The mmc driver
      ignored the error and happily continued with the bounce buffer address
      being set to 0, which just happened to work fine..
      Signed-off-by: default avatarSjoerd Simons <sjoerd.simons@collabora.co.uk>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      b1f492ca