1. 11 Oct, 2015 18 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 11 commits
  8. 02 Oct, 2015 1 commit