<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/mmc, branch v2025.04</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.</subtitle>
<id>http://cgit.235523.xyz/u-boot.git/atom/drivers/mmc?h=v2025.04</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers/mmc?h=v2025.04'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2025-02-24T20:16:28Z</updated>
<entry>
<title>mmc: Fix size calculation for sector addressed MMC version 4</title>
<updated>2025-02-24T20:16:28Z</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2025-01-29T11:15:54Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dbb9e136b8c01de581a08113ae6124f484b29362'/>
<id>urn:sha1:dbb9e136b8c01de581a08113ae6124f484b29362</id>
<content type='text'>
For eMMC v4 and newer that is smaller than 2 GiB, the JEDEC JESD84-B51
section 6.2.4 Configure partitions indicates that EXT_CSD SEC_COUNT
should not be used to determine device size, and instead device size
should be calculated from C_SIZE and C_SIZE_MULT.

This is not exactly accurate, the 2 GiB limit is not a hard line,
there are eMMC devices which are smaller than 2 GiB and still
require device size to be determined from EXT_CSD SEC_COUNT. The
hard line is instead OCR HCS bit, which indicates whether the device
is byte or sector addressed, the former applies to most devices
below 2 GiB, and the later applies mostly to devices above 2 GiB.

However, there are a couple of devices which are smaller than 2 GiB
and still set the OCR HCS bit to indicate they are sector addressed,
and therefore the size calculation for those devices should also
use EXT_CSD SEC_COUNT . Use mmc-&gt;high_capacity flag to discern the
devices instead of arbitrary 2 GiB limit. The mmc-&gt;high_capacity flag
reflects the OCR HCS bit state.

Fixes: 639b7827d1ca ("mmc: fix the condition for MMC version 4")
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
</entry>
<entry>
<title>mmc: Allow controlling DM_MMC for VPL builds</title>
<updated>2025-02-03T22:00:42Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2025-01-26T18:43:13Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=00ae9b2ac3493ed74449cd3b7cf50bce1b98d36d'/>
<id>urn:sha1:00ae9b2ac3493ed74449cd3b7cf50bce1b98d36d</id>
<content type='text'>
VPL may want to use driver model for MMC even if TPL does not. Update
the rule in this driver to support that.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>mmc: mediatek: add support for MediaTek MT7987 SoCs</title>
<updated>2025-01-30T20:35:14Z</updated>
<author>
<name>Weijie Gao</name>
<email>weijie.gao@mediatek.com</email>
</author>
<published>2025-01-23T08:54:56Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e5d20906f7a62c431b4ccf3cd5eaa49254853960'/>
<id>urn:sha1:e5d20906f7a62c431b4ccf3cd5eaa49254853960</id>
<content type='text'>
This patch adds eMMC/SD support for MT7987 SoC

Signed-off-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
</content>
</entry>
<entry>
<title>blk: Make block subsystems select BLK</title>
<updated>2025-01-21T01:26:54Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-01-15T01:22:11Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a72fa7f2fee76b65c34ec1299334fef4f98aee50'/>
<id>urn:sha1:a72fa7f2fee76b65c34ec1299334fef4f98aee50</id>
<content type='text'>
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".

Reviewed-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>drivers/mmc/Kconfig: Make DM_MMC a hidden symbol</title>
<updated>2025-01-21T01:26:25Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-01-15T01:22:09Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0569ca68561e87ba513f2e4b57e398fa8b6518d0'/>
<id>urn:sha1:0569ca68561e87ba513f2e4b57e398fa8b6518d0</id>
<content type='text'>
At this point in time, DM is always enabled. So if MMC is enabled, it
should select DM_MMC. No drivers need to depend on DM_MMC being enabled
now, so remove that from dependency lists. This now means that a number
of platforms which select'd DM_MMC need to select MMC instead. This also
fixes a migration problem with espresso7420 in that MMC is built again
with the platform.

Reviewed-by: Peter Robinson &lt;pbrobinson@gmail.com&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>drivers/mmc/Kconfig: Remove extraneous BLK dependencies</title>
<updated>2025-01-21T01:19:43Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2025-01-15T01:22:08Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3de327ab495b2eed8c47b45a8aad87cab1b6e620'/>
<id>urn:sha1:3de327ab495b2eed8c47b45a8aad87cab1b6e620</id>
<content type='text'>
At this point in time, we know that with the MMC symbol enabled we will
always also have the BLK symbol enabled, so we do not need to list that
as a dependency for MMC drivers.

Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Quentin Schulz &lt;quentin.schulz@cherry.de&gt;
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'v2025.01-rc5' into next</title>
<updated>2024-12-26T04:31:04Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2024-12-26T04:31:04Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5cfbf8c3644cc95c3c8b5d2541ed7f32136c0da1'/>
<id>urn:sha1:5cfbf8c3644cc95c3c8b5d2541ed7f32136c0da1</id>
<content type='text'>
Prepare v2025.01-rc5
</content>
</entry>
<entry>
<title>mmc: snps_sdhci: Add sdhci driver support for TH1520 SoC</title>
<updated>2024-12-18T05:19:16Z</updated>
<author>
<name>Maksim Kiselev</name>
<email>bigunclemax@gmail.com</email>
</author>
<published>2024-12-11T20:10:59Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=1cf3e900affa34d59067c0c5ea49242f864086ba'/>
<id>urn:sha1:1cf3e900affa34d59067c0c5ea49242f864086ba</id>
<content type='text'>
Add support for DesignWare SDHCI host controller on Alibaba TH1520 SoC

Signed-off-by: Maksim Kiselev &lt;bigunclemax@gmail.com&gt;
Tested-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
</content>
</entry>
<entry>
<title>mmc: dw_mmc: Add "starfive, jh7110-mmc" compatible to match upstream DT</title>
<updated>2024-12-18T05:19:15Z</updated>
<author>
<name>Hal Feng</name>
<email>hal.feng@starfivetech.com</email>
</author>
<published>2024-12-08T09:19:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=b364642f61c3568707651903eb82b9fcd5c30853'/>
<id>urn:sha1:b364642f61c3568707651903eb82b9fcd5c30853</id>
<content type='text'>
Make the U-Boot JH7110 MMC driver compatible with upstream DT.

Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
</content>
</entry>
<entry>
<title>mmc: Fix potential timer value truncation</title>
<updated>2024-12-16T02:24:42Z</updated>
<author>
<name>Ronald Wahl</name>
<email>ronald.wahl@legrand.com</email>
</author>
<published>2024-12-11T20:52:00Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=822afeb7bf84ca1c9289a61ea99604b4deb8e091'/>
<id>urn:sha1:822afeb7bf84ca1c9289a61ea99604b4deb8e091</id>
<content type='text'>
On 64bit systems the timer value might be truncated to a 32bit value
causing malfunctions. For example on ARM the timer might start from 0
again only after a cold reset. The 32bit overflow occurs after a bit
more than 49 days (1000 Hz counter) so booting after that time may lead
to a surprise because the board might become stuck requiring a cold
reset.

Signed-off-by: Ronald Wahl &lt;ronald.wahl@legrand.com&gt;
Cc: Peng Fan &lt;peng.fan@nxp.com&gt;
Cc: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
</entry>
</feed>
