OMAP2+: optional clock handling fixes
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] OMAP2+: optional clock handling fixes
Quoted 16 lines · Paul Walmsley
Hi Rajendra,
Quoted 11 lines · Rajendra Nayak
The patches fix some opt clock handling in gpio and in hwmod.
Rajendra Nayak (2):
gpio: omap: prepare and unprepare the debounce clock
ARM: OMAP2+: hwmod: Don't leave the optional clocks in
clk_prepare()ed statearch/arm/mach-omap2/omap_hwmod.c | 13 ++----------- drivers/gpio/gpio-omap.c | 10 +++++----- 2 files changed, 7 insertions(+), 16 deletions(-)
Quoted 6 lines
Can these patches be merged separately? Looks to me that the two options are either to:
A. to merge them together, or
B. to merge patch 1 first, then patch 2
Thats right.
Quoted 2 lines
Or will things break if only patch 1 is merged?
Things will break if only patch 2 is merged as gpios clk_enable() request would fail. Merging only patch 1 has no issues.
Quoted 8 lines
If we merge them together, I'd say the best situation would be to take them through the OMAP tree, since the changes are all OMAP-specific. In that case we'll want an ack for the first patch from the GPIO maintainers, Linus Walleij <[email protected]> and Alexandre Courbot <[email protected]>.
Quoted 7 lines
Otherwise the path of least resistance would be (B) - you can get patch 1 merged via the GPIO tree. The GPIO maintainers can then provide a stable branch for us to base our changes on, or we can wait until the change reaches Linus. Then we can subsequently merge patch 2 via the OMAP side.
Thoughts?
I am fine either way. I will check with Linus W. what he prefers. Thanks.
regards,
Rajendra
Quoted 4 lines
- Paul