On Mon, Jan 21, 2019 at 03:56:29PM -0800, Stefano Stabellini wrote:
> > Where should we pick this up? I could pick it up through the dma-mapping
> > tree given that is where the problem is introduced, but the Xen or arm64
> > trees would also fit.
>
> I am happy for you to carry it in the dma-map
On Sat, 19 Jan 2019, Christoph Hellwig wrote:
> [full quote deleted, please take a little more care when quoting]
>
> On Fri, Jan 18, 2019 at 04:44:23PM -0800, Stefano Stabellini wrote:
> > > #ifdef CONFIG_XEN
> > > - if (xen_initial_domain()) {
> > > - dev->archdata.dev_dma_ops = dev->dm
[full quote deleted, please take a little more care when quoting]
On Fri, Jan 18, 2019 at 04:44:23PM -0800, Stefano Stabellini wrote:
> > #ifdef CONFIG_XEN
> > - if (xen_initial_domain()) {
> > - dev->archdata.dev_dma_ops = dev->dma_ops;
> > + if (xen_initial_domain())
> >
On Thu, 17 Jan 2019, Christoph Hellwig wrote:
> Xen-swiotlb hooks into the arm/arm64 arch code through a copy of the
> DMA mapping operations stored in the struct device arch data.
>
> Switching arm64 to use the direct calls for the merged DMA direct /
> swiotlb code broke this scheme. Replace th
Xen-swiotlb hooks into the arm/arm64 arch code through a copy of the
DMA mapping operations stored in the struct device arch data.
Switching arm64 to use the direct calls for the merged DMA direct /
swiotlb code broke this scheme. Replace the indirect calls with
direct-calls in xen-swiotlb as wel
