<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/mmc/host, branch v6.7.2</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.7.2</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.7.2'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-01-25T23:45:07Z</updated>
<entry>
<title>mmc: sdhci_omap: Fix TI SoC dependencies</title>
<updated>2024-01-25T23:45:07Z</updated>
<author>
<name>Peter Robinson</name>
<email>pbrobinson@gmail.com</email>
</author>
<published>2023-12-20T13:59:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e2ab99c1f1a42da7eabe44cc913a6af8b39cf656'/>
<id>urn:sha1:e2ab99c1f1a42da7eabe44cc913a6af8b39cf656</id>
<content type='text'>
[ Upstream commit 09f164d393a6671e5ff8342ba6b3cb7fe3f20208 ]

The sdhci_omap is specific to  older TI SoCs, update the
dependencies for those SoCs and compile testing. While we're
at it update the text to reflect the wider range of
supported TI SoCS the driver now supports.

Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
Signed-off-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Link: https://lore.kernel.org/r/20231220135950.433588-2-pbrobinson@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci_am654: Fix TI SoC dependencies</title>
<updated>2024-01-25T23:45:07Z</updated>
<author>
<name>Peter Robinson</name>
<email>pbrobinson@gmail.com</email>
</author>
<published>2023-12-20T13:59:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a606be902f66cbe4b876d2e5be80602308e9414f'/>
<id>urn:sha1:a606be902f66cbe4b876d2e5be80602308e9414f</id>
<content type='text'>
[ Upstream commit cb052da7f031b0d2309a4895ca236afb3b4bbf50 ]

The sdhci_am654 is specific to recent TI SoCs, update the
dependencies for those SoCs and compile testing. While we're
at it update the text to reflect the wider range of
supported TI SoCS the driver now supports.

Fixes: 41fd4caeb00b ("mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver")
Signed-off-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Link: https://lore.kernel.org/r/20231220135950.433588-1-pbrobinson@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-sprd: Fix eMMC init failure after hw reset</title>
<updated>2024-01-03T10:24:03Z</updated>
<author>
<name>Wenchao Chen</name>
<email>wenchao.chen@unisoc.com</email>
</author>
<published>2023-12-04T06:49:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8abf77c88929b6d20fa4f9928b18d6448d64e293'/>
<id>urn:sha1:8abf77c88929b6d20fa4f9928b18d6448d64e293</id>
<content type='text'>
Some eMMC devices that do not close the auto clk gate after hw reset will
cause eMMC initialization to fail. Let's fix this.

Signed-off-by: Wenchao Chen &lt;wenchao.chen@unisoc.com&gt;
Fixes: ff874dbc4f86 ("mmc: sdhci-sprd: Disable CLK_AUTO when the clock is less than 400K")
Reviewed-by: Baolin Wang &lt;baolin.wang@linux.alibaba.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231204064934.21236-1-wenchao.chen@unisoc.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: meson-mx-sdhc: Fix initialization frozen issue</title>
<updated>2023-12-07T13:08:19Z</updated>
<author>
<name>Ziyang Huang</name>
<email>hzyitc@outlook.com</email>
</author>
<published>2023-10-10T16:44:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8c124d998ea0c9022e247b11ac51f86ec8afa0e1'/>
<id>urn:sha1:8c124d998ea0c9022e247b11ac51f86ec8afa0e1</id>
<content type='text'>
Commit 4bc31edebde5 ("mmc: core: Set HS clock speed before sending
HS CMD13") set HS clock (52MHz) before switching to HS mode. For this
freq, FCLK_DIV5 will be selected and div value is 10 (reg value is 9).
Then we set rx_clk_phase to 11 or 15 which is out of range and make
hardware frozen. After we send command request, no irq will be
interrupted and the mmc driver will keep to wait for request finished,
even durning rebooting.

So let's set it to Phase 90 which should work in most cases. Then let
meson_mx_sdhc_execute_tuning() to find the accurate value for data
transfer.

If this doesn't work, maybe need to define a factor in dts.

Fixes: e4bf1b0970ef ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Signed-off-by: Ziyang Huang &lt;hzyitc@outlook.com&gt;
Tested-by: Anand Moon &lt;linux.amoon@gmail.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/TYZPR01MB5556A3E71554A2EC08597EA4C9CDA@TYZPR01MB5556.apcprd01.prod.exchangelabs.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-sprd: Fix vqmmc not shutting down after the card was pulled</title>
<updated>2023-11-23T17:04:17Z</updated>
<author>
<name>Wenchao Chen</name>
<email>wenchao.chen@unisoc.com</email>
</author>
<published>2023-11-15T08:34:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=477865af60b2117ceaa1d558e03559108c15c78c'/>
<id>urn:sha1:477865af60b2117ceaa1d558e03559108c15c78c</id>
<content type='text'>
With cat regulator_summary, we found that vqmmc was not shutting
down after the card was pulled.

cat /sys/kernel/debug/regulator/regulator_summary
1.before fix
1)Insert SD card
 vddsdio		1    1  0 unknown  3500mV 0mA  1200mV  3750mV
    71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV

2)Pull out the SD card
 vddsdio                1    1  0 unknown  3500mV 0mA  1200mV  3750mV
    71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV

2.after fix
1)Insert SD cardt
 vddsdio                1    1  0 unknown  3500mV 0mA  1200mV  3750mV
    71100000.mmc-vqmmc  1                         0mA  3500mV  3600mV

2)Pull out the SD card
 vddsdio		0    1  0 unknown  3500mV 0mA  1200mV  3750mV
    71100000.mmc-vqmmc  0                         0mA  3500mV  3600mV

Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
Signed-off-by: Wenchao Chen &lt;wenchao.chen@unisoc.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231115083406.7368-1-wenchao.chen@unisoc.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-pci-gli: Disable LPM during initialization</title>
<updated>2023-11-23T17:01:12Z</updated>
<author>
<name>Kornel Dulęba</name>
<email>korneld@chromium.org</email>
</author>
<published>2023-11-14T11:54:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d9ed644f58670865cf067351deb71010bd87a52f'/>
<id>urn:sha1:d9ed644f58670865cf067351deb71010bd87a52f</id>
<content type='text'>
To address IO performance commit f9e5b33934ce
("mmc: host: Improve I/O read/write performance for GL9763E")
limited LPM negotiation to runtime suspend state.
The problem is that it only flips the switch in the runtime PM
resume/suspend logic.

Disable LPM negotiation in gl9763e_add_host.
This helps in two ways:
1. It was found that the LPM switch stays in the same position after
   warm reboot. Having it set in init helps with consistency.
2. Disabling LPM during the first runtime resume leaves us susceptible
   to the performance issue in the time window between boot and the
   first runtime suspend.

Fixes: f9e5b33934ce ("mmc: host: Improve I/O read/write performance for GL9763E")
Cc: stable@vger.kernel.org
Signed-off-by: Kornel Dulęba &lt;korneld@chromium.org&gt;
Reviewed-by: Sven van Ashbrook &lt;svenva@chromium.org&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20231114115516.1585361-1-korneld@chromium.org
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: cqhci: Fix task clearing in CQE error recovery</title>
<updated>2023-11-14T16:15:08Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2023-11-03T08:47:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1de1b77982e1a1df9707cb11f9b1789e6b8919d4'/>
<id>urn:sha1:1de1b77982e1a1df9707cb11f9b1789e6b8919d4</id>
<content type='text'>
If a task completion notification (TCN) is received when there is no
outstanding task, the cqhci driver issues a "spurious TCN" warning. This
was observed to happen right after CQE error recovery.

When an error interrupt is received the driver runs recovery logic.
It halts the controller, clears all pending tasks, and then re-enables
it. On some platforms, like Intel Jasper Lake, a stale task completion
event was observed, regardless of the CQHCI_CLEAR_ALL_TASKS bit being set.

This results in either:
a) Spurious TC completion event for an empty slot.
b) Corrupted data being passed up the stack, as a result of premature
   completion for a newly added task.

Rather than add a quirk for affected controllers, ensure tasks are cleared
by toggling CQHCI_ENABLE, which would happen anyway if
cqhci_clear_all_tasks() timed out. This is simpler and should be safe and
effective for all controllers.

Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Cc: stable@vger.kernel.org
Reported-by: Kornel Dulęba &lt;korneld@chromium.org&gt;
Tested-by: Kornel Dulęba &lt;korneld@chromium.org&gt;
Co-developed-by: Kornel Dulęba &lt;korneld@chromium.org&gt;
Signed-off-by: Kornel Dulęba &lt;korneld@chromium.org&gt;
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Link: https://lore.kernel.org/r/20231103084720.6886-7-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: cqhci: Warn of halt or task clear failure</title>
<updated>2023-11-14T16:15:07Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2023-11-03T08:47:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=35597bdb04ec27ef3b1cea007dc69f8ff5df75a5'/>
<id>urn:sha1:35597bdb04ec27ef3b1cea007dc69f8ff5df75a5</id>
<content type='text'>
A correctly operating controller should successfully halt and clear tasks.
Failure may result in errors elsewhere, so promote messages from debug to
warnings.

Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Link: https://lore.kernel.org/r/20231103084720.6886-6-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: cqhci: Increase recovery halt timeout</title>
<updated>2023-11-14T16:15:07Z</updated>
<author>
<name>Adrian Hunter</name>
<email>adrian.hunter@intel.com</email>
</author>
<published>2023-11-03T08:47:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b578d5d18e929aa7c007a98cce32657145dde219'/>
<id>urn:sha1:b578d5d18e929aa7c007a98cce32657145dde219</id>
<content type='text'>
Failing to halt complicates the recovery. Additionally, unless the card or
controller are stuck, which is expected to be very rare, then the halt
should succeed, so it is better to wait. Set a large timeout.

Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Link: https://lore.kernel.org/r/20231103084720.6886-3-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdhci-pci-gli: GL9750: Mask the replay timer timeout of AER</title>
<updated>2023-11-07T12:08:12Z</updated>
<author>
<name>Victor Shih</name>
<email>victor.shih@genesyslogic.com.tw</email>
</author>
<published>2023-11-07T09:57:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=015c9cbcf0ad709079117d27c2094a46e0eadcdb'/>
<id>urn:sha1:015c9cbcf0ad709079117d27c2094a46e0eadcdb</id>
<content type='text'>
Due to a flaw in the hardware design, the GL9750 replay timer frequently
times out when ASPM is enabled. As a result, the warning messages will
often appear in the system log when the system accesses the GL9750
PCI config. Therefore, the replay timer timeout must be masked.

Fixes: d7133797e9e1 ("mmc: sdhci-pci-gli: A workaround to allow GL9750 to enter ASPM L1.2")
Signed-off-by: Victor Shih &lt;victor.shih@genesyslogic.com.tw&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Acked-by: Kai-Heng Feng &lt;kai.heng.geng@canonical.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231107095741.8832-2-victorshihgli@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
</feed>
