<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/mmc, branch v2023.10</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=v2023.10</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers/mmc?h=v2023.10'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2023-08-09T15:31:11Z</updated>
<entry>
<title>bootstd: Rename bootdev_setup_sibling_blk()</title>
<updated>2023-08-09T15:31:11Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2023-07-30T17:15:14Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d7d78576bbfddd52b258771c9e926bd51b50d91e'/>
<id>urn:sha1:d7d78576bbfddd52b258771c9e926bd51b50d91e</id>
<content type='text'>
This name is a little confusing since it suggests that it sets up the
sibling block device. In fact it sets up a bootdev for it. Rename the
function to make this clearer.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
Reviewed-by: Mattijs Korpershoek &lt;mkorpershoek@baylibre.com&gt;
</content>
</entry>
<entry>
<title>atmel_sdhci: Force card-detect if MMC_CAP_NONREMOVABLE.</title>
<updated>2023-07-24T11:21:00Z</updated>
<author>
<name>Zixun LI</name>
<email>admin@hifiphile.com</email>
</author>
<published>2023-05-17T13:49:45Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e83b6f99fc512acda05691db35e7d83817eac0b9'/>
<id>urn:sha1:e83b6f99fc512acda05691db35e7d83817eac0b9</id>
<content type='text'>
If the device attached to the MMC bus is not removable, set force card-detect
bit to bypass card detection procedure, so card detection pin can be used for
other purposes.

It's also a workaround for SAMA5D2 who doesn't drive CMD if using GPIO for card
detection.

Signed-off-by: Zixun LI &lt;zli@ogga.fr&gt;
Reviewed-by: Eugen Hristev &lt;eugen.hristev@collabora.com&gt;
</content>
</entry>
<entry>
<title>mmc: zynq_sdhci: Dll reset only for ZynqMP platform</title>
<updated>2023-07-21T07:00:38Z</updated>
<author>
<name>Ashok Reddy Soma</name>
<email>ashok.reddy.soma@amd.com</email>
</author>
<published>2023-07-10T12:11:59Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=752e4b6c8efb5bd624f316f7a9686d9956d55dd7'/>
<id>urn:sha1:752e4b6c8efb5bd624f316f7a9686d9956d55dd7</id>
<content type='text'>
Dll reset is needed only for ZynqMP platforms, add condition in tuning
to call arasan_zynqmp_dll_reset() just for ZynqMP platforms.

On other platforms like Versal NET, If this condition is not added, we
see PLM error messages when dll reset smc is called.

Signed-off-by: Ashok Reddy Soma &lt;ashok.reddy.soma@amd.com&gt;
Reviewed-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Michal Simek &lt;michal.simek@amd.com&gt;
Link: https://lore.kernel.org/r/d673ff3bdc5c236a7f0403c920e719684abd6059.1688991117.git.michal.simek@amd.com
</content>
</entry>
<entry>
<title>mmc: Set clock when reverting to safe bus mode</title>
<updated>2023-07-18T00:17:29Z</updated>
<author>
<name>Valentine Barshak</name>
<email>valentine.barshak@cogentembedded.com</email>
</author>
<published>2023-06-10T11:22:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=50dee4f3610331cc31f1f02f9d4116b716907011'/>
<id>urn:sha1:50dee4f3610331cc31f1f02f9d4116b716907011</id>
<content type='text'>
Set MMC clock when reverting to safe bus mode and speed
in case current MMC mode fails. Otherwise, trying out
the other modes may fail as well.

Reviewed-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Signed-off-by: Valentine Barshak &lt;valentine.barshak@cogentembedded.com&gt;
[hp: fallback to legacy_speed]
Signed-off-by: Hai Pham &lt;hai.pham.ud@renesas.com&gt;
Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>mmc: renesas-sdhi: Send stop when MMC tuning command fails</title>
<updated>2023-07-18T00:17:23Z</updated>
<author>
<name>Hai Pham</name>
<email>hai.pham.ud@renesas.com</email>
</author>
<published>2023-06-19T22:38:25Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=99ab3d8dc45c184dcec692fd7130f8732e8c25e4'/>
<id>urn:sha1:99ab3d8dc45c184dcec692fd7130f8732e8c25e4</id>
<content type='text'>
When tuning command (CMD21) fails with command error, call
mmc_send_stop_transmission() to send stop command (CMD12).

Reviewed-by: Takeshi Kihara &lt;takeshi.kihara.df@renesas.com&gt;
Reviewed-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Signed-off-by: Hai Pham &lt;hai.pham.ud@renesas.com&gt;
Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
[Marek: Add dev_dbg() message in case tuning abort fails
        Move tuning opcode check from mmc_abort_tuning()]
Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>mmc: Introduce mmc_send_stop_transmission()</title>
<updated>2023-07-18T00:17:16Z</updated>
<author>
<name>Hai Pham</name>
<email>hai.pham.ud@renesas.com</email>
</author>
<published>2023-06-19T22:38:24Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0ac2cca3a447cbc59d714b1b35425b54283d153a'/>
<id>urn:sha1:0ac2cca3a447cbc59d714b1b35425b54283d153a</id>
<content type='text'>
If a tuning command times out, the card could still be processing it,
which will cause problems for recovery. The eMMC specification section
6.6 Data transfer mode (cont’d) claims that CMD12 can be used to stop
CMD21:
"
The relationship between the various data transfer modes is summarized (see Figure 27):
- All data read commands can be aborted any time by the stop command (CMD12).
  The data transfer will terminate and the Device will return to the Transfer State.
  The read commands are: ... send tuning block (CMD21) ....
"
Add a function that does that.

Based on Linux commit [1] and [2].

[1] e711f0309109 ("mmc: mmc: Introduce mmc_abort_tuning()")
[2] 21adc2e45f4e ("mmc: Improve function name when aborting a tuning
cmd")

Reviewed-by: Takeshi Kihara &lt;takeshi.kihara.df@renesas.com&gt;
Reviewed-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Signed-off-by: Hai Pham &lt;hai.pham.ud@renesas.com&gt;
Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
[Marek: Update commit message, quote relevant part of the specification.
        Rename to mmc_send_stop_transmission().
	Remove tuning opcode check, this is controller driver specific.
	Deduplicate part of mmc_read_blocks() using this function.]
Reviewed-by:  Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment</title>
<updated>2023-07-18T00:17:07Z</updated>
<author>
<name>Marek Vasut</name>
<email>marek.vasut+renesas@mailbox.org</email>
</author>
<published>2023-06-19T22:38:23Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=41a1285c1c31080661fce8de782d8ee4a57014a9'/>
<id>urn:sha1:41a1285c1c31080661fce8de782d8ee4a57014a9</id>
<content type='text'>
For MMC/eMMC, the MMC_CMD_STOP_TRANSMISSION response is R1 for read
transfers and R1b for write transfers per JEDEC Standard No. 84-B51
Page 126 . The response is R1b unconditionally per Physical Layer
Simplified Specification Version 9.00.

Correct the response type and add a comment about it.

Signed-off-by: Marek Vasut &lt;marek.vasut+renesas@mailbox.org&gt;
Reviewed-by: Peng Fan &lt;peng.fan@nxp.com&gt;
</content>
</entry>
<entry>
<title>bootstd: Use bootdev instead of bootdevice</title>
<updated>2023-07-16T15:13:17Z</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2023-07-12T15:04:32Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=4de979f6646d05d13572ecd2b652f0358dfa5de6'/>
<id>urn:sha1:4de979f6646d05d13572ecd2b652f0358dfa5de6</id>
<content type='text'>
It seems better to call this a 'bootdev' since this is name used in the
documentation. The older 'Bootdevice' name is no-longer used and may cause
confusion with the 'bootdevice' environment variable.

Update throughout to use bootdev.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reviewed-by: Bin Meng &lt;bmeng.cn@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'xilinx-for-v2023.10-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next</title>
<updated>2023-06-12T20:42:37Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-06-12T20:42:37Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7da82de916d6aaeeef62431810cb3335e1207b28'/>
<id>urn:sha1:7da82de916d6aaeeef62431810cb3335e1207b28</id>
<content type='text'>
Xilinx changes for v2023.10-rc1

global:
- Use proper U-Boot project name

Fix sparse warnings in zynqmp-clk, zynqmp handoff, board

cmd:
- Cover incorrect 0 length entries

Versal NET:
- Add bootmode logic
- Support SPP production version
- Add loadpdi command

ZynqMP:
- Clear pmufw node command ID handling
- Change power domain behavior around zynqmp_pmufw_node()
- Fix zynqmp cmd return values and pmufw command
- Fix R5 tcm init and modes

mmc:
- Sync Versal NET emmc DT binding

pcie:
- Add support for ZynqMP PCIe root port

video:
- Add support for ZynqMP DP

tools:
- Fix debug message in relocate-rela
</content>
</entry>
<entry>
<title>Merge tag v2023.07-rc4 into next</title>
<updated>2023-06-12T18:55:33Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-06-12T18:55:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=260d4962e06c0a7d2713523c131416a3f70d7f2c'/>
<id>urn:sha1:260d4962e06c0a7d2713523c131416a3f70d7f2c</id>
<content type='text'>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
</entry>
</feed>
