The dwcmshc used on Rockchip rk3568 and rk3588 can use cqe, so set
the needed irq handler.
Tested on a rk3588-tiger SoM with dd, hdparm and fio. fio performance
does increase slightly from
Run status group 0 (all jobs):
READ: bw=209MiB/s (219MB/s), 209MiB/s-209MiB/s (219MB/s-219MB/s), io=4096MiB (4295MB), run=19607-19607msec
without CQE to
Run status group 0 (all jobs):
READ: bw=215MiB/s (225MB/s), 215MiB/s-215MiB/s (225MB/s-225MB/s), io=4096MiB (4295MB), run=19062-19062msec
with CQE enabled.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20240530215547.2192457-1-heiko@sntech.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Merge the mmc fixes for v6.9-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.10.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Clang warns (or errors with CONFIG_WERROR=y):
drivers/mmc/host/sdhci-of-dwcmshc.c:873:7: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
873 | if ((device_property_read_bool(dev, "mmc-ddr-1_8v")) |
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
874 | (device_property_read_bool(dev, "mmc-hs200-1_8v")) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ||
875 | (device_property_read_bool(dev, "mmc-hs400-1_8v")))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mmc/host/sdhci-of-dwcmshc.c:873:7: note: cast one or both operands to int to silence this warning
drivers/mmc/host/sdhci-of-dwcmshc.c:873:7: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
873 | if ((device_property_read_bool(dev, "mmc-ddr-1_8v")) |
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ||
874 | (device_property_read_bool(dev, "mmc-hs200-1_8v")) |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mmc/host/sdhci-of-dwcmshc.c:873:7: note: cast one or both operands to int to silence this warning
2 errors generated.
There is little reason for this if statement to use bitwise ORs, as the
short circuiting of logical OR does not need to be avoided in this
context; it would be wasteful to call device_property_read_bool() three
times if the first two calls returned true. Switch to logical OR to fix
the warning.
While in the area, the parentheses around the calls to
device_property_read_bool() are not necessary and make the if statement
harder to read, so remove them.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1960
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Drew Fustini <dfustini@baylibre.com>
Link: https://lore.kernel.org/r/20231116-sdhci-of-dwcmshc-fix-wbitwise-instead-of-logical-v1-1-7e1a7f4ccaab@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
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: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20230727070051.17778-26-frank.li@vivo.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20230718143054.1065288-1-robh@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently .get_max_clock returns the current clock rate for cclk_emmc
on rk35xx, thus max clock gets set to whatever bootloader set it to.
In case of u-boot, it is intentionally reset to 50 MHz if it boots
from eMMC, see mmc_deinit() in u-boot sources. As a result, HS200 and
HS400 modes are never selected by Linux, because dwcmshc_rk35xx_postinit
clears appropriate caps if host->mmc->f_max is < 52MHz
cclk_emmc is not a fixed clock on rk35xx, so using
sdhci_pltfm_clk_get_max_clock is not appropriate here.
Implement rk35xx_get_max_clock that returns actual max clock for cclk_emmc.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20230310010349.509132-1-anarsoul@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This commit adds ACPI support in the sdhci-of-dwcmshc driver for
BlueField-3 SoC. It has changes to only use the clock hierarchy
for Deviec Tree since the clk is not supported by ACPI. Instead,
ACPI can define 'clock-frequency' which is parsed by existing
sdhci_get_property(). This clock value will be returned in function
dwcmshc_get_max_clock().
Signed-off-by: Liming Sun <limings@nvidia.com>
Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com>
Link: https://lore.kernel.org/r/1616453211-275165-1-git-send-email-limings@nvidia.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit a44f7cb937 ("mmc: core: use mrq->sbc when sending CMD23 for
RPMB") began to use ACMD23 for RPMB if the host supports ACMD23. In
RPMB ACM23 case, we need to set bit 31 to CMD23 argument, otherwise
RPMB write operation will return general fail.
However, no matter V4 is enabled or not, the dwcmshc's ARGUMENT2
register is 32-bit block count register which doesn't support stuff
bits of CMD23 argument. So let's handle this specific ACMD23 case.
From another side, this patch also prepare for future v4 enabling
for dwcmshc, because from the 4.10 spec, the ARGUMENT2 register is
redefined as 32bit block count which doesn't support stuff bits of
CMD23 argument.
Fixes: a44f7cb937 ("mmc: core: use mrq->sbc when sending CMD23 for RPMB")
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20201229161625.38255233@xhacker.debian
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
