Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Liming,
I am OK waiting till the freeze is over.
Thanks
Ashish
-Original Message-
From: Gao, Liming
Sent: Saturday, March 2, 2019 9:01 AM
To: Ashish Singhal ; edk2-devel@lists.01.org
Cc: Wu, Hao A
Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Ashish:
This seems a feature. Now, we are in Hard Feature Freeze. So, it will not be
added until edk2-stable201903 tag is created at 2019-03-08.
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Saturday, March 2, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ashish Singhal
>
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of
> the BSD License @@ -666,8 +666,12 @@ 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->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].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..68d8a5c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corporation. All rights reserved. This
> program and the accompanying materials are licensed and made
> available under the terms and conditions of the BSD License @@ -145,13
> +145,15 @@ typedef struct {
>EFI_PHYSICAL_ADDRESSDataPhy;
>VOID*DataMap;
>SD_MMC_HC_TRANSFER_MODE Mode;
> + SD_MMC_HC_ADMA_LEGTHLength;
>
>EFI_EVENT Event;
>BOOLEAN Started;
>UINT64 Timeout;
>
>SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> - SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
> + SD_MMC_HC_ADMA_64_V3_DESC_LINE *Adma64V3Desc;
> + SD_MMC_HC_ADMA_64_V4_DESC_LINE *Adma64V4Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32 AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index d73fa10..a6d2395 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are
Re: [edk2] [edk2-announce] March Community Meeting
Awesome, thanks! Em sáb, 2 de mar de 2019 19:02, stephano escreveu: > Sure, no problem. I added "BRT" timezone to the North America / Europe > meeting. The Asia/Pacific meeting is at midnight in São Paulo, so I > didn't bother to add it there. :) > > Cheers, > Stephano > > On 3/1/2019 9:32 AM, Rafael Machado wrote: > > Hi Stephano > > > > Could you please add at the https://www.tianocore.org/monthly-meeting > page > > the > > South America TZ (São Paulo if possible ) , in case these calendar > items > > are still being used? > > > > Thanks and Regards > > Rafael > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc failed
Reviewed-by: Bob Feng
-Original Message-
From: Fan, ZhijuX
Sent: Friday, March 1, 2019 10:52 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Feng, Bob C
Subject: [edk2][PATCH V2] BaseTools:Run packagedoc_cli.py to generate doc failed
The reason for this problem is that the file was opened incorrectly.
Cc: Bob Feng
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan
---
.../plugins/EdkPlugins/edk2/model/doxygengen.py| 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
index e31df262bc..73349e2f48 100644
---
a/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
+++
b/BaseTools/Scripts/PackageDocumentTools/plugins/EdkPlugins/edk2/model/doxygengen.py
@@ -376,9 +376,10 @@ class PackageDocumentAction(DoxygenAction):
return
try:
-f = open(path, 'r')
-lines = f.readlines()
-f.close()
+with open(path, 'r') as f:
+lines = f.readlines()
+except UnicodeDecodeError:
+return
except IOError:
ErrorMsg('Fail to open file %s' % path)
return
--
2.14.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Hi Eugene, Ashish and Ard Sorry for the delayed response, I was out of office in the previous several days. According to the discussion, my understanding is that (quote the comments from Ard): > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute > 1. If the device does not support it; > 2. If the driver does not implement the 64-bit DMA mode that the device does >support. Thus, for the current implementation of the SdMmcPciHcDxe driver (including the V4 ADMA descriptor support from Ashish): * The driver should set the DUAL_ADDRESS_CYCLE attribute only when 'SysBus64V4' bit set, because of the statement 2 above. And for the previous implementation (before the change from Ashish): * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since the implementation was written to support only the 32b ADMA descriptor. If this is true, I am fine with your proposed fix. Eugene, Could you help to state the reason for the fix a bit more clear in the commit log? Also, I have filed a Bugzilla tracker for this one: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Could you help to add this information into the commit log as well? Thanks. Best Regards, Hao Wu > -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Friday, March 01, 2019 11:25 PM > To: Ard Biesheuvel; Cohen, Eugene > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Acked-by: Ashish Singhal > > -Original Message- > From: Ard Biesheuvel > Sent: Friday, March 1, 2019 4:39 AM > To: Cohen, Eugene > Cc: Ashish Singhal ; Wu, Hao A > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > SW1Lab.) > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > Ard, > > > > > 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. > > > > Interesting - I did not realize that there were designs that were crazy > enough to have no addressable DRAM below 4G. > > > > You must be new here :-) > > But seriously, it does make sense for an implementation to, say, put all > peripherals, PCIe resource windows etc in the bottom half and all DRAM in > the top half of a 40-bit address space, which is how the AMD Seattle SoC > ended with its system memory at address 0x80__. > Note that on this platform, we can still use 32-bit DMA if we want to with the > help of the SMMUs, but we haven't wired those up in UEFI (and the generic > host bridge driver did not have the IOMMU hooks at the > time) > > > > 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. > > > > Okay, that's a great reason - let's get V3 64b ADMA2 in! > > > > Any objection to committing the original patch in the short term? > > > > not at all > > Acked-by: Ard Biesheuvel > > --- > 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. > --- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Monday, March 04, 2019 12:00 PM > To: Wu, Hao A; Cohen, Eugene; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Hao, > > I agree that there has been a bug all along which got exposed just now. We > should submit the patch as proposed by Eugene. Yes. I will co-work with Eugene to address this soon. > > Also, I have submitted the patch for enabling 64b DMA for V3. Please take > that into consideration once the freeze is over so that we can fix the issue > in > real sense. Sure. I will take a look at your proposed patch. Please grant me some time for the review and test. Best Regards, Hao Wu > > Eugene, > > Please let me know once you have tried my patch on your board. > > Thanks > Ashish > > -Original Message- > From: Wu, Hao A > Sent: Sunday, March 3, 2019 7:39 PM > To: Cohen, Eugene ; Ashish Singhal > ; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Eugene, Ashish and Ard > > Sorry for the delayed response, I was out of office in the previous several > days. > > According to the discussion, my understanding is that (quote the comments > from > Ard): > > > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > > attribute 1. If the device does not support it; 2. If the driver does > > not implement the 64-bit DMA mode that the device does > >support. > > Thus, for the current implementation of the SdMmcPciHcDxe driver > (including the > V4 ADMA descriptor support from Ashish): > > * The driver should set the DUAL_ADDRESS_CYCLE attribute only when > 'SysBus64V4' > bit set, because of the statement 2 above. > > And for the previous implementation (before the change from Ashish): > > * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since > the > implementation was written to support only the 32b ADMA descriptor. > > If this is true, I am fine with your proposed fix. > > > Eugene, > > Could you help to state the reason for the fix a bit more clear in the commit > log? > > Also, I have filed a Bugzilla tracker for this one: > https://bugzilla.tianocore.org/show_bug.cgi?id=1583 > > Could you help to add this information into the commit log as well? Thanks. > > Best Regards, > Hao Wu > > > -Original Message- > > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > > Sent: Friday, March 01, 2019 11:25 PM > > To: Ard Biesheuvel; Cohen, Eugene > > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > Acked-by: Ashish Singhal > > > > -Original Message- > > From: Ard Biesheuvel > > Sent: Friday, March 1, 2019 4:39 AM > > To: Cohen, Eugene > > Cc: Ashish Singhal ; Wu, Hao A > > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > > SW1Lab.) > > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > > > Ard, > > > > > > > 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. > > > > > > Interesting - I did not realize that there were designs that were > > > crazy > > enough to have no addressable DRAM below 4G. > > > > > > > You must be new here :-) > > > > But seriously, it does make sense for an implementation to, say, put > > all peripherals, PCIe resource windows etc in the bottom half and all > > DRAM in the top half of a 40-bit address space, which is how the AMD > > Seattle SoC ended with its system memory at address 0x80__. > > Note that on this platform, we can still use 32-bit DMA if we want to > > with the help of the SMMUs, but we haven't wired those up in UEFI (and > > the generic host bridge driver did not have the IOMMU hooks at the > > time) > > > > > > 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. > > > > > > Okay, that's a great reason - let's get V3 64b ADMA2 in! > > > > > > Any objection to
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Hi Hao, I agree that there has been a bug all along which got exposed just now. We should submit the patch as proposed by Eugene. Also, I have submitted the patch for enabling 64b DMA for V3. Please take that into consideration once the freeze is over so that we can fix the issue in real sense. Eugene, Please let me know once you have tried my patch on your board. Thanks Ashish -Original Message- From: Wu, Hao A Sent: Sunday, March 3, 2019 7:39 PM To: Cohen, Eugene ; Ashish Singhal ; Ard Biesheuvel Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems Hi Eugene, Ashish and Ard Sorry for the delayed response, I was out of office in the previous several days. According to the discussion, my understanding is that (quote the comments from Ard): > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > attribute 1. If the device does not support it; 2. If the driver does > not implement the 64-bit DMA mode that the device does >support. Thus, for the current implementation of the SdMmcPciHcDxe driver (including the V4 ADMA descriptor support from Ashish): * The driver should set the DUAL_ADDRESS_CYCLE attribute only when 'SysBus64V4' bit set, because of the statement 2 above. And for the previous implementation (before the change from Ashish): * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since the implementation was written to support only the 32b ADMA descriptor. If this is true, I am fine with your proposed fix. Eugene, Could you help to state the reason for the fix a bit more clear in the commit log? Also, I have filed a Bugzilla tracker for this one: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Could you help to add this information into the commit log as well? Thanks. Best Regards, Hao Wu > -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Friday, March 01, 2019 11:25 PM > To: Ard Biesheuvel; Cohen, Eugene > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Acked-by: Ashish Singhal > > -Original Message- > From: Ard Biesheuvel > Sent: Friday, March 1, 2019 4:39 AM > To: Cohen, Eugene > Cc: Ashish Singhal ; Wu, Hao A > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > SW1Lab.) > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > Ard, > > > > > 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. > > > > Interesting - I did not realize that there were designs that were > > crazy > enough to have no addressable DRAM below 4G. > > > > You must be new here :-) > > But seriously, it does make sense for an implementation to, say, put > all peripherals, PCIe resource windows etc in the bottom half and all > DRAM in the top half of a 40-bit address space, which is how the AMD > Seattle SoC ended with its system memory at address 0x80__. > Note that on this platform, we can still use 32-bit DMA if we want to > with the help of the SMMUs, but we haven't wired those up in UEFI (and > the generic host bridge driver did not have the IOMMU hooks at the > time) > > > > 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. > > > > Okay, that's a great reason - let's get V3 64b ADMA2 in! > > > > Any objection to committing the original patch in the short term? > > > > not at all > > Acked-by: Ard Biesheuvel > > -- > - 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. > --- ___ edk2-devel mailing list edk2-devel@lists.01.org
