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.web10.9927.1613667135222455559 for ; Thu, 18 Feb 2021 08:52:15 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=EhY/xZGs; spf=pass (domain: kernel.org, ip: 198.145.29.99, mailfrom: ardb@kernel.org) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6D1AB64EB9 for ; Thu, 18 Feb 2021 16:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613667134; bh=349d4xyRCu7nhXScs/2PDqIkklCp6t+Zy9aNjbS0KLg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EhY/xZGs6KhYrzzrf+ob5Zr5zuwQTXPlOC8dMrIyBIvDZeo1OEcqkLrUNIS+o5n18 pt2tMoXl3Lu8qcxdZdOD0DOp77lD9/v1NyaRiDFGRYPHfB1aHHlIBO4Y4c05fGxPB4 1YkL7EjXLnjrhIatHk+kUn4FpLBXz2SEuukuJBx7Xde7rQqdl9jtm6WXkfCW8HoN9F ciaob3CEt2mN3HlVwEQOU0X74E8qqWDY5HM+7aGnnBtG4cEgHCk5SXhXWyWm7kRHni CkdELhBDL152wjYnX7YvJdoVyL1OyyvPSKMq6MZX6IzJPMNi8yWF5Uh4zUnLmprZXq E9F4YyoCVjzBQ== Received: by mail-ot1-f43.google.com with SMTP id v16so2418683ote.12 for ; Thu, 18 Feb 2021 08:52:14 -0800 (PST) X-Gm-Message-State: AOAM530ZtxTsFKMq0ynUdOey4bg5mJzlHiSu5BVEL9ACI7MBpiJNiXtm OjLJLVgzoTIkmo7Rl4B6Pi8dIf7G+syLs0hbbDM= X-Google-Smtp-Source: ABdhPJwAWrsLa4wMW1s3JN5pyajyDUEGNBPnACa4VV1LRoJ7gnOxYU8M7URV5nlWfC2hXxDVl9vxIexSDh+lQUy9qxc= X-Received: by 2002:a05:6830:13ce:: with SMTP id e14mr3481717otq.108.1613667133462; Thu, 18 Feb 2021 08:52:13 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <412f45c0-6dd3-436d-8c19-49dce52a2f07@arm.com> From: "Ard Biesheuvel" Date: Thu, 18 Feb 2021 17:52:02 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v3 0/4] RPi: SD/WiFi ACPI updates To: Jeremy Linton Cc: devel@edk2.groups.io, jlinton , Peter Batard , Andrei Warkentin , Samer El-Haj-Mahmoud , Leif Lindholm , Ard Biesheuvel Content-Type: text/plain; charset="UTF-8" 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? > > > > >>> > >>> > >>>> 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. > > >