On Fri, 14 Nov 2014 07:00:17 +1000 Dave Airlie <airlied@xxxxxxxxx> wrote: > > Aside from all this (and now with my community hat on) just adding > > code to get a sticker (labelled "passed DP validation") which is > > separate code and not used by actual users is imo not useful for > > merging upstream. But that's just my own opinion, not sure what's > > Dave's stance here or whether there's much precendence either way. > > > > So short answer: I still think exposing this with properties is the > > right approach, presuming we really need it (and it's not just to > > paper over a deficient link training logic in the kernel). I also > > think it'll be less code since we can simplify the debugfs option > > parser. > > Don't expose DP stuff in properties, I don't want users controlling > the parameters of the DP link in any way. I can't see any use > in userspace for controlling this stuff. So I'm happier with debugfs, > to avoid making an ABI we hate later. > > Yes I do prefer we make DP validation go via the same paths, > but some parts of DP validation require things userspace shouldn't > be allowed setup, and for those we should have bypasses, everything > else should be done via normal channels. Yeah, agreed on re-using code paths. I just don't think it means we have to re-use ioctl or property entry points. The internals of the debugfs file can just as easily call internal functions as the ioctl/property code, so I think we can be covered that way too. I guess we'll have to check out Todd's latest patches when he posts them. Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
