On 2021-08-16 07:48, Sven Peter wrote:
On Thu, Aug 12, 2021, at 13:29, Joerg Roedel wrote:
Hi Sven,
On Tue, Aug 10, 2021 at 08:09:53AM +0200, Sven Peter wrote:
This happens because apple/dart is missing the "Optimizing iommu_[map/unmap]
performance"
series which is already in the core branch [1].
The same commit works fine in iommu/next since that branch merges both
iommu/core and
apple/dart.
Okay, thanks. I re-based the DART patches on-top of my core branch,
which contains the changes for iommu_[map/unmap] performance. I
generally don't like rebasing topic branches, but made an exception here
to not break bisectability.
Thanks,
Joerg
Hi Joerg,
Thanks, and sorry about that! I'll try to make it more clear if anything depends
on another series in the future or just try to avoid it altogether if possible.
Just a heads up about a similar situation you may already be aware of: Once
Robin's
DMA domain strictness refactoring [1] is merged, the current DART driver will
fail due
to patch 12 there, which unexports iommu_get_dma_cookie. It'll need a small
adjustment just like all the other drivers (which will also fix two small bugs
it just made me notice: I never use iommu_put_dma_cookie and also
unconditionally
grab a DMA cookie for all domain types).
Unless I'm mistaken I can't make that adjustment before the first patch of
that series has been merged, and Robin can't make that adjustment in his series
because it'll presumably go through another topic branch.
Hmm, the exports only affect modules though - the cookie functions are
still public so that the core code can call them - so it should only
break certain configs. Possibly the most self-contained way to avoid
issues in -next would be to switch APPLE_DART from tristate to bool for
now, then flip it back along with cleaning up the iommu-dma remnants at
rc1. That should avoid any more rebasing at least.
At worst, my patch #12 could in principle be held back and applied at
rc1 alongside the DART fixup - functionally it shouldn't be an issue,
but patch #16 would need fixing up to apply without the context change.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
