<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/mmc/core/mmc.c, branch linux-5.0.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-12-17T08:01:15Z</updated>
<entry>
<title>mmc: core: Cleanup BKOPS support</title>
<updated>2018-12-17T08:01:15Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-12-10T16:52:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0c204979c691f05666ecfb74501e7adfdde8fbf9'/>
<id>urn:sha1:0c204979c691f05666ecfb74501e7adfdde8fbf9</id>
<content type='text'>
It's been ~6 years ago since we introduced the BKOPS support for eMMC
cards. The current code is a bit messy and primarily that's because it
prepares to support running BKOPS in an asynchronous mode. However, that
mode has never been fully implemented/enabled. Instead BKOPS is always
executed in synchronously, when the card has reported an urgent BKOPS
level.

For these reasons, let's make the code more readable by dropping the unused
parts. Let's also rename mmc_start_bkops() to mmc_run_bkops(), as to make
it more descriptive.

Cc: Jaehoon Chung &lt;jh80.chung@samsung.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'fixes' into next</title>
<updated>2018-12-17T08:00:52Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-12-17T08:00:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=01e421feec0817bb3141eaae4c517410d193d440'/>
<id>urn:sha1:01e421feec0817bb3141eaae4c517410d193d440</id>
<content type='text'>
</content>
</entry>
<entry>
<title>mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl</title>
<updated>2018-12-17T07:59:42Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-12-10T16:52:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e3ae3401aa19432ee4943eb0bbc2ec704d07d793'/>
<id>urn:sha1:e3ae3401aa19432ee4943eb0bbc2ec704d07d793</id>
<content type='text'>
Some eMMCs from Micron have been reported to need ~800 ms timeout, while
enabling the CACHE ctrl after running sudden power failure tests. The
needed timeout is greater than what the card specifies as its generic CMD6
timeout, through the EXT_CSD register, hence the problem.

Normally we would introduce a card quirk to extend the timeout for these
specific Micron cards. However, due to the rather complicated debug process
needed to find out the error, let's simply use a minimum timeout of 1600ms,
the double of what has been reported, for all cards when enabling CACHE
ctrl.

Reported-by: Sjoerd Simons &lt;sjoerd.simons@collabora.co.uk&gt;
Reported-by: Andreas Dannenberg &lt;dannenberg@ti.com&gt;
Reported-by: Faiz Abbas &lt;faiz_abbas@ti.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Allow BKOPS and CACHE ctrl even if no HPI support</title>
<updated>2018-12-17T07:57:18Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-12-10T16:52:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba9f39a785a9977e72233000711ef1eb48203551'/>
<id>urn:sha1:ba9f39a785a9977e72233000711ef1eb48203551</id>
<content type='text'>
In commit 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC
cards"), then intent was to prevent HPI from being used for some eMMC
cards, which didn't properly support it. However, that went too far, as
even BKOPS and CACHE ctrl became prevented. Let's restore those parts and
allow BKOPS and CACHE ctrl even if HPI isn't supported.

Fixes: 5320226a0512 ("mmc: core: Disable HPI for certain Hynix eMMC cards")
Cc: Pratibhasagar V &lt;pratibha@codeaurora.org&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Reset HPI enabled state during re-init and in case of errors</title>
<updated>2018-12-17T07:56:54Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-12-10T16:52:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a0741ba40a009f97c019ae7541dc61c1fdf41efb'/>
<id>urn:sha1:a0741ba40a009f97c019ae7541dc61c1fdf41efb</id>
<content type='text'>
During a re-initialization of the eMMC card, we may fail to re-enable HPI.
In these cases, that isn't properly reflected in the card-&gt;ext_csd.hpi_en
bit, as it keeps being set. This may cause following attempts to use HPI,
even if's not enabled. Let's fix this!

Fixes: eb0d8f135b67 ("mmc: core: support HPI send command")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Add -&gt;hs400_prepare_ddr() callback</title>
<updated>2018-12-17T07:26:24Z</updated>
<author>
<name>Yinbo Zhu</name>
</author>
<published>2018-11-23T03:15:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cc14eec0889bb06abab3d6ea1e0e0676521542c8'/>
<id>urn:sha1:cc14eec0889bb06abab3d6ea1e0e0676521542c8</id>
<content type='text'>
Some eMMC controllers need specific settings for HS400 mode before the
speed mode can be switched to DDR mode, during the HS400 initialization
sequence. For that reason, let's introduce a new host callback,
-&gt;hs400_prepare_ddr() and invoked it just before switching to DDR mode.

Signed-off-by: Yinbo Zhu &lt;yinbo.zhu@nxp.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: improve reasonableness of bus width setting for HS400es</title>
<updated>2018-08-01T12:15:28Z</updated>
<author>
<name>Hongjie Fang</name>
</author>
<published>2018-07-31T02:55:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7f38abf220e2c800a2c451372e9f07ed5fd0ea49'/>
<id>urn:sha1:7f38abf220e2c800a2c451372e9f07ed5fd0ea49</id>
<content type='text'>
mmc_select_hs400es() calls mmc_select_bus_width() which will continue
to set 4bit transfer mode if fail to set 8bit mode. The bus width
should not be set to 4bit in HS400es.

When fail to set 8bit mode, need return error directly for HS400es.

Signed-off-by: Hongjie Fang &lt;hongjiefang@asrmicro.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: more fine-grained hooks for HS400 tuning</title>
<updated>2018-07-16T09:21:45Z</updated>
<author>
<name>Simon Horman</name>
</author>
<published>2018-06-18T12:57:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba6c7ac3a2f421635ae4446269526359d8bff721'/>
<id>urn:sha1:ba6c7ac3a2f421635ae4446269526359d8bff721</id>
<content type='text'>
This adds two new HS400 tuning operations:
* hs400_downgrade
* hs400_complete

These supplement the existing HS400 operation:
* prepare_hs400_tuning

This is motivated by a requirement of Renesas SDHI for the following:
1. Disabling SCC before selecting to HS if selection of HS400 has occurred.
   This can be done in an implementation of prepare_hs400_tuning_downgrade
2. Updating registers after switching to HS400
   This can be done in an implementation of complete_hs400_tuning

If hs400_downgrade or hs400_complete are not implemented then they are not
called. Thus means there should be no affect for existing drivers as none
implemt these ops.

Signed-off-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: Move calls to -&gt;prepare_hs400_tuning() closer to mmc code</title>
<updated>2018-05-29T10:24:26Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-05-22T14:26:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c8a4e30d9ac0a7d405c4d26e313af7464ee00929'/>
<id>urn:sha1:c8a4e30d9ac0a7d405c4d26e313af7464ee00929</id>
<content type='text'>
Move the calls to -&gt;prepare_hs400_tuning(), from mmc_retune() into
mmc_hs400_to_hs200(), as it better belongs there, rather than being generic
to all type of cards.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
</content>
</entry>
<entry>
<title>mmc: core: Rename -&gt;reset() bus ops to -&gt;hw_reset()</title>
<updated>2018-05-08T07:33:29Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2018-04-05T11:24:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3a3db6030b64ceb4b4e41a6811168c5d90a9f7f8'/>
<id>urn:sha1:3a3db6030b64ceb4b4e41a6811168c5d90a9f7f8</id>
<content type='text'>
The bus ops -&gt;reset() executes a full HW reset of the card, as the calling
function mmc_hw_reset() also indicates by its name. Let's convert to follow
the similar names, for both the bus ops callback and for the corresponding
bus ops functions, as to clarify the purpose of code.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Tested-by: Quentin Schulz &lt;quentin.schulz@bootlin.com&gt;
Reviewed-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
</content>
</entry>
</feed>
