summaryrefslogtreecommitdiffstats
path: root/drivers/mmc
Commit message (Collapse)AuthorAgeFilesLines
...
* | mmc: zynq: Use phys_addr_t for addressesMichal Simek2015-01-211-2/+2
|/ | | | | | | phys_addr_t is designed for physical addresses that's why use it. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* mmc: Skip changing bus width for MMC cards earlier than version 4.0Andrew Gabbasov2015-01-191-2/+5
| | | | | | | | | | | 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>
* mmc: Avoid redundant switching to 1-bit bus width for MMC cardsAndrew Gabbasov2015-01-191-0/+12
| | | | | | | | | | | | | | | | | | | | 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>
* mmc: extend mmcinfo output to show partition write reliability settingsDiego Santa Cruz2015-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: extend the mmc hardware partitioning API with write reliabilityDiego Santa Cruz2015-01-191-0/+39
| | | | | | | | | 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>
* mmc: add API to do eMMC hardware partitioningDiego Santa Cruz2015-01-191-0/+155
| | | | | | | | | | | | | | | | | | 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>
* mmc: the ext_csd data may be used during init even if reading failedDiego Santa Cruz2015-01-191-1/+3
| | | | | | | | | | 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>
* mmc: eMMC partitioning data is not effective till partitioning completedDiego Santa Cruz2015-01-191-23/+35
| | | | | | | | | | | | | | | | | 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>
* mmc: read the high capacity WP group size for eMMCDiego Santa Cruz2015-01-191-0/+6
| | | | | | | | 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>
* mmc: fix erase_grp_size computation with high-capacity size definitionDiego Santa Cruz2015-01-191-2/+1
| | | | | | | | | 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>
* mmc: read the size of eMMC enhanced user data areaDiego Santa Cruz2015-01-191-0/+15
| | | | | | | | 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>
* mmc: computation of eMMC GP partition size was missing 512 KiB factorDiego Santa Cruz2015-01-191-0/+1
| | | | Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: incomplete test to switch to high-capacity group size definitionsDiego Santa Cruz2015-01-191-22/+30
| | | | | | | | | | | | | | | | | 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>
* mmc: extend mmcinfo to show enhanced partition attributeDiego Santa Cruz2015-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: rmobile: Add SDHC support for Renesas rmobile ARM SoCNobuhiro Iwamatsu2015-01-193-0/+705
| | | | | | | | This adds Renesas rmobile ARM SoC's SD/MMC host support. This drivers tested with Gose board and Koelsch board. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* mmc: sunxi: Fix misuse of gpio_direction_input()Axel Lin2015-01-141-2/+5
| | | | | | | | | | | | It does not make sense to make gpio_direction_input() return the gpio input status. The return value of gpio_direction_input() is inconsistent if CONFIG_DM_GPIO is defined. And we don't need to call gpio_direction_input() int sunxi_mmc_getcd(). Just init the gpio once in mmc_resource_init() is enough. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
* sunxi: mmc: Properly setup mod-clk and clock sampling phasesHans de Goede2015-01-141-27/+68
| | | | | | | | | | | | | | | | | | | | | | | The sunxi mmc controller has both an internal clock divider, as well as the divider in the mod0-clk for the mmc controller. The internal divider cannot be used, as it conflicts with the setting of clock sampling phases which is done in the mod0-clk, so it must be set to 0 (divide by 1). For some reason while the kernel has had this correct from day one, the u-boot sunxi mmc code has been using a fixed mod0-clk and setting its internal divider depending on the desired speed. This is something which we've inherited from the original Allwinner u-boot sources, but while this has been fixed in Allwinner's own u-boot code at least for the A23 and later upstream u-boot was still doing this wrong. This commit fixes this, thereby also fixing mmc support not working reliable on the A23 (which seems more sensitive to this) and possible also fixes some other sunxi mmc issues. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
* MVEBUMMC : REMOVE unnecessary delay from initGerald Kerma2015-01-061-2/+0
| | | | | | | Remove unnessecary delay from mvebu_mmc_initialize Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* MVEBUMMC : CLEAN codeGerald Kerma2015-01-061-20/+20
| | | | | | | Clean mvebu_mmc_send_cmd Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* MVEBUMMC : REMOVE unnecessary delaysGerald Kerma2015-01-061-3/+0
| | | | | | | Remove delays in mvebu_mmc_set_bus and mvebu_mmc_set_clk Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* MVEBUMMC : FIX debug stringsGerald Kerma2015-01-061-5/+13
| | | | | Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* MVEBUMMC : Speed up access timeGerald Kerma2015-01-061-17/+31
| | | | | | | | | | | | | | | | | | | Get about 40x faster access on SHEEVAPLUG MMC Fix some SD type compatibility Changes in v3: - fix the HW_STATE (from linux mvsdio) - review delays and timeouts Changes in v2: - increase number of loops - remove initial delay Changes in v1: - review all loops, delays and timeouts Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* MVEBUMMC : Change copyright dateGerald Kerma2015-01-061-1/+1
| | | | | Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* mmc: dw_mmc: Use active DDR mode flagAndrew Gabbasov2014-12-121-1/+1
| | | | | | | The card_caps bit should denote the card capability to use DDR mode, but we need the flag indicating that the DDR mode is active. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
* mmc: Fix block length for DDR modeAndrew Gabbasov2014-12-121-0/+6
| | | | | | | | | 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>
* mmc: Fix Dual Data Rate capability recognitionAndrew Gabbasov2014-12-121-1/+1
| | | | | | | | | 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>
* mmc: Fix handling of bus widths and DDR card capabilitiesAndrew Gabbasov2014-12-121-21/+31
| | | | | | | | | | | | | | | | | | | | | | | 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>
* mmc: exynos_dw-mmc: change debug messageJaehoon Chung2014-12-121-10/+12
| | | | | | To debug more exactly, add the index for device. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
* MMC: add MMC_VERSION_5_0Markus Niebel2014-12-121-0/+3
| | | | | Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
* MMC: fix user capacity for partitioned eMMC cardMarkus Niebel2014-12-121-0/+15
| | | | | | | | | | 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>
* mmc: Cosmetic fix for nicer, aligned device list printoutLubomir Popov2014-12-121-2/+5
| | | | | | | | 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>
* Merge branch 'master' of git://git.denx.de/u-boot-tiTom Rini2014-12-082-8/+11
|\
| * omap_hsmmc: Board-specific TWL4030 MMC power initializationsPaul Kocialkowski2014-12-041-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | Boards using the TWL4030 regulator may not all use the LDOs the same way (e.g. MMC2 power can be controlled by another LDO than VMMC2). This delegates TWL4030 MMC power initializations to board-specific functions, that may still call twl4030_power_mmc_init for the default behavior. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com> [trini: Fix omap3_evm warning, add twl4030.h] Signed-off-by: Tom Rini <trini@ti.com>
| * twl4030: device-index-specific MMC power initializations, common ramp-up delayPaul Kocialkowski2014-12-041-2/+2
| | | | | | | | | | | | | | | | | | Not every device has multiple MMC slots available, so it makes sense to enable only the required LDOs for the available slots. Generic code in omap_hsmmc will enable both VMMC1 and VMMC2, in doubt. Signed-off-by: Paul Kocialkowski <contact@paulk.fr> Reviewed-by: Tom Rini <trini@ti.com>
| * mmc: Board-specific MMC power initializationsPaul Kocialkowski2014-12-041-0/+7
| | | | | | | | | | | | | | | | | | 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>
| * arm: omap: add support for am57xx devicesFelipe Balbi2014-12-041-2/+3
| | | | | | | | | | | | | | | | just add a few ifdefs around because this device is very similar to dra7xxx. Signed-off-by: Felipe Balbi <balbi@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* | mmc: sh_mmcif: Add support rmobileNobuhiro Iwamatsu2014-12-052-2/+7
| | | | | | | | | | | | | | | | | | Renesas R-Mobile/R-Car ARM SoC of MMC has the same IP that are supported by sh_mmcif. This adds support R-Mobile/R-Car ARM SoC with the setting of the clock support. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
* | mmc: sh_mmcif: Change maximum and minimum value of MMC clockNobuhiro Iwamatsu2014-12-052-3/+5
| | | | | | | | | | | | | | | | | | Maximum value and the minimum value of clock for sh_mmcif instead by base of MMC clock. This removes fixed clock, make the changes to be calculated according to environment. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
* | mmc: sh_mmcif: Use DIV_ROUND_UP and fls instead of calculation loopNobuhiro Iwamatsu2014-12-051-8/+6
|/ | | | | | | Use DIV_ROUND_UP and fls to simplify the code. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
* Merge branch 'master' of git://git.denx.de/u-boot-mpc85xxTom Rini2014-11-261-1/+1
|\ | | | | | | | | | | | | Conflicts: drivers/mmc/fsl_esdhc.c Signed-off-by: Tom Rini <trini@ti.com>
| * mmc: fsl_esdhc: fix f_max retrieval during initMarkus Niebel2014-11-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | for multi instance API we use struct fsl_esdhc_cfg to pass the clock rate. Do not set f_max from global data, since this is wrong for multi instance case. Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Acked-by: Stefano Babic <sbabic@denx.de> Tested-by: Eric Nelson <eric.nelson@boundarydevices.com> Reviewed-by: York Sun <yorksun@freescale.com>
* | Merge branch 'master' of git://www.denx.de/git/u-boot-imxTom Rini2014-11-241-0/+8
|\ \
| * | mmc: fsl_esdhc: Update esdhc driver for iMX6SXYe.Li2014-11-201-0/+8
| |/ | | | | | | | | | | | | | | The reset value of "uSDHCx_INT_STATUS_EN" register is changed to 0 on iMX6SX. So the fsl_esdhc driver must update to set the register, otherwise no state can be detected. Signed-off-by: Ye.Li <B37916@freescale.com>
* | linux/kernel.h: sync min, max, min3, max3 macros with LinuxMasahiro Yamada2014-11-232-4/+4
|/ | | | | | | | | | | | | | | | | | | | U-Boot has never cared about the type when we get max/min of two values, but Linux Kernel does. This commit gets min, max, min3, max3 macros synced with the kernel introducing type checks. Many of references of those macros must be fixed to suppress warnings. We have two options: - Use min, max, min3, max3 only when the arguments have the same type (or add casts to the arguments) - Use min_t/max_t instead with the appropriate type for the first argument Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Pavel Machek <pavel@denx.de> Acked-by: Lukasz Majewski <l.majewski@samsung.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [trini: Fixup arch/blackfin/lib/string.c] Signed-off-by: Tom Rini <trini@ti.com>
* sort drivers/mmc/MakefilePavel Machek2014-11-071-10/+12
| | | | | | | Sort drivers/mmc makefile, as requested by wd. Signed-off-by: Pavel Machek <pavel@denx.de> Acked-by: Chin Liang See <clsee@altera.com>
* omap: hsmmc: assume cd gpio is active lowIgor Grinberg2014-11-061-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Switch the default CD GPIO polarity to active low. The current hsmmc driver assumption that the CD GPIO is active high, but in the real hardware, usually the opposite holds. The usual SD card socket has a mechanical switch which is grounded as soon as a card is inserted. Of course there might be some board logic which inverts the signal, but as far as current users are concerned, there is no such logic. Current U-Boot users either not using the CD functionality, or have a different way (e.g. external to SoC GPIO controller) for checking the card presence. This patch also brings the polarity assumption in line with the Linux kernel and adds appropriate comments. This patch also might spare issues once the TWL GPIO driver will be converted to the DM. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Dmitry Lifshitz <lifshitz@compulab.co.il> Reviewed-by: Tom Rini <trini@ti.com>
* dm: sunxi: Request card detect gpioHans de Goede2014-11-051-10/+22
| | | | | | | This is necessary for the device-model enabled builds to work properly. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Simon Glass <sjg@chromium.org>
* sunxi: Use CONFIG_MACH_SUN?I from Kconfig instead of CONFIG_SUN?IIan Campbell2014-11-051-2/+2
| | | | | | | | | | | Mostly automatic with: sed -i -e 's/CONFIG_\(SUN[45678]I\)/CONFIG_MACH_\1/g' $(git grep -l CONFIG_SUN[45678]I) followed by removing the relevant #defines from include/configs/sun?i.h by hand. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* mmc: s5p: set SD detection pin as inputPrzemyslaw Marczak2014-10-271-1/+1
| | | | | | | The SD Card slot detection pin should be configured as input. Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com> Acked-by: Simon Glass <sjg@chromium.org>
* Merge http://git.denx.de/u-boot-sunxiTom Rini2014-10-261-9/+33
|\
OpenPOWER on IntegriCloud