(On my phone, apologies for brevity.)

On 2 Nov 2016 17:09, "Marcin Wojtas" <mw@semihalf.com> wrote:
>
> Hi Leif,
>
> Thanks for your answer. We'll check AMD and try to adjust our platform
> to it. Hopefully everything works fine. We have only USB/SATA/SD left
> - all of them users of PciIO stuff. We have to finalize adaptation,
> submit patches that can work with Ard's solution.
>
> My preferable scenario is following: let's achieve state that we have
> ready-to-go, accepted patches in November. Their merge to OPP would be
> gated only by Ard's PciIO merge to EDK2. This would allow to fulfill
> our commitments and also prevent from creating mess in the repo. What
> do you think?

Yes, this sounds good.
But I'm also serious about pushing Ard's set into OPP temporarily if needed (and tester).

> Best regards,
> Marcin
>
> 2016-11-02 23:49 GMT+01:00 Leif Lindholm <leif.lindholm@linaro.org>:
> > 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:
> >> 1. Is it possible to use it with multiple devices?
> >
> > Yes.
> >
> >> 2. Is there any exaple of usage?
> >
> > See Ard's recent posts to linaro-uefi for moving the AMD platforms
> > onto this infrastructure.
> >
> >> 3. 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)
> >
> >> 4. 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