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

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.

show more ...

arm64: GENERIC-MMCCAM: Fix build and module depend

Fix the build of the GENERIC-MMCCAM kernel config after the sdhci_xenon
driver was commited.
While here correct sdhci_fdt and tegra_sdhci, even wit

arm64: GENERIC-MMCCAM: Fix build and module depend

Fix the build of the GENERIC-MMCCAM kernel config after the sdhci_xenon
driver was commited.
While here correct sdhci_fdt and tegra_sdhci, even with MMCCAM they do
need to depend on sdhci(4)

Reported by: Reshetnikov Dmitriy <genserg@hotmail.com>
Approved by: re (kib)
Sponsored by: Rubicon Communications, LLC ("NetGate")

show more ...

Fix build when option MMCCAM is defined.

Add support for SDHCI controller found in Qualcomm Snapdragon 410e.

Tested on DragonBoard 410c.

Sponsored by: DARPA, AFRL

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...

Add the Marvell SDHCI controller to the list of supported devices in
sdhci_fdt.

Enable the SDHCI controller, bus and devices on ARMADA38X kernel.

Tested on: ClearFog Pro
Reviewed by: Marcin Wojtas

Add the Marvell SDHCI controller to the list of supported devices in
sdhci_fdt.

Enable the SDHCI controller, bus and devices on ARMADA38X kernel.

Tested on: ClearFog Pro
Reviewed by: Marcin Wojtas <mw at semihalf.com>
Sponsored by: Rubicon Communications, LLC (Netgate)
Differential Revision: https://reviews.freebsd.org/D10606

show more ...

Add support for the no-1-8-v and wp-inverted properties in generic SDHCI
FDT glue.

MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)

Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omis

Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges
as kernel drivers and their dependency onto mmc(4); this allows for
incrementing the mmc(4) module version but also for entire omission
of these bridge declarations for mmccam(4) in a single place, i. e.
in dev/mmc/bridge.h.

show more ...

o Another round fixes for mmc(4), mmcsd(4) and sdhci(4) regarding
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:

o Another round fixes for mmc(4), mmcsd(4) and sdhci(4) regarding
comments, marking unused parameters as such, style(9), whitespace,
etc.
o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method (I've whipped these out of the tree as part of r227843
once, but they keep coming back ...),
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.
o Trim/adjust includes.

show more ...

Fix some more overly long lines, whitespace and other bugs according to
style(9) as well as spelling in comments.

Fix fallout from r292180 (Dec 2015)... ensure that every driver which has
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for s

Fix fallout from r292180 (Dec 2015)... ensure that every driver which has
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).

(Thanks to jilles@ for providing the vital clue about the kernel linker.)

show more ...

Move the DRIVER_MODULE() statements that declare mmc(4) to be a child of
the various bridge drivers out of dev/mmc.c and into the bridge drivers.

Requested by: jhb (almost two years ago; better l

Move the DRIVER_MODULE() statements that declare mmc(4) to be a child of
the various bridge drivers out of dev/mmc.c and into the bridge drivers.

Requested by: jhb (almost two years ago; better late than never)

show more ...

- Nuke unused sdhci_softc.
- Static'ize sdhci_debug local to sdhci.c.
- Const'ify PCI device description strings.
- Nuke redundant resource ID members from sdhci_pci_softc.
- Nuke unused hw.sdhci_pci

- Nuke unused sdhci_softc.
- Static'ize sdhci_debug local to sdhci.c.
- Const'ify PCI device description strings.
- Nuke redundant resource ID members from sdhci_pci_softc.
- Nuke unused hw.sdhci_pci.debug tunable.
- Add support for using MSI instead of INTx, controllable via the tunable
hw.sdhci.enable_msi (defaulting to on) and tested with a RICOH R5CE823 SD
controller.
- Use NULL instead of 0 for pointers.

MFC after: 3 days

show more ...

Honor the max-frequency property if it appears in the fdt data.
Adjust the exynos and zedboard dts files to use max-frequency (the
documented standard property) instead of clock-frequency.

Submitted

Honor the max-frequency property if it appears in the fdt data.
Adjust the exynos and zedboard dts files to use max-frequency (the
documented standard property) instead of clock-frequency.

Submitted by: Thomas Skibo <ThomasSkibo@sbcglobal.net>

show more ...

Follow r261352 by updating all drivers which are children of simplebus
to check the status property in their probe routines.

Simplebus used to only instantiate its children whose status="okay"
but t

Follow r261352 by updating all drivers which are children of simplebus
to check the status property in their probe routines.

Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.

Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.

show more ...

Add Xilinx Zynq ARM/FPGA SoC support to FreeBSD/arm port.

Submitted by: Thomas Skibo <ThomasSkibo (at) sbcglobal.net>
Reviewed by: wkoszek, freebsd-arm@ (no objections raised)

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

Add support for Rockchip RK3568 SDHCI controller.

sdhci: Remove unused devclass arguments to DRIVER_MODULE.

sdhci: Make ext_resources non-optional

EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.

MFC after: 1 month
Differential Revis

sdhci: Make ext_resources non-optional

EXT_RESOURCES have been introduced in 12-CURRENT and all supported
releases have it enabled in their kernel config.

MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33824

show more ...

sdhci: clean up empty lines in .c and .h files

Add emmc support for Rockchip RK3399 SoC.
Tested on NanoPC-T4 board.

Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D20156

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

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.

show more ...

arm64: GENERIC-MMCCAM: Fix build and module depend

Fix the build of the GENERIC-MMCCAM kernel config after the sdhci_xenon
driver was commited.
While here correct sdhci_fdt and tegra_sdhci, even wit

arm64: GENERIC-MMCCAM: Fix build and module depend

Fix the build of the GENERIC-MMCCAM kernel config after the sdhci_xenon
driver was commited.
While here correct sdhci_fdt and tegra_sdhci, even with MMCCAM they do
need to depend on sdhci(4)

Reported by: Reshetnikov Dmitriy <genserg@hotmail.com>
Approved by: re (kib)
Sponsored by: Rubicon Communications, LLC ("NetGate")

show more ...

Fix build when option MMCCAM is defined.