<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/mmc/host/Makefile, branch v5.8</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>mmc: host: add Coldfire esdhc support</title>
<updated>2020-05-28T09:22:15+00:00</updated>
<author>
<name>Angelo Dureghello</name>
<email>angelo.dureghello@timesys.com</email>
</author>
<published>2020-05-18T19:17:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a5a944d24cbce13f86932f6d9ae4ac4586fe543a'/>
<id>a5a944d24cbce13f86932f6d9ae4ac4586fe543a</id>
<content type='text'>
This driver has been developed as a separate module starting
from the similar sdhci-esdhc-imx.c.

Reasons for a separate sdchi-esdhc-mcf driver:

- m68K architecture does not support devicetrees, so modifying
sdhci-of-esdhc.c that is devicetree-related adding platform data
seems not appropriate,
- clock-related part, has to be implemented specifically for
mcf5441x family (see esdhc_mcf_pltfm_set_clock()),
- this is a big endian cpu accessing a big endian controller,
but about sdma, this controller does not support hw swap, which
needs to be handled with specific code,
- some other minor differences but mainly to avoid risks on
tweaking inside largely used imx driver. Adding just a small
size ColdFire-specific driver, with benefits in a further less
risky maintenance.

Signed-off-by: Angelo Dureghello &lt;angelo.dureghello@timesys.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20200518191742.1251440-3-angelo.dureghello@timesys.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver has been developed as a separate module starting
from the similar sdhci-esdhc-imx.c.

Reasons for a separate sdchi-esdhc-mcf driver:

- m68K architecture does not support devicetrees, so modifying
sdhci-of-esdhc.c that is devicetree-related adding platform data
seems not appropriate,
- clock-related part, has to be implemented specifically for
mcf5441x family (see esdhc_mcf_pltfm_set_clock()),
- this is a big endian cpu accessing a big endian controller,
but about sdma, this controller does not support hw swap, which
needs to be handled with specific code,
- some other minor differences but mainly to avoid risks on
tweaking inside largely used imx driver. Adding just a small
size ColdFire-specific driver, with benefits in a further less
risky maintenance.

Signed-off-by: Angelo Dureghello &lt;angelo.dureghello@timesys.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Link: https://lore.kernel.org/r/20200518191742.1251440-3-angelo.dureghello@timesys.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: meson-mx-sdhc: Fix building with CONFIG_MMC_MESON_MX_SDHC=m</title>
<updated>2020-05-28T09:22:14+00:00</updated>
<author>
<name>Martin Blumenstingl</name>
<email>martin.blumenstingl@googlemail.com</email>
</author>
<published>2020-05-18T06:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=67c7daec6981d9b15ba85018b20ff8bcc3bcd193'/>
<id>67c7daec6981d9b15ba85018b20ff8bcc3bcd193</id>
<content type='text'>
For an x86_64 allmodconfig build Stephen reports that building
meson-mx-sdhc-clkc.o warns that MODULE_LICENSE is missing and when
linking meson_mx_sdhc_register_clkc cannot be found.

Compile the MMC controller driver together with the build-in clock
controller driver into one module rather than using two separate
modules to fix these issues.

Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Link: https://lore.kernel.org/r/20200518060811.1499962-1-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For an x86_64 allmodconfig build Stephen reports that building
meson-mx-sdhc-clkc.o warns that MODULE_LICENSE is missing and when
linking meson_mx_sdhc_register_clkc cannot be found.

Compile the MMC controller driver together with the build-in clock
controller driver into one module rather than using two separate
modules to fix these issues.

Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Link: https://lore.kernel.org/r/20200518060811.1499962-1-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host</title>
<updated>2020-05-28T09:22:14+00:00</updated>
<author>
<name>Martin Blumenstingl</name>
<email>martin.blumenstingl@googlemail.com</email>
</author>
<published>2020-05-12T20:41:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e4bf1b0970ef96135c78c7dcf4e14484ce3b9804'/>
<id>e4bf1b0970ef96135c78c7dcf4e14484ce3b9804</id>
<content type='text'>
The SDHC MMC host controller on Amlogic SoCs provides an eMMC and MMC
card interface with 1/4/8-bit bus width.
It supports eMMC spec 4.4x/4.5x including HS200 (up to 100MHz clock).

The public S805 datasheet [0] contains a short documentation about the
registers. Unfortunately it does not describe how to use the registers
to make the hardware work. Thus this driver is based on reading (and
understanding) the Amlogic 3.10 GPL kernel code.

Some hardware details are not easy to see. Jianxin Pan was kind enough
to answer my questions:
The hardware has built-in busy timeout support. The maximum timeout is
30 seconds. This is only documented in Amlogic's internal
documentation.

The controller only works with very specific clock configurations. The
details are not part of the public datasheet. In my own words the
supported configurations are:
- 399.812kHz:	clkin =  850MHz div = 2126 sd_rx_phase = 63
- 1MHz:		clkin =  850MHz div = 850  sd_rx_phase = 55
- 5.986MHz:	clkin =  850MHz div = 142  sd_rx_phase = 24
- 25MHz:	clkin =  850MHz div = 34   sd_rx_phase = 15
- 47.222MHz:	clkin =  850MHz div = 18   sd_rx_phase = 11/15 (SDR50/HS)
- 53.125MHz:	clkin =  850MHz div = 16   sd_rx_phase = (tuning)
- 70.833MHz:	clkin =  850MHz div = 12   sd_rx_phase = (tuning)
- 85MHz:	clkin =  850MHz div = 10   sd_rx_phase = (tuning)
- 94.44MHz:	clkin =  850MHz div = 9    sd_rx_phase = (tuning)
- 106.25MHz:	clkin =  850MHz div = 8    sd_rx_phase = (tuning)
- 127.5MHz:     clkin = 1275MHz div = 10   sd_rx_phase = (tuning)
- 141.667MHz:   clkin =  850MHz div = 6    sd_rx_phase = (tuning)
- 159.375MHz:	clkin = 1275MHz div = 8    sd_rx_phase = (tuning)
- 212.5MHz:	clkin = 1275MHz div = 6    sd_rx_phase = (tuning)
- (sd_tx_phase is always 1, 94.44MHz is not listed in the datasheet
   but this is what the 3.10 BSP kernel on Odroid-C1 actually uses)

NOTE: CMD23 support is disabled for now because it results in command
timeouts and thus decreases read performance.

Tested-by: Wei Wang &lt;lnykww@gmail.com&gt;
Tested-by: Xin Yin &lt;yinxin_1989@aliyun.com&gt;
Reviewed-by: Xin Yin &lt;yinxin_1989@aliyun.com&gt;
Tested-by: Anand Moon &lt;linux.amoon@gmail.com&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Reviewed-by: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Link: https://lore.kernel.org/r/20200512204147.504087-3-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SDHC MMC host controller on Amlogic SoCs provides an eMMC and MMC
card interface with 1/4/8-bit bus width.
It supports eMMC spec 4.4x/4.5x including HS200 (up to 100MHz clock).

The public S805 datasheet [0] contains a short documentation about the
registers. Unfortunately it does not describe how to use the registers
to make the hardware work. Thus this driver is based on reading (and
understanding) the Amlogic 3.10 GPL kernel code.

Some hardware details are not easy to see. Jianxin Pan was kind enough
to answer my questions:
The hardware has built-in busy timeout support. The maximum timeout is
30 seconds. This is only documented in Amlogic's internal
documentation.

The controller only works with very specific clock configurations. The
details are not part of the public datasheet. In my own words the
supported configurations are:
- 399.812kHz:	clkin =  850MHz div = 2126 sd_rx_phase = 63
- 1MHz:		clkin =  850MHz div = 850  sd_rx_phase = 55
- 5.986MHz:	clkin =  850MHz div = 142  sd_rx_phase = 24
- 25MHz:	clkin =  850MHz div = 34   sd_rx_phase = 15
- 47.222MHz:	clkin =  850MHz div = 18   sd_rx_phase = 11/15 (SDR50/HS)
- 53.125MHz:	clkin =  850MHz div = 16   sd_rx_phase = (tuning)
- 70.833MHz:	clkin =  850MHz div = 12   sd_rx_phase = (tuning)
- 85MHz:	clkin =  850MHz div = 10   sd_rx_phase = (tuning)
- 94.44MHz:	clkin =  850MHz div = 9    sd_rx_phase = (tuning)
- 106.25MHz:	clkin =  850MHz div = 8    sd_rx_phase = (tuning)
- 127.5MHz:     clkin = 1275MHz div = 10   sd_rx_phase = (tuning)
- 141.667MHz:   clkin =  850MHz div = 6    sd_rx_phase = (tuning)
- 159.375MHz:	clkin = 1275MHz div = 8    sd_rx_phase = (tuning)
- 212.5MHz:	clkin = 1275MHz div = 6    sd_rx_phase = (tuning)
- (sd_tx_phase is always 1, 94.44MHz is not listed in the datasheet
   but this is what the 3.10 BSP kernel on Odroid-C1 actually uses)

NOTE: CMD23 support is disabled for now because it results in command
timeouts and thus decreases read performance.

Tested-by: Wei Wang &lt;lnykww@gmail.com&gt;
Tested-by: Xin Yin &lt;yinxin_1989@aliyun.com&gt;
Reviewed-by: Xin Yin &lt;yinxin_1989@aliyun.com&gt;
Tested-by: Anand Moon &lt;linux.amoon@gmail.com&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Reviewed-by: Jerome Brunet &lt;jbrunet@baylibre.com&gt;
Link: https://lore.kernel.org/r/20200512204147.504087-3-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: Add MMC host software queue support</title>
<updated>2020-03-24T13:35:39+00:00</updated>
<author>
<name>Baolin Wang</name>
<email>baolin.wang@linaro.org</email>
</author>
<published>2020-02-12T04:12:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=511ce378e16f07b66ab78118587b7cc6ac197364'/>
<id>511ce378e16f07b66ab78118587b7cc6ac197364</id>
<content type='text'>
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead and spend some extra time to poll the card for busy completion
for I/O writes via sending CMD13, especially for high I/O per second
rates, to affect the IO performance.

Thus this patch introduces MMC software queue interface based on the
hardware command queue engine's interfaces, which is similar with the
hardware command queue engine's idea, that can remove the context
switching. Moreover we set the default queue depth as 64 for software
queue, which allows more requests to be prepared, merged and inserted
into IO scheduler to improve performance, but we only allow 2 requests
in flight, that is enough to let the irq handler always trigger the
next request without a context switch, as well as avoiding a long latency.

Moreover the host controller should support HW busy detection for I/O
operations when enabling the host software queue. That means, the host
controller must not complete a data transfer request, until after the
card stops signals busy.

From the fio testing data in cover letter, we can see the software
queue can improve some performance with 4K block size, increasing
about 16% for random read, increasing about 90% for random write,
though no obvious improvement for sequential read and write.

Moreover we can expand the software queue interface to support MMC
packed request or packed command in future.

Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang7@gmail.com&gt;
Link: https://lore.kernel.org/r/4409c1586a9b3ed20d57ad2faf6c262fc3ccb6e2.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead and spend some extra time to poll the card for busy completion
for I/O writes via sending CMD13, especially for high I/O per second
rates, to affect the IO performance.

Thus this patch introduces MMC software queue interface based on the
hardware command queue engine's interfaces, which is similar with the
hardware command queue engine's idea, that can remove the context
switching. Moreover we set the default queue depth as 64 for software
queue, which allows more requests to be prepared, merged and inserted
into IO scheduler to improve performance, but we only allow 2 requests
in flight, that is enough to let the irq handler always trigger the
next request without a context switch, as well as avoiding a long latency.

Moreover the host controller should support HW busy detection for I/O
operations when enabling the host software queue. That means, the host
controller must not complete a data transfer request, until after the
card stops signals busy.

From the fio testing data in cover letter, we can see the software
queue can improve some performance with 4K block size, increasing
about 16% for random read, increasing about 90% for random write,
though no obvious improvement for sequential read and write.

Moreover we can expand the software queue interface to support MMC
packed request or packed command in future.

Reviewed-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Baolin Wang &lt;baolin.wang7@gmail.com&gt;
Link: https://lore.kernel.org/r/4409c1586a9b3ed20d57ad2faf6c262fc3ccb6e2.1581478568.git.baolin.wang7@gmail.com
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: Add Actions Semi Owl SoCs SD/MMC driver</title>
<updated>2019-11-13T15:10:16+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@linaro.org</email>
</author>
<published>2019-09-16T15:45:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ff65ffe46d2839b434dbab77dd3af0cb4f6d2a98'/>
<id>ff65ffe46d2839b434dbab77dd3af0cb4f6d2a98</id>
<content type='text'>
Add SD/MMC driver for Actions Semi Owl SoCs. This driver currently
supports standard, high speed, SDR12, SDR25 and SDR50. DDR50 mode is
supported but it is untested. There is no SDIO support for now.

Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add SD/MMC driver for Actions Semi Owl SoCs. This driver currently
supports standard, high speed, SDR12, SDR25 and SDR50. DDR50 mode is
supported but it is untested. There is no SDIO support for now.

Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-milbeaut: add Milbeaut SD controller driver</title>
<updated>2019-11-13T15:10:16+00:00</updated>
<author>
<name>Takao Orito</name>
<email>orito.takao@socionext.com</email>
</author>
<published>2019-09-10T01:41:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dd79b7e367033bacff8ff8c1bd85b2a848cf475d'/>
<id>dd79b7e367033bacff8ff8c1bd85b2a848cf475d</id>
<content type='text'>
SD Host controller on Milbeaut consists of two controller parts.
One is core controller F_SDH30, this is similar to sdhci-fujitsu
controller.
Another is bridge controller.
This bridge controller is not compatible with sdhci-fujitsu controller.
This is special for Milbeaut series. This has some functions.
For example, reset control, clock enable/select for SDR50/25/12, set
property of SD physical pins, retuning control, set capabilityies.

This bridge controller requires special procedures at reset or clock
enablement or change for further tuning of clock.

Signed-off-by: Takao Orito &lt;orito.takao@socionext.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SD Host controller on Milbeaut consists of two controller parts.
One is core controller F_SDH30, this is similar to sdhci-fujitsu
controller.
Another is bridge controller.
This bridge controller is not compatible with sdhci-fujitsu controller.
This is special for Milbeaut series. This has some functions.
For example, reset control, clock enable/select for SDR50/25/12, set
property of SD physical pins, retuning control, set capabilityies.

This bridge controller requires special procedures at reset or clock
enablement or change for further tuning of clock.

Signed-off-by: Takao Orito &lt;orito.takao@socionext.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: host: sdhci-pci: Add Genesys Logic GL975x support</title>
<updated>2019-09-27T18:48:20+00:00</updated>
<author>
<name>Ben Chuang</name>
<email>ben.chuang@genesyslogic.com.tw</email>
</author>
<published>2019-09-11T07:23:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e51df6ce668a8f75ce27f83ce0f60103c568c375'/>
<id>e51df6ce668a8f75ce27f83ce0f60103c568c375</id>
<content type='text'>
Add support for the GL9750 and GL9755 chipsets.

Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
tuning flow for GL9750.

Co-developed-by: Michael K Johnson &lt;johnsonm@danlj.org&gt;
Signed-off-by: Michael K Johnson &lt;johnsonm@danlj.org&gt;
Signed-off-by: Ben Chuang &lt;ben.chuang@genesyslogic.com.tw&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for the GL9750 and GL9755 chipsets.

Enable v4 mode and wait 5ms after set 1.8V signal enable for GL9750/
GL9755. Fix the value of SDHCI_MAX_CURRENT register and use the vendor
tuning flow for GL9750.

Co-developed-by: Michael K Johnson &lt;johnsonm@danlj.org&gt;
Signed-off-by: Michael K Johnson &lt;johnsonm@danlj.org&gt;
Signed-off-by: Ben Chuang &lt;ben.chuang@genesyslogic.com.tw&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci-of-aspeed: Add support for the ASPEED SD controller</title>
<updated>2019-09-11T13:58:39+00:00</updated>
<author>
<name>Andrew Jeffery</name>
<email>andrew@aj.id.au</email>
</author>
<published>2019-08-07T00:36:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bb7b8ec62dfb9b255027c3a54d01f12fc3bd1d2c'/>
<id>bb7b8ec62dfb9b255027c3a54d01f12fc3bd1d2c</id>
<content type='text'>
Add a minimal driver for ASPEED's SD controller, which exposes two
SDHCIs.

The ASPEED design implements a common register set for the SDHCIs, and
moves some of the standard configuration elements out to this common
area (e.g. 8-bit mode, and card detect configuration which is not
currently supported).

The SD controller has a dedicated hardware interrupt that is shared
between the slots. The common register set exposes information on which
slot triggered the interrupt; early revisions of the patch introduced an
irqchip for the register, but reality is it doesn't behave as an
irqchip, and the result fits awkwardly into the irqchip APIs. Instead
I've taken the simple approach of using the IRQ as a shared IRQ with
some minor performance impact for the second slot.

Ryan was the original author of the patch - I've taken his work and
massaged it to drop the irqchip support and rework the devicetree
integration. The driver has been smoke tested under qemu against a
minimal SD controller model and lightly tested on an ast2500-evb.

Signed-off-by: Ryan Chen &lt;ryanchen.aspeed@gmail.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a minimal driver for ASPEED's SD controller, which exposes two
SDHCIs.

The ASPEED design implements a common register set for the SDHCIs, and
moves some of the standard configuration elements out to this common
area (e.g. 8-bit mode, and card detect configuration which is not
currently supported).

The SD controller has a dedicated hardware interrupt that is shared
between the slots. The common register set exposes information on which
slot triggered the interrupt; early revisions of the patch introduced an
irqchip for the register, but reality is it doesn't behave as an
irqchip, and the result fits awkwardly into the irqchip APIs. Instead
I've taken the simple approach of using the IRQ as a shared IRQ with
some minor performance impact for the second slot.

Ryan was the original author of the patch - I've taken his work and
massaged it to drop the irqchip support and rework the devicetree
integration. The driver has been smoke tested under qemu against a
minimal SD controller model and lightly tested on an ast2500-evb.

Signed-off-by: Ryan Chen &lt;ryanchen.aspeed@gmail.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Reviewed-by: Joel Stanley &lt;joel@jms.id.au&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver</title>
<updated>2018-12-17T07:26:24+00:00</updated>
<author>
<name>Faiz Abbas</name>
<email>faiz_abbas@ti.com</email>
</author>
<published>2018-12-10T18:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=41fd4caeb00bbd6dc55f056f3e8e956697b0760d'/>
<id>41fd4caeb00bbd6dc55f056f3e8e956697b0760d</id>
<content type='text'>
The host controllers on TI's AM654 SOCs are not compatible with
the phy and consumer model of the sdhci-of-arasan driver. It turns out
that for optimal operation at higher speeds, a special tuning procedure
needs to be implemented which involves configuration of platform
specific phy registers.

Therefore, branch out to a new sdhci_am654 driver and add the phy
register space with all phy configurations to it. Populate AM654
specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
applicable.

Only add support for upto High Speed for SD card and upto DDR52 speed
mode for eMMC. Higher speeds will be added in subsequent patches.

Signed-off-by: Faiz Abbas &lt;faiz_abbas@ti.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The host controllers on TI's AM654 SOCs are not compatible with
the phy and consumer model of the sdhci-of-arasan driver. It turns out
that for optimal operation at higher speeds, a special tuning procedure
needs to be implemented which involves configuration of platform
specific phy registers.

Therefore, branch out to a new sdhci_am654 driver and add the phy
register space with all phy configurations to it. Populate AM654
specific callbacks to sdhci_ops and add SDHCI_QUIRKS wherever
applicable.

Only add support for upto High Speed for SD card and upto DDR52 speed
mode for eMMC. Higher speeds will be added in subsequent patches.

Signed-off-by: Faiz Abbas &lt;faiz_abbas@ti.com&gt;
Acked-by: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mmc: add new Alcor Micro Cardreader SD/MMC driver</title>
<updated>2018-12-17T07:26:24+00:00</updated>
<author>
<name>Oleksij Rempel</name>
<email>linux@rempel-privat.de</email>
</author>
<published>2018-12-02T10:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c5413ad815a675b5c98a002353d8e96b44b164e9'/>
<id>c5413ad815a675b5c98a002353d8e96b44b164e9</id>
<content type='text'>
This driver provides support for Alcor Micro AU6601 and AU6621
SD/MMC controller.

Signed-off-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This driver provides support for Alcor Micro AU6601 and AU6621
SD/MMC controller.

Signed-off-by: Oleksij Rempel &lt;linux@rempel-privat.de&gt;
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
