- 29 Feb, 2016 40 commits
-
-
Shawn Lin authored
This patch add correct err handle if dw_mci_ctrl_reset failed while probing. Signed-off-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Shawn Lin authored
dw_mmc already use mmc_of_parse to get "broken-cd" property, but it considered "broken-cd" to be a quirk in its driver. We don't need this quirk here, and just take what we need from mmc->caps. Signed-off-by:
-
Shawn Lin authored
This patch removes struct block_settings since it's never used anywhere. Signed-off-by:
-
Shawn Lin authored
This patch implement hw_reset function for DesignWare MMC controller. By adding this feature, mmc blk can do some basic recovery. Set the following resets: software reset – BMOD[0] for IDMAC only DMA reset - CTRL[2] FIFO reset - CTRL[1] bits Program the CARD_RESET register with a value of 0 for the bit corresponding to the card number; This programming asserts the RST_n signal and resets the card. After a minimum of 1 ?s, de-asserts the RST_n signal and takes the card out of reset. The application can program a new CMD only after a minimum of 200 us This implementation can be easily tested by cutting off->On vmmc while doing data accessing in background to simulate that case. Signed-off-by:
-
Jaehoon Chung authored
This patch removes the prepare_command hook from entire dw_mmc driver. Now, almost all SoCs are using by default, except Exynos. It seems that dwmmc controller is using unnecessary hook. To know whether needs to set this bit or not, add the DW_MMC_CARD_NO_USE_HOLD bit. If some SoCs need to disable this in future, just set the DW_MMC_CARD_NO_USE_HOLD bit. set_bit(DW_MMC_CARD_NO_USE_HOLD, &slot->flags), Signed-off-by:
-
Russell King authored
Print the error code when the tuning command fails. This allows the reason for the failure to be reported, which aids debugging. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
Re-tuning is part of standard requirements for the higher speed SD card protocols, and is not an error when this occurs. When we retry a command due to a retune, we should not print a message to the kernel log. Signed-off-by:
-
Russell King authored
Improve mmc_of_parse_voltage()'s return values so that drivers can tell whether a voltage-range specification was present, and whether it has been successfully parsed, or there was an error while parsing. We return a negative errno when parsing fails, zero if no voltage-range specification is present, or one if a voltage-range specification is successfully parsed. No users need modifying as no users check the return value. Signed-off-by:
-
Russell King authored
Each time a driver such as sdhci-esdhc-imx is probed, we get a info printk complaining that the DT voltage-ranges property has not been specified. However, the DT binding specifically says that the voltage-ranges property is optional. That means we should not be complaining that DT hasn't specified this property: by indicating that it's optional, it is valid not to have the property in DT. Silence the warning if the property is missing. Signed-off-by:
-
Wolfram Sang authored
Rcar2 & 3 docs state that for going to and coming from the 0xff setting, the clock must first be disabled before the DIV bits are changed. Instead of tracking this, let's just do this unconditionally. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
Some of the indentation made the code awful to read. Fix that. Also, introduce defines instead of magic hex values. Note that this includes one change: We mask out know 0xff instead of 0x1ff. But 0x100 has always been the clock enable bit. It doesn't make any sense to set it depending on the clock calculation. Update copyright notices, too. I'll be working on those files some more in the future. Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
Wolfram Sang authored
These don't make sense anymore. Since commit 5d60e500 ("mmc: tmio: add new TMIO_MMC_HAVE_HIGH_REG flags"), we don't deal with a resource here. Signed-off-by:
-
Wolfram Sang authored
The docs for RCar Gen2 & 3 I have access to, mention delays of 5ms after stop and 1ms after start. Make it possible to apply these values. Signed-off-by:
-
Wolfram Sang authored
We will get a full dump anyhow. Signed-off-by:
-
Shinobu Uehara authored
All the docs I have access to say that this register needs the bus busy check. Signed-off-by:
Shinobu Uehara <shinobu.uehara.xc@renesas.com> Signed-off-by:
Ai Kyuse <ai.kyuse.uw@renesas.com> Signed-off-by:
-
Wolfram Sang authored
When compiling the driver with CONFIG_MMC_DEBUG set, I got build warnings. They have been 'fixed' meanwhile. However, because these debug messages look random anyhow (some duplicate information printed etc), let's just drop them and rather re-add something consistent if that should ever be needed. Signed-off-by:
-
Jaehoon Chung authored
After removed the MMC_DATA_STREAM, only two flags are remained. (MMC_DATA_READ and MMC_DATA_WRITE) The flags of READ and WRITE can't be used together. That's why it doesn't need to use "OR' operation. Signed-off-by:
-
Jaehoon Chung authored
It's not set to MMC_DATA_STREAM anywhere. It seems that it had been used with CMD11/CMD20. But according to Spec, CMD11/CMD20 are obsolete command. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
-
Jaehoon Chung authored
Remove the MMC_DATA_STREAM flag because it isn't used anymore. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Chen-Yu Tsai authored
Now that clock delay settings for 8 bit DDR are correct, and vqmmc support is available, we can enable MMC_CAP_1_8V_DDR support. This enables MMC HS-DDR at up to 52 MHz, even if signal voltage switching is not available. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
Allwinner's MMC controller needs to run at double the card clock rate for 8 bit DDR transfer modes. Interestingly, this is not needed for 4 bit DDR transfers. Different clock delays are needed for 8 bit eMMC DDR, due to the increased module clock rate. For the A80 though, the same values for 4 bit and 8 bit are shared. The new values for the other SoCs were from A83T user manual's "new timing mode" default values, which describes them in clock phase, rather than delay periods. These values were used without any modification. They may not be correct, but they work. Signed-off-by:
-
Chen-Yu Tsai authored
DDR transfer modes include UHS-1 DDR50 and MMC HS-DDR (or MMC_DDR52). Consider MMC_DDR52 when setting clock delays. Since MMC high speed mode goes up to 52 MHz instead of 50 MHz for SD, and this number is visible in the capability macro, increase the clock rate upper limit to 52 MHz. Signed-off-by:
-
Wolfram Sang authored
The bus width is sometimes the actual bus width, and sometimes indices to different arrays encoding the bus width. In my debugging case "2" could mean 8-bit as well as 4-bit, which was extremly confusing. Let's use the human-readable actual bus width in all places. Signed-off-by:
-
Jaehoon Chung authored
In linux/mmc/host.h, mmc_card_is_removable() is already defined. There is no reason that it doesn't use. Signed-off-by:
-
Jisheng Zhang authored
The sdhci_iproc_remove() is jsut a wrapper to sdhci_pltfm_unregister. So use the sdhci_pltfm_unregister() for the .remove hook directly. Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Acked-by:
Scott Branden <sbranden@broadcom.com> Signed-off-by:
-
Stefan Wahren authored
Since sdhci-iproc can support bcm2835 we need add the compatible string to the binding. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Eric Anholt <eric@anholt.net> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Stefan Wahren authored
Scott Branden from Broadcom said that the BCM2835 eMMC IP core is very similar to IPROC and share most of the quirks. So use this driver instead of separate one. The sdhci-iproc contains a better workaround for the clock domain crossing problem which doesn't need any delays. This results in a better write performance. Btw we get the rid of the SDHCI_CAPABILITIES hack in the sdhci_readl function. Suggested-by:
-
Stefan Wahren authored
This patch moves the definition of the MMC capabilities from the probe function into iproc platform data. After that we are able to add support for another platform more easily. Signed-off-by:
-
Wolfram Sang authored
I had to use the source to determine what I need to write to 'test' so that all tests are run. Let's mention this explicitly in 'testlist'. Signed-off-by:
-
Wolfram Sang authored
I don't see a reason why a host driver should depend on the card driver. It also prevents that we can use the mmc_test driver. So, remove it. Signed-off-by:
-
Wolfram Sang authored
IMO this info is only useful for developers. Most users won't need this information, since there is not much they can do about it. Signed-off-by:
-
