- 26 Sep, 2016 40 commits
-
-
Zach Brown authored
The sdhci controller on xilinx zynq devices will not function unless the CD bit is provided. http://www.xilinx.com/support/answers/61064.html In cases where it is impossible to provide the CD bit in hardware, setting the controller to test mode and then setting inserted to true will get the controller to function without the CD bit. When the device has the property xlnx,fails-without-test-cd the driver changes the controller to test mode and sets test inserted to true to make the controller function. Signed-off-by:
Zach Brown <zach.brown@ni.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Zach Brown authored
The sdhci controller on xilinx zynq devices will not function unless the CD bit is provided. http://www.xilinx.com/support/answers/61064.html In cases where it is impossible to provide the CD bit in hardware, setting the controller to test mode and then setting inserted to true will get the controller to function without the CD bit. The device property "xlnx,fails-without-test-cd" will let the arasan driver know the controller does not have the CD line wired and that the controller does not function without it. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Wolfram Sang authored
We need to add R1 without CRC support, refactor the bus width routine a little and extend a quirk check. To support "non-removable;" we need a workaround which will be hopefully removed when reworking PM soon. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
Wolfram Sang authored
Signed-off-by:
-
Wolfram Sang authored
The core uses it for polling. Give drivers a proper define handle this case like for other response types. Signed-off-by:
-
Linus Walleij authored
We have enough vtables in the kernel as it is, we don't need this one to create even more artificial separation of concerns. As is proved by the Makefile: obj-$(CONFIG_MMC_BLOCK) += mmc_block.o mmc_block-objs := block.o queue.o block.c and queue.c are baked into the same mmc_block.o object. So why would one of these objects access a function in the other object by dereferencing a pointer? Create a new block.h header file for the single shared function from block to queue and remove the function pointer and just call the queue request function. Apart from making the code more readable, this also makes link optimizations possible and probably speeds up the call as well. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Adrian Hunter authored
Set MMC_CAP_CMD_DURING_TFR for Intel BYT and related eMMC host controllers. Signed-off-by:
-
Adrian Hunter authored
Set MMC_CAP_CMD_DURING_TFR for Intel BYT and related eMMC host controllers. Signed-off-by:
-
Adrian Hunter authored
Now SDHCI supports commands during transfer, enable support for the core API. There are 3 small changes needed: First, auto-CMD12 cannot be used with a cap_cmd_during_tfr request because the host controller cannot expect the command line to be available. Secondly, a cap_cmd_during_tfr request must not send a stop command, again because the host controller cannot expect the command line to be available. Thirdly, when a cap_cmd_during_tfr command completes, use mmc_command_complete() to notify the upper layers that the command line is now available for further commands. Signed-off-by:
-
Adrian Hunter authored
Add 6 tests for sending commands during transfer. The tests are: * Commands during read - no Set Block Count (CMD23). * Commands during write - no Set Block Count (CMD23). * Commands during read - use Set Block Count (CMD23). * Commands during write - use Set Block Count (CMD23). * Commands during non-blocking read - use Set Block Count (CMD23). * Commands during non-blocking write - use Set Block Count (CMD23). For a range of transfer sizes, the tests start an ongoing data transfer and then repeatedly send the status command (CMD13) while the transfer continues. The tests pass if all requests complete with no errors. The host controller driver must support MMC_CAP_CMD_DURING_TFR. Signed-off-by:
-
Adrian Hunter authored
A host controller driver exposes its capability using caps flag MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the upper layers when the command line is available for further commands by calling mmc_command_done(). Because of that, the driver will not then automatically send STOP commands, and it is the responsibility of the upper layer to send a STOP command if it is required. For requests submitted through the mmc_wait_for_req() interface, the caller sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact not to wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete by calling mmc_wait_for_req_done() which is now exported. For requests submitted through the mmc_start_req() interface, the caller again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does not wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete in the normal way i.e. calling mmc_start_req() again. Irrespective of how a cap_cmd_during_tfr request is started, mmc_is_req_done() can be called if the upper layer needs to determine if the request is done. However the appropriate waiting function (either mmc_wait_for_req_done() or mmc_start_req()) must still be called. The implementation consists primarily of a new completion mrq->cmd_completion which notifies when the command line is available for further commands. That completion is completed by mmc_command_done(). When there is an ongoing data transfer, calls to mmc_wait_for_req() will automatically wait on that completion, so the caller does not have to do anything special. Note, in the case of errors, the driver may call mmc_request_done() without calling mmc_command_done() because mmc_request_done() always calls mmc_command_done(). Signed-off-by:
-
Jaedon Shin authored
Clear incorrect SDHCI_CAN_64BIT capability on Broadcom MIPS based SoCs. The MIPS based SoCs are using ADMA only, but the several SoCs have the incorrect capability bit about ADMA 64-bit. The "brcm,bcm7425-sdhci" is compatible string for MIPS based SoC. Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Acked-by:
-
Jaedon Shin authored
Changes to the DT binding document to separate the BCM7425 and the BCM7445. A compatible string "brcm,bcm7425-sdhci" was representing the BCM7425 SDHCI host controller with all BRCMSTB SoCs including the BCM7445. Now it should be separated because vary a bit in initialize each host controller. - Renames the DT binding document to common name. - Adds a compatible string "brcm,bcm7445-sdhci" that is representing the BCM7445 with thereafter 28nm generation ARM based SoCs. Signed-off-by:
-
Icenowy Zheng authored
A64 SoC features a MMC controller which need only the mod clock, and can calibrate delay by itself. This patch adds support for the new MMC controller IP core. Signed-off-by:
Icenowy Zheng <icenowy@aosc.xyz> Signed-off-by:
-
Icenowy Zheng authored
Signed-off-by:
-
Baolin Wang authored
In most cases the 'card->erase_size' is power of 2, then the round_up/down() function is more efficient than '%' operation when the 'card->erase_size' is power of 2. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Tested-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
-
Baolin Wang authored
In order to clean up the mmc_erase() function and do some optimization for erase size alignment, factor out the guts of erase size alignment into mmc_align_erase_size() function. Signed-off-by:
-
Arnd Bergmann authored
platform_get_irq() returns an error value on failure, not NO_IRQ, so the error handling here could never work. This changes the code to propagate the error value instead. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ai Kyuse authored
Add support for r8a7796 SoC. Signed-off-by:
Ai Kyuse <ai.kyuse.uw@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Ulf Hansson authored
In cases when the host->max_busy_timeout isn't specified, the calculated number of maximum discard sectors defaults to UINT_MAX. This may cause a too long timeout for a discard request. Avoid this by using a default maximum erase timeout of 60s, used when we calculate the maximum number of sectors that are allowed to be discarded per request. Do note that the minimum number of sectors to be discarded is still at least one "preferred erase size". Signed-off-by:
-
Thierry Reding authored
According to the TRM, the SD/MMC controller on Tegra124 supports 34-bit addressing, but testing shows that this doesn't work. On a device which has more than 2 GiB of RAM and LPAE enabled, buffer allocations can use addresses above the 32-bit boundary. One way to work around this would be to enable IOMMU physical to virtual address translations for the SD/MMC controllers, but that's not easy to implement without breaking existing use-cases. It's also not obvious why 34-bit addressing doesn't work as advertised. In order to fix this for existing users, add the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk for now. Reported-by:
Paul Kocialkowski <contact@paulk.fr> Acked-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Shawn Lin authored
corecfg_clockmultiplier indicates clock multiplier value of programmable clock generator which should be the same value of SDHCI_CAPABILITIES_1. The default value of the register, corecfg_clockmultiplier, is 0x10. But actually it is a mistake by designer as our intention was to set it to be zero which means we don't support programmable clock generator. So we have to make it to be zero on bootloader which seems work fine until now. But now we find an issue that when deploying genpd support for it, the remove callback will trigger the genpd to poweroff the power domain for sdhci-of-arasan which manage the controller, phy and corecfg_* stuff. So when we do bind/unbind the driver, we have already reinit the controller and phy, but without doing that for corecfg_*. Regarding to only the corecfg_clockmultipler is wrong, let's fix it by explicitly marking it to be zero when probing. With this change, we could do bind/unbind successfully. Reported-by:
Ziyuan Xu <xzy.xu@rock-chips.com> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
Andy Shevchenko authored
Intel Merrifield provides an interface to an external SD card. Enable it here. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Andy Shevchenko authored
Intel Merrifield is known to have an SDIO interface and on Intel Edison board a WiFi card is wired to it. Enable the interface here to allow WiFi card enumeration. Signed-off-by:
-
Andy Shevchenko authored
Refactor intel_mrfld_mmc_probe_slot() to use switch case. The change allows to add a support for SD and SDIO interfaces without any pain. Signed-off-by:
-
Jin Guojun authored
Hisilicon Hikey have no tuning function in dw_mmc-k3.c, so we must do the tuning function stub when we init UHS card. Signed-off-by:
Jin Guojun <kid.jin@hisilicon.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
Shawn Lin authored
The following log we found indicate the fact that dw_mmc didn't treat EBE or SBE as a similar problem as CRC error. -EIO is quite not informative as it may indicate that the device is broken rather than that of tuning stuff. ... [ 89.057226] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 [ 89.058811] bcmsdh_sdmmc: Failed to Read byte F1:@0x1001f=ff, Err: -5 [ 89.059415] bcmsdh_sdmmc: Failed to Read byte F1:@0x1000e=ff, Err: -84 [ 89.254248] dwmmc_rockchip fe310000.dwmmc: Successfully tuned phase to 199 [ 89.273912] dhd_set_suspend: Remove extra suspend setting [ 89.274478] dhd_enable_packet_filter: enter, value = 0 64 bytes from 112.90.83.112: icmp_seq=24 ttl=53 time=1321 ms 64 bytes from 112.90.83.112: icmp_seq=25 ttl=53 time=319 ms 64 bytes from 112.90.83.112: icmp_seq=26 ttl=53 time=69.8 ms 64 bytes from 112.90.83.112: icmp_seq=27 ttl=53 time=37.5 ms ... For the host, when failing to sample cmd's response due to tuning stuff, we still return -EIO as it's quite vague to figure out whether it related to signal or just the broken devices, especially for the card type detection when booting kernel as all things go well but the cmd set used. But for the data phase, if receiving the cmd's response which carriess data transfer, we should have more confidence that it is very probably related to the tuning stuff. Just as the log shown above, we sometimes suffer too much this kind of pain as the dw_mmc return -EIO for the case, so mmc-core will not do retune and caller drivers like bcm's wifi driver, still retry the failure more and more until dw_mmc finally generate CRC. Adrian suggested that drivers who care the specific cases should call mmc_retune_needed rather than doing it in mmc core. It makes sense but I'm considering that -EILSEQ actually means illegal sequence , so we use it for CRC cases. Meanwhile, SBE/EBE indicate the illegal sequence of start bit or end bit for data0~7. So I realize that we should use -EILSEQ for them both as well CRC cases. Suggested-by:
-
Guodong Xu authored
Dwmmc host controller may in unknown state when entering kernel boot. One example is when booting from eMMC, bootloader need initialize MMC host controller into some state so it can read. In order to make sure MMC host controller in a clean initial state, this reset support is added. With this patch, a 'resets' property can be added into dw_mmc device tree node. The hardware logic is: dwmmc host controller IP receives a reset signal from a 'reset provider' (eg. power management unit). The 'resets' property points to this reset signal. So, during dwmmc driver probe, it can use this signal to reset itself. Refer to [1] for more information. [1] Documentation/devicetree/bindings/reset/reset.txt Signed-off-by:
Guodong Xu <guodong.xu@linaro.org> Signed-off-by:
Xinwei Kong <kong.kongxinwei@hisilicon.com> Signed-off-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Reviewed-by:
-
Guodong Xu authored
Add resets property to synopsys-dw-mshc bindings. It is intended to represent the hardware reset signal present internally in some host controller IC designs. See Documentation/devicetree/bindings/reset/reset.txt for details. Signed-off-by:
-
Jaehoon Chung authored
If ciu/biu clock are NULL, clk_disable_unprepare should be just returned. In clk_disable_unprepare(), already checked whether clk is error or NULL. Signed-off-by:
-
Shawn Lin authored
The intention to remove it comes from the conflict of what the mmc-core does with the way dw_mmc treats disable-wp. We could see that 'disable-wp' is supported by core but it's deprecated by dw_mmc as we don't expect it to be existed for each slot subnode but should be in the parent node. Based on searching for all the upstream dts using dw_mmc, we're confident that none of them use the deprecated way. Maybe we should take old dtb in consideration but it was a flag day since the time we was considering to take it away. The fact is that there are none of dts using the deprecated way since v3.18 or even earlier. So personally I don't believe the old dtb would/could bootup current kernel(may not?). Let's remove it now. Signed-off-by:
-
Krzysztof Kozlowski authored
Chipsets before Exynos5420 did not support HS400 so if MMC core tries to configure HS400 timing, this might or might not work. Warn in such cases because this is DTB misconfiguration. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
-
Daniel Glöckner authored
CMD23 aka SET_BLOCK_COUNT was introduced with MMC v3.1. Older versions of the specification allowed to terminate multi-block transfers only with CMD12. The patch fixes the following problem: mmc0: new MMC card at address 0001 mmcblk0: mmc0:0001 SDMB-16 15.3 MiB mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 ... blk_update_request: I/O error, dev mmcblk0, sector 0 Buffer I/O error on dev mmcblk0, logical block 0, async page read mmcblk0: unable to read partition table Signed-off-by:
Daniel Glöckner <dg@emlix.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Ulf Hansson authored
The commit 1ef5e49e ("mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version") moved sdhci-of-esdhc away from using the ->platform_init() callback. As it was the only user of it and that it seems reasonable to believe that it won't be needed again, let's just remove it. Signed-off-by:
-
Andy Shevchenko authored
The commit 52ac7acf ("mmc: sdhci-pci: Convert to use managed functions pcim_* and devm_*") converted ->probe() / ->remove() functions to use device managed resource API. Here is a follow up to cover sdhci_pci_probe_slot() and sdhci_pci_remove_slot(). Signed-off-by:
-
Shawn Lin authored
When using mmc_io_rw_extended, it's intent to avoid null pointer of card and invalid func number. But actually it didn't prevent that as the seg_size already use the card. Currently the wrapper function sdio_io_rw_ext_helper already use card before calling mmc_io_rw_extended, so we should move this check to there. As to the func number, it was token from '(ocr & 0x70000000) >> 28' which should be enough to guarantee that it won't be larger than 7. But we should prevent the caller like wifi drivers modify this value. So let's move this check into sdio_io_rw_ext_helper either. Also we remove the BUG_ON for mmc_send_io_op_cond since all possible paths calling this function are protected by checking the arguments in advance. After deploying these changes, we could not see any panic within SDIO API even if func drivers abuse the SDIO func APIs. Signed-off-by:
-
Shawn Lin authored
packed should always exist without calling its cleanup function explicitly. Moreover, we have use it when preparing packed list. So I don't believe we should ever fall into this check again when doing mmc_blk_packed_hdr_wrq_prep or mmc_blk_end_packed_req,etc. And the code of mmc_blk_end_packed_req is trying to use packed before checking it which makes it quite weird. This patch is trying to remove these two checks and move it to the mmc_blk_prep_packed_list. If we find packed is null, then we should never use MMC_BLK_PACKED_CMD. By doing this, we could fall back to non-packed request if finding null packed, though it's impossible theoretically. After removing these two BUG_ONs, we also remove all other similar checks within the routine of mmc_blk_issue_rw_rq which checks the error handling of packed request. Signed-off-by:
-
Jungseung Lee authored
The switch failure message in mmc_select_timing() had been removed since that is invalid: commit 0400ed0a ("mmc: core: remove the invalid message in mmc_select_timing") Now, in the case when mmc_select_hs() return error in mmc_select_timing(), there is nothing to print failure message. Let's make for mmc_select_hs() print message itself in the failure case. Signed-off-by:
Jungseung Lee <js07.lee@samsung.com> Signed-off-by:
-
Wolfram Sang authored
Populating card_busy caused a side-effect on a chip variant we don't have documentation for (r8a73a4). So, enable it and voltage switching only on devices known to support those features. Signed-off-by:
-
