- 13 2月, 2017 11 次提交
-
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Geert Uytterhoeven 提交于
With gcc-4.1.2: mmc/core/block.c: In function ‘mmc_blk_issue_discard_rq’: mmc/core/block.c:1150: warning: ‘arg’ may be used uninitialized in this function mmc/core/block.c:1150: warning: ‘nr’ may be used uninitialized in this function mmc/core/block.c:1150: warning: ‘from’ may be used uninitialized in this function While this is a false positive, it can be avoided easily by jumping over the checks for "err" that are always false. Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Jungseung Lee 提交于
In the eMMC 5.0 version of the spec, several EXT_CSD fields about device lifetime are added. - Two types of estimated indications reflected by averaged wear out of memory - An indication reflected by average reserved blocks Export the information through sysfs. Signed-off-by: NJungseung Lee <js07.lee@samsung.com> Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
Setup tuning when the board is HS200 enabled. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
The function will only be available if SDR104 was detected in probe, so no need to check in the function itself again. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
The function will only be available if SDR104 was detected in probe, so no need to check in the function itself again. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
The capability for HW_RESET is only activated if SDR104 is present, so no need to check for SDR104 in the function itself again. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
Prerequisites for tuning are the same as for hw_reset. We need an SCC and a supported mode. Populate the tuning related functions only when those conditions are met. This also removes a tiny race window. Previously, the functions were populated when the SCC offset was not initialized which could have led to an OOPS. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
We need a SCC unit for hw_reset. Those units can only be described in of_data. So, of_data and a valid SCC offset are prerequisites for enabling the hw_reset capability. Merge the two 'if' conditions into one and add a check for an scc offset. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
By using the helper of_device_get_match_data(), we can skip some checking and make the code simpler. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Wolfram Sang 提交于
The master bit to enable SDIO interrupts can only be accessed if SCLKDIVEN bit allows that. However, the core uses the SDIO enable callback at times when SCLKDIVEN forbids the change. This leads to "timeout waiting for SD bus idle" messages. We now activate the master bit in probe once if SDIO is supported. IRQ en-/disabling will be done now by the individual IRQ enablement bits only. Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: NYasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 08 2月, 2017 1 次提交
-
-
由 Jean-Nicolas Graux 提交于
This fixes a race condition that may occur whenever ST micro busy end interrupt is raised just after being unmasked but before leaving mmci interrupt context. A dead-lock has been found if connecting mmci ST Micro variant whose amba id is 0x10480180 to some new eMMC that supports internal caches. Whenever mmci driver enables cache control by programming eMMC's EXT_CSD register, block driver may request to flush the eMMC internal caches causing mmci driver to send a MMC_SWITCH command to the card with FLUSH_CACHE operation. And because busy end interrupt may be mistakenly cleared while not yet processed, this mmc request may never complete. As a result, mmcqd task may be stuck forever. Here is an instance caught by lockup detector which shows that mmcqd task was hung while waiting for mmc_flush_cache command to complete: .. [ 240.251595] INFO: task mmcqd/1:52 blocked for more than 120 seconds. [ 240.257973] Not tainted 4.1.13-00510-g9d91424 #2 [ 240.263109] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.270955] mmcqd/1 D c047504c 0 52 2 0x00000000 [ 240.277359] [<c047504c>] (__schedule) from [<c04754a0>] (schedule+0x40/0x98) [ 240.284418] [<c04754a0>] (schedule) from [<c0477d40>] (schedule_timeout+0x148/0x188) [ 240.292191] [<c0477d40>] (schedule_timeout) from [<c0476040>] (wait_for_common+0xa4/0x170) [ 240.300491] [<c0476040>] (wait_for_common) from [<c02efc1c>] (mmc_wait_for_req_done+0x4c/0x13c) [ 240.309224] [<c02efc1c>] (mmc_wait_for_req_done) from [<c02efd90>] (mmc_wait_for_cmd+0x64/0x84) [ 240.317953] [<c02efd90>] (mmc_wait_for_cmd) from [<c02f5b14>] (__mmc_switch+0xa4/0x2a8) [ 240.325964] [<c02f5b14>] (__mmc_switch) from [<c02f5d40>] (mmc_switch+0x28/0x30) [ 240.333389] [<c02f5d40>] (mmc_switch) from [<c02f0984>] (mmc_flush_cache+0x54/0x80) [ 240.341073] [<c02f0984>] (mmc_flush_cache) from [<c02ff0c4>] (mmc_blk_issue_rq+0x114/0x4e8) [ 240.349459] [<c02ff0c4>] (mmc_blk_issue_rq) from [<c03008d4>] (mmc_queue_thread+0xc0/0x180) [ 240.357844] [<c03008d4>] (mmc_queue_thread) from [<c003cf90>] (kthread+0xdc/0xf4) [ 240.365339] [<c003cf90>] (kthread) from [<c0010068>] (ret_from_fork+0x14/0x2c) .. .. [ 240.664311] INFO: task partprobe:564 blocked for more than 120 seconds. [ 240.670943] Not tainted 4.1.13-00510-g9d91424 #2 [ 240.676078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.683922] partprobe D c047504c 0 564 486 0x00000000 [ 240.690318] [<c047504c>] (__schedule) from [<c04754a0>] (schedule+0x40/0x98) [ 240.697396] [<c04754a0>] (schedule) from [<c0477d40>] (schedule_timeout+0x148/0x188) [ 240.705149] [<c0477d40>] (schedule_timeout) from [<c0476040>] (wait_for_common+0xa4/0x170) [ 240.713446] [<c0476040>] (wait_for_common) from [<c01f3300>] (submit_bio_wait+0x58/0x64) [ 240.721571] [<c01f3300>] (submit_bio_wait) from [<c01fbbd8>] (blkdev_issue_flush+0x60/0x88) [ 240.729957] [<c01fbbd8>] (blkdev_issue_flush) from [<c010ff84>] (blkdev_fsync+0x34/0x44) [ 240.738083] [<c010ff84>] (blkdev_fsync) from [<c0109594>] (do_fsync+0x3c/0x64) [ 240.745319] [<c0109594>] (do_fsync) from [<c000ffc0>] (ret_fast_syscall+0x0/0x3c) .. Here is the detailed sequence showing when this issue may happen: 1) At probe time, mmci device is initialized and card busy detection based on DAT[0] monitoring is enabled. 2) Later during run time, since card reported to support internal caches, a MMCI_SWITCH command is sent to eMMC device with FLUSH_CACHE operation. On receiving this command, eMMC may enter busy state (for a relatively short time in the case of the dead-lock). 3) Then mmci interrupt is raised and mmci_irq() is called: MMCISTATUS register is read and is equal to 0x01000440. So the following status bits are set: - MCI_CMDRESPEND (= 6) - MCI_DATABLOCKEND (= 10) - MCI_ST_CARDBUSY (= 24) Since MMCIMASK0 register is 0x3FF, status variable is set to 0x00000040 and BIT MCI_CMDRESPEND is cleared by writing MMCICLEAR register. Then mmci_cmd_irq() is called. Considering the following conditions: - host->busy_status is 0, - this is a "busy response", - reading again MMCISTATUS register gives 0x1000400, MMCIMASK0 is updated to unmask MCI_ST_BUSYEND bit. Thus, MMCIMASK0 is set to 0x010003FF and host->busy_status is set to wait for busy end completion. Back again in status loop of mmci_irq(), we quickly go through mmci_data_irq() as there are no data in that case. And we finally go through following test at the end of while(status) loop: /* * Don't poll for busy completion in irq context. */ if (host->variant->busy_detect && host->busy_status) status &= ~host->variant->busy_detect_flag; Because status variable is not yet null (is equal to 0x40), we do not leave interrupt context yet but we loop again into while(status) loop. So we run across following steps: a) MMCISTATUS register is read again and this time is equal to 0x01000400. So that following bits are set: - MCI_DATABLOCKEND (= 10) - MCI_ST_CARDBUSY (= 24) Since MMCIMASK0 register is equal to 0x010003FF: b) status variable is set to 0x01000000. c) MCI_ST_CARDBUSY bit is cleared by writing MMCICLEAR register. Then, mmci_cmd_irq() is called one more time. Since host->busy_status is set and that MCI_ST_CARDBUSY is set in status variable, we just return from this function. Back again in mmci_irq(), status variable is set to 0 and we finally leave the while(status) loop. As a result we leave interrupt context, waiting for busy end interrupt event. Now, consider that busy end completion is raised IN BETWEEN steps 3.a) and 3.c). In such a case, we may mistakenly clear busy end interrupt at step 3.c) while it has not yet been processed. This will result in mmc command to wait forever for a busy end completion that will never happen. To fix the problem, this patch implements the following changes: Considering that the mmci seems to be triggering the IRQ on both edges while monitoring DAT0 for busy completion and that same status bit is used to monitor start and end of busy detection, special care must be taken to make sure that both start and end interrupts are always cleared one after the other. 1) Clearing of card busy bit is moved in mmc_cmd_irq() function where unmasking of busy end bit is effectively handled. 2) Just before unmasking busy end event, busy start event is cleared by writing card busy bit in MMCICLEAR register. 3) Finally, once we are no more busy with a command, busy end event is cleared writing again card busy bit in MMCICLEAR register. This patch has been tested with the ST Accordo5 machine, not yet supported upstream but relies on the mmci driver. Signed-off-by: NSarang Mairal <sarang.mairal@garmin.com> Signed-off-by: NJean-Nicolas Graux <jean-nicolas.graux@st.com> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org> Tested-by: NUlf Hansson <ulf.hansson@linaro.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 31 1月, 2017 1 次提交
-
-
由 Gabriel Krisman Bertazi 提交于
One of our kernelCI boxes hanged at boot because a faulty eSDHC device was triggering spurious CARD_INT interrupts for SD cards, causing CMD52 reads, which are not allowed for SD devices. This adds a sanity check to the interruption path, preventing that illegal command from getting sent if the CARD_INT interruption should be disabled. This quirk allows that particular machine to resume boot despite the faulty hardware, instead of getting hung dealing with thousands of mishandled interrupts. Suggested-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.co.uk> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Cc: <stable@vger.kernel.org>
-
- 23 1月, 2017 1 次提交
-
-
由 Ziyuan Xu 提交于
It's necessary to setup bus if any slots are present. - update clock after ctrl reset - if the host has genpd node, we can guarantee the clock is available before starting request. Otherwies, the clock register is reset once power off the pd, and host can't output the active clock during communication. Fixes: e9ed8835 ("mmc: dw_mmc: add runtime PM callback") Fixes: df9bcc2b ("mmc: dw_mmc: add missing codes for runtime resume") cc: <stable@vger.kernel.org> Reported-by: NRandy Li <randy.li@rock-chips.com> Reported-by: NS. Gilles <sgilles@math.umd.edu> Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 16 1月, 2017 1 次提交
-
-
由 Ulf Hansson 提交于
Regressions for not being able to detect an eMMC HS DDR mode card has been reported for the sdhci-esdhc-imx driver, but potentially other sdhci variants may suffer from the similar problem. The commit e173f891 ("mmc: core: Update CMD13 polling policy when switch to HS DDR mode"), is causing the problem. It seems that change moved one step to far, regarding changing the host's timing before polling for a busy card. To fix this, let's move back to the behaviour when the host's timing is updated after the polling, but before the switch status is fetched and validated. In cases when polling with CMD13, we keep validating the switch status at each attempt. However, to align with the other card busy detections mechanism, let's fetch and validate the switch status also after the host's timing is updated. Reported-by: NClemens Gruber <clemens.gruber@pqgruber.com> Reported-by: NGary Bisson <gary.bisson@boundarydevices.com> Fixes: e173f891 ("mmc: core: Update CMD13 polling policy when switch..") Cc: Shawn Lin <shawn.lin@rock-chips.com> Cc: Dong Aisheng <aisheng.dong@nxp.com> Cc: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com> Tested-by: NJagan Teki <jagan@amarulasolutions.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Tested-by: NHaibo Chen <haibo.chen@nxp.com> Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
-
- 12 1月, 2017 2 次提交
-
-
由 Stefan Wahren 提交于
According to the code the intention is to append 8 SCK cycles instead of 4 at end of a MMC_STOP_TRANSMISSION command. But this will never happened because it's an AC command not an ADTC command. So fix this by moving the statement into the right function. Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com> Fixes: e4243f13 (mmc: mxs-mmc: add mmc host driver for i.MX23/28) Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Hans de Goede 提交于
Commit e5bbf307 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") introduced code to powerup any acpi child nodes listed in the dstd. But some dstd-s list all possible devices used on some board variants, while reporting if the device is actually present and enabled in the status field of the device. So we end up calling the acpi _PS0 (power-on) method for devices which are not actually present. This does not always end well, e.g. on my cube iwork8 air tablet, this results in freezing the entire tablet as soon as the r8723bs module is loaded. This commit fixes this by checking the child device's status.present and status.enabled bits and only call acpi_device_fix_up_power() if both are set. Fixes: e5bbf307 ("mmc: sdhci-acpi: Ensure connected devices are powered when probing") BugLink: https://github.com/hadess/rtl8723bs/issues/80Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 10 1月, 2017 1 次提交
-
-
由 Heinrich Schuchardt 提交于
No actual segmentation faults were observed but the coding is at least inconsistent. irqreturn_t meson_mmc_irq(): We should not dereference host before checking it. meson_mmc_irq_thread(): If cmd or mrq are NULL we should not dereference them after writing a warning. Fixes: 51c5d844 MMC: meson: initial support for GX platforms Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: NKevin Hilman <khilman@baylibre.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 25 12月, 2016 1 次提交
-
-
由 Linus Torvalds 提交于
This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 12月, 2016 1 次提交
-
-
由 Paul Burton 提交于
The mmc_read_ssr() function results in DMA to the raw_ssr member of struct mmc_card, which is not guaranteed to be cache line aligned & thus might not meet the requirements set out in Documentation/DMA-API.txt: Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate correctly, the mapped region must begin exactly on a cache line boundary and end exactly on one (to prevent two separately mapped regions from sharing a single cache line). Since the cache line size may not be known at compile time, the API will not enforce this requirement. Therefore, it is recommended that driver writers who don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). On some systems where DMA is non-coherent this can lead to us losing data that shares cache lines with the raw_ssr array. Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc will ensure the buffer is suitably aligned, allowing the DMA to be performed without any loss of data. Signed-off-by: NPaul Burton <paul.burton@imgtec.com> Fixes: 5275a652 ("mmc: sd: Export SD Status via “ssr” device attribute") Cc: <stable@vger.kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 20 12月, 2016 3 次提交
-
-
由 Adrian Hunter 提交于
Commit e0097cf5 ("mmc: queue: Fix queue thread wake-up") did not go far enough. mmc_wait_for_data_req_done() still contains some problems and can be further simplified. First it should not touch context_info->is_waiting_last_req because that is a wake-up control used by the owner of the context. Secondly, it should always return when one of its wake-up conditions is met because, again, that is contolled by the owner of the context. While the current block driver does not have an issue, these problems were exposed during testing of the Software Command Queue patches. Fixes: e0097cf5 ("mmc: queue: Fix queue thread wake-up") Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Tested-by: NHarjani Ritesh <riteshh@codeaurora.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
Since commit c2c24819 ("mmc: core: Don't power off the card when starting the host"), the power state can still be MMC_POWER_UNDEFINED after mmc_start_host() is called. That can trigger a warning in SDHCI during runtime resume as it tries to restore the I/O state. Handle MMC_POWER_UNDEFINED simply by not updating the I/O state in that case. Fixes: c2c24819 ("mmc: core: Don't power off the card when starting the host") Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Masahiro Yamada 提交于
Add a Socionext SoC specific compatible (suggested by Rob Herring). No SoC specific data are associated with the compatible strings for now, but other SoC vendors may use this IP and want to differentiate IP variants in the future. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 12 12月, 2016 1 次提交
-
-
由 Ulf Hansson 提交于
Once upon a time it made sense to keep the mmc block device driver and its related code, in its own directory called card. Over time, more an more functions/structures have become shared through generic mmc header files, between the core and the card directory. In other words, the relationship between them has become closer. By sharing functions/structures via generic header files, it becomes easy for outside users to abuse them. In a way to avoid that from happen, let's move the files from card directory into the core directory, as it enables us to move definitions of functions/structures into mmc core specific header files. Note, this is only the first step in providing a cleaner mmc interface for outside users. Following changes will do the actual cleanup, as that is not part of this change. Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org> Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 08 12月, 2016 2 次提交
-
-
由 Masahiro Yamada 提交于
Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller. For SD, it basically relies on the SDHCI standard code. For eMMC, this driver provides some callbacks to support the hardware part that is specific to this IP design. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Masahiro Yamada 提交于
Some SDHCI-compat controllers support not only SD, but also eMMC, but they use different commands for tuning: CMD19 for SD, CMD21 for eMMC. Due to the difference of the underlying mechanism, some controllers (at least, the Cadence IP is the case) provide their own registers for the eMMC tuning. This commit will be useful when we want to override .execute_tuning callback (for eMMC HS200 tuning), but still let it fall back to sdhci_execute_tuning() for SD timing. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
- 05 12月, 2016 14 次提交
-
-
由 Adrian Hunter 提交于
Tidy the tuning loop by moving it to a separate function and making it a for-loop. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
There are only 2 possible block sizes, so simplify 2 if-statements into 1. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
Factor out some functions to tidy up the code in sdhci_execute_tuning. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
Use mmc_abort_tuning() instead of open-coding the stop command. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
If a tuning command times out, the card could still be processing it, which will cause problems for recovery. The eMMC specification says that CMD12 can be used to stop CMD21, so add a function that does that. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
SDHCI falls back to fixed sampling if there is an error during tuning. However it also reports an error unless there is periodic re-tuning. That is not the best option because: a) there is a reasonable chance that fixed sampling will work, especially at room temperature. b) re-tuning will be done again anyway if there are CRC errors. Change to return no error always when falling back to fixed sampling. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
If the driver has exhausted the maximum number of tuning loops, then fixed sampling is used. To do that both SDHCI_CTRL_TUNED_CLK and SDHCI_CTRL_EXEC_TUNING must be reset to 0, but only SDHCI_CTRL_TUNED_CLK was being reset. Reset SDHCI_CTRL_EXEC_TUNING to 0 also. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
Clearing the tuning bits should reset the tuning circuit. However there is more to do. Reset the command and data lines for good measure, and then for eMMC ensure the card is not still trying to process a tuning command by sending a stop command. Note the JEDEC eMMC specification says the stop command (CMD12) can be used to stop a tuning command (CMD21) whereas the SD specification is silent on the subject with respect to the SD tuning command (CMD19). Considering that CMD12 is not a valid SDIO command, the stop command is sent only when the tuning command is CMD21 i.e. for eMMC. That addresses cases seen so far which have been on eMMC. Note that this replaces the commit fe5fb2e3 ("mmc: sdhci: Reset cmd and data circuits after tuning failure") which is being reverted for v4.9+. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Tested-by: NDan O'Donovan <dan@emutex.com> Cc: stable@vger.kernel.org Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
This reverts commit fe5fb2e3 ("mmc: sdhci: Reset cmd and data circuits after tuning failure"). A better fix is available, and it will be applied to older stable releases, so get this out of the way by reverting it. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Adrian Hunter 提交于
The JEDEC specification indicates CMD13 can be used after a HS200 switch to check for errors. However in practice some boards experience CRC errors in the CMD13 response. Consequently, for HS200, CRC errors are not a reliable way to know the switch failed. If there really is a problem, we would expect tuning will fail and the result ends up the same. So change the error condition to ignore CRC errors in that case. Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Daniel Drake 提交于
Add an entry for the SDIO bus in the ECS EF20 cherry trail laptop: Device (SDHB) { Name (_ADR, 0x00110000) Name (_HID, "80860F14" /* Intel Baytrail SDIO/MMC Host Controller */) Name (_CID, "PNP0D40" /* SDA Standard Compliant SD Host Controller */) Name (_DDN, "Intel(R) SDIO Controller - 80862295") Name (_UID, 0x02) Name (_HRV, One) A SDHB device with the same _HID and _UID can also be found on other cherry trail products like Chuwi Hi10. Signed-off-by: NDaniel Drake <drake@endlessm.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Masahiro Yamada 提交于
I see no override of read/write callbacks in sdhci-of-at91.c. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Zach Brown 提交于
On NI 9037 boards the max SDIO frequency is limited by trace lengths and other layout choices. The max SDIO frequency is stored in an ACPI table. The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the f_max field of the host. Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com> Reviewed-by: NJaeden Amero <jaeden.amero@ni.com> Reviewed-by: NJosh Cartwright <joshc@ni.com> Signed-off-by: NZach Brown <zach.brown@ni.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-
由 Zach Brown 提交于
Add PCI ID for Intel byt sdio host controller sub-vended by NI. The controller has different behavior because of the board layout NI puts it on. Signed-off-by: NZach Brown <zach.brown@ni.com> Acked-by: NAdrian Hunter <adrian.hunter@intel.com> Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
-