1. 01 Apr, 2016 1 commit
  2. 14 Mar, 2016 2 commits
  3. 25 Jan, 2016 2 commits
  4. 14 Jan, 2016 2 commits
    • Stephen Warren's avatar
      mmc: store hwpart in the block device · 873cc1d7
      Stephen Warren authored
      
      
      This will allow us to have multiple block device structs each referring
      to the same eMMC device, yet different HW partitions.
      
      For now, there is still a single block device per eMMC device. As before,
      this block device always accesses whichever HW partition was most recently
      selected. Clients wishing to make use of multiple block devices referring
      to different HW partitions can simply take a copy of this block device
      once it points at the correct HW partition, and use each one as they wish.
      This feature will be used by the next patch.
      
      In the future, perhaps get_device() could be enhanced to return a
      dynamically allocated block device struct, to avoid the client needing to
      copy it in order to maintain multiple block devices. However, this would
      require all users to be updated to free those block device structs at some
      point, which is rather a large change.
      
      Most callers of mmc_switch_part() wish to permanently switch the default
      MMC block device's HW partition. Enhance mmc_switch_part() so that it does
      this. This removes the need for callers to do this. However,
      common/env_mmc.c needs to save and restore the current HW partition. Make
      it do this more explicitly.
      
      Replace use of mmc_switch_part() with mmc_select_hwpart() in order to
      remove duplicate code that skips the call if that HW partition is already
      selected.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      873cc1d7
    • Stephen Warren's avatar
      block: pass block dev not num to read/write/erase() · 7c4213f6
      Stephen Warren authored
      
      
      This will allow the implementation to make use of data in the block_dev
      structure beyond the base device number. This will be useful so that eMMC
      block devices can encompass the HW partition ID rather than treating this
      out-of-band. Equally, the existence of the priv field is crying out for
      this patch to exist.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      7c4213f6
  5. 05 Dec, 2015 1 commit
  6. 20 Nov, 2015 1 commit
  7. 23 Feb, 2015 1 commit
  8. 19 Jan, 2015 9 commits
  9. 12 Dec, 2014 1 commit
    • Andrew Gabbasov's avatar
      mmc: Fix handling of bus widths and DDR card capabilities · 786e8f81
      Andrew Gabbasov authored
      
      
      If the MMC_MODE_DDR_52MHz flag is set in card capabilities bitmask,
      it is never cleared, even if switching to DDR mode fails, and if
      the controller driver uses this flag to check the DDR mode, it can
      take incorrect actions.
      
      Also, DDR related checks in mmc_startup() incorrectly handle the case
      when the host controller does not support some bus widths (e.g. can't
      support 8 bits), since the host_caps is checked for DDR bit, but not
      bus width bits.
      
      This fix clearly separates using of card_caps bitmask, having there
      the flags for the capabilities, that the card can support, and actual
      operation mode, described outside of card_caps (i.e. bus_width and
      ddr_mode fields in mmc structure). Separate host controller drivers
      may need to be updated to use the actual flags. Respectively,
      the capabilities checks in mmc_startup are made more correct and clear.
      
      Also, some clean up is made with errors handling and code syntax layout.
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      786e8f81
  10. 03 Oct, 2014 1 commit
  11. 12 Jun, 2014 4 commits
  12. 23 May, 2014 2 commits
    • Stephen Warren's avatar
      cmd_mmc: use new mmc_select_hwpart() function · df348d82
      Stephen Warren authored
      
      
      The implementation of mmc_select_hwpart() was cribbed from do_mmcops().
      Update do_mmcops() to call mmc_select_hwpart() to avoid duplication.
      
      <panto> Manual patch update due to patch order.
      Acked-by: default avatarPantelis Antoniou <panto@antoniou-consulting.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      df348d82
    • Pierre Aubert's avatar
      eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command · 1fd93c6e
      Pierre Aubert authored
      
      
      This sub-command adds support for the RPMB partition of an eMMC:
      * mmc rpmb key <address of the authentication key>
        Programs the authentication key in the eMMC This key can not
        be overwritten.
      * mmc rpmb read <address> <block> <#count> [address of key]
        Reads <#count> blocks of 256 bytes in the RPMB partition
        beginning at block number <block>. If the optionnal
        address of the authentication key is provided, the
        Message Authentication Code (MAC) is verified on each
        block.
      * mmc rpmb write <address> <block> <#count> <address of key>
        Writes <#count> blocks of 256 bytes in the RPMB partition
        beginning at block number <block>. The datas are signed
        with the key provided.
      * mmc rpmb counter
        Returns the 'Write counter' of the RPMB partition.
      
      The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB
      Acked-by: default avatarPantelis Antoniou <panto@antoniou-consulting.com>
      Signed-off-by: default avatarPierre Aubert <p.aubert@staubli.com>
      CC: Wolfgang Denk <wd@denx.de>
      1fd93c6e
  13. 02 Apr, 2014 1 commit
  14. 24 Mar, 2014 1 commit
    • Pantelis Antoniou's avatar
      mmc: Split mmc struct, rework mmc initialization (v2) · 93bfd616
      Pantelis Antoniou authored
      
      
      The way that struct mmc was implemented was a bit of a mess;
      configuration and internal state all jumbled up in a single structure.
      
      On top of that the way initialization is done with mmc_register leads
      to a lot of duplicated code in drivers.
      
      Typically the initialization got something like this in every driver.
      
      	struct mmc *mmc = malloc(sizeof(struct mmc));
      	memset(mmc, 0, sizeof(struct mmc);
      	/* fill in fields of mmc struct */
      	/* store private data pointer */
      	mmc_register(mmc);
      
      By using the new mmc_create call one just passes an mmc config struct
      and an optional private data pointer like this:
      
      	struct mmc = mmc_create(&cfg, priv);
      
      All in tree drivers have been updated to the new form, and expect
      mmc_register to go away before long.
      
      Changes since v1:
      
      * Use calloc instead of manually calling memset.
      * Mark mmc_register as deprecated.
      Signed-off-by: default avatarPantelis Antoniou <panto@antoniou-consulting.com>
      93bfd616
  15. 07 Feb, 2014 5 commits
  16. 09 Jan, 2014 1 commit
    • Markus Niebel's avatar
      mmc: add setdsr support · ab71188c
      Markus Niebel authored
      
      
      The eMMC and the SD-Card specifications describe the optional SET_DSR command.
      During measurements at our lab we found that some cards implementing this feature
      having really strong driver strengts per default. This can lead to voltage peaks
      above the specification of the host on signal edges for data sent from a card to
      the host.
      
      Since availability of a given card type may be shorter than the time a certain
      hardware will be produced it is useful to have support for this command (Alternative
      would be changing termination resistors and adapting the driver strength of the
      host to the used card.)
      
      Following proposal for an implementation:
      
      - new field that reflects CSD field DSR_IMP in struct mmc
      - new field for design specific DSR value in struct mmc
      - board code can set DSR value in mmc struct just after registering an controller
      - mmc_startup sends the the stored DSR value before selecting a card, if DSR_IMP is set
      
      Additionally the mmc command is extended to make is possible to play around with different
      DSR values.
      
      The concept was tested on a i.MX53 based platform using a Micron eMMC card where the default
      DSR is 0x0400 (12mA) but in our design 0x0100 (0x0100) were enough. To use this feature for
      instance on a mx53loco one have to add a call to mmc_set_dsr() in board_mmc_init() after
      calling fsl_esdhc_initialize() for the eMMC.
      Signed-off-by: default avatarMarkus Niebel <Markus.Niebel@tqs.de>
      Acked-by: default avatarPantelis Antoniou <panto@antoniou-consulting.com>
      ab71188c
  17. 20 Sep, 2013 1 commit
  18. 24 Jul, 2013 1 commit
  19. 13 Jun, 2013 1 commit
  20. 17 Apr, 2013 1 commit
  21. 02 Apr, 2013 1 commit
    • Stephen Warren's avatar
      mmc: don't allow extra cmdline arguments · 9fd38372
      Stephen Warren authored
      
      
      The "mmc rescan" command takes no arguments. However, executing
      "mmc rescan 1" succeeds, leading the user to believe that MMC device 1
      has been rescanned. In fact, the "current" MMC device has been
      rescanned, and the current device may well not be 1. Add error-checking
      to the "mmc" command to explicitly reject any extra command-line
      arguments so that it's more obvious when U-Boot isn't doing what the
      user thought they asked it to.
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      9fd38372