Hi Russell, On 30 January 2015 at 00:56, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > 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". > I agree, and I'll add the check for max_segment_size * max_segment_count < dmabuf->size and resend; will that be alright with you? > 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. Best regards, ~Sumit. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
