<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/mmc, branch v2015.01-rc4</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=v2015.01-rc4</id>
<link rel='self' href='http://cgit.235523.xyz/u-boot.git/atom/drivers/mmc?h=v2015.01-rc4'/>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<updated>2014-12-12T19:09:01Z</updated>
<entry>
<title>mmc: dw_mmc: Use active DDR mode flag</title>
<updated>2014-12-12T19:09:01Z</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2014-12-01T12:59:12Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2b8a9692f9d8a744b6a93a9bed115ca46541ca1f'/>
<id>urn:sha1:2b8a9692f9d8a744b6a93a9bed115ca46541ca1f</id>
<content type='text'>
The card_caps bit should denote the card capability to use DDR mode,
but we need the flag indicating that the DDR mode is active.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
</content>
</entry>
<entry>
<title>mmc: Fix block length for DDR mode</title>
<updated>2014-12-12T19:08:38Z</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2014-12-01T12:59:11Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=5af8f45cd049cf01790a17ff68e61303bc08abc3'/>
<id>urn:sha1:5af8f45cd049cf01790a17ff68e61303bc08abc3</id>
<content type='text'>
Block length for write and read commands is fixed to 512 bytes
when the card is in Dual Data Rate mode. If block length read from CSD
is different, make sure the driver will use correct length
in all further calculations and settings.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
</content>
</entry>
<entry>
<title>mmc: Fix Dual Data Rate capability recognition</title>
<updated>2014-12-12T19:08:21Z</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2014-12-01T12:59:10Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=201d5ac4388d66bf7a78e71c32939b3fc5779207'/>
<id>urn:sha1:201d5ac4388d66bf7a78e71c32939b3fc5779207</id>
<content type='text'>
Since the driver doesn't work in 1.2V or 1.8V signaling level modes,
Dual Data Rate mode can be supported by the driver only if it is supported
by the card in regular 3.3V mode. So, check for a particular single
bit in card type field.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
</content>
</entry>
<entry>
<title>mmc: Fix handling of bus widths and DDR card capabilities</title>
<updated>2014-12-12T19:08:06Z</updated>
<author>
<name>Andrew Gabbasov</name>
<email>andrew_gabbasov@mentor.com</email>
</author>
<published>2014-12-01T12:59:09Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=786e8f818c25265d12d5d06e257fe2b1ba516134'/>
<id>urn:sha1:786e8f818c25265d12d5d06e257fe2b1ba516134</id>
<content type='text'>
If the MMC_MODE_DDR_52MHz flag is set in card capabilities bitmask,
it is never cleared, even if switching to DDR mode fails, and if
the controller driver uses this flag to check the DDR mode, it can
take incorrect actions.

Also, DDR related checks in mmc_startup() incorrectly handle the case
when the host controller does not support some bus widths (e.g. can't
support 8 bits), since the host_caps is checked for DDR bit, but not
bus width bits.

This fix clearly separates using of card_caps bitmask, having there
the flags for the capabilities, that the card can support, and actual
operation mode, described outside of card_caps (i.e. bus_width and
ddr_mode fields in mmc structure). Separate host controller drivers
may need to be updated to use the actual flags. Respectively,
the capabilities checks in mmc_startup are made more correct and clear.

Also, some clean up is made with errors handling and code syntax layout.

Signed-off-by: Andrew Gabbasov &lt;andrew_gabbasov@mentor.com&gt;
</content>
</entry>
<entry>
<title>mmc: exynos_dw-mmc: change debug message</title>
<updated>2014-12-12T18:35:30Z</updated>
<author>
<name>Jaehoon Chung</name>
<email>jh80.chung@samsung.com</email>
</author>
<published>2014-11-28T11:42:33Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dfcb683a31d4222c30a9ef5d4acea1142f6bde48'/>
<id>urn:sha1:dfcb683a31d4222c30a9ef5d4acea1142f6bde48</id>
<content type='text'>
To debug more exactly, add the index for device.

Signed-off-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
</entry>
<entry>
<title>MMC: add MMC_VERSION_5_0</title>
<updated>2014-12-12T18:34:20Z</updated>
<author>
<name>Markus Niebel</name>
<email>Markus.Niebel@tq-group.com</email>
</author>
<published>2014-11-18T14:13:53Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=edab723b47bfba617efb55f97d01e273546ec2bf'/>
<id>urn:sha1:edab723b47bfba617efb55f97d01e273546ec2bf</id>
<content type='text'>
Signed-off-by: Markus Niebel &lt;Markus.Niebel@tq-group.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
</entry>
<entry>
<title>MMC: fix user capacity for partitioned eMMC card</title>
<updated>2014-12-12T18:28:04Z</updated>
<author>
<name>Markus Niebel</name>
<email>Markus.Niebel@tq-group.com</email>
</author>
<published>2014-11-18T14:11:42Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d7b2912991bb18db26b6c6b51cdc637142e21d3e'/>
<id>urn:sha1:d7b2912991bb18db26b6c6b51cdc637142e21d3e</id>
<content type='text'>
if the card claims to be high capacity and the card
is partitioned the capacity shall still be read from
ext_csd SEC_COUNT even if the resulting capacity is
smaller than 2 GiB

Signed-off-by: Markus Niebel &lt;Markus.Niebel@tq-group.com&gt;
Acked-by: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
</content>
</entry>
<entry>
<title>mmc: Cosmetic fix for nicer, aligned device list printout</title>
<updated>2014-12-12T18:08:47Z</updated>
<author>
<name>Lubomir Popov</name>
<email>lpopov@mm-sol.com</email>
</author>
<published>2014-11-11T10:25:42Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e75eaf100bdf01b94757e2b40365b46a7d380275'/>
<id>urn:sha1:e75eaf100bdf01b94757e2b40365b46a7d380275</id>
<content type='text'>
If print_mmc_devices() was called with a '\n' separator (as done
for example by the "mmc list" command), it offset the 2-nd and
all subsequent lines by one space. Fixing this.

Signed-off-by: Lubomir Popov &lt;l-popov@ti.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of git://git.denx.de/u-boot-ti</title>
<updated>2014-12-08T21:35:06Z</updated>
<author>
<name>Tom Rini</name>
<email>trini@ti.com</email>
</author>
<published>2014-12-08T21:35:06Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=98d2d5e8c473232dc718763dbec284b7349dcc05'/>
<id>urn:sha1:98d2d5e8c473232dc718763dbec284b7349dcc05</id>
<content type='text'>
</content>
</entry>
<entry>
<title>omap_hsmmc: Board-specific TWL4030 MMC power initializations</title>
<updated>2014-12-05T02:28:15Z</updated>
<author>
<name>Paul Kocialkowski</name>
<email>contact@paulk.fr</email>
</author>
<published>2014-11-08T19:55:47Z</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=aac5450ea92abc9109a78cc099d366962148719f'/>
<id>urn:sha1:aac5450ea92abc9109a78cc099d366962148719f</id>
<content type='text'>
Boards using the TWL4030 regulator may not all use the LDOs the same way
(e.g. MMC2 power can be controlled by another LDO than VMMC2).
This delegates TWL4030 MMC power initializations to board-specific functions,
that may still call twl4030_power_mmc_init for the default behavior.

Signed-off-by: Paul Kocialkowski &lt;contact@paulk.fr&gt;
Reviewed-by: Tom Rini &lt;trini@ti.com&gt;
[trini: Fix omap3_evm warning, add twl4030.h]
Signed-off-by: Tom Rini &lt;trini@ti.com&gt;
</content>
</entry>
</feed>
