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

["Jeremy Linton" <jeremy.linton@arm.com>]

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).

> 
> 
>> 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.


> 
>> 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. So then we don't have to have a 1G 
IORT, or dynamic _DMA translation.

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..


> 
>> Presumably windows, *bsd, etc could make some use of the _DMA in the
>> SSDT as well.
>>
> 
> I don't think Windows uses _DMA, but I am mostly interested in Linux
> in any case. Modulo the 'other case' above, I don't think this is the
> approach I would prefer tbh. >
> Thanks,
> Ard.
> 
> 
>>
>>>
>>>
>>>> v1->v2: Add option for user to enable/disable eMMC DMA
>>>>           Only enable the emmc2 table on rpi4 &
>>>>               !Arasan routing
>>>>           Move emmc2 into its own SSDT and drop
>>>>               second _DMA entry
>>>>
>>>> Jeremy Linton (4):
>>>>     Platform/RaspberryPi: Add Negative table check
>>>>     Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan
>>>>     Platform/RaspberryPi: User control of eMMC2 DMA
>>>>     Platform/RaspberryPi: Invert default Arasan, eMMC2 routing
>>>>
>>>>    Platform/RaspberryPi/AcpiTables/AcpiTables.inf     |   1 +
>>>>    Platform/RaspberryPi/AcpiTables/Emmc.asl           | 129 +++++++++++++++++++++
>>>>    Platform/RaspberryPi/AcpiTables/Sdhc.asl           |  18 ++-
>>>>    Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  26 +++++
>>>>    .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf    |   1 +
>>>>    .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |   4 +
>>>>    .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  17 +++
>>>>    Platform/RaspberryPi/Include/ConfigVars.h          |   8 ++
>>>>    Platform/RaspberryPi/RPi3/RPi3.dsc                 |   1 +
>>>>    Platform/RaspberryPi/RPi4/RPi4.dsc                 |   3 +-
>>>>    Platform/RaspberryPi/RPi4/Readme.md                |   2 +-
>>>>    Platform/RaspberryPi/RaspberryPi.dec               |   1 +
>>>>    12 files changed, 206 insertions(+), 5 deletions(-)
>>>>    create mode 100644 Platform/RaspberryPi/AcpiTables/Emmc.asl
>>>>
>>>> --
>>>> 2.13.7
>>>>
>>
> 
> 
> 
> 
>