Thanks,
Chao
On 2023/12/21 20:31, Ard Biesheuvel wrote:
On Thu, 21 Dec 2023 at 13:11, Chao Li<lic...@loongson.cn>  wrote:
Hi Ard,


Thanks,
Chao
On 2023/12/21 15:31, Ard Biesheuvel wrote:

On Thu, 21 Dec 2023 at 04:48, Chao Li<lic...@loongson.cn>  wrote:

...

Ard,

PcdPciIoTranslationIsEnabled is only use for whether to trigger the Ffio read 
or write, it seem that only x86 or x64 need them, not others.

When I was submitted the patch V2, CpuIo2Dxe was private to LoongArch, just 
like Arm and RISC-V. Gerd recommended finding a better place for 
ArmPciCpuIo2Dxe so that other ARCH can easily use it. And then I found the 
UefiCpuPkg/CpuIo2Dxe might be able to accommodate the MMIO methods, so I merged 
them togeter in this change.

I think it makes sense to have a shared implementation under
UefiCpuPkg or even MdeModulePkg. But merging it with the x86
implementation using function pointers that are dereferenced at
runtime seems unnecessary to me.

So what do you suggest? Write some new functions to handle the MMIO method 
under the CpuIo2Dxe?

A given platform will either be able to use port IO, or it will need
to use MMIO translation. So a driver that can do both based on a PCD
is not very useful, it makes more sense to have two different drivers,
and the platform incorporates the one it can use.
Ok, I get it, I think you are more inclined to move the ArmCpuIo2Dxe to a new place and rename it, maybe: CpuMmio2Dxe, while some platforms choose the different CpuIo2 drvier by themselves when building FW, right?






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112813): https://edk2.groups.io/g/devel/message/112813
Mute This Topic: https://groups.io/mt/103261693/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to