Felipe Balbi <balbi@xxxxxx> writes: [...] >> >This question remains. Why do we need those funtions ? >> >> These functions are called from the CPUIdle path so outside the scope >> of the GPIO driver. These are part of a bunch of nasty PM hacks we >> are doing in the CPU idle loop. We are in the process of getting rid >> of most of them, but it looks like some are still needed. > > Too bad. I can see that the gpio pm implementation seems a bit > "peculiar". I mean, pm does reference counting and yet the driver has > checks to prevent multiple gets and puts on a single bank (meaning that > pm counter will be either 0 or 1 at any point in time). > > To me it looks like those functions are there in order to forcefully put > PER power domain in OFF because drivers are always holding a reference > to their gpios (drivers generally gpio_request() on probe() and > gpio_free() on remove()). > > Looks like the entire pm implementation on OMAP gpio driver has always > considered only the fact that gpios can be requested and freed, but > never that we want the system to go to OFF even while gpios are > requested, because we have I/O PAD wakeups. At some point that has to be > sorted out because that HACK is quite ugly :-) > > I'll see if I find some time to go over the interactions between > gpio-omap.c and pm24x.c and pm34xx.c any of these days, but I can't > promise anything ;-) If you look at the state of these prepare/resume hacks at the end of this series, you'll see that they are significantly cleaner and do nothing but call the runtime PM hooks. We have explored several ways to get rid of them completely in the idle path but have not yet come up with a clean way, but this series gets us a long ways towards that goal. Kevin -- 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
