bcm2835_sdhci: some style cleanup, no functional change

bcm2835_sdhci: drop an assert in start_dma_seg

Trivial change to clarify locking expectations... no functional change.

bcm2835_sdhci: use a macro for interrupts we handle

This is just further simplification, very little functional change. In the
DMA interrupt handler, we *do* now acknowledge both DATA_AVAIL | SPACE_

bcm2835_sdhci: use a macro for interrupts we handle

This is just further simplification, very little functional change. In the
DMA interrupt handler, we *do* now acknowledge both DATA_AVAIL | SPACE_AVAIL
every time -- these operations are mutually exclusive, so while this is a
functional change, it's effectively a nop. Removing the 'mask' local allows
us to further simplify in a future change.

show more ...

bcm2835_sdhci: push DATA_END handling out of DMA interrupt path

This simplifies the DMA interrupt handler quite a bit. The sdhci framework
will call platform_finish_transfer() if it's received SDHCI

bcm2835_sdhci: push DATA_END handling out of DMA interrupt path

This simplifies the DMA interrupt handler quite a bit. The sdhci framework
will call platform_finish_transfer() if it's received SDHCI_INT_DATA_END, so
we can take care of any final cleanup there and simply not worry about the
possibility of it ending in the DMA interrupt path.

show more ...

bcm2835_sdhci: don't panic in DMA interrupt if curcmd went away

This is an exceptional case; generally found during controller errors.
A panic when we attempt to acess slot->curcmd->data is less ide

bcm2835_sdhci: don't panic in DMA interrupt if curcmd went away

This is an exceptional case; generally found during controller errors.
A panic when we attempt to acess slot->curcmd->data is less ideal than
warning, and other verbiage will be emitted to indicate the exact error.

show more ...

bcm2835_sdhci: remove unused power_id field

This was once set, but I removed it by the time I committed it because both
configurations use the same POWER_ID. This can be separated back out if the
si

bcm2835_sdhci: remove unused power_id field

This was once set, but I removed it by the time I committed it because both
configurations use the same POWER_ID. This can be separated back out if the
situation changes.

show more ...

bcm2835_sdhci: add some very basic support for rpi4

DMA is currently disabled while I work out why it's broken, but this is
enough for upstream U-Boot + rpi-firmware + our rpi3-psci-monitor to boot

bcm2835_sdhci: add some very basic support for rpi4

DMA is currently disabled while I work out why it's broken, but this is
enough for upstream U-Boot + rpi-firmware + our rpi3-psci-monitor to boot
with the right config.

The RPi 4 is still not in a good "supported" state, as we have no
USB/PCI-E/Ethernet drivers, but if air-gapped pies only able to operate over
cereal is your thing, here's your guy.

Submitted by: Robert Crowston (with modifications)

show more ...

MFHead @349234

Sponsored by: The FreeBSD Foundation

Add a bus_add_child device method to bcm2835_sdhci.

This allows SDIO (through CAM) to attach to an upstream, e.g.,
..
sdhci_bcm0 pnpinfo name=mmc@7e300000 compat=brcm,bcm2835-mmc

Add a bus_add_child device method to bcm2835_sdhci.

This allows SDIO (through CAM) to attach to an upstream, e.g.,
..
sdhci_bcm0 pnpinfo name=mmc@7e300000 compat=brcm,bcm2835-mmc
sdiob0
..

Without this, upon trying to load sdio, we would panic with
"bus_add_child is not implemented".

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation

show more ...

bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors

In the DMA case, given we disable the data interrupts, we never seem
to get DATA_END. Given we are relying on DMA interrupt

bcm2835_sdhci.c: exit DMA if not enough data left to avoid timeout errors

In the DMA case, given we disable the data interrupts, we never seem
to get DATA_END. Given we are relying on DMA interrupts we are not
using the SDHCI state machine and hence only call into
sdhci_platform_will_handle() for the first check of data.
We do not call "will handle" for any following round trips of the same
transaction if block size * count > BCM_DMA_BLOCK_SIZE.
Manually check "left" in the DMA interrupt handler to see if we have at
least another full BCM_DMA_BLOCK_SIZE to handle.
Without this change we would DMA that and then even start a DMA with
left == 0 which would lead to a timeout and error.
Now we re-enable data interrupts and return and let the SDHCI generic
interrupt handler and state machine pick the SPACE_AVAIL up and then
find that it should punt to the pio_handler for the remaining bytes
or finish the data transaction.

With this change block mode seems to work beyond 7 * 64byte blocks,
which worked as it was below BCM_DMA_BLOCK_SIZE.

MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20199

show more ...

bcm2835_sdhci.c: save block registers to avoid controller bug

Extending what the initial revision, r273264, r276985, r277346 have
started for the transfer mode and command registers, another pair of

bcm2835_sdhci.c: save block registers to avoid controller bug

Extending what the initial revision, r273264, r276985, r277346 have
started for the transfer mode and command registers, another pair of
16bit registers written in sequence are block size and block count,
which fall together onto the same 32bit line and hence the same
register(s) would be written twice in sequence for those as well.

Use a similar approach to transfer mode and command and save the writes
to either of the block regiters and then only execute a write once.
We can do this as with transfer mode their values are meaningless until
a command is issued so we can use that write to command as a trigger
to also write out the block registers.
Compared to transfer mode and command the value of block count can
change, so we need to keep state and actually read the block registers
back the first time after a write.

MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20197

show more ...

MFHead@r345880

Improve debugging options in bcm2835_sdhci.c

Similar to bcm2835_sdhost.c add a TUNABLE and SYSCTL to selectively
turn on debugging printfs if debugging is turned on at compile time.

MFC after: 2 w

Improve debugging options in bcm2835_sdhci.c

Similar to bcm2835_sdhost.c add a TUNABLE and SYSCTL to selectively
turn on debugging printfs if debugging is turned on at compile time.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Reviewed by: gonzo, andrew
Differential Revision: https://reviews.freebsd.org/D19745

show more ...

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 ...

Switch to mainstream DTS for Raspberry Pi-B and Pi-2.
This is first step in attempt to make FreeBSD compatible with all variants of
RPi boards.

Reviewed by: gonzo
MFC after: 3 weeks

sys/arm: 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/arm: 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 ...

Merge ^/head r323559 through r325504.

MFhead@r323974

Rename sdhci_cam_start_slot() into sdhci_start_slot()

This change allows to just call sdhci_start_slot() in SDHCI drivers
and not to think about which stack handles the operation.

As a side effect,

Rename sdhci_cam_start_slot() into sdhci_start_slot()

This change allows to just call sdhci_start_slot() in SDHCI drivers
and not to think about which stack handles the operation.

As a side effect, this will also fix MMCCAM with sdhci_acpi driver.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12471

show more ...

MFhead@r323635

Miscellaneous fixes and improvements to MMCCAM stack

* Demote the level of several debug messages to CAM_DEBUG_TRACE
* Add detection for SDHC cards that can do 1.8V. No voltage switch sequence

Miscellaneous fixes and improvements to MMCCAM stack

* Demote the level of several debug messages to CAM_DEBUG_TRACE
* Add detection for SDHC cards that can do 1.8V. No voltage switch sequence
is issued yet;
* Don't create a separate LUN for each SDIO function. We need just one to make
pass(4) attach;
* Remove obsolete mmc_sdio* files. SDIO functionality will be moved into the
separate device that will manage a new sdio(4) bus;
* Terminate probing if got no reply to CMD0;
* Make bcm2835 SDHCI host controller driver compile with 'option MMCCAM'.

Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D12109

show more ...

MFhead@r320180

Merge ^/head r319973 through 321382.

Merge ^/head r320573 through r320970.

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers

An MMC/SD/SDIO stack using CAM

Implement the MMC/SD/SDIO protocol within a CAM framework. CAM's
flexible queueing will make it easier to write non-storage drivers
than the legacy stack. SDIO drivers from both the kernel and as
userland daemons are possible, though much of that functionality will
come later.

Some of the CAM integration isn't complete (there are sleeps in the
device probe state machine, for example), but those minor issues can
be improved in-tree more easily than out of tree and shouldn't gate
progress on other fronts. Appologies to reviews if specific items
have been overlooked.

Submitted by: Ilya Bakulin
Reviewed by: emaste, imp, mav, adrian, ian
Differential Review: https://reviews.freebsd.org/D4761

merge with first commit, various compile hacks.

show more ...