On Mon, Mar 18, 2019 at 10:04 AM Jerome Glisse <jglisse@xxxxxxxxxx> wrote: > > On Wed, Mar 13, 2019 at 09:10:04AM -0700, Andrew Morton wrote: > > On Tue, 12 Mar 2019 21:27:06 -0400 Jerome Glisse <jglisse@xxxxxxxxxx> wrote: > > > > > Andrew you will not be pushing this patchset in 5.1 ? > > > > I'd like to. It sounds like we're converging on a plan. > > > > It would be good to hear more from the driver developers who will be > > consuming these new features - links to patchsets, review feedback, > > etc. Which individuals should we be asking? Felix, Christian and > > Jason, perhaps? > > > > So i am guessing you will not send this to Linus ? Should i repost ? > This patchset has 2 sides, first side is just reworking the HMM API > to make something better in respect to process lifetime. AMD folks > did find that helpful [1]. This rework is also necessary to ease up > the convertion of ODP to HMM [2] and Jason already said that he is > interested in seing that happening [3]. By missing 5.1 it means now > that i can not push ODP to HMM in 5.2 and it will be postpone to 5.3 > which is also postoning other work ... > > The second side is it adds 2 new helper dma map and dma unmap both > are gonna be use by ODP and latter by nouveau (after some other > nouveau changes are done). This new functions just do dma_map ie: > hmm_dma_map() { > existing_hmm_api() > for_each_page() { > dma_map_page() > } > } > > Do you want to see anymore justification than that ? Yes, why does hmm needs its own dma mapping apis? It seems to perpetuate the perception that hmm is something bolted onto the side of the core-mm rather than a native capability.