From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (NAM02-CY1-obe.outbound.protection.outlook.com [40.107.76.88]) by mx.groups.io with SMTP id smtpd.web09.4771.1613548764739714896 for ; Tue, 16 Feb 2021 23:59:25 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@vmware.com header.s=selector2 header.b=jmCZa49t; spf=pass (domain: vmware.com, ip: 40.107.76.88, mailfrom: awarkentin@vmware.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EX1FnbjB8K/qXJ02PQ8JyejrUROX3wyJgom3mZxNjyyQYhwJ7Si/2bQyF20qI5Kvsj/tGk0aA9GQ8FnJJeawls/RTzW7P1DL94zX+Dzg4/OZEroWbTUBMSjGusBfkxcIdw9tG26N4plwJY5tps8JPIlI7WSKcSNTtn+W6gbyxTHAzUbxuxS2epIXKd+3UVMVCcSOYps8Pf2kf7d0+eSYOtvVgCeAzCn3lIGpbk8KCHrRbiz5xDygBz6fpcUwEsG9tfq6lFgAZhZ0XUaR8FpfVPO7f/PoxyneHZnaVkL1VUcnDzbhC09Wn3xovhlQk3Xe1ApUMTyVca34znIHziJWSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xoXnpJKulqr0nAh6vIu/AY7bYXZwSoaMqxCuXThwvQs=; b=OC1ojOWrFlJpoRRVxyeGVT7z6PAnK0pVymar27oWS1AhqRJ7LnxRF0u5vscPkhYMiNMPr2mDZRGeV+KFbyCLDL3BtGWJ1QOWkxQ7ft6xkaWj9a40dPwr3SEV98CarrYyP02cv9igqBkjDGMAVkH2srZi3RxuyAiM88DgIp2S0rMrQF202IV7MKNezyxSzByChAN892unZoBlssVs5TK/3wi3Z8O2Gt309spQ0KArJnorGByWNlXo4OpZLFbk6qgmwe/AYmQLnTTzfL9isnA9S76whufK/t31nyuVzFI2MXvnHx6hcBN4QB1m0NV5CArR27E8dyNbt8/fkxPf4QIezA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vmware.com; dmarc=pass action=none header.from=vmware.com; dkim=pass header.d=vmware.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xoXnpJKulqr0nAh6vIu/AY7bYXZwSoaMqxCuXThwvQs=; b=jmCZa49tMTs0iDAtBgdjrgBhXgO9kb+H3tYX7Njv62xHpJZjFbWUWl9SDbwUB3P+A1GDxFRFokAckGV03F/O3B4y7R50r90ct+wNoX4LPQjkcvKa+a+kJJ3sbhi63j43FhkSU29HmPo9/z+MeTcPdU0OMgD2O+eMHBHkXaLM660= Received: from SN7PR05MB7582.namprd05.prod.outlook.com (2603:10b6:806:f7::16) by SN6PR05MB4190.namprd05.prod.outlook.com (2603:10b6:805:1a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.11; Wed, 17 Feb 2021 07:59:21 +0000 Received: from SN7PR05MB7582.namprd05.prod.outlook.com ([fe80::d1f7:9f0e:9655:eadb]) by SN7PR05MB7582.namprd05.prod.outlook.com ([fe80::d1f7:9f0e:9655:eadb%4]) with mapi id 15.20.3868.027; Wed, 17 Feb 2021 07:59:21 +0000 From: "Andrei Warkentin" To: Ard Biesheuvel , Jeremy Linton CC: jlinton , "devel@edk2.groups.io" , Peter Batard , Samer El-Haj-Mahmoud , Leif Lindholm , Ard Biesheuvel Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates Thread-Topic: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates Thread-Index: AQHXBP7Doa/bSQ8VT06nR8kVQZj1ZKpb+pKAgAAAe64= Date: Wed, 17 Feb 2021 07:59:21 +0000 Message-ID: References: <20210217061809.307479-1-lintonrjeremy@gmail.com> <8a8bbe3d-d65d-17d3-6c4b-6bffb49cfb2f@arm.com>, In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [69.174.145.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42bd1b16-b9ec-48df-f4a4-08d8d319ef5c x-ms-traffictypediagnostic: SN6PR05MB4190: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2089; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NXwW+tJFssz+bZPNkoVUL0e4X6nbzJocGGNWNekyCjJWORljCD0c1Aps16B0XhK5sBLiau3WwqQBbUIup9H4tAF6LYYD4IjSJiGvBncKFosIfVa/xJigRBv91IJUSMb1NDzIszI/mqFtRY9kXRkxJ/BeMruQLmxihvtr/5rhkUPkDg5Vs02OIXhIrEOBHaGeD1gjftRUI5xez34YNeLuFPsuiZrPfO7JDbOcNcS26x9sA1voZWZLaCtJm8TqreB7usR19Q8GWXuzjOacDj5I1RYhc1gGWi9rhzVEG20R4tMNfHgTLh3V+m6F0zqo4NKKnRs1kucbqz4X2Fo1YoGSqTHgZTnJiB5hopruy0zZltEpV661lwukMt+1PM5VFzj34z/KxAU7h8jcUEDz32oZu0GkiH2oz6b+uAG0cE+GXoKEx0HjOcSCS98gnB61DGNXcDNs7JjtXDQh7l3Syw9Y2706WqG71ayyb010qO7A33ndQhSJpnrZ0Bhuorya5bESB/UEQwUmoPalmcJ46Fv/Jg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN7PR05MB7582.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(6029001)(4636009)(366004)(376002)(39860400002)(346002)(136003)(396003)(8676002)(6506007)(53546011)(52536014)(186003)(5660300002)(26005)(83380400001)(2906002)(8936002)(76116006)(66446008)(4326008)(66946007)(66556008)(66476007)(64756008)(316002)(86362001)(19627405001)(7696005)(55016002)(54906003)(33656002)(15650500001)(9686003)(110136005)(478600001)(71200400001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?qWl8L/InacDa7nQ7LdKzgS8u2UzBs0y9bzobGbkkMAkEgVJVe+MYg2SpdVCp?= =?us-ascii?Q?EN/R20KIhr6ajMcWJ88uakfAecUmoXq20qZ68doXsJYz5LZg0Yzi6C39w770?= =?us-ascii?Q?Ukn09D9kkjckoAUzuDZ3n3XqKrjEPYATZEqicqhjMqoXAuzNVHr7xDNS8Bb7?= =?us-ascii?Q?YhnHQUvEaRqbQKSQ5rYtYORso+NWcT6E4l6JupWI1qqSt/yIjuVbXxtO1f0f?= =?us-ascii?Q?LL+8Yn6Wv8A/3nHZRd27sDwC+kJ4bTnZlZ+pXcNrjC4lOku/dUKvOA805/39?= =?us-ascii?Q?odK1x/qX9bIKr61HIKr3v4fFet9z31ryU24nZgYmp0LHRIwFDVcg+xQxdooz?= =?us-ascii?Q?ySDot5uEfslAhBNXe4W73QXzmPvJ2QFp2ROxEUq3vXFOgpLKRWXadmZR1rZ5?= =?us-ascii?Q?pKoBflYcoMVCgA8i+n+ogBkxZNL7wqE0BfPymOjZUAGMAwyoC1T6zNeUml9C?= =?us-ascii?Q?6xKpJZt5ZWIcSvK61SgyvhUGpd4rrNmoCYI8/ktKHn8y0ltrO2V9ZsCX+V8h?= =?us-ascii?Q?mfu3Bk87riz+AP7dCExJ7zUoWXWQgxdKY6zAgCsyggD3PqYABN/S/HeJ9GJw?= =?us-ascii?Q?goSs4e00Xvc/06yxHHyd76lO2E6zru8KHnUAGY1uxgxDAN3a2jKalVkzYMna?= =?us-ascii?Q?PZ9sVmXIPKYNqnZb3bUPjtVtgL/auDLAq6AtOAB84zgo2estCSt1b68L+iUh?= =?us-ascii?Q?lc0yYdtUdeT7cYWNj4tFFo9tZ6Cznn8+sWG/0Q52rcO/ygIoZEhnx7h0z6lb?= =?us-ascii?Q?hNtMFCTmW3Sb2fFab+w876tdhwD0/q5WbSd64sQ1+oeXiQVq2nayU/tjrXkE?= =?us-ascii?Q?A2p182arryc1kE3YqaKMCESMBtF2nBSazrblfu8P8ZVNzP+GeE1jDV9pzcCX?= =?us-ascii?Q?qJfpngLwnBPOKTGOyXjWnaysp7enfnvApPyx/wzIbnRSSn51T+HCkBFXo8X7?= =?us-ascii?Q?AIfpinD6sb/BmRcQA0YXKv7aepbZoBSi0Y/wluewJse3blZM7avNjhY97PUA?= =?us-ascii?Q?uolrEQCETL7G1erRvFYbwmnv/huV2l2MYGn/u7aCb501jQ2F9lZQugyQA8TL?= =?us-ascii?Q?KB1KSehFg4UqxZhVxG3BBKjTyU7Pd2HtbVH3qCBcl2Gy5NI7JgvKFAm1HSLC?= =?us-ascii?Q?6LsP7evO4eXb85g+be2QHsu21on/PUiN+BA2Db7sFbd88MTC0RD44wbb68G8?= =?us-ascii?Q?daetJ51GNjXsRmA/eN5mQz48QfQc+52OEFRi9DK/ZtMJoWkTG7+Vz4xFqpi5?= =?us-ascii?Q?Fdi/rYFtMnyJ+qE/aYzkB5rQVGISeM3+Kgtm1hL2Sb9IT+CM6xtfJzrdUWAE?= =?us-ascii?Q?iN1HwfGzaV9J6r12RMDkXbd1?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN7PR05MB7582.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42bd1b16-b9ec-48df-f4a4-08d8d319ef5c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2021 07:59:21.5021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZxrqGaj85j1NQ7PtWc8Auty/fYl+fpZ1INRFYHvFQxyYZy9cc8A1JoCChtJAEm3juzHOGke8itUvGBzjSVX4ng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4190 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_SN7PR05MB7582C17CF48EAD8DD54F0123B9869SN7PR05MB7582namp_" --_000_SN7PR05MB7582C17CF48EAD8DD54F0123B9869SN7PR05MB7582namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure I truly follow the conversation you're having (sorry), but I'l= l raise my hand as a _DMA user. I'm not that married to it, but I haven't a= dded support for the alternate IORT-based DMA range clamping. If long term = we want to bail on _DMA and adopt IORT exclusively, I'd love to know that s= o I can plan accordingly... A ________________________________ From: Ard Biesheuvel Sent: Wednesday, February 17, 2021 1:55 AM To: Jeremy Linton Cc: jlinton ; devel@edk2.groups.io ; Peter Batard ; Andrei Warkentin ; Samer El-Haj-Mahmoud ; Leif Lindholm ; Ard Biesheuvel Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates 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 > >> > --_000_SN7PR05MB7582C17CF48EAD8DD54F0123B9869SN7PR05MB7582namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm not sure I truly follow the conversation you're having (sorry), but I'l= l raise my hand as a _DMA user. I'm not that married to it, but I haven't a= dded support for the alternate IORT-based DMA range clamping. If long term = we want to bail on _DMA and adopt IORT exclusively, I'd love to know that so I can plan accordingly...

A
From: Ard Biesheuvel <ar= db@kernel.org>
Sent: Wednesday, February 17, 2021 1:55 AM
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: jlinton <lintonrjeremy@gmail.com>; devel@edk2.groups.io &l= t;devel@edk2.groups.io>; Peter Batard <pete@akeo.ie>; Andrei Warke= ntin <awarkentin@vmware.com>; Samer El-Haj-Mahmoud <samer.el-haj-m= ahmoud@arm.com>; Leif Lindholm <leif@nuviainc.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>
Subject: Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates
 
On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <je= remy.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 > >>          &n= bsp;   spelling, etc.
> >>
> >
> > What happened to the IORT change? Don't we need that to ensure th= at
> > 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<= br> > 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 disab= le
> patch I posted separately since I don't have to worry about enabling i= t
> 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<= br> > 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<= br> > 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 en= able the emmc2 table on rpi4 &
> >>          &n= bsp;   !Arasan routing
> >>          Move em= mc2 into its own SSDT and drop
> >>          &n= bsp;   second _DMA entry
> >>
> >> Jeremy Linton (4):
> >>    Platform/RaspberryPi: Add Negative table ch= eck
> >>    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&nb= sp;    |   1 +
> >>   Platform/RaspberryPi/AcpiTables/Emmc.asl &nb= sp;         | 129 +++++++++++++++++= ++++
> >>   Platform/RaspberryPi/AcpiTables/Sdhc.asl &nb= sp;         |  18 ++-
> >>   Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.= c |  26 +++++
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf&n= bsp;   |   1 +
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.un= i |   4 +
> >>   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vf= r |  17 +++
> >>   Platform/RaspberryPi/Include/ConfigVars.h &n= bsp;        |   8 ++
> >>   Platform/RaspberryPi/RPi3/RPi3.dsc  &nb= sp;            =   |   1 +
> >>   Platform/RaspberryPi/RPi4/RPi4.dsc  &nb= sp;            =   |   3 +-
> >>   Platform/RaspberryPi/RPi4/Readme.md  &n= bsp;            = ; |   2 +-
> >>   Platform/RaspberryPi/RaspberryPi.dec  &= nbsp;            |&n= bsp;  1 +
> >>   12 files changed, 206 insertions(+), 5 deletions(= -)
> >>   create mode 100644 Platform/RaspberryPi/AcpiTable= s/Emmc.asl
> >>
> >> --
> >> 2.13.7
> >>
>
--_000_SN7PR05MB7582C17CF48EAD8DD54F0123B9869SN7PR05MB7582namp_--