Date: Wed, 30 Sep 2020 20:35:41 -0700 From: Mark Millard <marklmi@yahoo.com> To: Robert Crowston <crowston@protonmail.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4B's DMA11 (DMA4 engine example) vs. xHCI/pcie Message-ID: <658D626D-4307-44F2-9B8A-1CE132EEB0F2@yahoo.com> In-Reply-To: <93A90975-39F1-4DA3-87E0-89E07505108A@yahoo.com> References: <8C6DE44F-6CE2-4C74-8748-3BBFB54AE183@yahoo.com> <0FE382AB-8DE3-4467-9CB0-E8582AC70EA2@yahoo.com> <85FEDC51-B5B0-4ED4-A5ED-62B63EF9D5A8@yahoo.com> <B440C8D8-AA02-49E4-A0D6-3EA9B7FFD13A@yahoo.com> <903FE769-ED46-4FBC-A272-4D2C89A9CD7A@yahoo.com> <tNJ_d5vRy5yTyYQw2MoZvybqy_7lqaHUfmXjedMUax0-LUolwajbPIPJLpQZqV6e9ymgkUogKFKRv0E0LrfDmLMiE99QraRHPamDyMDPVm4=@protonmail.com> <93A90975-39F1-4DA3-87E0-89E07505108A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Sep-30, at 15:40, Mark Millard <marklmi at yahoo.com> wrote:
> On 2020-Sep-30, at 14:15, Robert Crowston <crowston at protonmail.com> =
wrote:
>=20
>> Very interesting analysis. Certainly uncovered a few things I wasn't =
aware of.
>>=20
>> By default sc->sc_bus.dma_bits in xhci_init is 64 bits; I toggle it =
back to 32 bits in the xhci shim I wrote for the Pi 4. You can see that =
output in a verbose dmesg.
>>=20
>=20
> My biggest worry from all that material, for things as they currently
> are, is that it appears that FreeBSD could try to use a RPi4B DMA LITE
> engine but not follow its limitations when doing so. For example,
> ending up using a smaller size DMA transfer than intended (just 16 =
bits
> for size). (Other RPi's might have the same issue?)
So I looked at BCM2835-ARM-Peripherals.pdf, comparing to
rpi_DATA_2711_1p0.pdf and:
BCM2835-ARM-Peripherals.pdf indicated DMA engines 7-14 are all
DMA LITE engines for the context it was covering. DMA 0-6 are
normal DMA engines.
So the RPi4B reduced the number of DMA LITE engines (now only 7-10)
and filled the removed slots (11-14) with the new type DMA4 engines.
So I learn from this some about how to interpret "brcm,bcm2835-dma"
as shown by what the RPi4B is doing:
dma@7e007000 {
compatible =3D "brcm,bcm2835-dma";
reg =3D <0x7e007000 0x00000b00>;
interrupts =3D * 0x0000000007ef645c =
[0x00000084];
interrupt-names =3D "dma0", "dma1", "dma2", =
"dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10";
#dma-cells =3D <0x00000001>;
brcm,dma-channel-mask =3D <0x000001f5>;
phandle =3D <0x0000000b>;
};
The brcm,dma-channel-mask value and name list is different than in prior
examples of "brcm,bcm2835-dma" but the subset that is present follows =
the
original protocol. For example, how to tell DMA (normal) from DMA LITE
works the same [a debug register bit to check] --but only within the =
subset
present.
Seeing "brcm,bcm2835-dma" should not lead to presuming some fixed number =
of
interrupts or dma-channels to process.
The protocol for DMA (normal) vs. DMA LITE does not even apply to
the new RPi4B DMA4 engines (11-14):
dma@7e007b00 {
compatible =3D "brcm,bcm2711-dma";
reg =3D <0x00000000 0x7e007b00 0x00000000 =
0x00000400>;
interrupts =3D <0x00000000 0x00000059 0x00000004 =
0x00000000 0x0000005a 0x00000004 0x00000000 0x0000005b 0x00000004 =
0x00000000 0x0000005c 0x00000004>;
interrupt-names =3D "dma11", "dma12", "dma13", =
"dma14";
#dma-cells =3D <0x00000001>;
brcm,dma-channel-mask =3D <0x00007000>;
phandle =3D <0x0000003d>;
};
11-14 have a new, distinct protocol in various respects.
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?658D626D-4307-44F2-9B8A-1CE132EEB0F2>