From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web08.2081.1613677488310019111 for ; Thu, 18 Feb 2021 11:44:48 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: jeremy.linton@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 99E2A1FB; Thu, 18 Feb 2021 11:44:41 -0800 (PST) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B415C3F694; Thu, 18 Feb 2021 11:44:39 -0800 (PST) Subject: Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates To: Ard Biesheuvel Cc: devel@edk2.groups.io, jlinton , Peter Batard , Andrei Warkentin , Samer El-Haj-Mahmoud , Leif Lindholm , Ard Biesheuvel References: <20210217061809.307479-1-lintonrjeremy@gmail.com> <8a8bbe3d-d65d-17d3-6c4b-6bffb49cfb2f@arm.com> <512f403f-7bcb-1cfb-fcfb-d5eba964efd3@arm.com> <412f45c0-6dd3-436d-8c19-49dce52a2f07@arm.com> From: "Jeremy Linton" Message-ID: <30636040-ffe2-cb58-0a92-2264eacbdd63@arm.com> Date: Thu, 18 Feb 2021 13:44:30 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi, On 2/18/21 10:52 AM, Ard Biesheuvel wrote: > On Thu, 18 Feb 2021 at 17:47, Jeremy Linton wrote: >> >> Hi, >> >> On 2/17/21 11:57 AM, Ard Biesheuvel wrote: >>> On Wed, 17 Feb 2021 at 18:16, Jeremy Linton 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 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? >>>> >>>> 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? No, the newer SOC with the newer (broken xhci) firmware does away with it, and widens the window. I haven't tried the newer SOC with the experimental firmware that now boots uefi except to validate that the emmc works in PIO mode. It might "just work" with DMA enabled, but in that case we should probably do a SOC detection and flip the PIO/DMA default, but that needs to be done with the pi400 or an actual released product rather than this "special" one off device I have. > >> >>> >>>>> >>>>> >>>>>> 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 > > ? Oh, I guess I misunderstood what you were asking since this set is no longer dependent on the IORT change. I thought you were asking if the XHCI was having issues with the IORT when it had a 1G limit? So the answer should have been depends on the kernel. The older kernels don't work with SD/Wifi since we aren't using the standard pnp ID, but they have problems with the IORT regardless of of what its limits are when a device tries to use a buffer that exists between the 1G/2G IORT and the 3G mem limit. The newer kernel's WRT the IORT don't care what the limit is, but we would have needed to have the IORT in place even with the 3G limit applied to assure the SD/Wifi work. Its this latter case that influenced the original version of that patch which tied the IORT directly to the mem limit, and would have required the user to lift the 3G limit on a 2G device to enable the IORT. All these flags and options are failing KISS and part of the reason I think the PIO is a reasonable choice. Lets start with the lowest common denominator, and then worry about getting fancy. > >>> >>> 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. >>> >>