start phasing out legacy GPIO calls

Following this are four patches matching $SUBJECT:

- remove omap_set_gpio_dataout() and omap_get_gpio_datain() ... same call syntax, different name, minor code shrink
- use gpio_direction_input()
... minor call syntax change, otherwise not interesting
- use gpio_direction_output(), remove omap_set_gpio_direction() ... different call syntax and initialization model
- use gpio_to_irq()
... at least, outside of static initializers

The third patch might conceivably make trouble; see the patch comments. Ditto the fourth, but IMO that's less likely.

I did test builds for OMAP1, OMAP2420, OMAP2430, and OMAP3430, and tried to make sure all the files affected by this patch got rebuilt. The build breakage was mostly related to McBSP and iomem pointers; nothing affected by these patches.

Two remaining OMAP GPIO calls can be removed a bit later:

	int omap_request_gpio(int gpio);
	void omap_free_gpio(int gpio);

Once that's done, I think it'll be time to move the GPIO code into mach-omap1/mach-omap2 ... the OMAP2/OMAP3 stuff in particular should become a LOT simpler.

- Dave

Hi David

Did you know what? I was doing something like similar conversion patches just few days ago but didn't find yet time to finalize them and fix arch/arm/plat-omap/gpio.c for omap_[request | free]_gpio :-)

My set was basically doing all gpiolib conversions in one patch and the set was grouped so that one patch for all OMAP1 boards (all of them are in mainline), separate patches for couple OMAP2 boards and some random patches for different drivers.

I can add omap_request_gpio/omap_free_gpio conversion patch on top of yours but probably that will go somewhere next week. Useful conversion due label argument in gpio_request :-)

Jarkko

Sounds ... oddly familiar. :)

I've found that splitting such API changes into blatantly obvious chunks that make the same repetitive change is a big win in terms of reviewability and buglessness. The first two patches (get/set, direction_in) show that well. The other two followed naturally from that start, but weren't as brainless. The request/free stuff needed some actual thought, so I deferred it...

Did you find anything wrong with these patches?

The label is handy for auditing /sys/kernel/debug/gpio against board schematics, for sure ... a little cross-checking can be a big help. "Whoops, we must have overlooked <mechanism-X/> ..." Also helps code maintainability a bit, IMO!

I'd split that work in two phases:

- First a set of gpio_chip.request() and gpio_chip.free() hooks to make the standard calls *exactly* like the legacy ones, and replacing the legacy calls with inlined wrappers;

- Then then lots of syntactic changes to use the new calls, providing labels and then removing those wrappers.

If you'd like to do those parts, OK by me. Splitting things out into different gpio_chip flavors can be done in parallel with the second set of patches.

I wasn't planning to touch that stuff for a bit ... like until after Tony merges 2.6.28-rc1 (it's out now) and the $SUBJECT patches into the OMAP tree.

- Dave

Nope. My way was just bit more lazy by doing all changes into one file at once and by separating patches so that it's easier for Tony to get them forward.

Yeah, I'll try to look next week.

Jarkko