On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote: > Quite possibly for some of these edge some of cases, some of the > dma-buf exporters are going to need to get more clever (ie. hand off > different scatterlists to different clients). Although I think by far > the two common cases will be "I can support anything via an iommu/mmu" > and "I need phys contig". > > But that isn't an issue w/ dma-buf itself, so much as it is an issue > w/ drivers. I guess there would be more interest in fixing up drivers > when actual hw comes along that needs it.. However, validating the attachments is the business of dma-buf. This is actual infrastructure, which should ensure some kind of sanity such as the issues I've raised. The whole "we can push it onto our users" is really on - what that results in is the users ignoring most of the requirements and just doing their own thing, which ultimately ends up with the whole thing turning into a disgusting mess - one which becomes very difficult to fix later. Now, if we're going to do the "more clever" thing you mention above, that rather negates the point of this two-part patch set, which is to provide the union of the DMA capabilities of all users. A union in that case is no longer sane as we'd be tailoring the SG lists to each user. If we aren't going to do the "more clever" thing, then yes, we need this code to calculate that union, but we _also_ need it to do sanity checking right from the start, and refuse conditions which ultimately break the ability to make use of that union - in other words, when the union of the DMA capabilities means that the dmabuf can't be represented. Unless we do that, we'll just end up with random drivers interpreting what they want from the DMA capabilities, and we'll have some drivers exporting (eg) scatterlists which satisfy the maximum byte size of an element, but ignoring the maximum number of entries or vice versa, and that'll most probably hide the case of "too small a union". It really doesn't make sense to do both either: that route is even more madness, because we'll end up with two classes of drivers - those which use the union approach, and those which don't. The KISS principle applies here. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
