Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
56b99a52 |
| 21-Mar-2024 |
Mantas Pucka <mantas@8devices.com> |
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to pro
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
Cc: stable@vger.kernel.org Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by: Mantas Pucka <mantas@8devices.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
56b99a52 |
| 21-Mar-2024 |
Mantas Pucka <mantas@8devices.com> |
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to pro
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
Cc: stable@vger.kernel.org Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by: Mantas Pucka <mantas@8devices.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
56b99a52 |
| 21-Mar-2024 |
Mantas Pucka <mantas@8devices.com> |
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to pro
mmc: sdhci-msm: pervent access to suspended controller
commit f8def10f73a516b771051a2f70f2f0446902cb4f upstream.
Generic sdhci code registers LED device and uses host->runtime_suspended flag to protect access to it. The sdhci-msm driver doesn't set this flag, which causes a crash when LED is accessed while controller is runtime suspended. Fix this by setting the flag correctly.
Cc: stable@vger.kernel.org Fixes: 67e6db113c90 ("mmc: sdhci-msm: Add pm_runtime and system PM support") Signed-off-by: Mantas Pucka <mantas@8devices.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20240321-sdhci-mmc-suspend-v1-1-fbc555a64400@8devices.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43 |
|
#
a7dde463 |
| 27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: sdhci-msm: 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 erro
mmc: sdhci-msm: 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: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230727070051.17778-39-frank.li@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
c62da8a8 |
| 18-Jul-2023 |
Rob Herring <robh@kernel.org> |
mmc: Explicitly include correct DT includes
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 mer
mmc: Explicitly include correct DT includes
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>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30 |
|
#
e6f9e590 |
| 18-May-2023 |
Stephan Gerhold <stephan@gerhold.net> |
mmc: sdhci-msm: Disable broken 64-bit DMA on MSM8916
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 us
mmc: sdhci-msm: Disable broken 64-bit DMA on MSM8916
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>
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24 |
|
#
c7eed31e |
| 08-Apr-2023 |
Abel Vesa <abel.vesa@linaro.org> |
mmc: sdhci-msm: Switch to the new ICE API
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 pla
mmc: sdhci-msm: Switch to the new ICE API
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>
show more ...
|
Revision tags: v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10 |
|
#
3bf90eca |
| 03-Feb-2023 |
Elliot Berman <quic_eberman@quicinc.com> |
firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
Move include/linux/qcom_scm.h to include/linux/firmware/qcom/qcom_scm.h. This removes 1 of a few remaining Qualcomm-specific heade
firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
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
show more ...
|
Revision tags: v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
b98e7e8d |
| 24-Nov-2022 |
ChanWoo Lee <cw9316.lee@samsung.com> |
mmc: Avoid open coding by using mmc_op_tuning()
Replace code with the already defined function. No functional changes.
Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com> Reviewed-by: Adrian Hunter
mmc: Avoid open coding by using mmc_op_tuning()
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>
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6 |
|
#
08b863bb |
| 26-Oct-2022 |
Brian Norris <briannorris@chromium.org> |
mmc: sdhci-*: Convert drivers to new sdhci_and_cqhci_reset()
An earlier patch ("mmc: cqhci: Provide helper for resetting both SDHCI and CQHCI") does these operations for us.
I keep these as a separ
mmc: sdhci-*: Convert drivers to new sdhci_and_cqhci_reset()
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>
show more ...
|
Revision tags: v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70 |
|
#
4de95950 |
| 22-Sep-2022 |
Richard Acayan <mailingradian@gmail.com> |
mmc: sdhci-msm: add compatible string check for sdm670
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 f
mmc: sdhci-msm: add compatible string check for sdm670
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>
show more ...
|
Revision tags: v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55 |
|
#
b05cd716 |
| 14-Jul-2022 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
mmc: sdhci-msm: drop redundant of_device_id entries
This reverts three commits: 1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65" This reverts commit 953706844f0f2fd4dc6984cc010fe
mmc: sdhci-msm: drop redundant of_device_id entries
This reverts three commits: 1. Revert "mmc: sdhci-msm: Add compatible string check for sdx65" This reverts commit 953706844f0f2fd4dc6984cc010fe6cf51c041f2.
2. Revert "mmc: sdhci-msm: Add compatible string check for sm8150" This reverts commit 5acd6adb65802cc6f9986be3750179a820580d37.
3. Revert "mmc: sdhci-msm: Add SoC specific compatibles" This reverts commit 466614a9765c6fb67e1464d0a3f1261db903834b.
The oldest commit 466614a9765c ("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>
show more ...
|
Revision tags: v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
3e5a8e84 |
| 24-Apr-2022 |
Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com> |
mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
Reset GCC_SDCC_BCR register before every fresh initilazation. This will reset whole SDHC-msm controller, clears the previous power control states
mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
Reset GCC_SDCC_BCR register before every fresh initilazation. This will reset whole SDHC-msm controller, clears the previous power control states and avoids, software reset timeout issues as below.
[ 5.458061][ T262] mmc1: Reset 0x1 never completed. [ 5.462454][ T262] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 5.469065][ T262] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 5.475688][ T262] mmc1: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 [ 5.482315][ T262] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 [ 5.488927][ T262] mmc1: sdhci: Present: 0x01f800f0 | Host ctl: 0x00000000 [ 5.495539][ T262] mmc1: sdhci: Power: 0x00000000 | Blk gap: 0x00000000 [ 5.502162][ T262] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000003 [ 5.508768][ T262] mmc1: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 [ 5.515381][ T262] mmc1: sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000 [ 5.521996][ T262] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 5.528607][ T262] mmc1: sdhci: Caps: 0x362dc8b2 | Caps_1: 0x0000808f [ 5.535227][ T262] mmc1: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000 [ 5.541841][ T262] mmc1: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000 [ 5.548454][ T262] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 5.555079][ T262] mmc1: sdhci: Host ctl2: 0x00000000 [ 5.559651][ T262] mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP----------- [ 5.566621][ T262] mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 5.575465][ T262] mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00010800 | DDR cfg: 0x80040873 [ 5.584658][ T262] mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040
Fixes: 0eb0d9f4de34 ("mmc: sdhci-msm: Initial support for Qualcomm chipsets") Signed-off-by: Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1650816153-23797-1-git-send-email-quic_c_sbhanu@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
95370684 |
| 02-May-2022 |
Rohit Agarwal <quic_rohiagar@quicinc.com> |
mmc: sdhci-msm: Add compatible string check for sdx65
Add sdx65 SoC specific compatible string check inside qcom 'sdhci-msm' controller driver.
Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.c
mmc: sdhci-msm: Add compatible string check for sdx65
Add sdx65 SoC specific compatible string check inside qcom 'sdhci-msm' controller driver.
Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> Link: https://lore.kernel.org/r/1651480665-14978-3-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
5acd6adb |
| 29-Apr-2022 |
Bhupesh Sharma <bhupesh.sharma@linaro.org> |
mmc: sdhci-msm: Add compatible string check for sm8150
Add sm8150 SoC specific compatible string check inside qcom 'sdhci-msm' controller driver.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linar
mmc: sdhci-msm: Add compatible string check for sm8150
Add sm8150 SoC specific compatible string check inside qcom 'sdhci-msm' controller driver.
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20220429220833.873672-5-bhupesh.sharma@linaro.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
466614a9 |
| 29-Apr-2022 |
Bhupesh Sharma <bhupesh.sharma@linaro.org> |
mmc: sdhci-msm: Add SoC specific compatibles
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
mmc: sdhci-msm: Add SoC specific compatibles
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>
show more ...
|
#
668806a8 |
| 22-Sep-2022 |
Richard Acayan <mailingradian@gmail.com> |
mmc: sdhci-msm: add compatible string check for sdm670
[ Upstream commit 4de95950d970c71a9e82a24573bb7a44fd95baa1 ]
The Snapdragon 670 has the same quirk as Snapdragon 845 (needing to restore the d
mmc: sdhci-msm: add compatible string check for sdm670
[ Upstream commit 4de95950d970c71a9e82a24573bb7a44fd95baa1 ]
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> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
3c0a0a27 |
| 24-Apr-2022 |
Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com> |
mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
commit 3e5a8e8494a8122fe4eb3f167662f406cab753b9 upstream.
Reset GCC_SDCC_BCR register before every fresh initilazation. This will reset whole SD
mmc: sdhci-msm: Reset GCC_SDCC_BCR register for SDHC
commit 3e5a8e8494a8122fe4eb3f167662f406cab753b9 upstream.
Reset GCC_SDCC_BCR register before every fresh initilazation. This will reset whole SDHC-msm controller, clears the previous power control states and avoids, software reset timeout issues as below.
[ 5.458061][ T262] mmc1: Reset 0x1 never completed. [ 5.462454][ T262] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 5.469065][ T262] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 5.475688][ T262] mmc1: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 [ 5.482315][ T262] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 [ 5.488927][ T262] mmc1: sdhci: Present: 0x01f800f0 | Host ctl: 0x00000000 [ 5.495539][ T262] mmc1: sdhci: Power: 0x00000000 | Blk gap: 0x00000000 [ 5.502162][ T262] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000003 [ 5.508768][ T262] mmc1: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 [ 5.515381][ T262] mmc1: sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000 [ 5.521996][ T262] mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 5.528607][ T262] mmc1: sdhci: Caps: 0x362dc8b2 | Caps_1: 0x0000808f [ 5.535227][ T262] mmc1: sdhci: Cmd: 0x00000000 | Max curr: 0x00000000 [ 5.541841][ T262] mmc1: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0x00000000 [ 5.548454][ T262] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 5.555079][ T262] mmc1: sdhci: Host ctl2: 0x00000000 [ 5.559651][ T262] mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP----------- [ 5.566621][ T262] mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 5.575465][ T262] mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00010800 | DDR cfg: 0x80040873 [ 5.584658][ T262] mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040
Fixes: 0eb0d9f4de34 ("mmc: sdhci-msm: Initial support for Qualcomm chipsets") Signed-off-by: Shaik Sajida Bhanu <quic_c_sbhanu@quicinc.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Konrad Dybcio <konrad.dybcio@somainline.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1650816153-23797-1-git-send-email-quic_c_sbhanu@quicinc.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
ed78a03d |
| 06-Aug-2021 |
Sahitya Tummala <stummala@codeaurora.org> |
mmc: sdhci-msm: Use maximum possible data timeout value
The Qcom SD controller defines the usage of 0xF in data timeout counter register (0x2E) which is actually a reserved bit as per specification.
mmc: sdhci-msm: Use maximum possible data timeout value
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>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51 |
|
#
67b13f3e |
| 16-Jul-2021 |
Shaik Sajida Bhanu <sbhanu@codeaurora.org> |
mmc: sdhci-msm: Update the software timeout value for sdhc
Whenever SDHC run at clock rate 50MHZ or below, the hardware data timeout value will be 21.47secs, which is approx. 22secs and we have a cu
mmc: sdhci-msm: Update the software timeout value for sdhc
Whenever SDHC run at clock rate 50MHZ or below, the hardware data timeout value will be 21.47secs, which is approx. 22secs and we have a current software timeout value as 10secs. We have to set software timeout value more than the hardware data timeout value to avioid seeing the below register dumps.
[ 332.953670] mmc2: Timeout waiting for hardware interrupt. [ 332.959608] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== [ 332.966450] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00007202 [ 332.973256] mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000001 [ 332.980054] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000027 [ 332.986864] mmc2: sdhci: Present: 0x01f801f6 | Host ctl: 0x0000001f [ 332.993671] mmc2: sdhci: Power: 0x00000001 | Blk gap: 0x00000000 [ 333.000583] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 [ 333.007386] mmc2: sdhci: Timeout: 0x0000000e | Int stat: 0x00000000 [ 333.014182] mmc2: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b [ 333.020976] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 [ 333.027771] mmc2: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x0000808f [ 333.034561] mmc2: sdhci: Cmd: 0x0000183a | Max curr: 0x00000000 [ 333.041359] mmc2: sdhci: Resp[0]: 0x00000900 | Resp[1]: 0x00000000 [ 333.048157] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 333.054945] mmc2: sdhci: Host ctl2: 0x00000000 [ 333.059657] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000ffffff218 [ 333.067178] mmc2: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- [ 333.074343] mmc2: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x6000642c | DLL cfg2: 0x0020a000 [ 333.083417] mmc2: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x80040873 [ 333.092850] mmc2: sdhci_msm: Vndr func: 0x00008a9c | Vndr func2 : 0xf88218a8 Vndr func3: 0x02626040 [ 333.102371] mmc2: sdhci: ============================================
So, set software timeout value more than hardware timeout value.
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1626435974-14462-1-git-send-email-sbhanu@codeaurora.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30 |
|
#
ffa4877c |
| 08-Apr-2021 |
Jia Yang <jiayang5@huawei.com> |
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
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>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
411281d2 |
| 14-Mar-2021 |
Yangtao Li <tiny.windzz@gmail.com> |
mmc: sdhci-msm: Convert to use resource-managed OPP API
Use resource-managed OPP API to simplify code.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail
mmc: sdhci-msm: Convert to use resource-managed OPP API
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>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
c93767cf |
| 25-Jan-2021 |
Eric Biggers <ebiggers@google.com> |
mmc: sdhci-msm: add Inline Crypto Engine support
Add support for Qualcomm Inline Crypto Engine (ICE) to sdhci-msm.
The standard-compliant parts, such as querying the crypto capabilities and enablin
mmc: sdhci-msm: add Inline Crypto Engine support
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 df4ec2fa7a4d ("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>
show more ...
|
#
f16c8fd4 |
| 14-Dec-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: sdhci-msm: Actually set the actual clock
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 d
mmc: sdhci-msm: Actually set the actual clock
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>
show more ...
|
#
a8cd989e |
| 14-Dec-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: sdhci-msm: Warn about overclocking SD/MMC
As talked about in commit 5e4b7e82d497 ("clk: qcom: gcc-sdm845: Use floor ops for sdcc clks"), most clocks handled by the Qualcomm clock drivers are ro
mmc: sdhci-msm: Warn about overclocking SD/MMC
As talked about in commit 5e4b7e82d497 ("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>
show more ...
|