<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/mmc/core/core.h, branch linux-3.2.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.2.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.2.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2011-10-26T20:32:01Z</updated>
<entry>
<title>mmc: core: Fix hangs related to insert/remove of cards</title>
<updated>2011-10-26T20:32:01Z</updated>
<author>
<name>Ulf Hansson</name>
</author>
<published>2011-09-21T18:08:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7f7e4129c23f0419257184dff6fec89d2d5a8964'/>
<id>urn:sha1:7f7e4129c23f0419257184dff6fec89d2d5a8964</id>
<content type='text'>
During a rescan operation mmc_attach(sd|mmc|sdio) functions are
called. The error handling in these function can trigger a detach
of the bus, which also meant a power off. This is not notified by
the rescan operation which then continues to the next attach function.

If a power off has been done, the framework must never send any
new commands to the host driver, without first doing a new power up.
This will most likely trigger any host driver to hang.

Moving power off out of detach and instead handle power off
separately when it is actually needed, solves the issue.

Signed-off-by: Ulf Hansson &lt;ulf.hansson@stericsson.com&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: add support for eMMC Dual Data Rate</title>
<updated>2011-05-25T03:53:58Z</updated>
<author>
<name>Philip Rakity</name>
</author>
<published>2011-05-13T05:47:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4c4cb171054230c2e58ed6574d7faa1871c75bbe'/>
<id>urn:sha1:4c4cb171054230c2e58ed6574d7faa1871c75bbe</id>
<content type='text'>
eMMC voltage change not required for 1.8V.  3.3V and 1.8V vcc
are capable of doing DDR. vccq of 1.8v is not required.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Reviewed-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: eMMC signal voltage does not use CMD11</title>
<updated>2011-05-25T03:53:58Z</updated>
<author>
<name>Philip Rakity</name>
</author>
<published>2011-05-13T05:47:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=261bbd463a091b939770255d559bbc89b1bad568'/>
<id>urn:sha1:261bbd463a091b939770255d559bbc89b1bad568</id>
<content type='text'>
eMMC chips do not use CMD11 when changing voltage.  Add extra
argument to call to indicate if CMD11 needs to be sent.

Signed-off-by: Philip Rakity &lt;prakity@marvell.com&gt;
Reviewed-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: sd: add support for driver type selection</title>
<updated>2011-05-25T03:53:24Z</updated>
<author>
<name>Arindam Nath</name>
</author>
<published>2011-05-05T06:48:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d6d50a15a2897d4133d536dd4343b5cf21163db3'/>
<id>urn:sha1:d6d50a15a2897d4133d536dd4343b5cf21163db3</id>
<content type='text'>
This patch adds support for setting driver strength during UHS-I
initialization procedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can
save the ROCR from ACMD41 to check whether bit 24 is set.

We decide whether the Host Controller supports A, C, or D driver
type depending on the Capabilities register. Driver type B is
suported by default. We then set the appropriate driver type for
the card using CMD6 mode 1. As per Host Controller spec v3.00, we
set driver type for the host only if Preset Value Enable in the
Host Control2 register is not set. SDHCI_HOST_CONTROL has been
renamed to SDHCI_HOST_CONTROL1 to conform to the spec.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Reviewed-by: Philip Rakity &lt;prakity@marvell.com&gt;
Tested-by: Philip Rakity &lt;prakity@marvell.com&gt;
Acked-by: Zhangfei Gao &lt;zhangfei.gao@marvell.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: sd: add support for signal voltage switch procedure</title>
<updated>2011-05-25T01:04:38Z</updated>
<author>
<name>Arindam Nath</name>
</author>
<published>2011-05-05T06:48:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f2119df6b764609af4baceb68caf1e848c1c8aa7'/>
<id>urn:sha1:f2119df6b764609af4baceb68caf1e848c1c8aa7</id>
<content type='text'>
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.

Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply &gt;150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.

If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.

Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.

Signed-off-by: Arindam Nath &lt;arindam.nath@amd.com&gt;
Reviewed-by: Philip Rakity &lt;prakity@marvell.com&gt;
Tested-by: Philip Rakity &lt;prakity@marvell.com&gt;
Acked-by: Zhangfei Gao &lt;zhangfei.gao@marvell.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: quirks: Extends card quirks with MMC/SD quirks matching the CID.</title>
<updated>2011-05-25T01:00:54Z</updated>
<author>
<name>Andrei Warkentin</name>
</author>
<published>2011-04-11T22:02:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=32780cd1350e651e68bdf33b7f5b009d21d5b794'/>
<id>urn:sha1:32780cd1350e651e68bdf33b7f5b009d21d5b794</id>
<content type='text'>
The current mechanism is SDIO-only. This allows us to create
function-specific quirks, without creating messy Kconfig dependencies,
or polluting core/ with function-specific code.

Signed-off-by: Andrei Warkentin &lt;andreiw@motorola.com&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: add per device quirk placeholder</title>
<updated>2011-03-15T17:48:33Z</updated>
<author>
<name>Pierre Tardy</name>
</author>
<published>2011-02-06T18:03:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=57f0adc7eaaf4315d568e72069dbe48aa7e20995'/>
<id>urn:sha1:57f0adc7eaaf4315d568e72069dbe48aa7e20995</id>
<content type='text'>
Some cards have quirks valid for every platforms using current
platform quirk hooks leads to a lot of code and debug duplication.

So we inspire a bit from what exists in PCI subsystem and do our own
per vendorid/deviceid quirk.  We still drop the complexity of the pci
quirk system (with special section tables, and so on).
That can be added later if needed.

Signed-off-by: Pierre Tardy &lt;pierre.tardy@intel.com&gt;
Acked-by: Linus Walleij &lt;linus.walleij@stericsson.com&gt;
Acked-by: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: Fix sd/sdio/mmc initialization frequency retries</title>
<updated>2011-01-09T04:52:25Z</updated>
<author>
<name>Andy Ross</name>
</author>
<published>2011-01-03T18:36:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=807e8e40673d9628fa7dcdd14423424b4ee5f43b'/>
<id>urn:sha1:807e8e40673d9628fa7dcdd14423424b4ee5f43b</id>
<content type='text'>
Rewrite and clean up mmc_rescan() to properly retry frequencies lower
than 400kHz.  Failures can happen both in sd_send_* calls and
mmc_attach_*.  Break out "mmc_rescan_try_freq" from the frequency
selection loop.  Symmetrize claim/release logic in mmc_attach_* API,
and move the sd_send_* calls there to make mmc_rescan easier to read.

Signed-off-by: Andy Ross &lt;andy.ross@windriver.com&gt;
Reviewed-and-Tested-by: Hein Tibosch &lt;hein_tibosch@yahoo.es&gt;
Reviewed-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: Aggressive clock gating framework</title>
<updated>2011-01-09T03:48:03Z</updated>
<author>
<name>Linus Walleij</name>
</author>
<published>2010-11-09T02:36:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=04566831a703ae3ef4b49a2deae261c9ed26e020'/>
<id>urn:sha1:04566831a703ae3ef4b49a2deae261c9ed26e020</id>
<content type='text'>
This patch modifies the MMC core code to optionally call the set_ios()
operation on the driver with the clock frequency set to 0 (gate) after
a grace period of at least 8 MCLK cycles, then restore it (ungate)
before any new request. This gives the driver the option to shut down
the MCI clock to the MMC/SD card when the clock frequency is 0, i.e.
the core has stated that the MCI clock does not need to be generated.

It is inspired by existing clock gating code found in the OMAP and
Atmel drivers and brings this up to the host abstraction.  Gating is
performed before and after any MMC request.

This patchset implements this for the MMCI/PL180 MMC/SD host controller,
but it should be simple to switch OMAP/Atmel over to using this instead.

mmc_set_{gated,ungated}() add variable protection to the state holders
for the clock gating code.  This is particularly important when ordinary
.set_ios() calls would race with the .set_ios() call resulting from a
delayed gate operation.

Signed-off-by: Linus Walleij &lt;linus.walleij@stericsson.com&gt;
Reviewed-by: Chris Ball &lt;cjb@laptop.org&gt;
Tested-by: Chris Ball &lt;cjb@laptop.org&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
<entry>
<title>mmc: propagate power save/restore ops return value</title>
<updated>2010-10-23T13:11:17Z</updated>
<author>
<name>Ohad Ben-Cohen</name>
</author>
<published>2010-10-02T11:54:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=12ae637f081a7a05144af65802a7b492b9162660'/>
<id>urn:sha1:12ae637f081a7a05144af65802a7b492b9162660</id>
<content type='text'>
Allow power save/restore and their relevant mmc_bus_ops handlers
exit with a return value.

Signed-off-by: Ohad Ben-Cohen &lt;ohad@wizery.com&gt;
Tested-by: Luciano Coelho &lt;luciano.coelho@nokia.com&gt;
Signed-off-by: Chris Ball &lt;cjb@laptop.org&gt;
</content>
</entry>
</feed>
