On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, Mar 10, 2017 at 10:31:13AM +0000, Brian Starkey wrote: >> Hi, >> >> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote: >> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: >> >> [snip] >> >> > > >> > > For me those patches are going in the right direction. >> > > >> > > I still have few questions: >> > > - since alignment management has been remove from ion-core, should it >> > > be also removed from ioctl structure ? >> > >> > Yes, I think I'm going to go with the suggestion to fixup the ABI >> > so we don't need the compat layer and as part of that I'm also >> > dropping the align argument. >> > >> >> Is the only motivation for removing the alignment parameter that >> no-one got around to using it for something useful yet? >> The original comment was true - different devices do have different >> alignment requirements. >> >> Better alignment can help SMMUs use larger blocks when mapping, >> reducing TLB pressure and the chance of a page table walk causing >> display underruns. > > Extending ioctl uapi is easy, trying to get rid of bad uapi is much > harder. Given that right now we don't have an ion allocator that does > alignment I think removing it makes sense. And if we go with lots of > heaps, we might as well have an ion heap per alignment that your hw needs, > so there's different ways to implement this in the future. slight correction: if you plan ahead (and do things like zero init if userspace passes in a smaller ioctl struct like drm_ioctl does), extending ioctl uapi is easy.. might be something worth fixing from the get-go.. BR, -R > At least from the unix device memory allocator pov it's probably simpler > to encode stuff like this into the heap name, instead of having to pass > heap + list of additional properties/constraints. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
