OMAP: GPIO: Use PM runtime framework
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest posting 4/40 of 7 patches 0 repliesNew
- v2 posting 3/40 of 7 patches 0 repliesSuperseded
- v2 posting 2/40 of 7 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v2 posting 1/4 | 0 of 7 patches | 0 replies | Superseded |
Patches in v2 posting 4/4 No applies recorded yet
None of the 7 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [v2 0/7] OMAP: GPIO: Use PM runtime framework
Linus Walleij <[email protected]> writes:
[...]
Quoted 8 lines
For TI I guess this currently means you simply cannot work on GPIO stuff until you know where to go with it unless you allow the OMAP GPIO authors to keep churning in
arch/arm/*...That's unless Grant is OK with us moving stuff into
drivers/gpiothat does *not* use gpiolib and utilize singletons to get at thegpio_chipaddresses (i.e. current form) and keep it churning like that until it can be refactored.
The churn will happen one way or another. the only question is whether it happens in drivers/gpio or arch/arm/*.
Grant, what's your feeling here. How much ugliness are you willing to tolerate in a bulk move to drivers/gpio. At least for OMAP, I am personally be working on the cleanup/move so I can work either way, although I know Tony has an obvious preference for moving it to drivers/gpio. :)
The OMAP driver is already using gpiolib. The main ugliness in the OMAP driver is the awful ifdeffery used to handle the differences across the various SoCs in the OMAP family. I've already got most of that cleaned up[1].
Kevin