public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ashish Singhal <ashishsingha@nvidia.com>
To: "Cohen, Eugene" <eugene@hp.com>, "Wu, Hao A" <hao.a.wu@intel.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Date: Thu, 28 Feb 2019 22:20:40 +0000	[thread overview]
Message-ID: <DM6PR12MB3324B30FEB8FA49A8C5B71B4BA750@DM6PR12MB3324.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CS1PR8401MB118981B4A0E501E780D00666B4750@CS1PR8401MB1189.NAMPRD84.PROD.OUTLOOK.COM>

Eugene,

Thanks for the explanation. The problem is valid and is more clear to me now. How about we do this:

Instead of:

    if (Private->Capability[Slot].SysBus64V3 == 0 &&
        Private->Capability[Slot].SysBus64V4 == 0) {
      Support64BitDma = FALSE;
    }

What do you think about:

    if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
         Private->Capability[Slot].SysBus64V3 == 0) ||
        (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_400 &&
         Private->Capability[Slot].SysBus64V4 == 0)) {
      Support64BitDma = FALSE;
    }

With this, we would be checking 64b capability based on the version we are using and not for something we may not be using despite of being advertised in the controller.

Thanks
Ashish

From: Cohen, Eugene <eugene@hp.com>
Sent: Thursday, February 28, 2019 2:59 PM
To: Ashish Singhal <ashishsingha@nvidia.com>; Wu, Hao A <hao.a.wu@intel.com>; edk2-devel@lists.01.org; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Ashish,


  *   Right now, we disable 64b DMA Support in PCI if the controller cannot support 64b DMA in V3 as well as V4.  If either of these support 64b DMA, we do not disable it. In the code, we set Support64BitDma to TRUE by default and change it to FALSE only if any of the controller does not support it in V3 as well as V4. If all controllers support it in V3 or V4 we keep 64b DMA support enabled.

That is precisely the problem.  An SDHC v3 controller might support 64b DMA in V3 but not in V4 mode.  The current code will leave 64b DMA support enabled resulting in the issuing of the PCI DUAL_ADDRESS_CYCLE attribute ( see https://github.com/tianocore/edk2/blob/ece4c1de3e7b2340d351c2054c79ea689a954ed6/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c#L738 ) which then causes buffers to be allocated that cannot be DMAed.

For reference look at this snippet of the NonDiscoverablePciDeviceIo driver: https://github.com/tianocore/edk2/blob/ece4c1de3e7b2340d351c2054c79ea689a954ed6/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c#L622 and you can see that bounce buffering will only occur if DUAL_ADDRESS_CYCLE is clear.

So since we do not have V3 64b DMA (96-bit descriptor) support in place we must not allow the DUAL_ADDRESS_CYCLE attribute to be set or we will fail with this check: https://github.com/tianocore/edk2/blob/ece4c1de3e7b2340d351c2054c79ea689a954ed6/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c#L1426


I've added Ard who updated the driver with DUAL_ADDRESS_CYCLE support.

Eugene


From: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>
Sent: Thursday, February 28, 2019 2:28 PM
To: Cohen, Eugene <eugene@hp.com<mailto:eugene@hp.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Eugene,

We do not have support for V4 64b DMA right now but it can be added later if needed. I am trying to understand the reason behind changing the check from AND to OR. Right now, we disable 64b DMA Support in PCI if the controller cannot support 64b DMA in V3 as well as V4. If either of these support 64b DMA, we do not disable it. In the code, we set Support64BitDma to TRUE by default and change it to FALSE only if any of the controller does not support it in V3 as well as V4. If all controllers support it in V3 or V4 we keep 64b DMA support enabled.

  //
  // Enable 64-bit DMA support in the PCI layer if this controller
  // supports it.
  //
  if (Support64BitDma) {
    Status = PciIo->Attributes (
                      PciIo,
                      EfiPciIoAttributeOperationEnable,
                      EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE,
                      NULL
                      );
    if (EFI_ERROR (Status)) {
      DEBUG ((DEBUG_WARN, "SdMmcPciHcDriverBindingStart: failed to enable 64-bit DMA (%r)\n", Status));
    }
  }

Thanks
Ashish

From: Cohen, Eugene <eugene@hp.com<mailto:eugene@hp.com>>
Sent: Thursday, February 28, 2019 12:56 PM
To: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Ashish,


  *   With my change, if any of the controller did not support 64b DMA in V3 as well as V4 capability, we are not enabling it in PCI layer.

The logic is:

   if (Private->Capability[Slot].SysBus64V3 == 0 &&
       Private->Capability[Slot].SysBus64V4 == 0) {
        Support64BitDma = FALSE;
    }

which means that for a SDHC v3 controller you have SysBus64V3=1 and SysBus64V4=0 the FALSE assignment is never done - this is not correct.  Perhaps you intended an OR instead of an AND?  Either way changing this to an || or using my patch is the same logical result because a V3 controller will use 32-bit DMA and V4 controller will use 64-bit DMA (a V4 controller should have the V3 bit set).  I really saw no reason to be checking the V3 bit since the driver was unprepared to do V3 64-bit DMA operations anyways.

Eugene


From: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>
Sent: Thursday, February 28, 2019 12:15 PM
To: Cohen, Eugene <eugene@hp.com<mailto:eugene@hp.com>>; Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Hello Eugene,

My patch enabled support for SDHC 4.0 and above in general including support for 64b ADMA descriptor. The check for V3 capability for 64b DMA was already there and similar check was implemented for V4 capability for 64b DMA. Earlier, if any of the V3 controller did not support 64b DMA, we were not enabling it in PCI layer. With my change, if any of the controller did not support 64b DMA in V3 as well as V4 capability, we are not enabling it in PCI layer.

This check in my opinion is better because we only disable 64b DMA PCI support when both V3 and V4 have it disabled.

Thanks
Ashish

-----Original Message-----
From: Cohen, Eugene <eugene@hp.com<mailto:eugene@hp.com>>
Sent: Thursday, February 28, 2019 4:24 AM
To: Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Hao,

> I remember the commit b5547b9ce97e80c3127682a2a5d4b9bd14af353e from
> Ashish only handles the controllers with version greater or equal to 4.00.

Right - that commit added support for SDHC 4.0 and above. The original driver supported SDHC 3.0 albeit only with SDMA and 32-bit ADMA support.

With that commit two descriptor types are supported the 32-bit ADMA descriptor (SD_MMC_HC_ADMA_32_DESC_LINE which is 64-bits in size) and the V4 64-bit ADMA descriptor (SD_MMC_HC_ADMA_64_DESC_LINE which is 128-bits in size).

However the commit mistakenly added a check for the V3 capability for 64-bit DMA and used it to set the PCI DUAL_ADDRESS_CYCLE attributre which then does not the 32-bit compatible bounce buffer mechanism. Later, when we attempt an ADMA data transfer we hit an ASSERT because the PCI DMA subsystem is not using bounce buffers to provide 32-bit DMA compatible memory. So the patch I submitted simply removes the unnecessary check of the V3 64-bit DMA capability check so the PCI DUAL_ADDRESS_CYCLE attribute is not set allowing 32-bit DMA to succeed on these platforms.

> And the ADMA2 (96-bit Descriptor) mode for V3 controllers is selected
> by setting the 'DMA Select' filed in the Host Control 1 Register to
> 11b. But the currently behavior of the driver is setting the field to
> 10b, which I think will not switch to the ADMA2 (96-bit Descriptor) mode for V3.

Correct, right now for a V3 controller only 32-bit DMA is supported. An enhancement for V3 64-bit ADMA would improve performance on controllers that support that mode by eliminating the bounce buffer and associated memory copies. I think we should file a BZ for SD HCI V3 64-bit ADMA support - if you agree I would be happy to do that.

I should point out that we have done extensive testing of this change on our host controller.

Thanks,

Eugene

---

From: Wu, Hao A <hao.a.wu@intel.com<mailto:hao.a.wu@intel.com>>
Sent: Wednesday, February 27, 2019 8:25 PM
To: Cohen, Eugene <eugene@hp.com<mailto:eugene@hp.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Ashish Singhal <ashishsingha@nvidia.com<mailto:ashishsingha@nvidia.com>>
Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems

Loop Ashish in.
Some comments below.

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Wednesday, February 27, 2019 6:59 PM
> To: mailto:edk2-devel@lists.01.org; Wu, Hao A
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC
> v3 64-bit systems
>
> The SdMmcPciHcDriverBindingStart function was checking two different
> capability bits in determining whether 64-bit DMA modes were
> supported, one mode is defined in the SDHC version
> 3 specification (using 96-bit descriptors) and another is defined in
> the SDHC version 4 specification (using 128-bit descriptors). Since
> the currently implementation of 64-bit
> ADMA2 only supports the SDHC version 4 implementation it is incorrect
> to check the V3 64-bit capability bit since this will activate V4
> ADMA2 on V3 controllers.

I remember the commit b5547b9ce97e80c3127682a2a5d4b9bd14af353e from Ashish only handles the controllers with version greater or equal to 4.00.

And the ADMA2 (96-bit Descriptor) mode for V3 controllers is selected by setting the 'DMA Select' filed in the Host Control 1 Register to 11b. But the currently behavior of the driver is setting the field to 10b, which I think will not switch to the ADMA2 (96-bit Descriptor) mode for V3.

Maybe there is something I miss here. Could you help to provide some more detail on the issue you met? Thanks.

Best Regards,
Hao Wu

>
> Cc: Hao Wu <mailto:hao.a.wu@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eugene Cohen <mailto:eugene@hp.com>
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..5bc91c5 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -666,8 +666,7 @@ SdMmcPciHcDriverBindingStart ( // If any of the
> slots does not support 64b system bus // do not enable 64b DMA in the
> PCI layer.
> //
> - if (Private->Capability[Slot].SysBus64V3 == 0 &&
> - Private->Capability[Slot].SysBus64V4 == 0) {
> + if (Private->Capability[Slot].SysBus64V4 == 0) {
> Support64BitDma = FALSE;
> }
>
> --
> 2.7.4
> _______________________________________________
> edk2-devel mailing list
> mailto:edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


  reply	other threads:[~2019-02-28 22:21 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 [this message]
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
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=DM6PR12MB3324B30FEB8FA49A8C5B71B4BA750@DM6PR12MB3324.namprd12.prod.outlook.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