[edk2-devel] [PATCH v4 edk2-platforms 1/1] Silicon/DesignWare/Driver: DwEmacSnpDxe: Add DesignWare EMAC driver

Ooi, Tzy Way tzy.way.ooi at intel.com
Wed Jun 19 10:09:05 UTC 2019


Hi Bieshuevel,

In the DmaMap function, there is one line where my code look like this:

"Status = DmaMap (MapOperationBusMasterCommonBuffer, Snp->MacDriver.TxdescRing[0], &BufferSize, &Snp->MacDriver.TxdescRingMap[0], &Snp->MappingTxdesc);"

You asked me why the [0] and how many descriptor I am mapping. In my code, there is total 10 descriptors. The way I did in current code was I use DmaAllocateBuffer to allocate a memory size which is big enough for 10 descriptors. After that, I just map the first descriptor and I access the rest of the descriptor by using the first descriptor address plus the size for each descriptor to get the next descriptor address. Wonder if this method is ok? Or do I need to use DmaAllocateBuffer and DmaMap for 10 times for total 10 descriptors? 

Thank you

Best regards,
Tzy Way

-----Original Message-----
From: Ard Biesheuvel <ard.biesheuvel at linaro.org> 
Sent: Friday, May 31, 2019 5:20 PM
To: Ooi, Tzy Way <tzy.way.ooi at intel.com>
Cc: edk2-devel-groups-io <devel at edk2.groups.io>; Kinney, Michael D <michael.d.kinney at intel.com>; Loh, Tien Hock <tien.hock.loh at intel.com>; leif.lindholm at linaro.org
Subject: Re: [edk2-devel] [PATCH v4 edk2-platforms 1/1] Silicon/DesignWare/Driver: DwEmacSnpDxe: Add DesignWare EMAC driver

On Fri, 31 May 2019 at 11:14, Ooi, Tzy Way <tzy.way.ooi at intel.com> wrote:
>
> Thanks Biesheuvel.
>
> I would like to confirm with you on regards of one of the comment. There is one comment where you mentioned that:
> "I am aware that TX is usually the hot path in UEFI, but we should still try to map a buffer directly rather than copy the contents into uncached memory"
>
> I would like to confirm with you if do you mean I should do the DmaMap here instead of doing it at the beginning of the code while DmaAllocate is executed?

Yes.

Each time you receive a buffer, you DmaMap() it with the MapOperationBusMasterRead attribute, and hand it to the device. After the device is finished, you DmaUnmap() it again. This removes the need for uncached memory.

On the RX path, you can allocate the buffers via AllocatePages() rather than via DmaAllocateBuffer(), and map the for DMA using
DmaMap() with the MapOperationBusMasterWrite attribute. Once the buffer is filled by the hardware, you can DmaUnmap() it and copy the contents back to the caller, after which you can recycle the buffer or free it.

> Or do you mean I shouldn’t copy it into a uncached memory region?
>

DmaAllocateBuffer() gives you an uncached region, so you should only use it for data structures that are accessed and modified by the CPU and the hardware at the same time, e.g., the descriptor rings. The actual data buffers only need directional DMA, so using uncached memory results in an unnecessary performance hit.


> Thank you
> -----Original Message-----
> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Sent: Wednesday, May 22, 2019 3:22 PM
> To: edk2-devel-groups-io <devel at edk2.groups.io>; Ooi, Tzy Way 
> <tzy.way.ooi at intel.com>
> Cc: Kinney, Michael D <michael.d.kinney at intel.com>; Loh, Tien Hock 
> <tien.hock.loh at intel.com>; leif.lindholm at linaro.org
> Subject: Re: [edk2-devel] [PATCH v4 edk2-platforms 1/1] 
> Silicon/DesignWare/Driver: DwEmacSnpDxe: Add DesignWare EMAC driver
>
> On Wed, 22 May 2019 at 03:37, Ooi, Tzy Way <tzy.way.ooi at intel.com> wrote:
> >
> > Hi Maintainers,
> >
> > Please could you help to review this patch? Thanks.
> >
>
> I already did, but my email response got rejected twice
>
> https://edk2.groups.io/g/devel/message/40829?p=,,,20,0,0,0::Created,,e
> mac,20,2,0,31541649

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#42588): https://edk2.groups.io/g/devel/message/42588
Mute This Topic: https://groups.io/mt/31541649/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-





More information about the edk2-devel-archive mailing list