Revision tags: v6.6.25, v6.6.24, v6.6.23, 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 |
|
#
f0cdeb7c |
| 27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: xenon: 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 ha
mmc: xenon: 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: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230727070051.17778-20-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, 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, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, 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, 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, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, 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, 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, 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, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
7e2646ed |
| 18-Mar-2022 |
Pali Rohár <pali@kernel.org> |
Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.
Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization
Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.
Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") contains proper fix for the issue described in commit bb32e1987bc5 ("mmc: sdhci-xenon: fix annoying 1.8V regulator warning").
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable") Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
86b5d155 |
| 18-Mar-2022 |
Pali Rohár <pali@kernel.org> |
Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
commit 7e2646ed47542123168d43916b84b954532e5386 upstream.
This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.
Commit 1a3ed0
Revert "mmc: sdhci-xenon: fix annoying 1.8V regulator warning"
commit 7e2646ed47542123168d43916b84b954532e5386 upstream.
This reverts commit bb32e1987bc55ce1db400faf47d85891da3c9b9f.
Commit 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") contains proper fix for the issue described in commit bb32e1987bc5 ("mmc: sdhci-xenon: fix annoying 1.8V regulator warning").
Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable") Cc: stable@vger.kernel.org # 1a3ed0dc3594 ("mmc: sdhci-xenon: fix 1.8v regulator stabilization") Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <kabel@kernel.org> Reviewed-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20220318141441.32329-1-pali@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: 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, v5.10.53, v5.10.52, v5.10.51, 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, v5.10.27, v5.10.26, v5.10.25, v5.10.24, 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 |
|
#
7214d792 |
| 12-Jan-2021 |
Marcin Wojtas <mw@semihalf.com> |
mmc: xenon: add AP807 compatible string
This patch adds new compatible string to differentiate between the controllers versions included in the AP807 north bridge. Thanks to this change, the SoCs wh
mmc: xenon: add AP807 compatible string
This patch adds new compatible string to differentiate between the controllers versions included in the AP807 north bridge. Thanks to this change, the SoCs which use AP807 will not run unintentionally in the 'slow mode' with disabled UHS modes.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Link: https://lore.kernel.org/r/20210112094655.12274-3-kostap@marvell.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10 |
|
#
1a3ed0dc |
| 11-Dec-2020 |
Alex Leibovich <alexl@marvell.com> |
mmc: sdhci-xenon: fix 1.8v regulator stabilization
Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stab
mmc: sdhci-xenon: fix 1.8v regulator stabilization
Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platforms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later.
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich <alexl@marvell.com> Signed-off-by: Marcin Wojtas <mw@semihalf.com> Cc: stable@vger.kernel.org Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
471cf454 |
| 04-Dec-2020 |
Marcin Wojtas <mw@semihalf.com> |
mmc: sdhci-xenon: introduce ACPI support
Previous patches dropped the strict dependency on the OF_* in the sdhci-xenon driver. As a result the ACPI support can be introduced (except for the XENON_A3
mmc: sdhci-xenon: introduce ACPI support
Previous patches dropped the strict dependency on the OF_* in the sdhci-xenon driver. As a result the ACPI support can be introduced (except for the XENON_A3700 variant) by adding the necessary ID's in the acpi_match_table.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-5-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
15424880 |
| 04-Dec-2020 |
Marcin Wojtas <mw@semihalf.com> |
mmc: sdhci-xenon: use clk only with DT
As a preparation for supporting ACPI, modify the driver to use the clk framework only when booting with DT - otherwise rely on the configuration done by firmwa
mmc: sdhci-xenon: use clk only with DT
As a preparation for supporting ACPI, modify the driver to use the clk framework only when booting with DT - otherwise rely on the configuration done by firmware. For that purpose introduce also a custom SDHCI get_max_clock callback.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-4-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
f29bf660 |
| 04-Dec-2020 |
Marcin Wojtas <mw@semihalf.com> |
mmc: sdhci-xenon: switch to device_* API
In order to support both ACPI and DT, modify the driver to use device_* routines for obtaining the properties values.
Signed-off-by: Marcin Wojtas <mw@semih
mmc: sdhci-xenon: switch to device_* API
In order to support both ACPI and DT, modify the driver to use device_* routines for obtaining the properties values.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-3-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
f75fda37 |
| 04-Dec-2020 |
Marcin Wojtas <mw@semihalf.com> |
mmc: sdhci-xenon: use match data for controllers variants
As a part of the ACPI support preparation resign from checking compatible strings in the driver. Instead of that use a new enum and assign t
mmc: sdhci-xenon: use match data for controllers variants
As a part of the ACPI support preparation resign from checking compatible strings in the driver. Instead of that use a new enum and assign the values to match data accordingly.
Signed-off-by: Marcin Wojtas <mw@semihalf.com> Link: https://lore.kernel.org/r/20201204171626.10935-2-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
b97c26cf |
| 11-Dec-2020 |
Alex Leibovich <alexl@marvell.com> |
mmc: sdhci-xenon: fix 1.8v regulator stabilization
commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream.
Automatic Clock Gating is a feature used for the power consumption optimisation. It turn
mmc: sdhci-xenon: fix 1.8v regulator stabilization
commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream.
Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platforms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later.
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich <alexl@marvell.com> Signed-off-by: Marcin Wojtas <mw@semihalf.com> Cc: stable@vger.kernel.org Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7 |
|
#
7320915c |
| 03-Sep-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14
This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batc
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14
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.14 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> # SDHI drivers Link: https://lore.kernel.org/r/20200903162412.3.Id1ff21470f08f427aedd0a6535dcd83ccc56b278@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34 |
|
#
bb32e198 |
| 20-Apr-2020 |
Marek Behún <marek.behun@nic.cz> |
mmc: sdhci-xenon: fix annoying 1.8V regulator warning
For some reason the Host Control2 register of the Xenon SDHCI controller sometimes reports the bit representing 1.8V signaling as 0 when read af
mmc: sdhci-xenon: fix annoying 1.8V regulator warning
For some reason the Host Control2 register of the Xenon SDHCI controller sometimes reports the bit representing 1.8V signaling as 0 when read after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report 1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many times, and in each resume the switch to 1.8V is called, and so the kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's .voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz> Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...") Cc: stable@vger.kernel.org # v4.16+ Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3 |
|
#
c6303c5d |
| 24-Jul-2019 |
Baolin Wang <baolin.wang@linaro.org> |
mmc: sdhci-sprd: Fix the incorrect soft reset operation when runtime resuming
The SD host controller specification defines 3 types software reset: software reset for data line, software reset for co
mmc: sdhci-sprd: Fix the incorrect soft reset operation when runtime resuming
The SD host controller specification defines 3 types software reset: software reset for data line, software reset for command line and software reset for all. Software reset for all means this reset affects the entire Host controller except for the card detection circuit.
In sdhci_runtime_resume_host() we always do a software "reset for all", which causes the Spreadtrum variant controller to work abnormally after resuming. To fix the problem, let's do a software reset for the data and the command part, rather than "for all".
However, as sdhci_runtime_resume() is a common sdhci function and we don't want to change the behaviour for other variants, let's introduce a new in-parameter for it. This enables the caller to decide if a "reset for all" shall be done or not.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
a10e763b |
| 31-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 372
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 372
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 version 2
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 135 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/20190531081036.435762997@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9 |
|
#
0e6e7c2f |
| 10-Dec-2018 |
Adrian Hunter <adrian.hunter@intel.com> |
mmc: sdhci-xenon: Fix timeout checks
Always check the wait condition before returning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Zhoujie Wu <zjwu@marvell.com> Sign
mmc: sdhci-xenon: Fix timeout checks
Always check the wait condition before returning timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Zhoujie Wu <zjwu@marvell.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15 |
|
#
8d876bf4 |
| 18-Dec-2017 |
Zhoujie Wu <zjwu@marvell.com> |
mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
According to SD spec 3.00 3.6.1 signal voltage switch procedure step 6~8, (6) Set 1.8V Signal Enable in the Host Control 2 register. (7) Wait
mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
According to SD spec 3.00 3.6.1 signal voltage switch procedure step 6~8, (6) Set 1.8V Signal Enable in the Host Control 2 register. (7) Wait 5ms. 1.8V voltage regulator shall be stable within this period. (8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12). Host should wait 5ms after set 1.8V signal enable bit in Host Control 2 register and check if 1.8V is stable or not.
But current code checks this bit right after set it. On some platforms with xenon controller found the bit is cleared right away and host reports "1.8V regulator output did not became stable" and 5ms delay can help.
Implement voltage_switch callback for xenon controller to add 5ms delay to make sure the 1.8V signal enable bit is set by controller.
Signed-off-by: Zhoujie Wu <zjwu@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.13.16, v4.14, v4.13.5 |
|
#
bb16ea17 |
| 02-Oct-2017 |
Gregory CLEMENT <gregory.clement@free-electrons.com> |
mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at l
mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock
On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock is optional because not all the SoCs need them but at least for Armada 7K/8K it is actually mandatory.
The binding documentation is updating accordingly.
Without this patch the kernel hand during boot if the mvpp2.2 network driver was not present in the kernel. Indeed the clock needed by the xenon controller was set by the network driver.
Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality)" CC: Stable <stable@vger.kernel.org> Tested-by: Zhoujie Wu <zjwu@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.13 |
|
#
a027b2c5 |
| 29-Aug-2017 |
Zhoujie Wu <zjwu@marvell.com> |
mmc: sdhci-xenon: add runtime pm support and reimplement standby
Enable runtime pm support for xenon controller, which uses 50ms auto runtime suspend by default. Reimplement system standby based on
mmc: sdhci-xenon: add runtime pm support and reimplement standby
Enable runtime pm support for xenon controller, which uses 50ms auto runtime suspend by default. Reimplement system standby based on runtime pm API. Introduce restore_needed to restore the Xenon specific registers when resume.
Signed-off-by: Zhoujie Wu <zjwu@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
99c14fc3 |
| 21-Aug-2017 |
Zhoujie Wu <zjwu@marvell.com> |
mmc: sdhci-xenon: add set_power callback
Xenon sdh controller requests proper SD bus voltage select bits programmed even with vmmc power supply. Any reserved value(100b-000b) programmed in this fiel
mmc: sdhci-xenon: add set_power callback
Xenon sdh controller requests proper SD bus voltage select bits programmed even with vmmc power supply. Any reserved value(100b-000b) programmed in this field will lead to controller ignore SD bus power bit and keep its value at zero. Add set_power callback to handle this.
Signed-off-by: Zhoujie Wu <zjwu@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Cc: <stable@vger.kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
a0fd95b3 |
| 12-Jul-2017 |
Hu Ziji <huziji@marvell.com> |
mmc: sdhci-xenon: Add Xenon SDHCI specific system-level PM support
Add Xenon specific system-level suspend and resume support. Especially during resume, re-configure Xenon specific registers since r
mmc: sdhci-xenon: Add Xenon SDHCI specific system-level PM support
Add Xenon specific system-level suspend and resume support. Especially during resume, re-configure Xenon specific registers since registers setting will be lost in suspend if Xenon is power off.
Signed-off-by: Hu Ziji <huziji@marvell.com> Signed-off-by: Zhoujie Wu <zjwu@marvell.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
468c6483 |
| 21-Jul-2017 |
Zhoujie Wu <zjwu@marvell.com> |
mmc: sdhci-xenon: ignore timing DDR52 in tuning
Emmc DDR52 mode uses fixed delay, return earlier if timing is MMC_TIMING_MMC_DDR52 in execute tuning function.
Signed-off-by: Zhoujie Wu <zjwu@marvel
mmc: sdhci-xenon: ignore timing DDR52 in tuning
Emmc DDR52 mode uses fixed delay, return earlier if timing is MMC_TIMING_MMC_DDR52 in execute tuning function.
Signed-off-by: Zhoujie Wu <zjwu@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
a3a56aee |
| 06-Jul-2017 |
Shawn Lin <shawn.lin@rock-chips.com> |
mmc: sdhci-xenon: remove pointless struct xenon_priv *priv
It was never used and leave a long standing compile warning:
drivers/mmc/host/sdhci-xenon.c: In function 'xenon_probe': drivers/mmc/host/s
mmc: sdhci-xenon: remove pointless struct xenon_priv *priv
It was never used and leave a long standing compile warning:
drivers/mmc/host/sdhci-xenon.c: In function 'xenon_probe': drivers/mmc/host/sdhci-xenon.c:447:21: warning: variable 'priv' set but not used [-Wunused-but-set-variable]
Remove it to fix the warning.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.12, v4.10.17 |
|
#
bae3dee0 |
| 16-May-2017 |
Jisheng Zhang <jszhang@marvell.com> |
mmc: sdhci-xenon: kill xenon_clean_phy()
Currently, the xenon_clean_phy() is only used for freeing phy_params. The phy_params is allocated by devm_kzalloc(), there's no need to free is explicitly.
mmc: sdhci-xenon: kill xenon_clean_phy()
Currently, the xenon_clean_phy() is only used for freeing phy_params. The phy_params is allocated by devm_kzalloc(), there's no need to free is explicitly.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Hu Ziji <huziji@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
show more ...
|
Revision tags: v4.10.16, v4.10.15, v4.10.14 |
|
#
4cc59dff |
| 27-Apr-2017 |
Hu Ziji <huziji@marvell.com> |
mmc: sdhci-xenon: Fix the work flow in xenon_remove().
sdhci_remove_host() might execute SOFT_RESET_ALL. Inside xenon_remove(), Xenon SDHC should be enabled during sdhci_remove_host().
Move xenon_
mmc: sdhci-xenon: Fix the work flow in xenon_remove().
sdhci_remove_host() might execute SOFT_RESET_ALL. Inside xenon_remove(), Xenon SDHC should be enabled during sdhci_remove_host().
Move xenon_sdhc_unprepare after sdhci_remove_host() such that Xenon SDHC is disabled after sdhci_remove_host() completes.
Signed-off-by: Hu Ziji <huziji@marvell.com> Reported-by: Jisheng Zhang <jszhang@marvell.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8 |
|
#
298269c6 |
| 30-Mar-2017 |
Hu Ziji <huziji@marvell.com> |
mmc: sdhci-xenon: Add SoC PHY PAD voltage control
Some SoCs have PHY PAD outside Xenon IP. PHY PAD voltage should match signalling voltage in use.
Add generic SoC PHY PAD voltage control interface.
mmc: sdhci-xenon: Add SoC PHY PAD voltage control
Some SoCs have PHY PAD outside Xenon IP. PHY PAD voltage should match signalling voltage in use.
Add generic SoC PHY PAD voltage control interface. Implement Aramda-3700 SoC PHY PAD voltage control.
Signed-off-by: Hu Ziji <huziji@marvell.com> Tested-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|