If the mmc device is non-removable (as indicated by the device tree), set
the flag so that users of the device know.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
We need to clear the allocated memory explicitly as the included
struct sdhci_host has function pointers. Those are compared to NULL to
test if this (optional) feature is supported. Leaving them undefined let
u-boot jump to arbitrary memory.
Signed-off-by: Alexander Stein <alexanders83@web.de>
Freescale eMMC44 adapter card uses Micron N2M400FDB311A3CF eMMC
memory. According to the silicon datasheet, secure erase timeout
is 600ms. So increase erase timeout value from 250ms to 600ms.
Signed-off-by: Yangbo Lu <yangbo.lu@freescale.com>
Cc: York Sun <yorksun@freescale.com>
Timeout interrupt also work for response busy command(R1b) like
cmd38/cmd6. So need to set it accordingly. Current code only
set timeout for data command.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
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>
Remove the quirk SDHCI_QUIRK_NO_CD as it is not
required.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
SDHCI_HOST_CONTROL is a byte-sized register, so don't write to it
as if it were a long, as that would result in clobbering the three
registers following.
Signed-off-by: Matt Reimer <mreimer@sdgsystems.com>
Properly mask SELBASECLK by using an actual mask rather than the
number of bits to shift in order to create the mask.
Signed-off-by: Matt Reimer <mreimer@sdgsystems.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Add support of the DDR mode for eSDHC driver.
Enable it for i.MX6 SoC family only.
Signed-off-by: Volodymyr Riazantsev <volodymyr.riazantsev@globallogic.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Fix bus width switching from 8-bit mode down to 4-bit or 1-bit modes on
Samsung SoCs using SDHCI_QUIRK_USE_WIDE8. These SoCs report controller
version 2.0 yet they support 8-bit bus widths. If 8-bit mode was
previously enabled and then an operation like "mmc dev" caused a switch
back down to 4-bit or 1-bit mode, WIDE8 was left set, causing failures.
This problem was manifested by "mmc dev" timing out.
Signed-off-by: Matt Reimer <mreimer@sdgsystems.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>
Before this commit, the mmc devices were always registered
in the same order. So dwmmc channel 0 was registered as mmc 0,
channel 1 as mmc 1, etc.
In case of possibility to boot from more then one device,
the CONFIG_SYS_MMC_ENV_DEV should always point to right mmc device.
This can be achieved by init boot device as first, so it will be
always registered as mmc 0. Thanks to this, the 'saveenv' command
will work fine for all mmc boot devices.
Exynos based boards usually uses mmc host channels configuration:
- 0, or 0+1 for 8 bit - as a default boot device (usually eMMC)
- 2 for 4bit - as an optional boot device (usually SD card slot)
And usually the boot order is defined by OM pin configuration,
which can be changed in a few ways, eg.
- Odroid U3 - eMMC card insertion -> first boot from eMMC
- Odroid X2/XU3 - boot priority jumper
By this commit, Exynos dwmmc driver will check the OM pin configuration,
and then try to init the boot device and register it as mmc 0.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Akshay Saraswat <akshay.s@samsung.com>
High Capacity (e)MMC cards work fine on sun4i / sun5i, and not having this
capability set causes u-boot to not recognize the eMMC on an Utoo P66 A13
tablet, so always set it thereby fixing this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Clksel value is exynos specific value.
It removed "clksel_val" into dwmci_host and created the
"dwmci_exynos_priv_data" structure for exynos specific data.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
"clksel_val" is assigned to property of mmc or defined value.
But it doesn't write at initial sequence.
There is a reason that get the wrong source-clock value.
This patch fixed it.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Some boards cannot do voltage negotiation but need to set the VSELECT
bit forcely to ensure it to work at 1.8V.
This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
This adds support to switch to 1.8V in case CMD11 succeeds.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Marek Vasut <marex@denx.de>
Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.
This creates a generic PCI MMC device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
This results in a much more readable callgraph, because now they
can't be confused with the function having exactly the same name
in the generic mmc code.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The clocks on the A80 are hooked up slightly different, add support for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
Wait 1 second for the sdcard to respond, rather then waiting for
0xfffff milliseconds.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Ian Campbell <ijc@hellion.org.uk>
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>
