Merge the mmc fixes for v6.4-rc[n] into the next branch, to allow them to
get tested together with the new mmc changes that are targeted for v6.5.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
While SDHCI claims to support 64-bit DMA on MSM8916 it does not seem to
be properly functional. It is not immediately obvious because SDHCI is
usually used with IOMMU bypassed on this SoC, and all physical memory
has 32-bit addresses. But when trying to enable the IOMMU it quickly
fails with an error such as the following:
arm-smmu 1e00000.iommu: Unhandled context fault:
fsr=0x402, iova=0xfffff200, fsynr=0xe0000, cbfrsynra=0x140, cb=3
mmc1: ADMA error: 0x02000000
mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
mmc1: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000000
mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
mmc1: sdhci: Present: 0x03f80206 | Host ctl: 0x00000019
mmc1: sdhci: Power: 0x0000000f | Blk gap: 0x00000000
mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
mmc1: sdhci: Timeout: 0x0000000a | Int stat: 0x00000001
mmc1: sdhci: Int enab: 0x03ff900b | Sig enab: 0x03ff100b
mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
mmc1: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
mmc1: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
mmc1: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x5b590000
mmc1: sdhci: Resp[2]: 0xe6487f80 | Resp[3]: 0x0a404094
mmc1: sdhci: Host ctl2: 0x00000008
mmc1: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x0000000ffffff224
mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP -----------
mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x60006400 | DLL cfg2: 0x00000000
mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x00000000
mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88018a8 Vndr func3: 0x00000000
mmc1: sdhci: ============================================
mmc1: sdhci: fffffffff200: DMA 0x0000ffffffffe100, LEN 0x0008, Attr=0x21
mmc1: sdhci: fffffffff20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x03
Looking closely it's obvious that only the 32-bit part of the address
(0xfffff200) arrives at the SMMU, the higher 16-bit (0xffff...) get
lost somewhere. This might not be a limitation of the SDHCI itself but
perhaps the bus/interconnect it is connected to, or even the connection
to the SMMU.
Work around this by setting SDHCI_QUIRK2_BROKEN_64_BIT_DMA to avoid
using 64-bit addresses.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230518-msm8916-64bit-v1-1-5694b0f35211@gerhold.net
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Now that there is a new dedicated ICE driver, drop the sdhci-msm ICE
implementation and use the new ICE api provided by the Qualcomm soc
driver ice. The platforms that already have ICE support will use the
API as library since there will not be a devicetree node, but instead
they have reg range. In this case, the of_qcom_ice_get will return an
ICE instance created for the consumer's device. But if there are
platforms that do not have ice reg in the consumer devicetree node
and instead provide a dedicated ICE devicetree node, theof_qcom_ice_get
will look up the device based on qcom,ice property and will get the ICE
instance registered by the probe function of the ice driver.
The ICE clock is now handle by the new driver. This is done by enabling
it on the creation of the ICE instance and then enabling/disabling it on
SDCC runtime resume/suspend.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230408214041.533749-4-abel.vesa@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h.
This removes 1 of a few remaining Qualcomm-specific headers into a more
approciate subdirectory under include/.
Suggested-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com>
Acked-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230203210956.3580811-1-quic_eberman@quicinc.com
Replace code with the already defined function. No functional changes.
Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20221124080031.14690-1-cw9316.lee@samsung.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
An earlier patch ("mmc: cqhci: Provide helper for resetting both SDHCI
and CQHCI") does these operations for us.
I keep these as a separate patch, since the earlier patch is a
prerequisite to some important bugfixes that need to be backported via
linux-stable.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20221026124150.v4.7.Ia91f031f5f770af7bd2ff3e28b398f277606d970@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The Snapdragon 670 has the same quirk as Snapdragon 845 (needing to
restore the dll config). Add a compatible string check to detect the need
for this.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220923014322.33620-3-mailingradian@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts three commits:
1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65"
This reverts commit 953706844f.
2. Revert "mmc: sdhci-msm: Add compatible string check for sm8150"
This reverts commit 5acd6adb65.
3. Revert "mmc: sdhci-msm: Add SoC specific compatibles"
This reverts commit 466614a976.
The oldest commit 466614a976 ("mmc: sdhci-msm: Add SoC specific
compatibles") did not specify what benefits such multiple compatibles
bring, therefore assume there is none. On the other hand such approach
brings a lot of churn to driver maintenance by expecting commit for
every new compatible, even though it is already covered by the fallback.
There is really no sense in duplicating of_device_id for each
variant, which is already covered by generic compatible fallback
qcom,sdhci-msm-v4 or qcom,sdhci-msm-v5.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20220714091042.22287-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Since Qualcomm device-trees already use SoC specific compatibles for
describing the 'sdhci-msm' nodes, it makes sense to add the support for the
same in the driver as well.
Keep the old deprecated compatible strings still in the driver, to ensure
backward compatibility with older device-trees.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Link: https://lore.kernel.org/r/20220429220833.873672-3-bhupesh.sharma@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The Qcom SD controller defines the usage of 0xF in data
timeout counter register (0x2E) which is actually a reserved
bit as per specification. This would result in maximum of 21.26 secs
timeout value.
Some SDcard taking more time than 2.67secs (timeout value corresponding
to 0xE) and with that observed data timeout errors.
So increasing the timeout value to max possible timeout.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1628232901-30897-3-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
- Fix hanging on I/O during system suspend for removable cards
- Set read only for SD cards with permanent write protect bit
- Power cycle the SD/SDIO card if CMD11 fails for UHS voltage
- Issue a cache flush for eMMC only when it's enabled
- Adopt to updated cache ctrl settings for eMMC from MMC ioctls
- Use use device property API when parsing voltages
- Don't retry eMMC sanitize cmds
- Use the timeout from the MMC ioctl for eMMC santize cmds
MMC host:
- mmc_spi: Make of_mmc_spi.c resource provider agnostic
- mmc_spi: Use polling for card detect even without voltage-ranges
- sdhci: Check for reset prior to DMA address unmap
- sdhci-acpi: Add support for the AMDI0041 eMMC controller variant
- sdhci-esdhc-imx: Depending on OF Kconfig and cleanup code
- sdhci-pci: Add PCI IDs for Intel LKF
- sdhci-pci: Fix initialization of some SD cards for Intel BYT
- sdhci-pci-gli: Various improvements for GL97xx variants
- sdhci-of-dwcmshc: Enable support for MMC_CAP_WAIT_WHILE_BUSY
- sdhci-of-dwcmshc: Add ACPI support for BlueField-3 SoC
- sdhci-of-dwcmshc: Add Rockchip platform support
- tmio/renesas_sdhi: Extend support for reset and use a reset controller
- tmio/renesas_sdhi: Enable support for MMC_CAP_WAIT_WHILE_BUSY
- tmio/renesas_sdhi: Various improvements
MEMSTICK:
- Minor improvements/cleanups.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAmCJIGkXHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCnX+w//fvTbFsekv/bYZQoiDDGngbg0
LGUfTZPOLWuzHpiQSY5RjRHvt9CFOc07N96RAqxeqgJ3LS2WzIQSn9asK+5EupXH
CVnWKcYBs+1KthMCRsXjduXILztSQFJGbgO8DYrqvwu9mg6SU3ExfqNhX0O+D0ed
GhzQ55yJTitRpa8S2FYQcirl+clV/5+o3uC82nvaoVR1baE1+catNJ028k/Nd0XE
dFboEE6IJ4qndLWAyBnijYMXbLq/HKmqjeNsR5tooAA/QcXf9tQKqHtdim1N1Cac
THF3hGHMskw7bM4PoupzeJYHzYmL6UINkw192BLMNsGCHidflWTarjUR/5Y2OEz1
eKG5GX+Ww+fdsupN8h448rI1h3EcKJlQFvit9/OIcHS8r7ZeouWNXElH3WUpc3i4
pb3yHBBNMQ3rn0wUfjZh2sggyy+/pRAY1OPfeDud1wggRjg/xVMY3nxpqQmFRKZM
C2/mPUMxaY7zHb9AzCOYCjhgjTPh4HrzIRZeqnZ1FRGuv0yLDG46hc1ufLggCx5P
v1RGB2vJ2hGyWIqvBXw1nF8RwiOCXYXPyZjehWU0K6zryGQPq275/6ziFvL+Nh4U
8liwwHeeIQNvPs7HNzSQ1rXo8elNRvWkqZpvCqTWgJCX4/NFYQTj+Lq2T2EiTxWt
dlr9RLlARJEeutA07rM=
=WL87
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC and MEMSTICK updates from Ulf Hansson:
"MMC core:
- Fix hanging on I/O during system suspend for removable cards
- Set read only for SD cards with permanent write protect bit
- Power cycle the SD/SDIO card if CMD11 fails for UHS voltage
- Issue a cache flush for eMMC only when it's enabled
- Adopt to updated cache ctrl settings for eMMC from MMC ioctls
- Use use device property API when parsing voltages
- Don't retry eMMC sanitize cmds
- Use the timeout from the MMC ioctl for eMMC santize cmds
MMC host:
- mmc_spi: Make of_mmc_spi.c resource provider agnostic
- mmc_spi: Use polling for card detect even without voltage-ranges
- sdhci: Check for reset prior to DMA address unmap
- sdhci-acpi: Add support for the AMDI0041 eMMC controller variant
- sdhci-esdhc-imx: Depending on OF Kconfig and cleanup code
- sdhci-pci: Add PCI IDs for Intel LKF
- sdhci-pci: Fix initialization of some SD cards for Intel BYT
- sdhci-pci-gli: Various improvements for GL97xx variants
- sdhci-of-dwcmshc: Enable support for MMC_CAP_WAIT_WHILE_BUSY
- sdhci-of-dwcmshc: Add ACPI support for BlueField-3 SoC
- sdhci-of-dwcmshc: Add Rockchip platform support
- tmio/renesas_sdhi: Extend support for reset and use a reset controller
- tmio/renesas_sdhi: Enable support for MMC_CAP_WAIT_WHILE_BUSY
- tmio/renesas_sdhi: Various improvements
MEMSTICK:
- Minor improvements/cleanups"
* tag 'mmc-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: (79 commits)
mmc: block: Issue a cache flush only when it's enabled
memstick: r592: ignore kfifo_out() return code again
mmc: block: Update ext_csd.cache_ctrl if it was written
mmc: mmc_spi: Make of_mmc_spi.c resource provider agnostic
mmc: mmc_spi: Use already parsed IRQ
mmc: mmc_spi: Drop unused NO_IRQ definition
mmc: mmc_spi: Set up polling even if voltage-ranges is not present
mmc: core: Convert mmc_of_parse_voltage() to use device property API
mmc: core: Correct descriptions in mmc_of_parse()
mmc: dw_mmc-rockchip: Just set default sample value for legacy mode
mmc: sdhci-s3c: constify uses of driver/match data
mmc: sdhci-s3c: correct kerneldoc of sdhci_s3c_drv_data
mmc: sdhci-s3c: simplify getting of_device_id match data
mmc: tmio: always restore irq register
mmc: sdhci-pci-gli: Enlarge ASPM L1 entry delay of GL975x
mmc: core: Let eMMC sanitize not retry in case of timeout/failure
mmc: core: Add a retries parameter to __mmc_switch function
memstick: r592: remove unused variable
mmc: sdhci-st: Remove unnecessary error log
mmc: sdhci-msm: Remove unnecessary error log
...
devm_ioremap_resource() has recorded error log, so it's
unnecessary to record log again.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jia Yang <jiayang5@huawei.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20210409015424.3277212-1-jiayang5@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use resource-managed OPP API to simplify code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Add support for Qualcomm Inline Crypto Engine (ICE) to sdhci-msm.
The standard-compliant parts, such as querying the crypto capabilities
and enabling crypto for individual MMC requests, are already handled by
cqhci-crypto.c, which itself is wired into the blk-crypto framework.
However, ICE requires vendor-specific init, enable, and resume logic,
and it requires that keys be programmed and evicted by vendor-specific
SMC calls. Make the sdhci-msm driver handle these details.
This is heavily inspired by the similar changes made for UFS, since the
UFS and eMMC ICE instances are very similar. See commit df4ec2fa7a
("scsi: ufs-qcom: Add Inline Crypto Engine support").
I tested this on a Sony Xperia 10, which uses the Snapdragon 630 SoC,
which has basic upstream support. Mainly, I used android-xfstests
(https://github.com/tytso/xfstests-bld/blob/master/Documentation/android-xfstests.md)
to run the ext4 and f2fs encryption tests in a Debian chroot:
android-xfstests -c ext4,f2fs -g encrypt -m inlinecrypt
These tests included tests which verify that the on-disk ciphertext is
identical to that produced by a software implementation. I also
verified that ICE was actually being used.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Satya Tangirala <satyat@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20210126001456.382989-9-ebiggers@kernel.org
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>
As talked about in commit 5e4b7e82d4 ("clk: qcom: gcc-sdm845: Use
floor ops for sdcc clks"), most clocks handled by the Qualcomm clock
drivers are rounded _up_ by default instead of down. We should make
sure SD/MMC clocks are always rounded down in the clock drivers.
Let's add a warning in the Qualcomm SDHCI driver to help catch the
problem.
This would have saved a bunch of time [1].
NOTE: this doesn't actually fix any problems, it just makes it obvious
to devs that there is a problem and that should be an indication to
fix the clock driver.
[1] http://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20201214092048.v5.1.Iec3430c7d3c2a29262695edef7b82a14aaa567e5@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Detect if tassadar_dll is required by using core version rather than
just specifying it in the sdhci_msm_variant_info.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Reviewed-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/20201112173636.360186-1-dmitry.baryshkov@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/890ae5601594fca5de104695a682f4b6efbc631b.1599660554.git.viresh.kumar@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Turning on initcall debug on one system showed this:
initcall sdhci_msm_driver_init+0x0/0x28 returned 0 after 34782 usecs
The lion's share of this time (~33 ms) was in mmc_power_up(). This
shouldn't be terribly surprising since there are a few calls to delay
based on "power_delay_ms" and the default delay there is 10 ms.
Because we haven't specified that we'd prefer asynchronous probe for
this driver then we'll wait for this driver to finish before we start
probes for more drivers. While 33 ms doesn't sound like tons, every
little bit counts.
There should be little problem with turning on asynchronous probe for
this driver. It's already possible that previous drivers may have
turned on asynchronous probe so we might already have other things
(that probed before us) probing at the same time we are anyway. This
driver isn't really providing resources (clocks, regulators, etc) that
other drivers need to probe and even if it was they should be handling
-EPROBE_DEFER.
Let's turn this on and get a bit of boot speed back.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200902164303.1.I5e598a25222b4534c0083b61dbfa4e0e76f66171@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On sc7180 target, issues are observed with HS400 mode due to a
hardware limitation. If sdcc clock is dynamically gated and ungated,
the very next command is failing with command CRC/timeout errors.
To mitigate this issue, DLL phase has to be restored whenever sdcc
clock is gated dynamically. The restore_dll_config ensures this.
Enabling this flag with this change. And simply re-using the sdm845
target configuration for this flag.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/1598541694-15694-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
As the comments in this patch say, if we tune and find all phases are
valid it's _almost_ as bad as no phases being found valid. Probably
all phases are not really reliable but we didn't detect where the
unreliable place is. That means we'll essentially be guessing and
hoping we get a good phase.
This is not just a problem in theory. It was causing real problems on
a real board. On that board, most often phase 10 is found as the only
invalid phase, though sometimes 10 and 11 are invalid and sometimes
just 11. Some percentage of the time, however, all phases are found
to be valid. When this happens, the current logic will decide to use
phase 11. Since phase 11 is sometimes found to be invalid, this is a
bad choice. Sure enough, when phase 11 is picked we often get mmc
errors later in boot.
I have seen cases where all phases were found to be valid 3 times in a
row, so increase the retry count to 10 just to be extra sure.
Fixes: 415b5a75da ("mmc: sdhci-msm: Add platform_execute_tuning implementation")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200827075809.1.If179abf5ecb67c963494db79c3bc4247d987419b@changeid
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
__sdhci_msm_set_clock()'s function header is the only one in
kerneldoc format. Which seems odd as it's not part of an
external API and isn't referenced anywhere else. Seeing as
there has also been no attempt to describe the expected
function arguments either, we're going to assume that this is
not actually a bona fide kerneldoc use-case.
Fixes the following W=1 kernel build warnings:
drivers/mmc/host/sdhci-msm.c:1595: warning: Function parameter or member 'host' not described in '__sdhci_msm_set_clock'
drivers/mmc/host/sdhci-msm.c:1595: warning: Function parameter or member 'clock' not described in '__sdhci_msm_set_clock'
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20200701124702.908713-14-lee.jones@linaro.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fix sparse build warning:
drivers/mmc/host/sdhci-msm.c:1888:6: warning:
symbol 'sdhci_msm_dump_vendor_regs' was not declared. Should it be static?
Signed-off-by: Hulk Robot <hulkci@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200702020347.77214-1-weiyongjun1@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On qcom SD host controllers voltage switching be done after the HW
is ready for it. The HW informs its readiness through power irq.
The voltage switching should happen only then.
Use the internal voltage switching and then control the voltage
switching using power irq.
IO-bus supply of eMMC would be kept always-on. So set the load
for this supply to configure it in LPM when eMMC is suspend state
and in HPM when eMMC is active.
Co-developed-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Co-developed-by: Vijay Viswanath <vviswana@codeaurora.org>
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
Co-developed-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1592919288-1020-4-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Interconnect bandwidth scaling support is now added as a
part of OPP. So, make sure interconnect driver is ready
before handling interconnect scaling.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/1591691846-7578-2-git-send-email-ppvk@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
During DLL initialization, the DLL_CONFIG register value would be
updated with the value supplied from the device-tree.
Override this register only if a valid value is supplied.
Fixes: 03591160ca ("mmc: sdhci-msm: Read and use DLL Config property from device tree file")
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1594213888-2780-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Clear tuning_done flag while executing tuning to ensure vendor
specific HS400 settings are applied properly when the controller
is re-initialized in HS400 mode.
Without this, re-initialization of the qcom SDHC in HS400 mode fails
while resuming the driver from runtime-suspend or system-suspend.
Fixes: ff06ce4178 ("mmc: sdhci-msm: Add HS400 platform support")
Cc: stable@vger.kernel.org
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1590678838-18099-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Implement dump_vendor_registers host operation to print the
vendor specific registers in addition to standard SDHC
register during error conditions.
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1590139950-7288-9-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Certain platforms require different settings in the
SDCC_HC_REG_DLL_CONFIG register. This setting can change from platform
to platform. So the driver should check whether a particular platform
require a different setting by reading the DT file and use it.
Also use msm_cm_dll_set_freq only when DLL not supplied.
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1590139950-7288-7-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Certain platforms require different settings in the
SDCC_HC_REG_DDR_CONFIG register. This setting can change from platform
to platform. So the driver should check whether a particular platform
require a different setting by reading the device tree file and use it.
Signed-off-by: Bao D. Nguyen <nguyenb@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1590139950-7288-6-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Update dll_config_3 as per the host clock frequency as specified in the
DLL Hardware Reference Guide.
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1590139950-7288-5-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
With SDCC v5.1.0, additional setting needed for enabling DLL output.
The dll-user-control register need to be configured during dll
initialization for getting proper dll output.
Without this configuration, we don't get the DLL lock status properly.
Also update the DLL register settings according to the SDCC Hardware
Programming Guide.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Signed-off-by: Sarthak Garg <sartgarg@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1590139950-7288-4-git-send-email-sartgarg@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Even though specifying OPP's in device tree is optional, ignoring all errors
reported by dev_pm_opp_of_add_table() means we can't distinguish between a
missing OPP table and a wrong/buggy OPP table. While missing OPP table
(dev_pm_opp_of_add_table() returns a -ENODEV in such case) can be ignored,
a wrong/buggy OPP table in device tree should make the driver error out.
while we fix that, lets also fix the variable names for opp/opp_table to
avoid confusion and name them opp_table/has_opp_table instead.
Suggested-by: Matthias Kaehlcke <matthias@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Link: https://lore.kernel.org/r/1588080785-6812-10-git-send-email-rnayak@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
On some qualcomm SoCs we need to vote on a performance state of a power
domain depending on the clock rates. Hence move to using OPP api to set
the clock rate and performance state specified in the OPP table.
On platforms without an OPP table, dev_pm_opp_set_rate() is eqvivalent to
clk_set_rate()
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Link: https://lore.kernel.org/r/1587132279-27659-10-git-send-email-rnayak@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
ADMA_ERR_SIZE_EN bit of VENDOR_SPECIFIC_FUNC register controls
ADMA length mismatch error interrupt. Enable it by default.
And update all bit shift defines with BIT macro.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-4-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sdhci-msm can support auto cmd12.
So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-3-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
MSM sd host controller is capable of HW busy detection of device busy
signaling over DAT0 line. And it requires the R1B response for commands
that have this response associated with them.
So set the below two host capabilities for qcom SDHC.
- MMC_CAP_WAIT_WHILE_BUSY
- MMC_CAP_NEED_RSP_BUSY
Recent development of the mmc core in regards to this, revealed this as
being a potential bug, hence the stable tag.
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When SDHC gets reset (E.g. in runtime suspend path), CQE also gets
reset and goes to disable state. But s/w state still points it as CQE
is in enabled state. Since s/w and h/w states goes out of sync,
it results in s/w request timeout for subsequent CQE requests.
To synchronize CQE s/w and h/w state during SDHC reset,
explicitly deactivate CQE just before SDHC reset.
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1583503724-13943-3-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
SDHC core with new 14lpp and later tech DLL should not enable
PWRSAVE_DLL since such controller's internal gating cannot meet
following MCLK requirement:
When MCLK is gated OFF, it is not gated for less than 0.5us and MCLK
must be switched on for at-least 1us before DATA starts coming.
Adding support for this requirement.
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Reviewed-by: Can Guo <cang@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/1581077075-26011-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This function is not exported and only used in this file. Mark it static.
Cc: Ritesh Harjani <riteshh@codeaurora.org>
Cc: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Fixes: 87a8df0dce ("mmc: sdhci-msm: Add CQHCI support for sdhci-msm")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/20200206162124.201195-1-swboyd@chromium.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
