Page MenuHomeFreeBSD

ARM GICv3: Add support for non-coherent and/or bus address range limited DMA.
AcceptedPublic

Authored by mmel on Sun, Nov 30, 8:43 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 30, 3:20 PM
Unknown Object (File)
Sun, Nov 30, 3:14 PM
Unknown Object (File)
Sun, Nov 30, 1:56 PM
Unknown Object (File)
Sun, Nov 30, 1:14 PM
Unknown Object (File)
Sun, Nov 30, 11:23 AM
Unknown Object (File)
Sun, Nov 30, 11:17 AM
Subscribers

Details

Reviewers
imp
andrew
manu
Group Reviewers
arm64
Summary

Due to an implementation bug, the GICv3 and ITS master ports may be connected
to a non-coherent bus. The new DT resolves this issue by marking these ports
with the "dma-nocoherent" attribute. The older DT does not have this attribute,
so we must match the affected SoC.
Additionally, the RK356x family has GIC master ports on a 32-bit bus.
Therefore, we must limit the address range for all tables and command buffers
allocated for it. In this case, the DT does not have an attribute for this
case, so the quirk should only be applied by SoC matching.

MFC after|: 4 weeks

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mmel requested review of this revision.Sun, Nov 30, 8:43 AM

mixes a couple of different things, but they might not be as independent as I'm thinking, so I think this is fine from that perspective.
The workaround looks to match the one in Linux well enough I think it will work. The code bases are different enough that I didn't do a detailed copying analysis since direct copying between these drivers is kinda hard in structure, but is easy because the #defines are necessarily the same which has little to no copyright protection.

sys/arm64/arm64/gic_v3_fdt.c
126

How long do you think we'll need to use the list here? how quickly do DTs propagate? Eg, is this "until FreeBSD brings them in" or "until uboot gets updated on the target boards?"

This revision is now accepted and ready to land.Sun, Nov 30, 5:51 PM
sys/arm64/arm64/gicv3_its.c
300–301

Why are you removing this? A zero iidr and iidr_mask should work to ignore the iidr.

853

Why is this checking GIC_V3_FLAGS_FORCE_NOSHAREABLE rather than ITS_FLAGS_FORCE_NOSHAREABLE?

sys/arm64/arm64/gicv3_its.c
300–301

I moved everything to the detection routine. Please see its_detect_cavium_22375(). I understand that this change is questionable, but I decided not to mix two different quirk detection methods.

853

I don't have access to the GIC or ITS implementation guides, but I would guess that the redistributor uses the GIC's master port, while the command buffer and ITS table page use the ITS's master port. For this reason, DT may have one DMA-incoherent property on the GIC node and a different one on the ITS node. Thus, the cacheability and shareability of different entities are driven by the properties at the appropriate DT nodes.

sys/arm64/arm64/gic_v3_fdt.c
126

These properties were introduced in 6.15. However, we do not MFC DT imports. Therefore, we can remove this check once this patch has been MFCed to stable.