At present we add driver-model MMC devices in the order we find them. The
'alias' order is not honoured.
It is difficult to fix this for the case where we have holes in the
sequence. But for the common case where the devices are numbered from 0
without any gaps, we can add the devices to the internal data structures
in this order.
Signed-off-by: Simon Glass <sjg@chromium.org>
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: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
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: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
There is no sprintf implementation in tiny-printf, so don't try to use
it when tiny-printf if used.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Now that we have a new header file for cache-aligned allocation, we should
move the stack-based allocation macro there also.
Signed-off-by: Simon Glass <sjg@chromium.org>
During mmc initialize probe all devices with the MMC Uclass if build
with CONFIG_DM_MMC
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
`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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The mmc_startup() function uses the ext_csd data even if reading it
from the mmc device failed. This bug was introduced in commit
bc897b1d4d. 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>
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>
Read the eMMC high capacity write protect group size at mmc device
initialization. This is useful to correctly partition an eMMC device,
as partitions need to be aligned to this size.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The erase_grp_size in struct mmc is to be a size in 512-byte sectors
but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is
enabled computed it as bytes, leading to erase sizes and alignment
much larger than what is actually required by the mmc device.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This modification reads the size of the eMMC enhanced user data area
upon initialization of an mmc device, it will be used later by
mmcinfo.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
The eMMC spec mandates that the high-capacity group size definitions
should be enabled when the device is partitioned (by setting
ERASE_GROUP_DEF in EXT_CSD). The current test to determine when this is
required misses a few cases. In particular a device may have been
partitioned without setting the enhanced attribute on any partition
or partitioning may be completed without creating any extra partitions.
This change moves the code to set ERASE_GROUP_DEF to after reading
all partition information. It is also enabled when
PARTITIONING_SETTING_COMPLETED is set as it is necessary to enable
ERASE_GROUP_DEF before setting that bit, so it means that the user
previously switched to the high capacity definitions.
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
This extends the mmcinfo command's output to show which eMMC partitions
have the enhanced attribute set. Note that the eMMC spec says that
if the enhanced attribute is supported then the boot and RPMB
partitions are of the enhanced type.
The output of mmcinfo becomes:
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
User Capacity: 13.8 GiB ENH
Boot Capacity: 16 MiB ENH
RPMB Capacity: 128 KiB ENH
GP1 Capacity: 64 MiB ENH
GP2 Capacity: 64 MiB ENH
Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
Block length for write and read commands is fixed to 512 bytes
when the card is in Dual Data Rate mode. If block length read from CSD
is different, make sure the driver will use correct length
in all further calculations and settings.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Since the driver doesn't work in 1.2V or 1.8V signaling level modes,
Dual Data Rate mode can be supported by the driver only if it is supported
by the card in regular 3.3V mode. So, check for a particular single
bit in card type field.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
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: Andrew Gabbasov <andrew_gabbasov@mentor.com>
if the card claims to be high capacity and the card
is partitioned the capacity shall still be read from
ext_csd SEC_COUNT even if the resulting capacity is
smaller than 2 GiB
Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
If print_mmc_devices() was called with a '\n' separator (as done
for example by the "mmc list" command), it offset the 2-nd and
all subsequent lines by one space. Fixing this.
Signed-off-by: Lubomir Popov <l-popov@ti.com>
Some devices may use non-standard combinations of regulators to power MMC:
this allows these devices to provide a board-specific MMC power init function
to set everything up in their own way.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
After setting the bus width, the extended CSD register is read. Some selected
fields are compared with previously read extended CSD register fields. In this
comparison the EXT_CSD_ERASE_GROUP_DEF field is compared. But this field is
previously written under certain circumstances. And then the comparison fails.
Only compare read-only fields. Therefore compare field EXT_CSD_HC_WP_GRP_SIZE
instead of field EXT_CSD_ERASE_GROUP_DEF.
Signed-off-by: Mario Schuknecht <mario.schuknecht@dresearch-fe.de>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
The capacity and lba for an MMC device with part_num 0 reflects the
whole device. When mmc_switch_part() successfully switches to a
partition, the capacity is changed to that partition. As partition 0
does not physically exist, attempts to switch back to the whole device
will indicate an error, but the capacity setting for the whole device
must still be restored to match the partition.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Tested-by: Tom Rini <trini@ti.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
if we set manually this bit on the eMMC card using mmc_switch(...),
we also have to set it within our (before read) internal structure
'ext_csd'.
Otherwise following checks on this will fail.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
Add missing prototypes for global functions and
make local functions static.
cc: panto@antoniou-consulting.com
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Rather than just returning -1 everywhere, try to return something
meaningful from mmc_select_hwpart(). Note that most other MMC functions
don't do this, including functions called from mmc_select_hwpart(), so
I'm not sure how effective this will be. Still, it's one less place with
hard-coded -1.
Suggested-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
This enables specifying which eMMC HW partition to target for any U-Boot
command that uses the generic get_partition() function to parse its
command-line arguments.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
MMC switch command for unsupported feature (e.g. bus width) sets a switch
error bit in card status. This bit should be checked, and, if it's set,
no access with new controller settings should be performed.
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
