Add a resource-managed variant of blk_ksm_init() so that drivers don't
have to worry about calling blk_ksm_destroy().
Note that the implementation uses a custom devres action to call
blk_ksm_destroy() rather than switching the two allocations to be
directly devres-managed, e.g. with devm_kmalloc(). This is because we
need to keep zeroing the memory containing the keyslots when it is
freed, and also because we want to continue using kvmalloc() (and there
is no devm_kvmalloc()).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Satya Tangirala <satyat@google.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/20210121082155.111333-2-ebiggers@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Randy found that with the following Kconfig settings we have duplicate
definitions (e.g. __inittest()) in sdhci-of-aspeed due to competing
module_init()/module_exit() calls from kunit and driver the itself.
```
CONFIG_MMC_SDHCI_OF_ASPEED=m
CONFIG_MMC_SDHCI_OF_ASPEED_TEST=y
```
Conditionally open-code the kunit initialisation to avoid the error.
Fixes: 7efa02a981d6 ("mmc: sdhci-of-aspeed: Add KUnit tests for phase calculations")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Link: https://lore.kernel.org/r/20210122114852.3790565-1-andrew@aj.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The RPi4 has an Arasan controller it carries over from the RPi3 and a newer
eMMC2 controller. Because of a couple of quirks, it seems wiser to bind
these controllers to the same driver that DT is using on this platform
rather than the generic sdhci_acpi driver with PNP0D40.
So, BCM2847 describes the older Arasan and BRCME88C describes the newer
eMMC2. The older Arasan is reusing an existing ACPI _HID used by other OSes
booting these tables on the RPi.
With this change, Linux is capable of utilizing the SD card slot, and the
Wi-Fi when booted with UEFI+ACPI on the RPi4.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20210120000406.1843400-2-jeremy.linton@arm.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The AST2600 can achieve HS200 speeds with a change to the bus clock
divisor behaviour. The divisor can also be more accurate with respect
to the requested clock rate, but keep the one-hot behaviour for
backwards compatibility with the AST2400 and AST2500.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210114031433.2388532-4-andrew@aj.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The Aspeed SD/eMMC controllers expose configurable clock phase
correction by inserting delays of up to 15 logic elements in length into
the bus clock path. The hardware supports independent configuration for
both bus directions on a per-slot basis.
The timing delay per element encoded in the driver was experimentally
determined by scope measurements.
The phase controls for both slots are grouped together in a single
register of the global register block of the SD/MMC controller(s), which
drives the use of a locking scheme between the SDHCIs and the global
register set.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210114031433.2388532-3-andrew@aj.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Drivers for MMC hosts that accept phase corrections can take advantage
of the helper by embedding an instance of struct mmc_clk_phase_map in
their private data and invoking mmc_of_parse_clk_phase() to extract
phase parameters. It is the responsibility of the host driver to
translate and apply the extracted values to hardware as required.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210114031433.2388532-2-andrew@aj.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On TI J7200 SoC the SDHCI controller compatible defined as
"ti,j7200-sdhci-8bit", "ti,j721e-sdhci-8bit"
or
"ti,j7200-sdhci-4bit", "ti,j721e-sdhci-4bit"
which causes dtbs_check warnings:
mmc@4f80000: compatible: ['ti,j7200-sdhci-8bit', 'ti,j721e-sdhci-8bit'] is too long
mmc@4f80000: compatible: Additional items are not allowed ('ti,j721e-sdhci-8bit' was unexpected)
mmc@4fb0000: compatible:0: 'ti,j7200-sdhci-4bit' is not one of ['ti,am654-sdhci-5.1', 'ti,j721e-sdhci-8bit',
'ti,j721e-sdhci-4bit', 'ti,j7200-sdhci-8bit', 'ti,j721e-sdhci-4bit', 'ti,am64-sdhci-8bit', 'ti,am64-sdhci-4bit']
mmc@4fb0000: compatible: ['ti,j7200-sdhci-4bit', 'ti,j721e-sdhci-4bit'] is too long
mmc@4fb0000: compatible: Additional items are not allowed ('ti,j721e-sdhci-4bit' was unexpected)
Fix it by adding missing compatible strings and their combinations.
Fixes: 407d0c2cdd ("dt-bindings: mmc: sdhci-am654: Convert sdhci-am654 controller documentation to json schema")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Link: https://lore.kernel.org/r/20210115193218.5809-1-grygorii.strashko@ti.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
GL9763E enters ASPM L1 state after a very short idle in default,
even during a burst of request. So the R/W performance of GL9763E
is low with some platforms, which support ASPM mechanism, due to
entering ASPM L1 state very frequently in R/W process. Set the L1
entry delay bits in vendor-specific register to 0x3FF to enlarge
the idle period to 260us for improving the R/W performance
of GL9763E.
Signed-off-by: Renius Chen <reniuschengl@gmail.com>
Link: https://lore.kernel.org/r/20210115054736.27769-1-reniuschengl@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 36c6aadaae ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay")
introduces syscon map sdhci_arasan_update_support64b(). Unfortunately,
kernel-doc format script tool has not been run before and causing warning
on the documentation style.
Below is the output when running the kernel-doc script tool:
drivers/mmc/host/sdhci-of-arasan.c:1388: warning: contents before sections
Let's fix this by using standard conventions kernel-doc format.
Fixes: 36c6aadaae ("mmc: sdhci-of-arasan: Add support for Intel Keem Bay")
Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20210111155001.12307-2-muhammad.husaini.zulkifli@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enable SGDMA support for SD_IO_RW_EXTENDED and add proper check
for scatterlist size alignment in block mode.
According to documentation, in SDIO block mode meson-gx DMA could
only handle buffers with sizes that are multiples of SDIO block size.
Some SDIO drivers like brcmfmac use scatterlist API, but do not enforce
proper scatterlist buffer size alignemnt, this looks like a root cause
of non-working CMD53.
Some minor style fixes.
Signed-off-by: Dmitry Lebed <lebed.dmitry@gmail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20201218075312.67338-1-lebed.dmitry@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
when get request SW timeout, if CMD/DAT xfer done irq coming right now,
then there is race between the msdc_request_timeout work and irq handler,
and the host->cmd and host->data may set to NULL in irq handler. also,
current flow ensure that only one path can go to msdc_request_done(), so
no need check the return value of cancel_delayed_work().
Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Link: https://lore.kernel.org/r/20201218071611.12276-1-chaotian.jing@mediatek.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The MSM SDHCI driver always set the "actual_clock" field to 0. It had
a comment about it not being needed because we weren't using the
standard SDHCI divider mechanism and we'd just fallback to
"host->clock". However, it's still better to provide the actual
clock. Why?
1. It will make timeout calculations slightly better. On one system I
have, the eMMC requets 200 MHz (for HS400-ES) but actually gets 192
MHz. These are close, but why not get the more accurate one.
2. If things are seriously off in the clock driver and it's missing
rates or picking the wrong rate (maybe it's rounding up instead of
down), this will make it much more obvious what's going on.
NOTE: we have to be a little careful here because the "actual_clock"
field shouldn't include the multiplier that sdhci-msm needs
internally.
Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/20201214092048.v5.2.I7564620993acd4baa63fa0e3925ca879a86d3ee3@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
