On 6/2/23 1:23 PM, Jason Gunthorpe wrote: > On Fri, Jun 02, 2023 at 01:15:47PM -0400, Dennis Dalessandro wrote: >>> So you will have to think carefully about is needed. It is part of why >>> I don't want to take uAPI changed for incomplete features. I'm >>> wondering how you will fit dmabuf into hfi1 when I won't be happy if >>> this is done by adding dmabuf support to the cdev. The cdev just needs to know what type of memory it's dealing with. We expect the dmabuf to be allocated and ready to use. Just like we would a GPU buffer. So would you still reject the patch if we sent support for AMD's GPU instead of dmabuf if it's all in-tree and upstream and we have the user code to go with it? To me enabling this support for our cdev shouldn't be that big of a deal. It's in support of our existing HW. I'm still committed to fixing the cdev once and for all. However I'm planning that as part of the next gen HW release. I just don't see why we need to tie the two things together especially when the only uAPI change is to have a way to pass in the type of buffer that is backing the iovec, and I guess should bump the version number as well. We aren't adding any new IOCTLs or anything like that. Regardless, specific to this patch, Brendan has reworked the patch to not touch UAPI but just do the refactoring of splitting out the page pinning from the rest of the SDMA stuff. -Denny
