r348803 by bz:
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.
r348804 by bz:
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.
r354488:
bcm_lintc: don't attach if "interrupt-controller" is missing
This is a standard required property for interrupt controllers, and present
on the bcm_lintc nodes for currently supported RPi models. For the RPi4, we
have both bcm_lintc as well as GIC-400, but only one may be active at a
time.
Don't probe bcm_lintc if it's missing the "interrupt-controller" property --
in RPi 4 DTS, the bcm_lintc node is actually missing this along with other
required interrupt properties. Presumably, if the earlier boot stages will
support switching to the legacy interrupt controller (as is suggested
possible by the documentation), the DTS will need to be updated to indicate
the proper interrupt-parent and hopefully also mark this node as an
interrupt-controller instead.
r354524:
bcm2835_dma: Mark IRQs shareable
On the RPi4, some of these IRQs are shared. Start moving toward a mode where
we accept that shared IRQs happen and simply ignore interrupts that are
seemingly for no reason.
I would like to be more verbose here, but my 30-minute assessment of the
current world order is that mapping a resource/rid to an actual IRQ number
(as found in FDT) data is not a simple matter. Determining if more than one
handler is attached to an IRQ is closer to feasible, but it's unclear which
way is the cleaner path. Beyond that, we're only really using it to be
slightly more verbose when something's going wrong, so for now just suppress
and drop a complaint-comment.
This was originally submitted (via freebsd-arm@) by Robert Crowston; the
additional verbosity was dropped by kevans@.
r354560:
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.
r354561:
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.
r354563:
bcm2835: commit missing constant from r354560
Surgically pulling the patch from my debugging work lead to this slopiness-
my apologies.
r354577:
arm64: add SOC_BRCM_BCM2838, build it in GENERIC
BCM2838/BCM2711 is the Raspberry Pi 4, which we will soon be able to boot
on once some ports bits are worked out.
r354579:
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.
r354823:
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.
r354825:
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.
r354844:
bcm2835_sdhci: drop an assert in start_dma_seg
Trivial change to clarify locking expectations... no functional change.
r354845:
bcm2835_sdhci: some style cleanup, no functional change
This allows easy and care-free scaling of NUM_DMA_SEGS with proper-ish
calculations to make sure we can actually handle the number of segments we'd
like to handle on average so that performance comparisons can be easily made
at different values if/once we can actually handle it. It also makes it
helps the untrained reader understand more quickly the reasoning behind the
choice of maxsize/maxsegs/maxsegsize.
r354868:
bcm2835_sdhci: various refactoring of DMA path
This round of refactoring is mostly about streamlining the interrupt handler
to make it easier to verify and reason about operations taking place while
trying to bring FreeBSD up on the RPi4.
r354875:
bcm2835: push address mapping conversion for DMA/mailbox to runtime
We could maintain the static conversions for the !AArch64 Raspberry Pis, but
I'm not sure it's worth it -- we'll traverse the platform list exactly once
(of which there are only two for armv7), then every conversion there-after
traverses the memory map listing of which there are at-most two entries for
these boards: sdram and peripheral space.
Detecting this at runtime is necessary for the AArch64 SOC, though, because
of the distinct IO windows being otherwise not discernible just from support
compiled into the kernel. We currently select the correct window based on
/compatible in the FDT.
We also use a similar mechanism to describe the DMA restrictions- the RPi 4
can have up to 4GB of RAM while the DMA controller and mailbox mechanism can
technically, kind of, only access the lowest 1GB. See the comment in
bcm2835_vcbus.h for a fun description/clarification of this.
r354876:
bcm2835_vcbus: add compatibility name for ^/sys/contrib/vchiq
It's unclear how this didn't get caught in my last iteration, but the fix is
easy- the interface is still compatible, it was just gratuituously renamed
to match my arbitrary definition of consistency... VCBUS, the BCM2835 name,
represents an address on the VideoCore CPU Bus.
In a similar fashion, while it is a physical address, the ARMC portion
represents that these are addresses as seen by the ARM CPU.
To make things even more fun, the BCM2711 peripheral documentation describes
not virtual address space vs. physical address space, but instead the 32-bit
address map vs. the address map in "Low Peripheral" mode. The latter of
these is what the *ARMC* macros translate to/from.
r354930:
bcm2835_sdhci: clean up DMA segments in error handling path
Later parts assume that this would've been done if interrupts are enabled,
but this is the only case in which that wouldn't have been true. This commit
also reorders operations such that we're done touching slot/slot->intmask
before we call back into the SDHCI framework and exit.
r354931:
Revert r354930: wrong diff, right message.
r354932:
bcm2835_sdhci: roll back r354823
r354823 kicked DATA_END handling out of the DMA interrupt path "to make
things easy", but this was likely a mistake -- if we know we're done after
we've finished pending DMA operations, we should go ahead and acknowledge
it rather than waiting for the controller to finalize it. If it's not ready,
we'll simply re-enable interrupts and wait for it anyways, to be re-entered
in sdhci_data_intr.
r354933:
bcm2835_sdhci: clean up DMA segments in error handling path
Later parts assume that this would've been done if interrupts are enabled,
but this is the only case in which that wouldn't have been true. This commit
also reorders operations such that we're done touching slot/slot->intmask
before we call back into the SDHCI framework and exit.
r354956:
bcm2835_sdhci: only inspect interrupts we handle
We'll write the value we read back to ack pending interrupts, but we should
at least make it clear to ourselves that we only want to ack pending
transfer interrupts.
r355016:
bcm2835_vcbus: add the *other* rpi4 compat string
The DTS I used initially had brcm,bcm2838; the new one uses brcm,bcm2711.
Add that one as well.
r355025:
bcm2835_sdhci: "fix" DMA on the RPi 4
According to the documentation I have, DREQ pacing should be required here.
The DREQ# hasn't changed since the BCM2835. As soon as we attempt to setup
DREQ, DMA stalls and there's no clear reason why as of yet. Setting this
back to NONE seems to work just as well, though it's yet to be determined if
this is a sustainable model in high-throughput scenarios.
r355026:
bcm2835_dma: rip out the "use_dma" flag, make it non-optional
Now that it works for the Raspberry Pi 4, we can discontinue our workarounds
that were put in place to at least get a bootable kernel for other testing.
r355031:
bcm2835_sdhci: fix non-INVARIANTS build
sc is now only used to make sure we're not re-entering the data handling
path erroneously.
r355563:
RPI: Fix DMA/SDHCI on the BCM2836 (Raspberry Pi 2)
r354875 pushed VCBUS <-> ARMC translations to runtime determination, but
incorrectly mapped addresses for the BCM2836 -- SOC_BCM2835 and SOC_BCM2836
are actually mutually exclusive, so the BCM2836 config (GENERIC) would have
taken the latter path in the header and used 0x3f000000 as peripheral start.
Easily fixed -- split out the BCM2836 into its own memmap config and use
that instead if SOC_BCM2836 is included. With this, we get back to userland
again.
projects / FreeBSD / FreeBSD.git / commit