start phasing out legacy GPIO calls
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest4 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | remove omap_set_gpio_dataout() and omap_get_gpio_datain()Documentation/ arch/ arch/ +37 more | +161 | 0 replies | |
| 2/4 | use gpio_direction_input()arch/ arch/ arch/ +19 more | +32 | 0 replies | |
| 3/4 | remove omap_set_gpio_direction()arch/ arch/ arch/ +21 more | +50 | 2 replies | |
| 4/4 | use gpio_to_irq()arch/ arch/ arch/ +15 more | +58 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [patch 2.6.27-omap-git 0/4] 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