On Fri, Oct 31, 2025 at 08:46:34AM +0100, Christian König wrote:
On 10/31/25 06:15, Kasireddy, Vivek wrote:
Hi Jason,
Subject: Re: [RFC v2 0/8] dma-buf: Add support for mapping dmabufs via interconnects
On Thu, Oct 30, 2025 at 06:17:11AM +0000, Kasireddy, Vivek wrote:
It mostly looks OK to me but there are a few things that I want to discuss, after briefly looking at the patches in your branch:
- I am wondering what is the benefit of the SGT compatibility stuff especially
when Christian suggested that he'd like to see SGT usage gone from dma-buf
I think to get rid of SGT we do need to put it in a little well defined box and then create alternatives and remove things using SGT. This is a long journey, and I think this is the first step.
If SGT is some special case it will be harder to excise.
So the next steps would be to make all the exporters directly declare a SGT and then remove the SGT related ops from dma_ops itself and remove the compat sgt in the attach logic. This is not hard, it is all simple mechanical work.
IMO, this SGT compatibility stuff should ideally be a separate follow-on effort (and patch series) that would also probably include updates to various drivers to add the SGT mapping type.
Nope, just the other way around. In other words the SGT compatibility is a pre-requisite.
We should first demonstrate with existing drivers that the new interface works and does what it promised to do and then extend it with new functionality.
Ok, so I think that is what my github is showing.
Everything interworks, non-mapping-type aware code simply acts exactly as though it is using a SGT mapping type from the perspective of aware code.
I see a fairly easy path to do some driver upgrades to make more things more mapping aware and remove some of the compatibility parts.
Let me see if I can post a RFC version next week, got a big pile of other stuff to do still..
Jason