Rename the source file SDHI. A follow-up patch will make it a library
file used by a different top-level module file.

The name "renesas" is chosen as the SDHI driver is applicable to a wider
range of SoCs than SH-Mobile it seems to be a more appropriate name.
However, the SDHI driver source itself, is left as sh_mobile_sdhi to
avoid unnecessary churn.

the name "core" was chosen to reflect the desired role of this file,
to provide core functionality to the sdhi driver. A follow-up patch will
move the file into that role.

Internal symbols have also been renamed to reflect the filename change.

The .name member of struct platform_driver and parameter to
MODULE_ALIAS() have not been changed in order to avoid the complication
of potentially breaking SH SoCs which still use platform drivers.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Rename the source file for DMA for SDHI as a follow-up to attaching
DMA code to the SDHI driver rather than the tmio_core driver.

The name "renesas" is chosen as the SDHI driver is applicable to a wider
range of SoCs than SH-Mobile it seems to be a more appropriate name.
However, the SDHI driver source itself, is left as sh_mobile_sdhi to
avoid unnecessary churn.

The name sys_dmac was chosen to reflect the type of DMA used.

Internal symbols have also been renamed to reflect the filename change.

A follow-up patch will re-organise the SDHI driver removing
the need for renesas_sdhi_get_dma_ops().
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Rename tmio_mmc_pio.c to tmio_mmc_core.c to more accurately reflect its
function: to provide core code for the tmio-mmc and sh-mobole-sdhi drivers.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Refactor DMA support to allow it to be provided by a set of call-backs
that are provided by a host driver. The motivation is to allow multiple
DMA implementations to be provided and instantiated at run-time.

Instantiate the existing DMA implementation from the sh_mobile_sdhi driver
which appears to match the current use-case. This has the side effect
of moving the DMA code from the tmio_core to the sh_mobile_sdhi driver.

A follow-up patch will change the source file for the SDHI DMA
implementation accordingly. Another follow-up patch will re-organise the
SDHI driver removing the need for tmio_mmc_get_dma_ops().
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Reshuffle the comment at the top of the source
dropping filenames and moving up human readable strings.

This seems to be somewhat more useful information to start the
source file with. It is also less fragile, f.e. to file renames.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit a6db2c86 ("mmc: dw_mmc: Don't allow Runtime PM for
SDIO cards")'

As dw_mmc now is capable of preventing runtime PM suspend while SDIO IRQs
are enabled, let's drop the less fine-grained method, which is preventing
runtime PM suspend for all SDIO cards - no matter of whether SDIO IRQs are
being enabled or not.

In this way we don't keep the host runtime PM resumed, unless it's really
needed, thus avoiding to waste power.

Especially when SDIO IRQs is supported via a separate out-of-band IRQ line,
which isn't defined by the SDIO standard, typically the SDIO func driver
doesn't enable SDIO IRQs via sdio_claim_irq(). So, for these cases we can
now allow the dwmmc device to be runtime PM suspended in-between requests.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

To be able to handle SDIO IRQs the dw_mmc device needs to be powered and
providing clock to the SDIO card. Therefore, we must not allow the device
to be runtime PM suspended while SDIO IRQs are enabled.

To fix this, let's increase the runtime PM usage count while the mmc core
enables SDIO IRQs. Later when the mmc core tells dw_mmc to disable SDIO
IRQs, we drop the usage count to again allow runtime PM suspend.

This now becomes the default behaviour for dw_mmc. In cases where SDIO IRQs
can be re-routed as GPIO wake-ups during runtime PM suspend, one could
potentially allow runtime PM suspend. However, that will have to be
addressed as a separate change on top of this one.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

Convert to use the more lightweight method for processing SDIO IRQs, which
involves the following changes:

- Enable MMC_CAP2_SDIO_IRQ_NOTHREAD when SDIO IRQ is supported and use
  sdio_signal_irq() instead of mmc_signal_sdio_irq().
- Mask the SDIO IRQ before signaling a new one to be processed.
- Implement the ->ack_sdio_irq() callback to unmask the SDIO IRQ.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

For hosts not supporting MMC_CAP2_SDIO_IRQ_NOTHREAD but MMC_CAP_SDIO_IRQ,
the SDIO IRQs are processed from a dedicated kernel thread. For these
cases, the host calls mmc_signal_sdio_irq() from its ISR to signal a new
SDIO IRQ.

Signaling an SDIO IRQ makes the host's ->enable_sdio_irq() callback to be
invoked to temporary disable the IRQs, before the kernel thread is woken up
to process it. When processing of the IRQs are completed, they are
re-enabled by the kernel thread, again via invoking the host's
->enable_sdio_irq().

The observation from this, is that the execution path is being unnecessary
complex, as the host driver already knows that it needs to temporary
disable the IRQs before signaling a new one. Moreover, replacing the kernel
thread with a work/workqueue would not only greatly simplify the code, but
also make it more robust.

To address the above problems, let's continue to build upon the support for
MMC_CAP2_SDIO_IRQ_NOTHREAD, as it already implements SDIO IRQs to be
processed without using the clumsy kernel thread and without the ping-pong
calls of the host's ->enable_sdio_irq() callback for each processed IRQ.

Therefore, let's add new API sdio_signal_irq(), which enables hosts to
signal/process SDIO IRQs by using a work/workqueue, rather than using the
kernel thread.

Add also a new host callback ->ack_sdio_irq(), which the work invokes when
the SDIO IRQs have been processed. This informs the host about when it
shall re-enable the SDIO IRQs. Potentially, we could re-use the existing
->enable_sdio_irq() callback instead of adding a new one, however it has
turned out that it's more convenient for hosts to get this information via
a separate callback.

Hosts that wants to use this new method to signal/process SDIO IRQs, must
enable MMC_CAP2_SDIO_IRQ_NOTHREAD and implement the ->ack_sdio_irq()
callback.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

In cases when MMC_CAP2_SDIO_IRQ_NOTHREAD is set, there is a minor window
for when the mmc host could call sdio_run_irqs(), while in fact an SDIO
func driver could have decided to released the SDIO IRQ via a call to
sdio_release_irq(). In this scenario, processing of the SDIO IRQs are done
even if there is none IRQ claimed, which is not what we want.

To prevent this from happen, close the window by validating that at least
one SDIO IRQs is claimed, before deciding to process them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>

In case if a pwrseq-emmc has been bound to the host, a call to
mmc_power_up() triggers an eMMC HW reset via the pwrseq_emmc's
->post_power_on() callback. This isn't really what we want, as
mmc_power_up() is called each time when resuming the card.

As a matter of fact, the current approach may also violate the eMMC spec,
as the involved delays managed in pwrseq_emmc assumes both VCC and VCCQ has
been turned on, which isn't the case for VCCQ, unless the regulator is
always on.

Fix this behaviour by aligning to the same procedure used when the mmc host
implements the ->hw_reset() callback and has the MMC_CAP_HW_RESET flag set.
In this way the eMMC HW reset is issued at card detection scan, to cope
with bogus bootloaders and in the error recovery path via the mmc specific
bus_ops->reset() callback.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>

The ->reset() callback is needed to implement a better support for eMMC HW
reset. The following changes will take advantage of the new callback.
Suggested-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>

Add the missing endianness conversions when printing the USB
device-descriptor idVendor and idProduct fields during probe.
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

AVR32 is gone. Now it's time to clean up the driver by removing
leftovers that was used by AVR32 related code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

At the end of either of the read or write loops len is always zero
and hence the non-zero check on len and return of -EIO is redundant
and can be removed.

Detected by CoverityScan, CID#114293 ("Logically dead code")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

ret is signed however is printed as unsigned fix the same.
If printed as a negative number the result is easier to read.
No functional change.
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There have been reports about SDIO failing with certain WiFi chips in
descriptor chain mode. SD / eMMC are working fine.

So let's fall back to bounce buffer mode for command SD_IO_RW_EXTENDED.
This was reported to fix the error.

Fixes: 79ed05e3 "mmc: meson-gx: add support for descriptor chain mode"
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If the optional power-off-delay-us property is found, insert the
corresponding delay after asserting the GPIO during power off. This enables
a graceful shutdown sequence for some devices.

Cc: linux-mmc@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>

The stingray SDHCI hardware supports ACMD12 and automatically
issues after multi block transfer completed.

If ACMD12 in SDHCI is disabled, spurious tx done interrupts are seen
on multi block read command with below error message:

Got data interrupt 0x00000002 even though no data
operation was in progress.

This patch uses SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable
ACM12 support in SDHCI hardware and suppress spurious interrupt.
Signed-off-by: NSrinath Mannam <srinath.mannam@broadcom.com>
Reviewed-by: NRay Jui <ray.jui@broadcom.com>
Reviewed-by: NScott Branden <scott.branden@broadcom.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Fixes: b580c52d ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If the regulator probing is not yet finished this driver
might catch a -EPROBE_DEFER. Returning after this condition
did not remove the created platform device. On a repeated
call to the probe function the of_platform_device_create
fails.

Calling of_platform_device_destroy after EPROBE_DEFER resolves
this bug.
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In case the DT specifies neither a regulator nor a gpio
for the shared power the driver will crash accessing the regulator.
Prevent the crash by checking the regulator before use.

Use mmc_regulator_get_supply() instead of open coding the same
logic.
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The devm_gpiod_get_optional() function appends a "-gpios" to the
string passed to it, so if we want to find the "power-gpios" signal,
we must pass "power" to this function.

Fixes: 01d95843 ("mmc: cavium: Add MMC support for Octeon SOCs.")
Signed-off-by: NDavid Daney <david.daney@cavium.com>
[jglauber@cavium.com: removed point after subject line]
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

OCTEON SoCs with CIU3 do not have interrupt masking local to the MMC
bus interface.  Unfortunately, some even have a diagnostic register at
the same address of the enable register, which causes the interrupts
to fire immediately if stored to, thus breaking the driver.  The proper
action on these SoCs is not to touch this register.

Fixes: 01d95843 ("mmc: cavium: Add MMC support for Octeon SOCs.")
Signed-off-by: NDavid Daney <david.daney@cavium.com>
[jglauber@cavium.com: removed point after subject line]
Signed-off-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently, the xenon_clean_phy() is only used for freeing phy_params.
The phy_params is allocated by devm_kzalloc(), there's no need to free
is explicitly.
Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NHu Ziji <huziji@marvell.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>

The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The loop to poll ESDHC_CLOCK_STABLE bit with mdelay would waste time
because the time to stabilize is much less than 1 ms. This patch is
to use udelay instead to avoid time wasting.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The default value of LOGIC_TIMING_ADJUST register in eMMC 5.0 PHY is
different from that in eMMC 5.1 PHY.  Set the specific value for that
register in eMMC 5.0 PHY.
Signed-off-by: NHu Ziji <huziji@marvell.com>
Reported-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_remove_host() might execute SOFT_RESET_ALL.  Inside xenon_remove(),
Xenon SDHC should be enabled during sdhci_remove_host().

Move xenon_sdhc_unprepare after sdhci_remove_host() such that Xenon SDHC is
disabled after sdhci_remove_host() completes.
Signed-off-by: NHu Ziji <huziji@marvell.com>
Reported-by: NJisheng Zhang <jszhang@marvell.com>
Tested-by: NJisheng Zhang <jszhang@marvell.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use the module_pci_driver() macro to make the code simpler
by eliminating module_init and module_exit calls.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Acked-by: NJan Glauber <jglauber@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add platform driver for Octeon SOCs.
Signed-off-by: NSteven J. Hill <Steven.Hill@cavium.com>
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use the mmc_card_is_blockaddr() function to properly detect if the
card uses byte or block addressing.
Signed-off-by: NSteven J. Hill <Steven.Hill@cavium.com>
Acked-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSteven J. Hill <Steven.Hill@cavium.com>
Acked-by: NDavid Daney <david.daney@cavium.com>

The host may issue an I/O abort by writing to the CCCR at any time
during I/O read operation via CMD52. And host may need suspend
transcation during write busy stage in SDIO suspend/resume scenario.
>From other side, a card may accept CMD52 during data transfer phase.

Previous implement would block issuing above command in busy stage.
It cause function driver can't implement as proper way and has no
opportunity to do some coverage in error case via I/O abort etc.

We need bypass some necessary operation during busy check stage.
Signed-off-by: NJiajie Hao <jiajie.hao@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

USDHC tuning circuit should be reset before every time card enumeration
or re-enumeration.

SD3.0 card need tuning. For SDR104 card, when system suspend in standby
mode, and then resume back, the IO timing is still SDR104(tuned) which
may result in card re-enumeration fail in low card speed(400khz) for some
cards. And we did meet the issue that in certain probability, SDR104
card meet mmc command CRC/Timeout error when send CMD2 during mmc bus
resume.

This patch reset the tuning circuit when the ios timing is
MMC_TIMING_LEGACY/MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS, which means both
mmc_power_up() and mmc_power_off() will reset the tuning circuit.
Signed-off-by: NHaibo Chen <haibo.chen@nxp.com>
Acked-by: NDong Aisheng <aisheng.dong@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It's observed that eSDHC needed delay between tuning cycles for
HS200 successful tuning. This patch is to set 1ms delay for that.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The delay between tuning commands for SD cards is not part of the
specification. A driver that needs it probably needs it for eMMC
too, whereas most drivers would probably like to set it to 0. Make
it a host member (host->tuning_delay) that defaults to the existing
behaviour. Drivers can set it to zero to eliminate the delay, or
set it to a positive value to always have a delay.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

eSDHC uses tuning block for tuning procedure. So the tuning
block control register must be configured properly before tuning.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

eSDHC supports signal voltage switch from 3.3v to 1.8v by
eSDHC_PROCTL[VOLT_SEL] bit. This bit changes the value of output
signal SDHC_VS, and there must be a control circuit out of eSDHC
to change the signal voltage according to SDHC_VS output signal.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

eSDHC could select peripheral clock or platform clock as clock source by
the PCS bit of eSDHC Control Register, and this bit couldn't be reset by
software reset for all. In default, the platform clock is used. But we have
to use peripheral clock since it has a higher frequency to support eMMC
HS200 mode and SD UHS-I mode. This patch is to add peripheral clock support
and use it instead of platform clock if it's declared in eSDHC dts node.
Signed-off-by: NYangbo Lu <yangbo.lu@nxp.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>