summaryrefslogtreecommitdiff
path: root/drivers/mmc
Commit message (Collapse)AuthorAgeLines
* MLK-12001 MMC:USDHC: Clear DLL_CTRL delay line settings at driver initYe.Li2015-12-14-0/+3
| | | | | | | | | | | | Clear DLL_CTRL delay line settings at USDHC initialization to eliminate the pre-settings from boot rom. U-boot should re-init the USDHC not reply on the value set by boot from. On MX6DL, the ROM has set the default delay line(DLLCTRL) to 0x1000021, when eMMC works on DDR mode in kernel, it will possibly cause data CRC errors. Even u-boot always use eMMC in SDR mode, for safety sake, it is better to clear it too. Signed-off-by: Ye.Li <B37916@freescale.com>
* MLK-10453 mmc: fix possible unintialized ocrPeng Fan2015-04-29-1/+4
| | | | | | | | | | | | This commit ca4113da25b42bce44a2e7998966a47352f11613 "mmc: fix OCR Polling" does not consider cmd structure, and may leave it in uninitialized state. We can directly use op_cond_response here, since until here, op_cond_response already get the OCR value from chip. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Suggested-by: Ye.Li <B37916@freescale.com> (cherry picked from commit a033d2d43904f27778ee6a44f3e35494f9f72152)
* MLK-10445 mmc: fix OCR PollingPeng Fan2015-04-29-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If in mmc_send_op_cond, OCR_BUSY is set in CMD1's response, then state is transfered to Ready state, and there is no need to send CMD1 again. Otherwise following CMD1 will recieve no response, or timeour error from driver such as fsl_esdhc.c. If not into Ready state in previous CMD1, then continue CMD1 command. In mmc_complete_op_cond, we use the value mmc->op_cond_response from mmc_send_op_cond, since there should be no CMD1 command between mmc_send_op_cond and mmc_complete_op_cond Before fixing this, uboot log shows: " CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001AA MMC_RSP_R1,5,6,7 0x18EC1504 CMD_SEND:55 ARG 0x00000000 MMC_RSP_R1,5,6,7 0x18EC1504 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 MMC_RSP_R3,4 0x00FF8080 CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0xC0FF8080 --> Already OCR_BUSY set CMD_SEND:1 ARG 0x40300000 MMC_RSP_R3,4 0x0096850A --> Failed CMD1 MMC init failed " Using this patch, this issue is fixed, emmc can be detected correctly. This issue exists on mx7dsabresd and mx7d_12x12_lpddr3_arm2 board. Upstream Patchwork: https://patchwork.ozlabs.org/patch/451775/ Signed-off-by: Peng Fan <Peng.Fan@freescale.com> (cherry picked from commit ca4113da25b42bce44a2e7998966a47352f11613) Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
* ENGR00315499-19 Fix eMMC fast boot hang issueYe.Li2015-04-29-9/+28
| | | | | | | | | | | | | | | | | | When booting in eMMC fast boot, the uboot v2013.04 always hangs. The root cause is that MMC host does not exit from boot mode after bootrom loading image. So the first command 'CMD0' sent in uboot will pull down the CMD line to low and cause errors. This patch cleans the MMC boot register in "mmc_init" to put the MMC host back to normal mode. Signed-off-by: Ye Li <b37916@freescale.com> Signed-off-by: Nitin Garg <nitin.garg@freescale.com> (cherry picked from commit 2ead2f9501c6d2571e0f5365bd808ed7c73257ef) Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Conflicts: drivers/mmc/fsl_esdhc.c
* MLK-10178-8 mmc:fsl_esdhc fix dcache issuePeng Fan2015-04-29-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | DCIMVAC is upgraded to DCCIMVAC for the individual processor (Cortex-A7) that the DCIMVAC is executed on. We should follow the linux dma follow. Before DMA read, first invalidate dcache then after DMA read, invalidate dcache again. With the DMA direction DMA_FROM_DEVICE, the dcache need be invalidated again after the DMA completion. The reason is that we need explicity make sure the dcache been invalidated thus to get the DMA'ed memory correctly from the physical memory. Any cache-line fill during the DMA operations such as the pre-fetching can cause the DMA coherency issue, thus CPU get the stale data. Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Signed-off-by: Ye.Li <B37916@freescale.com> Signed-off-by: Nitin Garg <nitin.garg@freescale.com> Signed-off-by: Jason Liu <r64343@freescale.com> (cherry picked from commit 13cdb96bc52b3079ba91a08c1704307e5598ee59) Conflicts: drivers/mmc/fsl_esdhc.c
* ARM: bcm283x: move SoC headers to mach-bcm283x/include/machMasahiro Yamada2015-03-28-2/+2
| | | | | | | | Move arch/arm/include/asm/arch-bcm283x/* -> arch/arm/mach-bcm283x/include/mach/* Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
* mv_sdhci: fix warnings on 64-bit buildsRob Herring2015-03-18-2/+2
| | | | | | | | 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: fix warnings on 64-bit buildsRob Herring2015-03-18-3/+3
| | | | | | | | 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>
* mmc: sdhci: don't clobber adjacent registersMatt Reimer2015-03-18-1/+1
| | | | | | | | 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>
* mmc: s5p: properly mask SELBASECLKMatt Reimer2015-03-18-1/+1
| | | | | | | | 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>
* mmc: fsl_esdhc fix register offsetPeng Fan2015-03-17-1/+1
| | | | | | | | | | Commit f022d36e8a4517b2a9d25ff2d75bd2459d0c68b1 introduces error register offset. Change the "char reserved3[59]" to "char reserved3[56]". Signed-off-by: Peng Fan <Peng.Fan@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
* Merge branch 'master' of git://git.denx.de/u-bootStefano Babic2015-03-02-21/+77
|\
| * mmc: fsl_esdhc: Add support for DDR modeVolodymyr Riazantsev2015-02-24-2/+6
| | | | | | | | | | | | | | | | 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>
| * mmc: sdhci: fix bus width switching on Samsung SoCsMatt Reimer2015-02-23-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * mmc: print SD/eMMC type for inited mmc devicesPrzemyslaw Marczak2015-02-23-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * mmc: exynos dwmmc: check boot mode before init dwmmcPrzemyslaw Marczak2015-02-23-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * sunxi: mmc: Always declare High Capacity capabilityHans de Goede2015-02-23-5/+1
| | | | | | | | | | | | | | | | | | 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>
| * mmc: exynos_dw_mmc: use the exynos specific data structureJaehoon Chung2015-02-23-13/+47
| | | | | | | | | | | | | | | | 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>
| * mmc: exynos_dw_mmc: set to clksel_val into board-init functionJaehoon Chung2015-02-23-0/+4
| | | | | | | | | | | | | | | | | | "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>
| * mmc: dw_mmc: fixed the wrong bit controlJaehoon Chung2015-02-23-1/+1
| | | | | | | | | | | | If mode is not DDR-mode, then it needs to clear it. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
* | mmc: fsl_esdhc: Add support to force VSELECT setOtavio Salvador2015-02-23-0/+4
| | | | | | | | | | | | | | | | | | 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>
* | mmc: fsl_esdhc: Add CMD11 support to switch to 1.8VOtavio Salvador2015-02-23-7/+22
|/ | | | | | | 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>
* x86: mmc: Move common FSP functions into a common fileSimon Glass2015-02-06-0/+43
| | | | | | | | | | | | 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>
* Merge branch 'master' of git://git.denx.de/u-boot-tiTom Rini2015-02-02-0/+4
|\
| * omap3: mmc: add 1.8v bias setting for MMC1Albert ARIBAUD \(3ADEV\)2015-01-29-0/+4
| | | | | | | | Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
* | Merge branch 'master' of git://git.denx.de/u-boot-sunxiTom Rini2015-02-02-7/+7
|\ \
| * | sunxi: mmc: Add 'sunxi_' prefix to the static functionsSiarhei Siamashka2015-02-02-7/+7
| |/ | | | | | | | | | | | | | | | | | | 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>
* | dm: mmc: Remove use of fdtdec GPIO supportSimon Glass2015-01-29-35/+21
|/ | | | | | These functions are going away, so use the new uclass support instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* Merge branch 'master' of http://git.denx.de/u-boot-sunxiTom Rini2015-01-23-3/+15
|\
| * sunxi: mmc: Add support for sun9i (A80)Hans de Goede2015-01-22-2/+14
| | | | | | | | | | | | | | 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>
| * sunxi: mmc: Use a realistic timeout when sending a mmc commandHans de Goede2015-01-22-1/+1
| | | | | | | | | | | | | | | | 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>
* | mmc: zynq: Use phys_addr_t for addressesMichal Simek2015-01-21-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-19-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-14-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-14-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-06-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-06-20/+20
| | | | | | | Clean mvebu_mmc_send_cmd Signed-off-by: Gérald Kerma <drEagle@doukki.net> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
generated by cgit v1.1 at 2024-11-05 22:15:55 +0000