<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/mmc, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>mmc: sdhci-cadence: trigger tuning for SD HS mode on SD6HC (v6) PHY</title>
<updated>2026-05-12T17:42:41+00:00</updated>
<author>
<name>Tze Yee Ng</name>
<email>tze.yee.ng@altera.com</email>
</author>
<published>2026-05-05T02:36:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b42c67188c1453a68de4464b07a21da660f811c6'/>
<id>b42c67188c1453a68de4464b07a21da660f811c6</id>
<content type='text'>
The Cadence SD6HC (SDHCI spec v4.20+) controller uses a soft PHY whose
DLL delay characteristics vary with PVT (Process, Voltage, Temperature)
and board-level trace routing.

A static delay value programmed via device tree for SD High Speed mode is
insufficient because the optimal sampling point varies per board, SD card,
and operating conditions. Runtime calibration is required.

While the SD Physical Layer Specification does not mandate tuning for
SD HS mode (only for UHS-I SDR50/SDR104), the Cadence SD6HC PHY
requires runtime calibration of its receive data delay line to find a
valid sampling window under constrained clock conditions.

The tuning is triggered from the set_ios_post callback because at that
moment hardware has committed the new bus width, clock frequency, and speed
mode to the controller registers. This ensuring the tuning sequence runs
at the correct SD HS operating conditions.

The tuning is gated by a device tree property "cdns,sd-hs-tuning" so
that only boards requiring runtime calibration opt in. When enabled,
the driver performs a 40-tap DLL sweep using CMD19 to find the largest
consecutive passing window, then programs the midpoint into
PHY_DLL_SLAVE_CTRL_REG.

To enable on a board, add to the MMC node in device tree:

    &amp;mmc {
        cdns,sd-hs-tuning;
    };

Signed-off-by: Tze Yee Ng &lt;tze.yee.ng@altera.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Cadence SD6HC (SDHCI spec v4.20+) controller uses a soft PHY whose
DLL delay characteristics vary with PVT (Process, Voltage, Temperature)
and board-level trace routing.

A static delay value programmed via device tree for SD High Speed mode is
insufficient because the optimal sampling point varies per board, SD card,
and operating conditions. Runtime calibration is required.

While the SD Physical Layer Specification does not mandate tuning for
SD HS mode (only for UHS-I SDR50/SDR104), the Cadence SD6HC PHY
requires runtime calibration of its receive data delay line to find a
valid sampling window under constrained clock conditions.

The tuning is triggered from the set_ios_post callback because at that
moment hardware has committed the new bus width, clock frequency, and speed
mode to the controller registers. This ensuring the tuning sequence runs
at the correct SD HS operating conditions.

The tuning is gated by a device tree property "cdns,sd-hs-tuning" so
that only boards requiring runtime calibration opt in. When enabled,
the driver performs a 40-tap DLL sweep using CMD19 to find the largest
consecutive passing window, then programs the midpoint into
PHY_DLL_SLAVE_CTRL_REG.

To enable on a board, add to the MMC node in device tree:

    &amp;mmc {
        cdns,sd-hs-tuning;
    };

Signed-off-by: Tze Yee Ng &lt;tze.yee.ng@altera.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: msm_sdhci: Use max-frequency to get clock rate</title>
<updated>2026-05-06T02:20:30+00:00</updated>
<author>
<name>Varadarajan Narayanan</name>
<email>varadarajan.narayanan@oss.qualcomm.com</email>
</author>
<published>2026-04-16T05:11:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=f07c15c16a1bbdf8eaa9ad79af774e31948bcba3'/>
<id>f07c15c16a1bbdf8eaa9ad79af774e31948bcba3</id>
<content type='text'>
msm_sdc_clk_init() uses clock-frequency to get the clock rate for SDC
clocks. However, the DT files seem to use max-frequency for the same.
Since msm_sdc_clk_init() doesn't find clock-frequency in the DT, it sets
201500000 as the clock rate and this results in timeout errors on IPQ
platforms.

Additionally, clock-frequency is not DT bindings compliant. Hence, get
clock rate using DT bindings compliant max-frequency.

Signed-off-by: Varadarajan Narayanan &lt;varadarajan.narayanan@oss.qualcomm.com&gt;
Reviewed-by: Sumit Garg &lt;sumit.garg@oss.qualcomm.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
msm_sdc_clk_init() uses clock-frequency to get the clock rate for SDC
clocks. However, the DT files seem to use max-frequency for the same.
Since msm_sdc_clk_init() doesn't find clock-frequency in the DT, it sets
201500000 as the clock rate and this results in timeout errors on IPQ
platforms.

Additionally, clock-frequency is not DT bindings compliant. Hence, get
clock rate using DT bindings compliant max-frequency.

Signed-off-by: Varadarajan Narayanan &lt;varadarajan.narayanan@oss.qualcomm.com&gt;
Reviewed-by: Sumit Garg &lt;sumit.garg@oss.qualcomm.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: Kconfig: allows m68k to use esdhc imx driver</title>
<updated>2026-05-04T20:19:49+00:00</updated>
<author>
<name>Angelo Dureghello</name>
<email>angelo@kernel-space.org</email>
</author>
<published>2026-03-23T22:11:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=cc4c0cbc29d80a570d49f88bb8d109a102d90ea9'/>
<id>cc4c0cbc29d80a570d49f88bb8d109a102d90ea9</id>
<content type='text'>
Allow cpu families as mcf5441x (m68k) to use the fsl_esdhc_imx driver
since the hardware ip module is the same.

Signed-off-by: Angelo Dureghello &lt;angelo@kernel-space.org&gt;

---
Changes in v2:
- moved before menuconfig changes
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow cpu families as mcf5441x (m68k) to use the fsl_esdhc_imx driver
since the hardware ip module is the same.

Signed-off-by: Angelo Dureghello &lt;angelo@kernel-space.org&gt;

---
Changes in v2:
- moved before menuconfig changes
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mtk-sd: fix msdc cmd ready check</title>
<updated>2026-04-28T15:45:07+00:00</updated>
<author>
<name>ht.lin</name>
<email>ht.lin@mediatek.com</email>
</author>
<published>2026-04-21T14:24:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8436dd6b0e7e529fda238edf762076fa436bdfda'/>
<id>8436dd6b0e7e529fda238edf762076fa436bdfda</id>
<content type='text'>
Correct the check condition in msdc_cmd_is_ready() for MSDC_PS_DAT0
polling. Without this change, it may not be able to detect if the SD
controller is busy correctly for issuing the command.

Fixes: d24b69395949 ("mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC")
Signed-off-by: ht.lin &lt;ht.lin@mediatek.com&gt;
Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-3-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Correct the check condition in msdc_cmd_is_ready() for MSDC_PS_DAT0
polling. Without this change, it may not be able to detect if the SD
controller is busy correctly for issuing the command.

Fixes: d24b69395949 ("mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC")
Signed-off-by: ht.lin &lt;ht.lin@mediatek.com&gt;
Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-3-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mtk-sd: enable async_fifo_crcsts on mt8189</title>
<updated>2026-04-28T15:45:07+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2026-04-21T14:24:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=93f67d893b32606cfb723b82be783a013c16fc0c'/>
<id>93f67d893b32606cfb723b82be783a013c16fc0c</id>
<content type='text'>
Enable the async_fifo_crcsts option for mediatek,mt8189-mmc compatible.

Without this option, writing will fail in HS200 mode.

Fixes: b3d16267b509 ("mmc: mtk-sd: add mediatek,mt8189-mmc compatible")
Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-2-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable the async_fifo_crcsts option for mediatek,mt8189-mmc compatible.

Without this option, writing will fail in HS200 mode.

Fixes: b3d16267b509 ("mmc: mtk-sd: add mediatek,mt8189-mmc compatible")
Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-2-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: mtk-sd: enable DMA on mediatek,mt8189-mmc</title>
<updated>2026-04-28T15:45:07+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2026-04-21T14:24:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=336602a2f912fd19eb717083306e54804bc92e79'/>
<id>336602a2f912fd19eb717083306e54804bc92e79</id>
<content type='text'>
Enable DMA on mediatek,mt8189-mmc compatible. The issue that was
preventing DMA from working correctly was fixed by the
get_effective_memsize() implementation in commit a7c682565b4b ("arm:
mediatek: add support of MT8189 SoC family").

Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-1-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Enable DMA on mediatek,mt8189-mmc compatible. The issue that was
preventing DMA from working correctly was fixed by the
get_effective_memsize() implementation in commit a7c682565b4b ("arm:
mediatek: add support of MT8189 SoC family").

Reviewed-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Tested-by: Julien Stephan &lt;jstephan@baylibre.com&gt;
Link: https://patch.msgid.link/20260421-mmc-mtk-sd-fixes-v1-1-5b840c546af2@baylibre.com
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Correct duplicate U_BOOT_DRIVER entry names</title>
<updated>2026-04-07T17:32:56+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-03-23T22:55:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8c212d6e2e778b4f294d1d9f85eac9680a66d463'/>
<id>8c212d6e2e778b4f294d1d9f85eac9680a66d463</id>
<content type='text'>
The U_BOOT_DRIVER macro creates a list of drivers used at link time, and
all entries here must be unique. This in turn means that all entries in
the code should also be unique in order to not lead to build failures
later with unexpected build combinations. Typically, the problem we have
here is when a driver is obviously based on another driver and didn't
update this particular field and so while the name field reflects
something unique the linker entry itself is not. In a few places this
provides a more suitable string name as well, however.

Reviewed-by: Marek Vasut &lt;marek.vasut+usb@mailbox.org&gt;
Reviewed-by: Svyatoslav Ryhel &lt;clamor95@gmail.com&gt; # Tegra
Reviewed-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@nabladev.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The U_BOOT_DRIVER macro creates a list of drivers used at link time, and
all entries here must be unique. This in turn means that all entries in
the code should also be unique in order to not lead to build failures
later with unexpected build combinations. Typically, the problem we have
here is when a driver is obviously based on another driver and didn't
update this particular field and so while the name field reflects
something unique the linker entry itself is not. In a few places this
provides a more suitable string name as well, however.

Reviewed-by: Marek Vasut &lt;marek.vasut+usb@mailbox.org&gt;
Reviewed-by: Svyatoslav Ryhel &lt;clamor95@gmail.com&gt; # Tegra
Reviewed-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@nabladev.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>core: Rework REGMAP symbols implementation</title>
<updated>2026-03-30T22:59:35+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-03-17T01:24:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0da1866a8fdd4d4bc4837ef2af281dbe010ae16b'/>
<id>0da1866a8fdd4d4bc4837ef2af281dbe010ae16b</id>
<content type='text'>
As exposed by "make randconfig", we have an issue with the dependencies
for REGMAP (and xPL variants). As this is a library function, it should
always be selected and not depended on by other functionality. This is
largely done correctly today, so just correct the few outliers.

Acked-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As exposed by "make randconfig", we have an issue with the dependencies
for REGMAP (and xPL variants). As this is a library function, it should
always be selected and not depended on by other functionality. This is
largely done correctly today, so just correct the few outliers.

Acked-by: Anshul Dalal &lt;anshuld@ti.com&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: Add support for eMMC 5.1B specification</title>
<updated>2026-03-23T03:27:52+00:00</updated>
<author>
<name>Han Xu</name>
<email>han.xu@nxp.com</email>
</author>
<published>2026-02-25T21:13:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=67fc505228558efa19380542d801807fa9eee054'/>
<id>67fc505228558efa19380542d801807fa9eee054</id>
<content type='text'>
Add support for eMMC specification version 5.1B by defining
MMC_VERSION_5_1B and including it in the version array.

eMMC 5.1B (JESD84-B51B) is a minor revision of the 5.1 specification
that primarily addresses MDT (Manufacturing Date) adjustment for dates
beyond 2025. This aligns with the Linux kernel commit 9996707822f82
("mmc: core: Adjust MDT beyond 2025").

Since the manufacturing date field is not currently used in U-Boot,
this change has no functional impact beyond proper device recognition.
It allows the driver to correctly identify and initialize eMMC devices
that report version 5.1B in their Extended CSD register.

Signed-off-by: Han Xu &lt;han.xu@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for eMMC specification version 5.1B by defining
MMC_VERSION_5_1B and including it in the version array.

eMMC 5.1B (JESD84-B51B) is a minor revision of the 5.1 specification
that primarily addresses MDT (Manufacturing Date) adjustment for dates
beyond 2025. This aligns with the Linux kernel commit 9996707822f82
("mmc: core: Adjust MDT beyond 2025").

Since the manufacturing date field is not currently used in U-Boot,
this change has no functional impact beyond proper device recognition.
It allows the driver to correctly identify and initialize eMMC devices
that report version 5.1B in their Extended CSD register.

Signed-off-by: Han Xu &lt;han.xu@nxp.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'v2026.04-rc4' into next</title>
<updated>2026-03-09T21:26:34+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2026-03-09T21:26:34+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1e240f7206fccde4ec73ea432ab8360d321c5fe5'/>
<id>1e240f7206fccde4ec73ea432ab8360d321c5fe5</id>
<content type='text'>
Prepare v2026.04-rc4
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Prepare v2026.04-rc4
</pre>
</div>
</content>
</entry>
</feed>
