On Wed, Nov 02, 2016 at 11:39:43PM +0100, Marcin Wojtas wrote:
2016-11-02 22:56 GMT+01:00 Ard Biesheuvel ard.biesheuvel@linaro.org:
On 2 November 2016 at 21:52, Marcin Wojtas mw@semihalf.com wrote:
Hi Ard,
2016-11-02 21:55 GMT+01:00 Ard Biesheuvel ard.biesheuvel@linaro.org:
On 2 November 2016 at 20:02, Jan Dąbroś jsd@semihalf.com wrote:
Hi Ard,
I have a question regarding DmaLib implementation. We took a deeper look at AHCI controller and it will be coherent on newer SoC version - as for now, we have non-coherent one and it's not working with NullDmaLib, whereas everything is ok when ArmDmaLib is used. In the same time, tests show that XHCI works fine both with NullDmaLib and ArmDmaLib. My question is, what are the contraindications for using ArmDmaLib for coherent devices if it is working good on them also? This solution seems to be covering for every case (contrary to NullDmaLib).
No, ArmDmaLib is fundamentally incompatible with coherent devices. The code performs a cache invalidate for data written by the bus master, since on non-coherent systems, this may be necessary to get rid of stale cachelines that shadow the incoming data. On coherent devices, the device will write to the cache, not to main memory, and so this cache invalidation will discard the data coming from the device.
Could you help understand then, how come a coherent device (XHCI) can work both with ArmDmaLib/NullDmaLib, whereas non-coherent device (AHCI) can work only with ArmDmaLib? In other words, how do you suggest to proceed here?
In case we switch to NullDmaLib, what's suggested solution of handling non-coherent devices? Do you know of any reference PciEmulation driver that deals with such situation?
I am working on a generic solution for this: https://lists.01.org/pipermail/edk2-devel/2016-October/003842.html
Great, thanks! It seems like all we need is there. I have a dillema now - since it's under review on EDK2 lists, I have doubts if there is any reason for adding similar solution in OPP.
I would very much prefer to not add your implementation to OPP only to delete it again a week or two later.
It may be a good moment to adjust to your solution and test - if everything is fine, we can drop our driver - what do you think?
Yes, that sounds good.
I know it's hard to predict, but when do you expect to get it merged? It's important due to tight schedule we have:/ In case of problems we will try to enhance OPP driver to be accepted and later replace solution, once it's ready - we still have almost a month to go.
I am not overly concerned by this. Worst case, we could add Ard's generic solution to OPP as a stop-gap solution.
I have a couple of questions:
- Is it possible to use it with multiple devices?
Yes.
- Is there any exaple of usage?
See Ard's recent posts to linaro-uefi for moving the AMD platforms onto this infrastructure.
- Sata in current silicone revision has some quirks (non-dma
coherent, +2 other minor stuff, which was avoided by substituting PciIoMemRead/Write with custom functions). Is there any backdoor in your design for creating sort of wrappers?
(pass, I'll let Ard answer)
- Do you have some branch in public repo, so that it would be easier
to obtain the patches?
Again, see Ard's recent posts to edk2-devel and linaro-uefi.
https://git.linaro.org/people/ard.biesheuvel/uefi-next.git/log/?h=pciio-emu
Regards,
Leif