On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.lin...@arm.com> wrote: > > Hi, > > On 2/17/21 11:57 AM, Ard Biesheuvel wrote: > > On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.lin...@arm.com> wrote: > >> > >> Hi, > >> > >> On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote: > >>> On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <jeremy.lin...@arm.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 2/17/21 12:56 AM, Ard Biesheuvel wrote: > >>>>> On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjer...@gmail.com> wrote: > >>>>>> > >>>>>> From: Jeremy Linton <jeremy.lin...@arm.com> > >>>>>> > >>>>>> The existing RPi3 ACPI entries for the Arasan > >>>>>> and SDHCI controllers need updating to work > >>>>>> with the RPi4. This is done by adding a caps > >>>>>> override for the legacy Arasan controller and > >>>>>> then adding an entirely new entry for the newer > >>>>>> eMMC2 controller. > >>>>>> > >>>>>> Then we flip the default routing to make the eMMC2 > >>>>>> the default for the SD card, so that the WiFi can > >>>>>> start working on the Arasan. > >>>>>> > >>>>>> Additional we add a menu item to enable the SDMA/ADMA2 > >>>>>> modes on the controller. > >>>>>> > >>>>>> v2->v3: Various small review tweaks, whitespace, wording > >>>>>> spelling, etc. > >>>>>> > >>>>> > >>>>> What happened to the IORT change? Don't we need that to ensure that > >>>>> Linux sizes ZONE_DMA appropriately? > >>>> > >>>> Ha, I gave up! There are more important things to fix, especially when I > >>>> found another case that couldn't just be fixed by the IORT tweaking > >>>> without more kernel patches. > >>>> > >>> > >>> Which case is that? > >> > >> Some of these firmware/board revisions appear to need the 3G > >> translation. The EMMC seems to be one of the devices who's DT > >> descriptions are being modified by the lower level firmware (like the PCI). > >> > > > > Considering that the reason for the 1 GB device limit is the -3 GB DMA > > translation, I'd assume that the former and the latter apply to the > > same set of peripherals. > > > > But are you saying the dma-ranges properties are manipulated by the VC > > firmware? Or other DT properties related to DMA translation? > > Yes, Its changing dma-range property associated with the emmc in the DT > its being handed which is then shared with atf/etc. >
But the translation is always the same, no? > > > > >>> > >>> > >>>> The default in this set is PIO mode, no DMA, same as the Arasan. If I > >>>> get motivated (or someone else does) they can pick up the pieces to > >>>> finish turning the DMA on in linux. It also simplifies that IORT disable > >>>> patch I posted separately since I don't have to worry about enabling it > >>>> for a limit <2G. > >>>> > >>> > >>> But having a 1 GB limit for only the eMMC2 in the IORT and a matching > >>> _DMA method in its container should not trigger this error, I'd > >>> assume. > >> > >> Well with stock linux, the device will configure, startup and corrupt data. > >> > > > > By 'this error', I mean the splat resulting from mismatching DMA > > limits for XHCI between IORT and _DMA. > > No, I don't see that. The PCI/XHCI is fine with the IORT changes. > Then why do you need [PATCH v2] Platform/RaspberryPi: Only enable IORT when 3G limit is disabled ? > > > > Is the reason for the data corruption understood? > > It runs but appears to the address translation portion doesn't get > applied (the command rings appear to be ok/etc) to FS buffers reliably > so garbage gets written to the disk as the wrong bus locations get used. > Its somewhat odd because at a first glance the directory structure/etc > come back so if one just mounts the FS and ls's it, then unmounts it all > appears to be ok. The first indications something is wrong are usually > FS corruption messages. I have an instrumented sdhci/etc driver > splatting on addrs > 1G so that all looks ok. > > > > >> > >>> > >>>> The sdhci_caps_mask choice is what flags the device as not supporting > >>>> DMA modes unless the user enables it. Yes this hurts perf, but not > >>>> nearly as badly as disabling UHS mode because we can't lower the card > >>>> voltage with the standard sdhci registers (rather having to depend on a > >>>> nonstandard rpi mailbox call which isn't available without a _DSM() or > >>>> something equally undesirable). > >>>> > >>> > >>> Are you saying switching to the Arasan disabled UHS mode, and this is > >>> why this is an improvement nonetheless? > >> > >> ? I'm not sure I understand. Right now in linux we don't have SD or > >> wifi. With just the caps _DSD entry the arasan will configure but it > >> runs PIO mode all the time (including with DT). The cap is needed > >> because the arasan returns 0 in the standard SDHCI caps registers. > >> > >> The emmc2 supports faster modes, but we can't easily switch the voltage > >> to support them because the standard voltage control registers aren't > >> wired correctly (AFAIK). Given the change detection doesn't work right > >> either (AFAIK), we could hack up the linux sdhci subsystem to not reset > >> the card at startup and leave faster cards at 1.8V, but that is uglier > >> than adding a _DSM() to forward the voltage change request to the rpi > >> mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver. > >> > >> IMHO, Given its just a perf thing, and this whole board is compromised > >> in so many ways, it just isn't worth trying to support low voltage/UHS. > >> Since the card is already running at the slower speeds, using PIO > >> instead of DMA isn't a huge hit. > > > > I could also argue that PIO at low speeds is worse then PIO at high > > speeds, given that the CPU will be tied up for longer to transfer the > > same amount of data. > > >> So then we don't have to have a 1G > >> IORT, or dynamic _DMA translation. > >> > > > > Yes, that is obviously a win. > > > >> But this set is about enabling both the SD and WiFi. The latter requires > >> the SD to be bound to the emmc2. At the moment there isn't much in the > >> way of a perf advantage to switching the SD from the Arasan to the > >> emmc2, the benefit comes from being able to use the wifi.. > >> > >> > > > > Fair enough. I'm just slightly disappointed that we cannot use the > > eMMC2 in DMA mode even for the lower speed, but I guess it is not the > > end of the world. > > Well its never done, at some point it can be revisited to make it > faster. Maybe someone will come up with a clever way to do the voltage > switching too. The platform has an easy way to trap to el3, but I can't > see how to utilize that without sdhci driver changes at the moment. > > > > > If everyone else is on board with this approach, I'll pick these up > > tomorrow. > > > > Thanks, > > Ard. > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#71786): https://edk2.groups.io/g/devel/message/71786 Mute This Topic: https://groups.io/mt/80698778/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
