On 10/31/2012 07:59 PM, Grant Likely wrote: >> Pin direction currently needs to be set up separately, analogous to >> requesting gpios. Need to document this better, right. The assumption is >> that I/O needs to be efficient primarily, before bloating the API with >> direction functions. Or should I add functions for this? > > Since this is a userspace facing ABI, once it is merged it cannot be > changed in an incompatible way. I cannot merge it until there is at > least a plan for how to handle all of the reasonable use cases. That > means it must support set/clear or mask operations. Also, if it sticks > with the design of grouping pins from multiple controllers, then it > needs to handle explicitly constraining what order operations are > performed in at the time of the operation. At the time of setup > doesn't work since constraints between pins may not always be in the > same order. > > I really think you should consider implementing a command stream type > of interface.
Yes, understand. What do you consider a good example of a command stream type interface? Link or hint appreciated! There was already mentioned the idea of a device node which can be interfaced to via ioctl() for the various operations. Can it be a "struct miscdevice" or do you require sth. more sophisticated? Thanks in advance, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/