public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Ashish Singhal <ashishsingha@nvidia.com>
Cc: "Cohen, Eugene" <eugene@hp.com>, "Wu, Hao A" <hao.a.wu@intel.com>,
	 "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Date: Fri, 1 Mar 2019 11:32:27 +0100	[thread overview]
Message-ID: <CAKv+Gu_sHQ7nDJY90pTAN9vSUeL-OL59X4CGmqjMzNCixoAOvQ@mail.gmail.com> (raw)
In-Reply-To: <DM6PR12MB332496289555386623A3DC5EBA760@DM6PR12MB3324.namprd12.prod.outlook.com>

On Fri, 1 Mar 2019 at 01:19, Ashish Singhal <ashishsingha@nvidia.com> wrote:
>
> Eugene,
>
> Small question. Did the issue appear after the V4 patch went in? Looking at the code before that patch, we were enabling 64b dma in pci based on capability register already despite of driver supporting only 32b dma.
>

I think this may have been an oversight on my part when I originally
added the DUAL_ADDRESS_CYCLE handling.

The following commit added EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE to the
host bridge driver

commit e58a71d9c50ba641b5ab19f5ce2cbf772187de4d
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Sep 5 09:55:16 2016 +0100

    MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that
support it

    Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely
    ignored by the PCI host bridge driver, which means that, on an
implementation
    that supports DMA above 4 GB, allocations above 4 GB may be provided to
    devices that have not expressed support for it.

and the SDHCI driver was fixed accordingly in

Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Sep 5 09:51:48 2016 +0100

    MdeModulePkg/SdMmcPciHcDxe: enable 64-bit PCI DMA

    PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE
    attribute if the controller supports 64-bit DMA addressing.

So before these changes, we were in the exact same situation, but
since PC platforms never enable DMA above 4 GB in the first place,
nobody ever noticed until we started running this code on arm64
platforms that have no 32-bit addressable DRAM to begin with.

The obvious conclusion is that the driver should not set the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device does
not support it, or, which seems to be our case, if the driver does not
implement the 64-bit DMA mode that the driver does support. However,
since there are platforms for which bounce buffering is not an option
(since there is no 32-bit addressable memory to bounce to), this is
not just a performance optimization, and so it would be useful to fix
the code so it can drive all 64-bit DMA capable hardware.


  reply	other threads:[~2019-03-01 10:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 10:58 [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems Cohen, Eugene
2019-02-28  3:24 ` Wu, Hao A
2019-02-28 11:23   ` Cohen, Eugene
2019-02-28 19:15     ` Ashish Singhal
2019-02-28 19:56       ` Cohen, Eugene
2019-02-28 21:27         ` Ashish Singhal
2019-02-28 21:58           ` Cohen, Eugene
2019-02-28 22:20             ` Ashish Singhal
2019-02-28 22:40               ` Cohen, Eugene
2019-02-28 23:58                 ` Ashish Singhal
2019-03-01  0:10                   ` Cohen, Eugene
2019-03-01  0:19                     ` Ashish Singhal
2019-03-01 10:32                       ` Ard Biesheuvel [this message]
2019-03-01 10:34                         ` Ard Biesheuvel
2019-03-01 10:54                         ` Cohen, Eugene
2019-03-01 11:38                           ` Ard Biesheuvel
2019-03-01 12:31                             ` Ashish Singhal
2019-03-01 18:31                               ` Ashish Singhal
2019-03-01 15:25                             ` Ashish Singhal
2019-03-04  2:39                               ` Wu, Hao A
2019-03-04  4:00                                 ` Ashish Singhal
2019-03-04  4:26                                   ` Wu, Hao A
2019-03-05 11:58                                   ` Cohen, Eugene
2019-03-01 11:02                       ` Cohen, Eugene

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu_sHQ7nDJY90pTAN9vSUeL-OL59X4CGmqjMzNCixoAOvQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox