| #
1b26bab1 |
| 29-May-2015 |
Daniel Kochmański <dkochmanski@turtle-solutions.eu> |
mmc: Protect `mmc_initialize` from initialising mmc multiple times
`mmc_initialize` might be called multiple times leading to the mmc-controllers being initialised twice, and initialising the `mmc_d
mmc: Protect `mmc_initialize` from initialising mmc multiple times
`mmc_initialize` might be called multiple times leading to the mmc-controllers being initialised twice, and initialising the `mmc_devices` list head twice which may lead to memory leaks.
Signed-off-by: Daniel Kochmański <dkochmanski@turtle-solutions.eu> CC: Roy Spliet <r.spliet@ultimaker.com> Cc: Ian Campbell <ijc@hellion.org.uk> CC: Pantelis Antoniou <panto@antoniou-consulting.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
show more ...
|
| #
11692991 |
| 23-Jun-2015 |
Simon Glass <sjg@chromium.org> |
mmc: Add debug() output on read errors
Allow read errors to be diagnosed more easily.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
| #
e7ecf7cb |
| 23-Jun-2015 |
Simon Glass <sjg@chromium.org> |
dm: mmc: Add an MMC uclass
Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model.
Signed-off-by: Simon Glass <sjg@chrom
dm: mmc: Add an MMC uclass
Add basic support for MMC, providing a uclass which can set up an MMC device. This allows MMC drivers to move to using driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
show more ...
|
| #
d81572c2 |
| 05-May-2015 |
Tom Rini <trini@konsulko.com> |
Merge git://git.denx.de/u-boot-mpc85xx
|
| #
ff7e9cfc |
| 05-May-2015 |
Tom Rini <trini@konsulko.com> |
Merge branch 'master' of git://git.denx.de/u-boot-mmc
|
| #
5a20397b |
| 23-Mar-2015 |
Rob Herring <robh@kernel.org> |
mmc: remove the MMC_MODE_HC flag
High capacity support is not a host capability, but a device capability that is queried via the OCR. The flag in the operating conditions request argument can just b
mmc: remove the MMC_MODE_HC flag
High capacity support is not a host capability, but a device capability that is queried via the OCR. The flag in the operating conditions request argument can just be set unconditionally. This matches the Linux implementation.
[panto] Hand merged and renumbering MMC_MODE_DDR_52MHz.
Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
show more ...
|
| #
bd47c135 |
| 19-Mar-2015 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Fix splitting device initialization
Starting part of device initialization sets the init_in_progress flag only if the MMC card did not yet come to ready state and needs to continue polling. If
mmc: Fix splitting device initialization
Starting part of device initialization sets the init_in_progress flag only if the MMC card did not yet come to ready state and needs to continue polling. If the card is SD or if the MMC card became ready quickly, the flag is not set and (if using pre-initialization) the starting phase will be re-executed from mmc_init function.
Set the init_in_progress flag in all non-error cases. Also, move flags setting statements around so that the flags are not set in error paths. Also, IN_PROGRESS return status becomes unnecessary, so get rid of it.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
show more ...
|
| #
1677eef4 |
| 19-Mar-2015 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Restructure polling loops to avoid extra delays
The polling loops in sd_send_op_cond and mmc_complete_op_cond functions check the ready flag state at the end of the loop, that is after executin
mmc: Restructure polling loops to avoid extra delays
The polling loops in sd_send_op_cond and mmc_complete_op_cond functions check the ready flag state at the end of the loop, that is after executing a delay inside the loop, which, in case of exiting with no error, is not needed. Also, one of these loops, as well as the loop in mmc_send_status, have the delay just before exiting on timeout conditions.
Restructure all these loops to check the respective conditions before making a delay for the next loop pass, and to appropriately exit without the delay.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
show more ...
|
| #
cc17c01f |
| 19-Mar-2015 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Continue polling MMC card for OCR only if it is still not ready
Some MMC cards come to ready state quite quickly, so that the respective flag appears to be set in mmc_send_op_cond already. In t
mmc: Continue polling MMC card for OCR only if it is still not ready
Some MMC cards come to ready state quite quickly, so that the respective flag appears to be set in mmc_send_op_cond already. In this case trying to continue polling the card with CMD1 in mmc_complete_op_cond is incorrect and may lead to unpredictable results. So check the flag before polling and skip it appropriately.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
show more ...
|
| #
5289b535 |
| 19-Mar-2015 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()
The previous change to use 'ocr' structure field for storing send_op_cond command response also stopped using command response
mmc: Do not pass external mmc_cmd structure to mmc_send_op_cond_iter()
The previous change to use 'ocr' structure field for storing send_op_cond command response also stopped using command response directly outside of mmc_send_op_cond_iter(). Now it becomes possible to use command structure in mmc_send_op_cond_iter() locally, removing a necessity to pass it as an argument from the caller.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
show more ...
|
| #
a626c8d4 |
| 19-Mar-2015 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Avoid extra duplicate entry in mmc device structure
The 'op_cond_response' field in mmc structure contains the response from the last SEND_OP_COND MMC command while making iterational polling o
mmc: Avoid extra duplicate entry in mmc device structure
The 'op_cond_response' field in mmc structure contains the response from the last SEND_OP_COND MMC command while making iterational polling of the card. Later it is copied to 'ocr' field, designed to contain the OCR register value, which is actually the same response from the same command. So, these fields have actually the same data, just in different time periods. It's easier to use the same 'ocr' field in both cases at once, without temporary using of the 'op_cond_response' field.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
show more ...
|
| #
5a8dbdc6 |
| 22-Apr-2015 |
Yangbo Lu <yangbo.lu@freescale.com> |
mmc: fsl_esdhc: Add adapter card type identification support
Add adapter card type identification support by reading FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function, define CON
mmc: fsl_esdhc: Add adapter card type identification support
Add adapter card type identification support by reading FPGA STAT_PRES1 register SDHC Card ID[0:2] bits. To use this function, define CONFIG_FSL_ESDHC_ADAPTER_IDENT.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com> Cc: York Sun <yorksun@freescale.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> [York Sun: resolve conflicts in README.fsl-esdhc] Reviewed-by: York Sun <yorksun@freescale.com>
show more ...
|
| #
b9cb6482 |
| 02-Mar-2015 |
Stefano Babic <sbabic@denx.de> |
Merge branch 'master' of git://git.denx.de/u-boot
|
| #
e1cc4d31 |
| 24-Feb-2015 |
Albert ARIBAUD <albert.u.boot@aribaud.net> |
Merge remote-tracking branch 'u-boot/master' into 'u-boot-arm/master'
|
| #
38dac81b |
| 23-Feb-2015 |
Tom Rini <trini@ti.com> |
Merge branch 'master' of git://git.denx.de/u-boot-mmc
|
| #
34dd9284 |
| 20-Feb-2015 |
Przemyslaw Marczak <p.marczak@samsung.com> |
mmc: print SD/eMMC type for inited mmc devices
Depending on the boot priority, the eMMC/SD cards, can be initialized with the same numbers for each boot.
To be sure which mmc device is SD and which
mmc: print SD/eMMC type for inited mmc devices
Depending on the boot priority, the eMMC/SD cards, can be initialized with the same numbers for each boot.
To be sure which mmc device is SD and which is eMMC, this info is printed by 'mmc list' command, when the init is done.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
show more ...
|
| #
e72d3443 |
| 13-Feb-2015 |
Stefano Babic <sbabic@denx.de> |
Merge branch 'master' of git://git.denx.de/u-boot
|
| #
1cd20006 |
| 20-Jan-2015 |
Tom Rini <trini@ti.com> |
Merge branch 'master' of git://git.denx.de/u-boot-mmc
|
| #
fc5b32fb |
| 25-Dec-2014 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Skip changing bus width for MMC cards earlier than version 4.0
Wider bus widths (larger than default 1 bit) appeared in MMC standard version 4.0. So, for MMC cards of any earlier version trying
mmc: Skip changing bus width for MMC cards earlier than version 4.0
Wider bus widths (larger than default 1 bit) appeared in MMC standard version 4.0. So, for MMC cards of any earlier version trying to change the bus width (including ext_csd comparison) does not make any sense. It may work incorrectly and at least cause unnecessary timeouts. So, just skip the entire bus width related activity for earlier versions.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
show more ...
|
| #
bf477073 |
| 25-Dec-2014 |
Andrew Gabbasov <andrew_gabbasov@mentor.com> |
mmc: Avoid redundant switching to 1-bit bus width for MMC cards
If all the commands switching an MMC card to 4- or 8-bit bus width fail, and the bus width for the controller and the driver is still
mmc: Avoid redundant switching to 1-bit bus width for MMC cards
If all the commands switching an MMC card to 4- or 8-bit bus width fail, and the bus width for the controller and the driver is still set to default 1 bit, there is no need to send one more command to switch the card to 1-bit bus width. Also, if the card or host controller do not support wider bus widths, there is no need to send a switch command at all.
However, if one of switch commands succeeds, but the subsequent ext_csd fields comparison fails, the card should be switched to some other bus width (next in the list for the loop), or to default 1-bit bus width as a last resort. That's why it would be incorrect to just remove the 1-bit bus width case from the list, it should still be processed in some cases.
panto: Minor cosmetic edit removing superfluous parentheses.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Tested-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
show more ...
|
| #
9e41a00b |
| 23-Dec-2014 |
Diego Santa Cruz <Diego.SantaCruz@spinetix.com> |
mmc: extend mmcinfo output to show partition write reliability settings
This extends the mmcinfo hardware partition info output to show partitions with write reliability enabled with the "WRREL" str
mmc: extend mmcinfo output to show partition write reliability settings
This extends the mmcinfo hardware partition info output to show partitions with write reliability enabled with the "WRREL" string. If the partition does not have write reliability enabled the "WRREL" string is omitted; this is analogous to the ehhanced attribute.
Example output:
Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit Erase Group Size: 8 MiB HC WP Group Size: 16 MiB User Capacity: 13.8 GiB ENH WRREL User Enhanced Start: 0 Bytes User Enhanced Size: 512 MiB Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH GP1 Capacity: 64 MiB ENH WRREL GP2 Capacity: 64 MiB ENH WRREL
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
show more ...
|
| #
8dda5b0e |
| 23-Dec-2014 |
Diego Santa Cruz <Diego.SantaCruz@spinetix.com> |
mmc: extend the mmc hardware partitioning API with write reliability
The eMMC partition write reliability settings are to be set while partitioning a device, as per the eMMC spec, so changes to thes
mmc: extend the mmc hardware partitioning API with write reliability
The eMMC partition write reliability settings are to be set while partitioning a device, as per the eMMC spec, so changes to these attributes needs to be done in the hardware partitioning API. This commit adds such support.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
show more ...
|
| #
ac9da0e0 |
| 23-Dec-2014 |
Diego Santa Cruz <Diego.SantaCruz@spinetix.com> |
mmc: add API to do eMMC hardware partitioning
This adds an API to do hardware partitioning on eMMC devices. The new mmc_hwpart_config() function does the partitioning in one go. As the different att
mmc: add API to do eMMC hardware partitioning
This adds an API to do hardware partitioning on eMMC devices. The new mmc_hwpart_config() function does the partitioning in one go. As the different attributes and partitioning options on eMMC may be interdependent validation has to be done based on the complete partitioning configuration. The function accepts three modes:
- MMC_HWPART_CONF_CHECK: just validates that the configuration is valid. - MMC_HWPART_CONF_SET: validates and sets all the fields in EXT_CSD but without setting the "partitioning completed" bit, and thus is reversible. - MMC_HWPART_CONF_COMPLETE: does everything and is thus not reversible.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
show more ...
|
| #
9cf199eb |
| 23-Dec-2014 |
Diego Santa Cruz <Diego.SantaCruz@spinetix.com> |
mmc: the ext_csd data may be used during init even if reading failed
The mmc_startup() function uses the ext_csd data even if reading it from the mmc device failed. This bug was introduced in commit
mmc: the ext_csd data may be used during init even if reading failed
The mmc_startup() function uses the ext_csd data even if reading it from the mmc device failed. This bug was introduced in commit bc897b1d4d86597311430dbe7b3e6c807c8c53e5. We now bail out if reading it fails, this should not be a problem as ext_csd was introduced in MMC 4.0 and this code is conditional on MMC >= 4.0.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
show more ...
|
| #
8a0cf490 |
| 23-Dec-2014 |
Diego Santa Cruz <Diego.SantaCruz@spinetix.com> |
mmc: eMMC partitioning data is not effective till partitioning completed
The eMMC spec says that partitioning is only effective after the PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power c
mmc: eMMC partitioning data is not effective till partitioning completed
The eMMC spec says that partitioning is only effective after the PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done, but that we cannot know). Thus the partition sizes and attributes should be ignored when that bit is not set, otherwise the various capacities are not coherent (e.g., the user data capacity will be that of the unpartitioned device while partition sizes would be non-zero).
Prescence of non-zero partitioning data is nevertheless still used to activate the high-capacity size definitions (EXT_CSD_ERASE_GROUP_DEF) as it is necessary to set that to write any of the partitioning fields in EXT_CSD, so having partitioning data means someone previously activated that and we should keep it activated.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
show more ...
|