On Wed, Oct 31, 2012 at 8:30 PM, Mark Brown <broo...@opensource.wolfsonmicro.com> wrote: > On Wed, Oct 31, 2012 at 04:00:17PM +0100, Grant Likely wrote: > >> For the API, I don't think it is a good idea at all to try and >> abstract away gpios on multiple controllers. I understand that it >> makes life a lot easier for userspace to abstract those details away, >> but the problem is that it hides very important information about how >> the system is actually constructed that is important to actually get >> things to work. For example, say you have a gpio-connected device with >> the constraint that GPIOA must change either before or at the same >> time as GPIOB, but never after. If those GPIOs are on separate >> controllers, then the order is completely undefined, and the user has >> no way to control that other than to fall back to manipulating GPIOs >> one at a time again (and losing all the performance benefits). Either >> controller affinity needs to be explicit in the API, or the API needs >> to be constraint oriented (ie. a stream of commands and individual >> commands can be coalesced if they meet the constraints**). Also, the >> API requires remapping the GPIO numbers which forces the code to be a >> lot more complex than it needs to be. > > It feels like I'm missing something here but can we not simply say that > if the user cares about the ordering of the signal changes within an > update then they should be doing two separate updates? Most of the > cases I'm aware of do things as an update with a strobe or clock that > latches the values. > > The big advantage of grouping things together is that it means that we > centralise the fallback code.
The internal ABI is less of an issue because it is a whole lot easier to change compared to a userspace ABI (though I think we can do a lot better before deciding to merge it). Userspace also appears to be the intended usage, so I've focused my review on that use case. g. -- 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/
