On Thursday 18 December 2008, Jani Nikula wrote: > On Tue, 2008-12-16 at 11:35 +0530, ext Trilok Soni wrote: > > > OK, I found other guys (android ??) using such home brew frameworks. > > Time to write a switch framework. > > To start a discussion on what such a GPIO switch framework should be > like if someone were to write it, here's a list of the kind of things > I'd like to see in it (mostly from gpio-switch.c): > > * Based on or integrated in the gpiolib. As noted earlier: such a thing should be a "switch" framework, with "gpio" just on implementation. Not every switch will be implemented as a GPIO. > * Dynamically changeable notification callbacks in kernel. Not clear what this means. Reconfigure the switch type on the fly? I'm not a big fan of the event namespace which <linux/notifier.h> defines, I hope that's not what is meant here ... though maybe its callback model is OK, adding and removing callbacks is easy enough. Current OMAP gpio-switch has a single callback, and that might be part of the problem. Linux has a single callback for things like timers and request completions; but these switches have different lifecycle model. Decoupling caller/switch and callee(s)/callbacks() may provide a better model. > * Sysfs notifications to userspace. Why sysfs in particular, rather than some /dev/input/* event channel? Note that input devices already decouple the event reporters and event receivers fairly well. > * Debouncing for the notifications to filter spurious events. > > * Dynamically adjustable debounce timeouts. Debouncing might not be a framework issue; at first thought, it seems like something the GPIO glue into that framework might need to handle. > * Arbitrary names for the GPIOs in sysfs instead of (or in addition to) > the gpiolib style "gpioN". This mostly sounds to me like an input device... Except maybe for the notion that in-kernel software needs to be responsive to the events too. I seem to recall "push those policies to userspace" arguments cropping up in similar cases. (My two cents: kernel is full of policy, sometimes reconfigurable; easy to believe system integrity can require a few more.) > Anything else? I didn't see anything in the Android source that couldn't > be covered with this. The Android stuff seems already split into a class and GPIO glue. (Hence my CC to Mike Lockwood, the author of that drivers/switch code.) Any reason you couldn't use that as-is, maybe after updating it a bit? Add some GPIO debouncing, use input framework not miscdev in the core, different headset issues, etc. - Dave > > > Jani. > > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
