aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mmc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-10-21mmc: mxs: fix flags passed to dmaengine_prep_slave_sgSascha Hauer1-3/+4
Since ceeeb99cd821 we no longer abuse the DMA_CTRL_ACK flag for custom driver use and introduced the MXS_DMA_CTRL_WAIT4END instead. We have not changed all users to this flag though. This patch fixes it for the mxs-mmc driver. Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag") Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Fabio Estevam <festevam@gmail.com> Reported-by: Bruno Thomsen <bruno.thomsen@gmail.com> Tested-by: Bruno Thomsen <bruno.thomsen@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-21mmc: cqhci: Commit descriptors before setting the doorbellFaiz Abbas1-1/+2
Add a write memory barrier to make sure that descriptors are actually written to memory, before ringing the doorbell. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-21mmc: sdhci-omap: Fix Tuning procedure for temperatures < -20CFaiz Abbas1-1/+1
According to the App note[1] detailing the tuning algorithm, for temperatures < -20C, the initial tuning value should be min(largest value in LPW - 24, ceil(13/16 ratio of LPW)). The largest value in LPW is (max_window + 4 * (max_len - 1)) and not (max_window + 4 * max_len) itself. Fix this implementation. [1] http://www.ti.com/lit/an/spraca9b/spraca9b.pdf Fixes: 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)") Cc: stable@vger.kernel.org Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-09mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711Nicolas Saenz Julienne1-0/+1
The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 after multiblock reads even when ACMD12 is disabled. This triggers spurious interrupts after the data transfer is done with the following message: mmc1: Got data interrupt 0x00000002 even though no data operation was in progress. mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001002 mmc1: sdhci: Blk size: 0x00007200 | Blk cnt: 0x00000000 mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000033 mmc1: sdhci: Present: 0x1fff0000 | Host ctl: 0x00000017 mmc1: sdhci: Power: 0x0000000f | Blk gap: 0x00000080 mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000107 mmc1: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 mmc1: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 mmc1: sdhci: Caps: 0x45ee6432 | Caps_1: 0x0000a525 mmc1: sdhci: Cmd: 0x00000c1a | Max curr: 0x00080008 mmc1: sdhci: Resp[0]: 0x00000b00 | Resp[1]: 0x00edc87f mmc1: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x00400e00 mmc1: sdhci: Host ctl2: 0x00000001 mmc1: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xf3025208 mmc1: sdhci: ============================================ Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock reads and suppress the spurious interrupts. Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711") Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-03mmc: sh_mmcif: Use platform_get_irq_optional() for optional interruptGeert Uytterhoeven1-4/+2
As platform_get_irq() now prints an error when the interrupt does not exist, a scary warning may be printed for an optional interrupt: sh_mmcif ee200000.mmc: IRQ index 1 not found Fix this by calling platform_get_irq_optional() instead for the second interrupt, which is optional. Remove the now superfluous error printing for the first interrupt, which is mandatory. Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-10-03mmc: renesas_sdhi: Do not use platform_get_irq() to count interruptsGeert Uytterhoeven1-12/+19
As platform_get_irq() now prints an error when the interrupt does not exist, counting interrupts by looping until failure causes the printing of scary messages like: renesas_sdhi_internal_dmac ee140000.sd: IRQ index 1 not found Fix this by using the platform_irq_count() helper to avoid touching non-existent interrupts. Fixes: 7723f4c5ecdb8d83 ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-27mmc: host: sdhci-pci: Add Genesys Logic GL975x supportBen Chuang5-1/+361
Add support for the GL9750 and GL9755 chipsets. Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/ GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor tuning flow for GL9750. Co-developed-by: Michael K Johnson <johnsonm@danlj.org> Signed-off-by: Michael K Johnson <johnsonm@danlj.org> Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-27mmc: tegra: Implement ->set_dma_mask()Nicolin Chen1-20/+28
The SDHCI controller on Tegra186 supports 40-bit addressing, which is usually enough to address all of system memory. However, if the SDHCI controller is behind an IOMMU, the address space can go beyond. This happens on Tegra186 and later where the ARM SMMU has an input address space of 48 bits. If the DMA API is backed by this ARM SMMU, the top- down IOVA allocator will cause IOV addresses to be returned that the SDHCI controller cannot access. Unfortunately, prior to the introduction of the ->set_dma_mask() host operation, the SDHCI core would set either a 64-bit DMA mask if the controller claimed to support 64-bit addressing, or a 32-bit DMA mask otherwise. Since the full 64 bits cannot be addressed on Tegra, this had to be worked around in commit 68481a7e1c84 ("mmc: tegra: Mark 64 bit dma broken on Tegra186") by setting the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk, which effectively restricts the DMA mask to 32 bits. One disadvantage of this is that dma_map_*() APIs will now try to use the swiotlb to bounce DMA to addresses beyond of the controller's DMA mask. This in turn caused degraded performance and can lead to situations where the swiotlb buffer is exhausted, which in turn leads to DMA transfers to fail. With the recent introduction of the ->set_dma_mask() host operation, this can now be properly fixed. For each generation of Tegra, the exact supported DMA mask can be configured. This kills two birds with one stone: it avoids the use of bounce buffers because system memory never exceeds the addressable memory range of the SDHCI controllers on these devices, and at the same time when an IOMMU is involved, it prevents IOV addresses from being allocated beyond the addressible range of the controllers. Since the DMA mask is now properly handled, the 64-bit DMA quirk can be removed. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> [treding@nvidia.com: provide more background in commit message] Tested-by: Nicolin Chen <nicoleotsuka@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Cc: stable@vger.kernel.org # v4.15 + Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-27mmc: sdhci: Let drivers define their DMA maskAdrian Hunter2-8/+5
Add host operation ->set_dma_mask() so that drivers can define their own DMA masks. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Cc: stable@vger.kernel.org # v4.15 + Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-27mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherenceRussell King1-1/+6
We must not unconditionally set the DMA snoop bit; if the DMA API is assuming that the device is not DMA coherent, and the device snoops the CPU caches, the device can see stale cache lines brought in by speculative prefetch. This leads to the device seeing stale data, potentially resulting in corrupted data transfers. Commonly, this results in a descriptor fetch error such as: mmc0: ADMA error mmc0: sdhci: ============ SDHCI REGISTER DUMP =========== mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202 mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001 mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013 mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038 mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000 mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000040d8 mmc0: sdhci: Timeout: 0x00000003 | Int stat: 0x00000001 mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202 mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00 mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000 mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33 mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00 mmc0: sdhci: Host ctl2: 0x00000000 mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c mmc0: sdhci: ============================================ mmc0: error -5 whilst initialising SD card but can lead to other errors, and potentially direct the SDHCI controller to read/write data to other memory locations (e.g. if a valid descriptor is visible to the device in a stale cache line.) Fix this by ensuring that the DMA snoop bit corresponds with the behaviour of the DMA API. Since the driver currently only supports DT, use of_dma_is_coherent(). Note that device_get_dma_attr() can not be used as that risks re-introducing this bug if/when the driver is converted to ACPI. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-27mmc: sdhci: improve ADMA error reportingRussell King1-5/+10
ADMA errors are potentially data corrupting events; although we print the register state, we do not usefully print the ADMA descriptors. Worse than that, we print them by referencing their virtual address which is meaningless when the register state gives us the DMA address of the failing descriptor. Print the ADMA descriptors giving their DMA addresses rather than their virtual addresses, and print them using SDHCI_DUMP() rather than DBG(). We also do not show the correct value of the interrupt status register; the register dump shows the current value, after we have cleared the pending interrupts we are going to service. What is more useful is to print the interrupts that _were_ pending at the time the ADMA error was encountered. Fix that too. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-19Merge tag 'dma-mapping-5.4' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds2-4/+39
Pull dma-mapping updates from Christoph Hellwig: - add dma-mapping and block layer helpers to take care of IOMMU merging for mmc plus subsequent fixups (Yoshihiro Shimoda) - rework handling of the pgprot bits for remapping (me) - take care of the dma direct infrastructure for swiotlb-xen (me) - improve the dma noncoherent remapping infrastructure (me) - better defaults for ->mmap, ->get_sgtable and ->get_required_mask (me) - cleanup mmaping of coherent DMA allocations (me) - various misc cleanups (Andy Shevchenko, me) * tag 'dma-mapping-5.4' of git://git.infradead.org/users/hch/dma-mapping: (41 commits) mmc: renesas_sdhi_internal_dmac: Add MMC_CAP2_MERGE_CAPABLE mmc: queue: Fix bigger segments usage arm64: use asm-generic/dma-mapping.h swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page swiotlb-xen: simplify cache maintainance swiotlb-xen: use the same foreign page check everywhere swiotlb-xen: remove xen_swiotlb_dma_mmap and xen_swiotlb_dma_get_sgtable xen: remove the exports for xen_{create,destroy}_contiguous_region xen/arm: remove xen_dma_ops xen/arm: simplify dma_cache_maint xen/arm: use dev_is_dma_coherent xen/arm: consolidate page-coherent.h xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance arm: remove wrappers for the generic dma remap helpers dma-mapping: introduce a dma_common_find_pages helper dma-mapping: always use VM_DMA_COHERENT for generic DMA remap vmalloc: lift the arm flag for coherent mappings to common code dma-mapping: provide a better default ->get_required_mask dma-mapping: remove the dma_declare_coherent_memory export remoteproc: don't allow modular build ...
2019-09-13Merge branch 'fixes' into nextUlf Hansson5-27/+15
2019-09-13mmc: tmio: Fixup runtime PM management during removeUlf Hansson1-3/+4
Accessing the device when it may be runtime suspended is a bug, which is the case in tmio_mmc_host_remove(). Let's fix the behaviour. Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-09-13mmc: tmio: Fixup runtime PM management during probeUlf Hansson2-1/+9
The tmio_mmc_host_probe() calls pm_runtime_set_active() to update the runtime PM status of the device, as to make it reflect the current status of the HW. This works fine for most cases, but unfortunate not for all. Especially, there is a generic problem when the device has a genpd attached and that genpd have the ->start|stop() callbacks assigned. More precisely, if the driver calls pm_runtime_set_active() during ->probe(), genpd does not get to invoke the ->start() callback for it, which means the HW isn't really fully powered on. Furthermore, in the next phase, when the device becomes runtime suspended, genpd will invoke the ->stop() callback for it, potentially leading to usage count imbalance problems, depending on what's implemented behind the callbacks of course. To fix this problem, convert to call pm_runtime_get_sync() from tmio_mmc_host_probe() rather than pm_runtime_set_active(). Additionally, to avoid bumping usage counters and unnecessary re-initializing the HW the first time the tmio driver's ->runtime_resume() callback is called, introduce a state flag to keeping track of this. Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-09-13Revert "mmc: tmio: move runtime PM enablement to the driver implementations"Ulf Hansson4-23/+2
This reverts commit 7ff213193310ef8d0ee5f04f79d791210787ac2c. It turns out that the above commit introduces other problems. For example, calling pm_runtime_set_active() must not be done prior calling pm_runtime_enable() as that makes it fail. This leads to additional problems, such as clock enables being wrongly balanced. Rather than fixing the problem on top, let's start over by doing a revert. Fixes: 7ff213193310 ("mmc: tmio: move runtime PM enablement to the driver implementations") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-09-12mmc: renesas_sdhi_internal_dmac: Add MMC_CAP2_MERGE_CAPABLEYoshihiro Shimoda1-1/+1
Since this host controller can merge bigger segments if DMA API layer cam merge the segments, this patch adds the flag. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-12mmc: queue: Fix bigger segments usageYoshihiro Shimoda1-1/+7
The commit 38c38cb73223 ("mmc: queue: use bigger segments if DMA MAP layer can merge the segments") always enables the bugger segments if DMA MAP layer can merge the segments, but some controllers (SDHCI) have strictly limitation about the segments size, and then the commit breaks on the controllers. To fix the issue, this patch adds a new flag MMC_CAP2_MERGE_CAPABLE into the struct mmc_host and the bigger segments usage is disabled as default. Reported-by: Thierry Reding <treding@nvidia.com> Fixes: 38c38cb73223 ("mmc: queue: use bigger segments if DMA MAP layer can merge the segments") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-11mmc: dw_mmc: hi3798cv200: make array degrees static const, makes object smallerColin Ian King1-1/+1
Don't populate the array degrees on the stack but instead make it static const. Makes the object code smaller by 46 bytes. Before: text data bss dec hex filename 5356 1560 0 6916 1b04 dw_mmc-hi3798cv200.o After: text data bss dec hex filename 5214 1656 0 6870 1ad6 dw_mmc-hi3798cv200.o (gcc version 9.2.1, amd64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Convert to use sdio_irq_claimed()Ulf Hansson2-7/+1
Instead of keeping track of whether SDIO IRQs have been enabled via an internal sdhci status flag, avoid the open-coding and convert into using sdio_irq_claimed(). Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Drop redundant code for SDIO IRQsUlf Hansson3-25/+16
Nowadays sdhci prevents runtime suspend when SDIO IRQs are enabled. However, some variants such as sdhci-esdhc-imx's, tries to allow runtime suspend while having the SDIO IRQs enabled, but without supporting remote wakeups. This support is a bit questionable, especially if the host device have a PM domain attached that can be power gated, but more importantly, the code have also become redundant (which was not the case when it was introduced). Rather than keeping the redundant code around, let's drop it and leave this to be revisited later on. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Drop redundant check in sdhci_ack_sdio_irq()Ulf Hansson1-2/+1
The sdhci_ack_sdio_irq() is called only when SDIO IRQs are enabled. Therefore, let's drop the redundant check of the internal SDHCI_SDIO_IRQ_ENABLED flag and just re-enable the IRQs immediately. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: core: Fixup processing of SDIO IRQs during system suspend/resumeUlf Hansson2-2/+3
System suspend/resume of SDIO cards, with SDIO IRQs enabled and when using MMC_CAP2_SDIO_IRQ_NOTHREAD is unfortunate still suffering from a fragile behaviour. Some problems have been taken care of so far, but more issues remains. For example, calling the ->ack_sdio_irq() callback to let host drivers re-enable the SDIO IRQs is a bad idea, unless the IRQ have been consumed, which may not be the case during system suspend/resume. This may lead to that a host driver re-signals the same SDIO IRQ over and over again, causing a storm of IRQs and gives a ping-pong effect towards the sdio_irq_work(). Moreover, calling the ->enable_sdio_irq() callback at system resume to re-enable already enabled SDIO IRQs for the host, causes the runtime PM count for some host drivers to become in-balanced. This then leads to the host to remain runtime resumed, no matter if it's needed or not. To fix these problems, let's check if process_sdio_pending_irqs() actually consumed the SDIO IRQ, before we continue to ack the IRQ by invoking the ->ack_sdio_irq() callback. Additionally, there should be no need to re-enable SDIO IRQs as the host driver already knows if they were enabled at system suspend, thus also whether it needs to re-enable them at system resume. For this reason, drop the call to ->enable_sdio_irq() during system resume. In regards to these changes there is yet another issue, which is when there is an SDIO IRQ being signaled by the host driver, but after the SDIO card has been system suspended. Currently these IRQs are just thrown away, while we should at least make sure to try to consume them when the SDIO card has been system resumed. Fix this by queueing a sdio_irq_work() after we system resumed the SDIO card. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: core: WARN if SDIO IRQs are enabled for non-powered card in suspendUlf Hansson1-0/+2
To make sure SDIO func drivers behaves correctly during system suspend/resume, let add a WARN_ON in case the condition is a non-powered SDIO card and there are some SDIO IRQs still being claimed. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: core: Clarify that the ->ack_sdio_irq() callback is mandatoryUlf Hansson1-2/+1
For the MMC_CAP2_SDIO_IRQ_NOTHREAD case and when using sdio_signal_irq(), the ->ack_sdio_irq() is already mandatory, which was not the case for those host drivers that called sdio_run_irqs() directly. As there are no longer any drivers calling sdio_run_irqs(), let's clarify the code by dropping the unnecessary check and explicitly state that the callback is mandatory in the header file. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREADUlf Hansson1-3/+6
The sdio_irq_pending flag is used to let host drivers indicate that it has signaled an IRQ. If that is the case and we only have a single SDIO func that have claimed an SDIO IRQ, our assumption is that we can avoid reading the SDIO_CCCR_INTx register and just call the SDIO func irq handler immediately. This makes sense, but the flag is set/cleared in a somewhat messy order, let's fix that up according to below. First, the flag is currently set in sdio_run_irqs(), which is executed as a work that was scheduled from sdio_signal_irq(). To make it more implicit that the host have signaled an IRQ, let's instead immediately set the flag in sdio_signal_irq(). This also makes the behavior consistent with host drivers that uses the legacy, mmc_signal_sdio_irq() API. This have no functional impact, because we don't expect host drivers to call sdio_signal_irq() until after the work (sdio_run_irqs()) have been executed anyways. Second, currently we never clears the flag when using the sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let make the behavior consistent, by moving the flag to be cleared inside the common process_sdio_pending_irqs() function. Additionally, tweak the behavior of the flag slightly, by avoiding to clear it unless we processed the SDIO IRQ. The purpose with this at this point, is to keep the information about whether there have been an SDIO IRQ signaled by the host, so at system resume we can decide to process it without reading the SDIO_CCCR_INTx register. Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: core: Move code to get pending SDIO IRQs to a functionMatthias Kaehlcke1-16/+30
To improve code quality, let's move the code that gets pending SDIO IRQs from process_sdio_pending_irqs() into a dedicated function. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> [Ulf: Converted function into static] Tested-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: mtk-sd: Re-store SDIO IRQs mask at system resumeUlf Hansson1-0/+3
In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means msdc_runtime_suspend|resume() gets called during system suspend/resume, via pm_runtime_force_suspend|resume(). This means during system suspend/resume, the register context of the mtk-sd device most likely loses its register context, even in cases when SDIO IRQs have been enabled. To re-enable the SDIO IRQs during system resume, the mtk-sd driver currently relies on the mmc core to re-enable the SDIO IRQs when it resumes the SDIO card, but this isn't the recommended solution. Instead, it's better to deal with this locally in the mtk-sd driver, so let's do that. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: dw_mmc: Re-store SDIO IRQs mask at system resumeUlf Hansson1-0/+4
In cases when SDIO IRQs have been enabled, runtime suspend is prevented by the driver. However, this still means dw_mci_runtime_suspend|resume() gets called during system suspend/resume, via pm_runtime_force_suspend|resume(). This means during system suspend/resume, the register context of the dw_mmc device most likely loses its register context, even in cases when SDIO IRQs have been enabled. To re-enable the SDIO IRQs during system resume, the dw_mmc driver currently relies on the mmc core to re-enable the SDIO IRQs when it resumes the SDIO card, but this isn't the recommended solution. Instead, it's better to deal with this locally in the dw_mmc driver, so let's do that. Tested-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11Merge branch 'fixes' into nextUlf Hansson2-2/+2
2019-09-11mmc: sdhci-pci-o2micro: Fix O2 Host data read/write DLL Lock phase shift issueShirley Her (SC)1-2/+122
Fix data read/write error in HS200 mode due to chip DLL lock phase shift Signed-off-by: Shirley Her <shirley.her@bayhubtech.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-pci-o2micro: Move functions in preparation to fix DLL lock phase shift issueShirley Her (SC)1-93/+94
Move functions in preparation to fix DLL lock phase shift issue Signed-off-by: Shirley Her <shirley.her@bayhubtech.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-pci-o2micro: Change O2 Host PLL and DLL register nameShirley Her (SC)1-8/+8
Change O2 Host PLL and DLL register name Signed-off-by: Shirley Her <shirley.her@bayhubtech.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Fix incorrect switch to HS modeAl Cooper1-1/+3
When switching from any MMC speed mode that requires 1.8v (HS200, HS400 and HS400ES) to High Speed (HS) mode, the system ends up configured for SDR12 with a 50MHz clock which is an illegal mode. This happens because the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register is left set and when this bit is set, the speed mode is controlled by the SDHCI_CTRL_UHS field in the SDHCI_HOST_CONTROL2 register. The SDHCI_CTRL_UHS field will end up being set to 0 (SDR12) by sdhci_set_uhs_signaling() because there is no UHS mode being set. The fix is to change sdhci_set_uhs_signaling() to set the SDHCI_CTRL_UHS field to SDR25 (which is the same as HS) for any switch to HS mode. This was found on a new eMMC controller that does strict checking of the speed mode and the corresponding clock rate. It caused the switch to HS400 mode to fail because part of the sequence to switch to HS400 requires a switch from HS200 to HS before going to HS400. Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Al Cooper <alcooperx@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-aspeed: Depend on CONFIG_OF_ADDRESSAndrew Jeffery1-1/+1
Resolves the following build error reported by the 0-day bot: ERROR: "of_platform_device_create" [drivers/mmc/host/sdhci-of-aspeed.ko] undefined! SPARC does not set CONFIG_OF_ADDRESS so the symbol is missing. Depend on CONFIG_OF_ADDRESS to ensure the driver is only built for supported configurations. Fixes: 2d28dbe042f4 ("mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-aspeed: Allow max-frequency limitation of SDCLKAndrew Jeffery1-2/+18
Add a get_max_clock() handler to sdhci-of-aspeed to report f_max as the maximum clock rate if it is set. This enables artificial limitation of the bus speed via max-frequency in the devicetree for e.g. the AST2600 evaluation board where I was seeing errors at 200MHz. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-aspeed: Uphold clocks-on post-condition of set_clock()Andrew Jeffery1-3/+0
The early-exit didn't seem to matter on the AST2500, but on the AST2600 the SD clock genuinely may not be running on entry to aspeed_sdhci_set_clock(). Remove the early exit to ensure we always run sdhci_enable_clk(). Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-aspeed: Drop redundant assignment to host->clockAndrew Jeffery1-4/+1
host->clock is already managed by sdhci_set_ios(). Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: mmc_spi: Convert to use for_each_sg()Andy Shevchenko1-1/+1
Use for_each_sg() macro instead of open coded variant. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhi: fill in actual_clockTamás Szűcs1-5/+8
Save set clock in mmc_host actual_clock enabling exporting it via debugfs. This will indicate the precise SD clock in I/O settings rather than only the sometimes misleading requested clock. Signed-off-by: Tamás Szűcs <tszucs@protonmail.ch> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: use lower/upper_32_bits() macros for DMA addressesMasahiro Yamada1-14/+13
Currently, the DMA addresses are casted to (u64) for the upper 32bits to avoid "right shift count >= width of type" warning. <linux/kernel.h> provides macros to address this, and I like the macro names are self-documenting. I introduced a new helper, sdhci_set_adma_addr() to avoid the code duplication. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-cadence: override spec versionMasahiro Yamada1-0/+2
The datasheet of the IP (sd4hc) says it is compiatible with SDHCI v4, but the spec version field in the version register is read as 2 (i.e. SDHCI_SPEC_300) based on the RTL provided by Cadence. Socionext did not fix it up when it integrated the IP into the SoCs. So, it is working as SDHCI v3. It is not a real problem because there is no difference in the program flow in sdhci.c between SDHCI_SPEC_300/400, but set the real version just in case. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: constify references of parameters to __sdhci_read_caps()Masahiro Yamada2-3/+4
__sdhci_read_caps() does not modify *ver, *caps, or *caps1. Probably, the caller of this function will want to constifythe parameters passed in. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: mediatek: enable SDIO IRQ low level trigger functionyong mao1-0/+2
SDIO IRQ is not defaultly triggered by low level, but by falling edge. It needs to set related register to enable SDIO IRQ low level trigger function. Otherwise the SDIO IRQ may be lost in some specail condition. Signed-off-by: Yong Mao <yong.mao@mediatek.com> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Export sdhci_abort_tuning function symbolBen Chuang2-1/+3
Export sdhci_abort_tuning() function symbols which are used by other SD Host controller driver modules. Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw> Co-developed-by: Michael K Johnson <johnsonm@danlj.org> Signed-off-by: Michael K Johnson <johnsonm@danlj.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Add PLL Enable support to internal clock setupBen Chuang2-0/+24
The GL9750 and GL9755 chipsets, and possibly others, require PLL Enable setup as part of the internal clock setup as described in 3.2.1 Internal Clock Setup Sequence of SD Host Controller Simplified Specification Version 4.20. Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw> Co-developed-by: Michael K Johnson <johnsonm@danlj.org> Signed-off-by: Michael K Johnson <johnsonm@danlj.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci: Change timeout of loop for checking internal clock stableBen Chuang1-2/+2
According to section 3.2.1 internal clock setup in SD Host Controller Simplified Specifications 4.20, the timeout of loop for checking internal clock stable is defined as 150ms. Signed-off-by: Ben Chuang <ben.chuang@genesyslogic.com.tw> Co-developed-by: Michael K Johnson <johnsonm@danlj.org> Signed-off-by: Michael K Johnson <johnsonm@danlj.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-arasan: Add Support for Intel LGM eMMCRamuthevar Vadivel Muruganx1-0/+15
The current arasan sdhci PHY configuration isn't compatible with the PHY on Intel's LGM(Lightning Mountain) SoC devices. Therefore, add a new compatible, to adapt the Intel's LGM eMMC PHY with arasan-sdhc controller to configure the PHY. Signed-off-by: Ramuthevar Vadivel Muruganx <vadivel.muruganx.ramuthevar@linux.intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: sdhci-of-aspeed: Fix return value check in aspeed_sdc_probe()Wei Yongjun1-2/+2
In case of error, the function of_platform_device_create() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2019-09-11mmc: bcm2835: Take SWIOTLB memory size limitation into accountStefan Wahren1-1/+1
Make sure the sdhost driver doesn't use requests bigger than SWIOTLB can handle. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.