<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/sys/dev/sdhci, branch releng/12.3</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>MFC r364779:</title>
<updated>2020-09-01T13:58:17+00:00</updated>
<author>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</author>
<published>2020-09-01T13:58:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=408f369cddc9ac56f458d4ecfa8625493082fd11'/>
<id>408f369cddc9ac56f458d4ecfa8625493082fd11</id>
<content type='text'>
sdhci(4): Recognize the Texas Instruments PCIxx12 card reader.

PR:	248650
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
sdhci(4): Recognize the Texas Instruments PCIxx12 card reader.

PR:	248650
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r350162:</title>
<updated>2020-07-11T16:38:46+00:00</updated>
<author>
<name>Ganbold Tsagaankhuu</name>
<email>ganbold@FreeBSD.org</email>
</author>
<published>2020-07-11T16:38:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=5b527d10d2efbc9fa2f10ad0b17569d2385dcb8f'/>
<id>5b527d10d2efbc9fa2f10ad0b17569d2385dcb8f</id>
<content type='text'>
Add emmc support for Rockchip RK3399 SoC.
Tested on NanoPC-T4 board.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add emmc support for Rockchip RK3399 SoC.
Tested on NanoPC-T4 board.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r353651-r353652</title>
<updated>2019-10-17T01:30:37+00:00</updated>
<author>
<name>Ian Lepore</name>
<email>ian@FreeBSD.org</email>
</author>
<published>2019-10-17T01:30:37+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d661b615f707c8bae27dc58a85a2434aba711228'/>
<id>d661b615f707c8bae27dc58a85a2434aba711228</id>
<content type='text'>
r353651:
Relax the sdhci(4) check that filters out the 1.8v voltage option unless
the slot is flagged as 'embedded'.

The features related to embedded and shared slots were added in v3.0 of
the sdhci spec.  Hardware prior to v3 sometimes supported 1.8v on non-
removable devices in embedded systems, but had no way to indicate that
via the standard sdhci registers (instead they use out of band metadata
such as FDT data).

This change adds the controller specification version to the check for
whether to filter out the 1.8v selection.  On older hardware, the 1.8v
option is allowed to remain.  On 3.0 or later it still requires the
embedded-slot flag to remain.

This is part of the fix for PR 241301 (eMMC not detected on Beaglebone).
Changes to the sdhci_ti driver are also needed for a full fix.

PR:		241301

r353652:
Revert r351218 (by manu).  While the changes in r351218 appear to be (and
should be) correct, they lead to the eMMC on a Beaglebone failing to work
in some situations.

The TI sdhci hardware is kind of strange.  The first device inherently
supports 1.8v and 3.3v and the abililty to switch between them, and the
other two devices must be set to 1.8v in the sdhci power control register to
operate correctly, but doing so actually makes them run at 3.3v (unless an
external level-shifter is present in the signal path).  Even the 1.8v on the
first device may actually be 3.3v (or any other value), depending on what
voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip.

Another strange quirk is that the convention for am335x sdhci drivers in
linux and uboot and the am335x boot ROM seems to be to set the voltage in
the sdhci capabilities register to 3.0v even though the actual voltage is
3.3v.  Why this is done is a complete mystery to me, but it seems to be
required for correct operation.

If we had complete modern support for the am335x chip we could get the
actual voltages from the FDT data and the regulator framework.  But our
am335x code currently doesn't have any regulator framework support.
Reverting to the prior code will get the popular Beaglebone boards working
again.

This is part of the fix for PR 241301, but also requires r353651 for a
complete fix.

PR:		241301
Discussed with: manu

Approved by:	re(gjb) for MFC without 3-day wait
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r353651:
Relax the sdhci(4) check that filters out the 1.8v voltage option unless
the slot is flagged as 'embedded'.

The features related to embedded and shared slots were added in v3.0 of
the sdhci spec.  Hardware prior to v3 sometimes supported 1.8v on non-
removable devices in embedded systems, but had no way to indicate that
via the standard sdhci registers (instead they use out of band metadata
such as FDT data).

This change adds the controller specification version to the check for
whether to filter out the 1.8v selection.  On older hardware, the 1.8v
option is allowed to remain.  On 3.0 or later it still requires the
embedded-slot flag to remain.

This is part of the fix for PR 241301 (eMMC not detected on Beaglebone).
Changes to the sdhci_ti driver are also needed for a full fix.

PR:		241301

r353652:
Revert r351218 (by manu).  While the changes in r351218 appear to be (and
should be) correct, they lead to the eMMC on a Beaglebone failing to work
in some situations.

The TI sdhci hardware is kind of strange.  The first device inherently
supports 1.8v and 3.3v and the abililty to switch between them, and the
other two devices must be set to 1.8v in the sdhci power control register to
operate correctly, but doing so actually makes them run at 3.3v (unless an
external level-shifter is present in the signal path).  Even the 1.8v on the
first device may actually be 3.3v (or any other value), depending on what
voltage is fed to the VDDS1-VDDS7 power supply pins on the am335x chip.

Another strange quirk is that the convention for am335x sdhci drivers in
linux and uboot and the am335x boot ROM seems to be to set the voltage in
the sdhci capabilities register to 3.0v even though the actual voltage is
3.3v.  Why this is done is a complete mystery to me, but it seems to be
required for correct operation.

If we had complete modern support for the am335x chip we could get the
actual voltages from the FDT data and the regulator framework.  But our
am335x code currently doesn't have any regulator framework support.
Reverting to the prior code will get the popular Beaglebone boards working
again.

This is part of the fix for PR 241301, but also requires r353651 for a
complete fix.

PR:		241301
Discussed with: manu

Approved by:	re(gjb) for MFC without 3-day wait
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r350847:</title>
<updated>2019-09-05T16:53:55+00:00</updated>
<author>
<name>Ian Lepore</name>
<email>ian@FreeBSD.org</email>
</author>
<published>2019-09-05T16:53:55+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=80408fd95b36bca0753179ee1f0f3c54795c5032'/>
<id>80408fd95b36bca0753179ee1f0f3c54795c5032</id>
<content type='text'>
Allow the sdhci timeout sysctl var to be set as a tunable.  Also, add a
missing newline in a warning printf.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allow the sdhci timeout sysctl var to be set as a tunable.  Also, add a
missing newline in a warning printf.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r348880, r348882</title>
<updated>2019-08-16T20:49:10+00:00</updated>
<author>
<name>Emmanuel Vadot</name>
<email>manu@FreeBSD.org</email>
</author>
<published>2019-08-16T20:49:10+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=34b91cbeb0f70ff7deed8249efa7022870c1afcf'/>
<id>34b91cbeb0f70ff7deed8249efa7022870c1afcf</id>
<content type='text'>
r348880 by loos:
Add the GPIO driver for the North/South bridge in Marvell Armada 37x0.

The A3700 has a different GPIO controller and thus, do not use the old (and
shared) code for Marvell.

The pinctrl driver, also part of the controller, is not supported yet (but
the implementation should be straightforward).

Sponsored by:	Rubicon Communications, LLC (Netgate)

r348882 by loos:
Add support for the GPIO SD Card VCC regulator/switch and the GPIO SD Card
detection pins to the Marvell Xenon SDHCI controller.

These features are enable by 'vqmmc-supply' and 'cd-gpios' properties in the
DTS.

This fixes the SD Card detection on espressobin.

Sponsored by:	Rubicon Communications, LLC (Netgate)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r348880 by loos:
Add the GPIO driver for the North/South bridge in Marvell Armada 37x0.

The A3700 has a different GPIO controller and thus, do not use the old (and
shared) code for Marvell.

The pinctrl driver, also part of the controller, is not supported yet (but
the implementation should be straightforward).

Sponsored by:	Rubicon Communications, LLC (Netgate)

r348882 by loos:
Add support for the GPIO SD Card VCC regulator/switch and the GPIO SD Card
detection pins to the Marvell Xenon SDHCI controller.

These features are enable by 'vqmmc-supply' and 'cd-gpios' properties in the
DTS.

This fixes the SD Card detection on espressobin.

Sponsored by:	Rubicon Communications, LLC (Netgate)
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r342008, r342010-r342020</title>
<updated>2019-08-05T17:43:44+00:00</updated>
<author>
<name>Emmanuel Vadot</name>
<email>manu@FreeBSD.org</email>
</author>
<published>2019-08-05T17:43:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=bb96de707c2e882044864a4f0a79d1f98e872f2d'/>
<id>bb96de707c2e882044864a4f0a79d1f98e872f2d</id>
<content type='text'>
r342008:
fdt: Add support for simple-mfd bus

Quoting the binding Documentation :

"These devices comprise a nexus for heterogeneous hardware blocks containing
more than one non-unique yet varying hardware functionality."

Reviewed by:	loos
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D17751

r342010:
arm64: Add new SoC type MARVELL_8K

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342011:
arm64: mvebu_pinctrl: Add driver for Marvell Pinmux Controller

Add a driver compatible with Marvell mvebu-pinctrl and add ap806-pinctrl
support.

Sponsored by:	Rubicon Communications, LCC ("Netgate")

r342012:
arm64: marvell: Add driver for Marvell Ap806 System Controller

The first two clocks are for the clusters and their frequencies can be
found reading a register. Then a fixed 1200Mhz clock is present and two
fixed clocks, 'mss' which is 1200 / 6 and 'sdio' which is 1200 / 3.

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342013:
arm64: mv_gpio: Add Marvell 8K support

While here put the interrupts setup in it's own function

Sponsored by:	Rubicon Communications, LCC ("Netgate")

r342014:
arm64: marvell: Add cp110 clock controller support

The cp110 clock controller controls the clocks and gate of the CP110
hardware block.

Every clock/gate are implemented except the NAND clock.

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342015:
twsi: Clean up marvell part and add support for Marvell 7k/8k

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342016:
arm64: Add mv_cp110_icu and mv_cp110_gicp

icu is a interrupt concentrator in the CP110 block and gicp
is a gic extension to allow interrupts in the CP block to be turned
into GIC SPI interrupts

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342017:
sdhci_xenon: Add Marvell 8k compatible string

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342018:
mv_gpio: Since it's also an interrupt controller, attach sooner

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342019:
arm64: mv_cp110_icu: Fix build

r342020:
mv_thermal: Add thermal driver for AP806 and CP110 thermal sensor

Sponsored by:	Rubicon Communications, LLC ("Netgate")
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r342008:
fdt: Add support for simple-mfd bus

Quoting the binding Documentation :

"These devices comprise a nexus for heterogeneous hardware blocks containing
more than one non-unique yet varying hardware functionality."

Reviewed by:	loos
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D17751

r342010:
arm64: Add new SoC type MARVELL_8K

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342011:
arm64: mvebu_pinctrl: Add driver for Marvell Pinmux Controller

Add a driver compatible with Marvell mvebu-pinctrl and add ap806-pinctrl
support.

Sponsored by:	Rubicon Communications, LCC ("Netgate")

r342012:
arm64: marvell: Add driver for Marvell Ap806 System Controller

The first two clocks are for the clusters and their frequencies can be
found reading a register. Then a fixed 1200Mhz clock is present and two
fixed clocks, 'mss' which is 1200 / 6 and 'sdio' which is 1200 / 3.

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342013:
arm64: mv_gpio: Add Marvell 8K support

While here put the interrupts setup in it's own function

Sponsored by:	Rubicon Communications, LCC ("Netgate")

r342014:
arm64: marvell: Add cp110 clock controller support

The cp110 clock controller controls the clocks and gate of the CP110
hardware block.

Every clock/gate are implemented except the NAND clock.

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342015:
twsi: Clean up marvell part and add support for Marvell 7k/8k

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342016:
arm64: Add mv_cp110_icu and mv_cp110_gicp

icu is a interrupt concentrator in the CP110 block and gicp
is a gic extension to allow interrupts in the CP block to be turned
into GIC SPI interrupts

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342017:
sdhci_xenon: Add Marvell 8k compatible string

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342018:
mv_gpio: Since it's also an interrupt controller, attach sooner

Sponsored by:	Rubicon Communications, LLC ("Netgate")

r342019:
arm64: mv_cp110_icu: Fix build

r342020:
mv_thermal: Add thermal driver for AP806 and CP110 thermal sensor

Sponsored by:	Rubicon Communications, LLC ("Netgate")
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r345372:</title>
<updated>2019-04-19T15:52:09+00:00</updated>
<author>
<name>Bjoern A. Zeeb</name>
<email>bz@FreeBSD.org</email>
</author>
<published>2019-04-19T15:52:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=6ff3733cb5050018899ef06225fd8e48391e5bae'/>
<id>6ff3733cb5050018899ef06225fd8e48391e5bae</id>
<content type='text'>
  Whitespace cleanup in sdhci.c

  No functional changes.  Replace whitespace by tabs, indent with 4 spaces,
  coalesce multi-line shorter than 80 characters,
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  Whitespace cleanup in sdhci.c

  No functional changes.  Replace whitespace by tabs, indent with 4 spaces,
  coalesce multi-line shorter than 80 characters,
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r345370:</title>
<updated>2019-04-19T15:50:51+00:00</updated>
<author>
<name>Bjoern A. Zeeb</name>
<email>bz@FreeBSD.org</email>
</author>
<published>2019-04-19T15:50:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=94b16715a03232095b276822dab01e1c2ae5c08e'/>
<id>94b16715a03232095b276822dab01e1c2ae5c08e</id>
<content type='text'>
  Align struct sdhci_slot MMCCAM members.

  Whitespace only, no functional change.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
  Align struct sdhci_slot MMCCAM members.

  Whitespace only, no functional change.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC: r342634</title>
<updated>2019-01-27T19:04:02+00:00</updated>
<author>
<name>Marius Strobl</name>
<email>marius@FreeBSD.org</email>
</author>
<published>2019-01-27T19:04:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=3163b8425921ffb810687c079fcd0eadaed277c1'/>
<id>3163b8425921ffb810687c079fcd0eadaed277c1</id>
<content type='text'>
o Don't allocate resources for SDMA in sdhci(4) if the controller or the
  front-end doesn't support SDMA or the latter implements a platform-
  specific transfer method instead. While at it, factor out allocation
  and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
  keep the code more readable when adding support for ADMA variants.

o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
  of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
  MAXPHYS of 128 KiB and depending on the controller and medium, this
  reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
  sequential reads while an increase of throughput of up to ~84 % was
  seen.

  Front-ends for broken controllers that only support an SDMA buffer
  boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
  and supply a size via struct sdhci_slot. According to Linux, only
  Qualcomm MSM-type SDHCI controllers are affected by this, though.

  Requested by: Shreyank Amartya (unconditional bump to 512 KiB)

o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
  front-end modules on the sdhci(4) one and bump the module version
  of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
  to ensure that all components are in sync WRT struct sdhci_slot.

o In sdhci(4):
  - Make pointers const were applicable,
  - replace a few device_printf(9) calls with slot_printf() for
    consistency, and
  - sync some local functions with their prototypes WRT static.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
o Don't allocate resources for SDMA in sdhci(4) if the controller or the
  front-end doesn't support SDMA or the latter implements a platform-
  specific transfer method instead. While at it, factor out allocation
  and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
  keep the code more readable when adding support for ADMA variants.

o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
  of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
  MAXPHYS of 128 KiB and depending on the controller and medium, this
  reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
  sequential reads while an increase of throughput of up to ~84 % was
  seen.

  Front-ends for broken controllers that only support an SDMA buffer
  boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
  and supply a size via struct sdhci_slot. According to Linux, only
  Qualcomm MSM-type SDHCI controllers are affected by this, though.

  Requested by: Shreyank Amartya (unconditional bump to 512 KiB)

o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
  front-end modules on the sdhci(4) one and bump the module version
  of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
  to ensure that all components are in sync WRT struct sdhci_slot.

o In sdhci(4):
  - Make pointers const were applicable,
  - replace a few device_printf(9) calls with slot_printf() for
    consistency, and
  - sync some local functions with their prototypes WRT static.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC: r340543, r340654</title>
<updated>2018-11-22T13:09:03+00:00</updated>
<author>
<name>Marius Strobl</name>
<email>marius@FreeBSD.org</email>
</author>
<published>2018-11-22T13:09:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=62eb68411db0f6abd67d778ec81bd11e266b1b47'/>
<id>62eb68411db0f6abd67d778ec81bd11e266b1b47</id>
<content type='text'>
Add a quirk handling for AMDI0040 controllers allowing them to do HS400.

Submitted by:	Shreyank Amartya (original version)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a quirk handling for AMDI0040 controllers allowing them to do HS400.

Submitted by:	Shreyank Amartya (original version)
</pre>
</div>
</content>
</entry>
</feed>
