As indicated by function esdhc_change_pinstate(), SDR50 and DDR50
require pins_100mhz, while SDR104 and HS400 require pins_200mhz. Some
system design may support SDR50 and DDR50 with 100mhz pin state only
(without 200mhz one). Currently the combined 100/200 MHz pinctrl state
check prevents such system from running SDR50 and DDR50. Separate the
check to support such system design.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The bit ESDHC_STD_TUNING_EN may be configed by bootloader code if
it choose to use standard tuning method. So on linux side, if
choose to use manual tuning method, need to clear the bit
ESDHC_STD_TUNING_EN, remove the impact of bootloader code.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
(cherry picked from commit 12a50859ce22f20c7191fc403a93c7f17fb752b8)
The field support_vsel is currently only used in the device tree
case. Get rid of it. No change in behavior.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 86f495c57f)
For some eMMC, after switch to HS400ES mode, it need to config the strobe
dll target dealy even if the clock is 50MHZ or 25MHz, otherwise will meet
CMD index/crc error when send CMD13 to check the switch status. Take
imx8MM-EVK board as example, without this patch, it will meet:
[ 2.473915] IRQ status 0x000a8001
[ 2.473930] the mmc send status get -84
[ 2.473934] mmc2: mmc_select_hs400es failed, error -84
[ 2.473938] mmc2: error -84 whilst initialising MMC card
And we also meet some customer require to let eMMC work at 80MHz HS400ES
mode, so here remove the 100MHz limitation for Strobe DLL target delay
setting.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
It's observed that uSDHC needed delay between tuning cycles for
HS200 successful tuning. This patch is to set 1ms delay for that.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
When using jailhouse to support two Linux on i.MX8MQ EVK,
we use the 1st Linux to configure pinctrl for the 2nd Linux.
Then the 2nd Linux could use the mmc without pinctrl driver.
So give a warning message when no pinctrl available, but no fail probe.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
(cherry picked from commit 0ededa450d69016a72755b428f89d149666d7968)
Add HS400 support for iMX7ULP B0.
According to IC suggest, need to clear the STROBE_DLL_CTRL_RESET
before any setting of STROBE_DLL_CTRL register.
USDHC has register bits(bit[27~20] of register STROBE_DLL_CTRL)
for slave sel vaule. If this register bits value is 0, it needs
256 ref_clk cycles to update slave sel value. IC suggest to set
bit[27~20] to 0x4, it only need 4 ref_clk cycle to update slave
sel vaule. This will short the lock time of slave.
i.MX7ULP B0 will need more time to lock the REF and SLV, so change
to add another 5us delay.
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
strobe-dll-delay-target is the delay cell add on the strobe line.
Strobe line the the uSDHC loopback read clock which is use in HS400
mode. Different strobe-dll-delay-target may need to set for different
board/SoC. If this delay cell is not set to an appropriate value,
we may see some read operation meet CRC error after HS400 mode select
which already pass the tuning.
This patch add the strobe-dll-delay-target setting in driver, so that
user can easily config this delay cell in dts file.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
The default max segment size of IOMMU is 64KB, which exceed the ADMA
limitation. ADMA only support max to 65535, 64KB - 1Byte. IOMMU will
optimize the segments it received, merge the little segment into one
big segment. If we use the default IOMMU config, then ADMA will get
some segments which it's size is 64KB. Then ADMA error will shows up.
Currently, when use standard tuning, driver default disable DMA. But
on i.MX usdhc, this is not enough. Need also clear DMA_SEL. If not,
once the DMA_SEL select AMDA2, even dma already disabled, when send
tuning command, usdhc will still prefetch the ADMA script from wrong
DMA address, then we will see IOMMU report some error which show
lack of TLB mapping.
This patch fix these two issue, make sure usdhc can work well by
operate data through IOMMU.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
When the last ready-buffer-ready is set, then usdhc execute-tuning
bit is clear, this means usdhc finish the tuning process, but at
this time, sd/mmc card may still out put the tuning data, can't
response to any command. So this patch add 1ms delay when usdhc
finish the tuning, make sure sd/mmc card finish sending the tuning
data, then sd/mmc can response the following command normally.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Currently, USDHC do not generate transfer complete interrupt
when send a non-data-command with R1b response. But if want
to support DCMD in CMDQ, need to change this, the DCMD IC
logic require the USDHC to enable this function, otherwise
DCMD will never get a CC(command complete) interrupt.
This patch set ESDHC_VEND_SPEC2_EN_BUSY_IRQ and add DCMD support.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Priority use the callback set_timeout() to set the maximum timeout
if the host has.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
This patch adds CMDQ support for command-queue compatible
hosts.
Command queue is added in eMMC-5.1 specification. This
enables the controller to process upto 32 requests at
a time.
Adrian Hunter contributed renaming to cqhci, recovery, suspend
and resume, cqhci_off, cqhci_wait_for_idle, and external timeout
handling.
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit a4080225f5)
When pm_runtime_suspend is run, a call to SCFW power off the SS in
which the resource resides is made. The SCFW can power off the SS
if no other resource in active in tha SS. If so, all state associated
with all the resources within the SS that is powered off is lost,
this includes the clock rates, clock state etc. When pm_runtime_resume
is called, the SS associated with that resource is powered up. But
the clocks are left in the default state.
This patch restore clock rate in pm_runtime_resume, make sure the
clock is right rather than depending on the default state setting
by SCFW.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
i.MX8QXP and i.MX8QM support Enhanced Strobe HS400 mode. This patch
add HS400_ES mode support, due to HS400_ES do not need tuning, select
HS400_ES mode should be faster than select HS400/HS200 mode.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
commit 3f0191b80cf1 ("MLK-14381 mmc: sdhci-esdhc-imx: reset tuning
circuit when system resume") add tuning reset when the timing is
MMC_TIMING_LEGACY/MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. For timing
MMC_TIMING_MMC_HS, we can not do tuning reset, otherwise HS400
timing is not right.
Here is the process of config HS400, it do tuning in HS200 mode,
then switch to HS mode and 8 bit DDR mode, finally switch to HS400
mode. If we do tuning reset in HS mode, this will cause HS400 mode
lost the tuning setting, which will cause CRC error.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
commit 70f2d20917bc ("MLK-14884 mmc: sdhci: make DDR50 tuning optionally")
want to make DDR50 card tuning optionally, but the code logic is not
right, the tuning of DDR50 card will also be impacted by the flag
'SDHCI_SDR50_NEEDS_TUNING'. e.g. imx6sl/imx6sx/imx6ul/imx7d default set
USE_TUNING_SDR50, which means on these SoC, DDR50 card still do tuning
even haven't the flag 'SDHCI_DDR50_NEEDS_TUNING'.
This patch fix the logic issue, separate DDR50 and SDR50 card.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
After commit 3e3274ab9f ("mmc: sdhci-esdhc-imx: Use common
sdhci_suspend|resume_host()"), we lost the pins state store and save
in common sdhci_pltfm_{suspend|resume} API which results in the
pins state lost in state un-retainable suspend/resume, then
CMD transfer will meet timeout subsequently.
Due to sdhci_pltfm_{suspend|resume} API becomes static after
that commit later, we then do manual pins state save and restore
in our platform suspend/resume API instead.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
DDR50 tuning is optinally defined in sd 3.0 spec. Per IC guys
suggestion, it internally already uses a fixed optimized timing
and normally does not require tuning.
Make it optionally and platform can claim SDHCI_DDR50_NEEDS_TUNING
support if it wants tuning.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
MMC SDHCI maintainer Adrian Hunter Introduce SDHCI flags for signal
voltage support and set them based on the supported transfer modes,
except in the case where 3V DDR52 is supported but 1.8V is not.
This patch add the support to make eMMC DDR52 only work at 3.3v when
property 'no-1-8-v' defined.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
On some SoCs such as i.MX7ULP, there is no busfreq
driver, but cpuidle has some levels which may disable
system/bus clocks, so need to add pm_qos to prevent
cpuidle from entering low level idles and make sure
system/bus clocks are enabled when usdhc is active.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
When suspend usdhc, it will access usdhc register. So usdhc clock
should be enabled, otherwise the access usdhc register will return
error or cause system.
Take this into consideration, if system enable a usdhc and do not
connect any SD/SDIO/MMC card, after system boot up, this usdhc
will do runtime suspend, and close all usdhc clock. At this time,
if suspend the system, due to no card persent, usdhc runtime resume
will not be called. So usdhc clock still closed, then in suspend,
once access usdhc register, system hung or bus error return.
This patch make sure usdhc clock always enabled while doing usdhc
suspend.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
This reverts commit 2c01452f4d7c0f65553b365adc27a1b7b6ba8644.
Besides, add other SoC request high bus freq. This is because
only imx6qdl do not implement low bus idle, so imx6qdl can work
well under low power mode without request high bus freq which
also can save power. For other SoC, need to request high bus
freq when usdhc is active.
Also can refer to commit 312979d1fc.
i.MX6ULL has errata ERR010450, which says due to SOC I/O timing
limit, eMMC HS200 and SD/SDIO 3.0 SDR104 at 1.8v can only work
below or equal to 150MHz. And eMMC DDR52 and SD/SDIO DDR50 at
1.8v can only work below or equal to 45MHz.
This patch add this limit for imx6ull.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
For Mega/Mix enabled SoCs like MX7D and MX6SX, uSDHC will lost power in
LP mode no matter whether the MMC_KEEP_POWER flag is set or not.
This may cause state misalign between kernel and HW, especially for
SDIO3.0 WiFi cards.
e.g. SDIO WiFi driver usually will keep power during system suspend.
And after resume, no card re-enumeration called.
But the tuning state is lost due to Mega/Mix.
Then CRC error may happen during next data transfer.
So we should always fire a mmc_retune_needed() for such type SoC
to tell MMC core retuning is needed for next data transfer.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Change SLV_DLY_TARGET to IC recommended value 0x7(4/1 cycle)
according to spec.
The old value 0x1 is not robust and may fail in some critical
circumstance.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Currently sdhci driver free irq in host suspend, and call
request_threaded_irq() in host resume. But during host resume,
Ctrl+C can impact sdhci host resume, see the error log:
CPU1 is up
PM: noirq resume of devices complete after 0.637 msecs imx-sdma 30bd0000.sdma: loaded firmware 4.1
PM: early resume of devices complete after 0.774 msecs
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b40000.usdhc failed to resume: error -4
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b50000.usdhc failed to resume: error -4
dpm_run_callback(): platform_pm_resume+0x0/0x44 returns -4
PM: Device 30b60000.usdhc failed to resume: error -4 fec 30be0000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: Timeout waiting for hardware interrupt.
mmc0: error -110 during resume (card was removed?)
mmc2: Timeout waiting for hardware interrupt.
mmc2: Timeout waiting for hardware interrupt.
mmc2: error -110 during resume (card was removed?)
In request_threaded_irq-> __setup_irq-> kthread_create
->kthread_create_on_node, the comment shows that SIGKILLed will
impact the kthread create, and return -EINTR.
This patch replace them with disable|enable_irq(), that will prevent
IRQs from being propagated to the sdhci driver.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
We see CRCs with SLV_DLY_TARGET of 7 during driver runtime suspend/resume
if disable sw auto retuning. Back to SLV_DLY_TARGET of 1 which is used
in 3.14 kernel and don't have such issue.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
When enable WIFi and connected with AP, the system is unable to suspend.
root@imx6qdlsolo:~# echo standby > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
dhdsdio_isr: Enter
dhdsdio_isr: Enter
dhdsdio_isr: disable SDIO interrupts
Calling dhdsdio_dpc() from dhdsdio_isr
dhdsdio_dpc: Enter
dhdsdio_bussleep: request WAKE (currently SLEEP)
(Keypress still response here.... )
It's caused by Broadcom WiFi driver will keep handling SDIO irq even after
the driver is already suspended.
This weird behavior will block the MMC host suspend during its irq
synchronize operation in free_irq(), then the system suspend is blocked
too and hanged.
Add SDHCI_QUIRK2_SDIO_IRQ_THREAD for BCM WiFi to use kernel thread
to process sdio interrupts which won't block system suspend and process
freeze operation.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Some special SDIO devices like Broadcom WiFi driver will keep handling
SDIO irq even after the driver is already suspended.
This weird behavior will block the MMC host suspend during its irq
synchronize operation in free_irq(), then the system suspend is blocked
too and hanged.
We add back sdio thread irq support for such WiFi driver to handle
SDIO irqs since the sdio thread is kernel thread which does not
block the process freeze operation during suspend.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
This will cause meaningless CPU overhead by polling the card at backgroud
if the CD is broken.
Most board does not intend to use this function, so remove it.
Platform driver could add it for test if needed.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Conflicts:
drivers/mmc/host/sdhci.c
After adding mega fast support, the default enabled usdhc wakeup will block
M/F to gate off power domain.
To avoid this issue, we only claim wakeup capability and reply on user to enable
it via sysfs according to real needs.
The drawback of such change is that for SDIO WiFi Wakeup On Wireless feature,
User has to enable both uSDHC and WiFi WoW wakeup mannually to make
WoW work well.
BTW, due to the wakeup feature is controller itself, so we do not need to reply
on WiFi PM flags to enable it.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 58f91ff6f6719fef44f5122ae1d8a5df7e0061d5)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
Do not need to enable the controller card cd interrupt wakeup
if using GPIO as card detect since it's meaningless.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Except SDHCI_QUIRK_BROKEN_CARD_DETECTION and MMC_CAP_NONREMOVABLE,
we also do not need to handle controller native card detect interrupt
for gpio as card detect case.
If we wrong enabled the card detect interrupt for gpio case,
it will cause a lot of unexpected card detect interrupts during data transfer
which should not happen.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Request BUS_FREQ_HIGH when bus is busy and then release BUS_FREQ_HIGH
when bus becomes idle.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 64994f7115573c9ede53b51536b2c15f7cf0112a)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
WiFi driver could call wifi_card_detect function to re-detect card,
this is required by some special WiFi cards like broadcom WiFi.
To use this function, a new property is introduced to indicate a wifi host.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
(cherry picked from commit 74e71dd0aebb9e931f02aefa3dd1990cbe642ae4)
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Conflicts:
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
For LPSR mode, usdhc iomux settings will be lost after resume,
so add pinctrl sleep mode support.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
(cherry picked from commit 983a7a174ed20d34a170a6aba70ff9d5bb2c9973)
Currently, we config the watermark_level register only in probe.
This will cause the mmc write operation timeout issue after system
resume back in LPSR mode. Because in LPSR mode, after system resume
back, the watermark_level register(0x44) changes to 0x08000880, which
set the write watermark level as 0, and set the read watermark level
as 128. This value is incorrect.
This patch move the setting of watermark level register out of probe,
so after system resume back, mmc driver will set back this watermark
level register back to 0x10401040.
Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
(cherry picked from commit 05f72329a3c288e15c2f187305a21815d6bffc6d)
Conflicts:
drivers/mmc/host/sdhci-esdhc-imx.c
[ Upstream commit 1b5190c2e7 ]
For eMMC devices it is valid to only support 1.8V signaling. When
vqmmc is set to a fixed 1.8V regulator the stack tries to set 3.3V
initially and prints the following warning:
mmc1: Switching to 3.3V signalling voltage failed
Clear the MMC_SIGNAL_VOLTAGE_330 flag in case 3.3V is signaling is
not available. This prevents the stack from even trying to use
3.3V signaling and avoids the above warning.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 127407e36f ]
The stack assumes that SDHC controller which support SD3.0 (SDR104) do
support HS200. This is not the case for Tegra 3, which does support SD
3.0
but only supports eMMC spec 4.41.
Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
support HS200.
Note that commit 156e14b126 ("mmc: sdhci: fix caps2 for HS200") added
the tie between SD3.0 (SDR104) and HS200. I don't think that this is
necessarly true. It is fully legitimate to support SD3.0 and not support
HS200. The quirk naming suggests something is broken in the controller,
but this is not the case: The controller simply does not support HS200.
Fixes: 7ad2ed1dfc ("mmc: tegra: enable UHS-I modes")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 5552d7ad59 ]
SDHCI controller in ls1043a and ls1046a generate 40-bit wide addresses
when doing DMA. Make sure that the corresponding dma mask is correctly
configured.
Context: when enabling smmu on these chips the following problem is
encountered: the smmu input address size is 48 bits so the dma mappings
for sdhci end up 48-bit wide. However, on these chips sdhci only use
40-bits of that address size when doing dma.
So you end up with a 48-bit address translation in smmu but the device
generates transactions with clipped 40-bit addresses, thus smmu context
faults are triggered. Setting up the correct dma mask fixes this
situation.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c398f3c3b upstream.
after unbinding mmc I get things like this:
[ 185.294067] mmc1: card 0001 removed
[ 185.305206] omap_hsmmc 480b4000.mmc: wake IRQ with no resume: -13
The wakeirq stays in /proc-interrupts
rebinding shows this:
[ 289.795959] genirq: Flags mismatch irq 112. 0000200a (480b4000.mmc:wakeup) vs. 0000200a (480b4000.mmc:wakeup)
[ 289.808959] omap_hsmmc 480b4000.mmc: Unable to request wake IRQ
[ 289.815338] omap_hsmmc 480b4000.mmc: no SDIO IRQ support, falling back to polling
That bug seems to be introduced by switching from devm_request_irq()
to generic wakeirq handling.
So let us cleanup at removal.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Fixes: 5b83b2234b ("mmc: omap_hsmmc: Change wake-up interrupt to use generic wakeirq")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Guo