Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.linton@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.linton@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.linton@arm.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 2/17/21 12:56 AM, Ard Biesheuvel wrote:
> >>>>> On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:
> >>>>>>
> >>>>>> From: Jeremy Linton <jeremy.linton@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.
> >
>