From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx.groups.io with SMTP id smtpd.web11.4692.1613548552319924001 for ; Tue, 16 Feb 2021 23:55:52 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dgAmPlOg; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 55AC764E28 for ; Wed, 17 Feb 2021 07:55:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613548551; bh=AS1Aj6CejHK/95Ja2yV4A8Ve5cn1VFPXAkKvfllPwxM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dgAmPlOgwWrf/QcMN5SV0Xvvca61xoYoqaVDF16qkzPEODyIt5Kyth8XRl/3xSVnP 580dnBK0Xsfvu+HmTMQ5CDzsWHSBx4NfAIvhUp75F/fGqiXyrIQt9Tj6TlExHBT1Ca jo1GDF+QPeagMjQxSDOPN7IblGqCl4AOF6QIaD0mNA6yvcM55BKXWNJzvQ6lo3rj1T 3yWDxCMF1wHQQLRdTaEwmLd2+Iw4P+Yoyqxctd+5nJ+Mt/02uLTIdFD/3HUwW6tLng uodsvnsYd//3ZYM25S5IF+fYebrk7vUMMOwuccrD9CJZJspScXvDyGDfHye6Z3O+68 72USqXvbxLyBw== Received: by mail-ot1-f49.google.com with SMTP id d7so11288730otq.6 for ; Tue, 16 Feb 2021 23:55:51 -0800 (PST) X-Gm-Message-State: AOAM533HvIgwD0WEDDisbFUjlvNEwxOT4KCcZnWh+wJdJioXZCBK12uI eE2OFN0xx+YmJhDuj2fGGe/Bpy3ywtCQJS2qgeQ= X-Google-Smtp-Source: ABdhPJwKv/+1d9mTvd224EVdP+7kHt6tfyzvDAYseQc33iK1nQ3htaeP/PZmj4kNJyc4ZyyOXZeUaAYW7/8lIvsRSVg= X-Received: by 2002:a05:6830:11:: with SMTP id c17mr16619380otp.77.1613548550522; Tue, 16 Feb 2021 23:55:50 -0800 (PST) MIME-Version: 1.0 References: <20210217061809.307479-1-lintonrjeremy@gmail.com> <8a8bbe3d-d65d-17d3-6c4b-6bffb49cfb2f@arm.com> In-Reply-To: <8a8bbe3d-d65d-17d3-6c4b-6bffb49cfb2f@arm.com> From: "Ard Biesheuvel" Date: Wed, 17 Feb 2021 08:55:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates To: Jeremy Linton Cc: jlinton , devel@edk2.groups.io, Peter Batard , Andrei Warkentin , Samer El-Haj-Mahmoud , Leif Lindholm , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" On Wed, 17 Feb 2021 at 08:30, Jeremy Linton wrote: > > Hi, > > On 2/17/21 12:56 AM, Ard Biesheuvel wrote: > > On Wed, 17 Feb 2021 at 07:18, jlinton wrote: > >> > >> From: Jeremy Linton > >> > >> 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? > 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. > 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? > 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 > >> >