mmc: dw_mmc: rockchip: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to

mmc: dw_mmc: rockchip: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20230727070051.17778-41-frank.li@vivo.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: rockchip: Obviously always return success in remove callback

dw_mci_pltfm_remove() returns 0 unconditionally and returning an error
in a platform remove callback isn't very sensible. (T

mmc: dw_mmc: rockchip: Obviously always return success in remove callback

dw_mci_pltfm_remove() returns 0 unconditionally and returning an error
in a platform remove callback isn't very sensible. (The only effect of
the latter is that the device core emits a generic warning and then
removes the device anyhow.)

So return 0 unconditionally to make it obvious there is no error
forwarded to the upper layers.

This is a preparation for making platform remove callbacks return void.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220610211257.102071-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw-mmc-rockchip: Fix handling invalid clock rates

The Rockchip rk356x ciu clock cannot be set as low as the dw-mmc
hardware supports. This leads to a situation during card initialization
where

mmc: dw-mmc-rockchip: Fix handling invalid clock rates

The Rockchip rk356x ciu clock cannot be set as low as the dw-mmc
hardware supports. This leads to a situation during card initialization
where the clock is set lower than the clock driver can support. The
dw-mmc-rockchip driver spews errors when this happens.
For normal operation this only happens a few times during boot, but when
cd-broken is enabled (in cases such as the SoQuartz module) this fires
multiple times each poll cycle.

Fix this by testing the lowest possible frequency that the clock driver
can support which is within the mmc specification. Divide that rate by
the internal divider and set f_min to this.

Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Link: https://lore.kernel.org/r/20220305215835.2210388-3-pgwipeout@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: rockchip: use common_caps

The capabilities for all instances are the same, so use common_caps
instead of caps/num_caps to remove the dependency on the mshcN device
tree alias.

Signed-o

mmc: dw_mmc: rockchip: use common_caps

The capabilities for all instances are the same, so use common_caps
instead of caps/num_caps to remove the dependency on the mshcN device
tree alias.

Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Link: https://lore.kernel.org/r/20211124184603.3897245-4-john@metanate.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: Just set default sample value for legacy mode

.set_ios() is called from .resume() as well. For SDIO device which sets
keep-power-in-suspend, nothing should be changed after res

mmc: dw_mmc-rockchip: Just set default sample value for legacy mode

.set_ios() is called from .resume() as well. For SDIO device which sets
keep-power-in-suspend, nothing should be changed after resuming, as well
as sample tuning value, since this value is tuned already. So we should
not overwrite it with the default value.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/1618539454-182170-1-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4

This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous
probe") but applied to a whole pile of drivers. This batch

mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4

This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous
probe") but applied to a whole pile of drivers. This batch converts
the drivers that appeared to be around in the v4.4 timeframe.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # SH_MMCIF
Tested-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20200903162412.1.Id501e96fa63224f77bb86b2135a5e8324ffb9c43@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

mmc: dw_mmc: fix misleading comment in dw_mci_rk3288_set_ios

DDR52 with 8-bit mode should be handled in a different way when
requesting ciu_clk. However DDR50 is used for SDMMC/SDIO and
could never

mmc: dw_mmc: fix misleading comment in dw_mci_rk3288_set_ios

DDR52 with 8-bit mode should be handled in a different way when
requesting ciu_clk. However DDR50 is used for SDMMC/SDIO and
could never be possible with 8-bit mode. It's trival but misleading.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: correct property names in debug

Following up the device tree fixed in commits e78c637127ee ("ARM: dts:
rockchip: Fix DWMMC clocks") and ca9eee95a2de ("arm64: dts: rockchip:
Fix

mmc: dw_mmc-rockchip: correct property names in debug

Following up the device tree fixed in commits e78c637127ee ("ARM: dts:
rockchip: Fix DWMMC clocks") and ca9eee95a2de ("arm64: dts: rockchip:
Fix DWMMC clocks", 2018-02-15), avoid confusion by using the correct
property name in the debug output if clocks are not found.

Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: Fix out-of-bounds access for slot's caps

Add num_caps field for dw_mci_drv_data to validate the controller
id from DT alias and non-DT ways.

Reported-by: Geert Uytterhoeven <geert+rene

mmc: dw_mmc: Fix out-of-bounds access for slot's caps

Add num_caps field for dw_mci_drv_data to validate the controller
id from DT alias and non-DT ways.

Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Fixes: 800d78bfccb3 ("mmc: dw_mmc: add support for implementation specific callbacks")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: parse rockchip, desired-num-phases from DT

Currently we unconditionally do tuning for each degree, which
costs 900ms for each boot and resume.

May someone argue that this is a

mmc: dw_mmc-rockchip: parse rockchip, desired-num-phases from DT

Currently we unconditionally do tuning for each degree, which
costs 900ms for each boot and resume.

May someone argue that this is a question of accuracy VS time. But I
would say it's a trick of how we need to do decision for our boards.
If we don't care the time we spend at all, we could definitely do tuning
for each degree. But when we need to improve the user experience, for
instance, speed up resuming from S3, we should also have the right to
do that. This patch add parsing "rockchip,desired-num-phases", for folks
to specify the number of doing tuning. If not specified, 360 will be used
as before.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: Remove the public dw_mmc header file

There are currently no external users of the public dw_mmc header file,
except the dw_mmc driver itself. Therefore let's move the definitions from
t

mmc: dw_mmc: Remove the public dw_mmc header file

There are currently no external users of the public dw_mmc header file,
except the dw_mmc driver itself. Therefore let's move the definitions from
the public dw_mmc header file into the existing private dw_mmc header file
and then remove the public one.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

show more ...

mmc: dw_mmc: disable biu clk if possible

We could disable biu clk if gpio card detect available,
or it is a non-removable device.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by:

mmc: dw_mmc: disable biu clk if possible

We could disable biu clk if gpio card detect available,
or it is a non-removable device.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: add runtime PM support

This patch adds runtime PM support for dw_mmc-rockchip.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@sam

mmc: dw_mmc-rockchip: add runtime PM support

This patch adds runtime PM support for dw_mmc-rockchip.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: rockchip: unset the MMC_CAP_ERASE flag

In dw_mmc.c, it's enabled by default.
It doesn't need to set MMC_CAP_ERASE in rockchip anymore.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.

mmc: dw_mmc: rockchip: unset the MMC_CAP_ERASE flag

In dw_mmc.c, it's enabled by default.
It doesn't need to set MMC_CAP_ERASE in rockchip anymore.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: remove the quirks flags

Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO)
For removing this, enabled the dto_timer by defaults.
It doesn't see any I/O performance degression.
In future,

mmc: dw_mmc: remove the quirks flags

Remove the quirks flag. (DW_MCI_QUIRK_BROKEN_DTO)
For removing this, enabled the dto_timer by defaults.
It doesn't see any I/O performance degression.
In future, dwmmc controller should not use the quirks flag.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: rockchip: Set the drive phase properly

Historically for Rockchip devices we've relied on the power-on
default (or perhaps the firmware setting) to get the correct drive
phase for dw_mmc

mmc: dw_mmc: rockchip: Set the drive phase properly

Historically for Rockchip devices we've relied on the power-on
default (or perhaps the firmware setting) to get the correct drive
phase for dw_mmc devices. This worked OK for the most part, but:

* Relying on the setting just "being right" is a bit fragile.

* As soon as there is an instance where the power on default is wrong or
where the firmware didn't configure this properly then we'll get a
mysterious failure.

In commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card
initialization") we actually started setting this explicitly in the
kernel, but that commit wasn't quite right and also wasn't quite
enough. See <https://patchwork.kernel.org/patch/9085311/> for some
details.

Let's explicitly set this phase in dw_mmc.

The comments inside this patch try to explain the situation quite
throughly, but the high level overview of this is:

Before this patch on rk3288 devices tested (after revert of the clock
patch described above):
* eMMC: 180 degrees
* SDMMC/SDIO0/SDIO1: 90 degrees

After this patch:
* Use 90 degree phase offset usually.
* Use 180 degree phase offset for MMC_DDR52, SDR104, HS200.

That means we are _changing_ behavior for those devices in this way:

* If we have HS200 eMMC or DDR52 eMMC, we'll run ID mode at 90
degrees (vs 180) but otherwise have no change.

* For any non-HS200 / non-DDR52 eMMC devices we'll now _always_ run at
90 degrees (vs 180). It seems fairly unlikely that building modern
hardware is using an eMMC that isn't using DDR52 or HS200, of course.

* For SDR104 cards we'll now run with 180 degree phase offset (vs 90).
It's expected that 90 degree phase offset would have worked OK, but
this gives us extra margin.

I have tested this by inserting my collection of uSD cards (mostly UHS,
though a few not) into a veyron_minnie and confirmed that they still
seem to enumerate properly. For a subset of them I tried putting a
filesystem on them and also tried running mmc_test.

Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities

Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise
failing to create rpmb partition. With it, we can
get rpmb successfully:

mmc1: new HS200 MMC ca

mmc: dw_mmc-rockchip: add MMC_CAP_CMD23 capabilities

Add MMC_CAP_CMD23 for dw_mmc-rockchip, otherwise
failing to create rpmb partition. With it, we can
get rpmb successfully:

mmc1: new HS200 MMC card at address 0001
mmcblk0: mmc1:0001 DS2016 14.7 GiB
mmcblk0boot0: mmc1:0001 DS2016 partition 1 4.00 MiB
mmcblk0boot1: mmc1:0001 DS2016 partition 2 4.00 MiB
mmcblk0rpmb: mmc1:0001 DS2016 partition 3 4.00 MiB

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: remove setup_clock for rockchip

We remove setup_clock hook and combine it into
init hook to simplify the code

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by

mmc: dw_mmc-rockchip: remove setup_clock for rockchip

We remove setup_clock hook and combine it into
init hook to simplify the code

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: fix failing to mount partition with "discard"

Without MMC_CAP_ERASE support, we fail to mount partition
with "discard" option since mmc_queue_setup_discard is limited
for check

mmc: dw_mmc-rockchip: fix failing to mount partition with "discard"

Without MMC_CAP_ERASE support, we fail to mount partition
with "discard" option since mmc_queue_setup_discard is limited
for checking mmc_can_erase. Without doing mmc_queue_setup_discard,
blk_queue_discard fails to test QUEUE_FLAG_DISCARD flag, so we get
the following log from f2fs(actually similar to other file system):

mounting with "discard" option, but the device does not support discard

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: remove dw_mci_rockchip_pmops

dw_mci_rockchip_pmops just copy-paste what dw_mci_pltfm_pmops
have done. Let's remove it.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Sign

mmc: dw_mmc-rockchip: remove dw_mci_rockchip_pmops

dw_mci_rockchip_pmops just copy-paste what dw_mci_pltfm_pmops
have done. Let's remove it.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc: remove the prepare_command hook

This patch removes the prepare_command hook from entire dw_mmc driver.
Now, almost all SoCs are using by default, except Exynos.
It seems that dwmmc cont

mmc: dw_mmc: remove the prepare_command hook

This patch removes the prepare_command hook from entire dw_mmc driver.
Now, almost all SoCs are using by default, except Exynos.
It seems that dwmmc controller is using unnecessary hook.
To know whether needs to set this bit or not,
add the DW_MMC_CARD_NO_USE_HOLD bit.

If some SoCs need to disable this in future, just set the
DW_MMC_CARD_NO_USE_HOLD bit.
set_bit(DW_MMC_CARD_NO_USE_HOLD, &slot->flags),

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Tested-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: core: Remove MMC_CAP_RUNTIME_RESUME as it's redundant

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

mmc: mmc: extend the mmc_send_tuning()

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() t

mmc: mmc: extend the mmc_send_tuning()

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.

Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
[Ulf: Rebased patch]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...

mmc: dw_mmc-rockchip: MMC tuning with the clock phase framework

This algorithm will try 1 degree increments, since there's no way to tell
what resolution the underlying phase code uses. As an added

mmc: dw_mmc-rockchip: MMC tuning with the clock phase framework

This algorithm will try 1 degree increments, since there's no way to tell
what resolution the underlying phase code uses. As an added bonus, doing
many tunings yields better results since some tests are run more than once
(ex: if the underlying driver uses 45 degree increments, the tuning code
will try the same angle more than once).

It will then construct a list of good phase ranges (even ranges that cross
360/0), will pick the biggest range then it will set the sample_clk to the
middle of that range.

We do not touch ciu_drive (and by extension define default-drive-phase).
Drive phase is mostly used to define minimum hold times, while one could
write some code to determine what phase meets the minimum hold time (ex 10
degrees) this will not work with the current clock phase framework (which
floors angles, so we'll get 0 deg, and there's no way to know what
resolution the floors happen at). We assume that the default drive angles
set by the hardware are good enough.

If a device has device specific code (like exynos) then that will still
take precedence, otherwise this new code will execute. If the device wants
to tune, but has no sample_clk defined we'll return EIO with an error
message.

Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

show more ...