I2C big cleanup
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v8 Latest posting 4/40 of 23 patches 0 repliesNew
- v8 posting 3/40 of 23 patches 0 repliesSuperseded
- v8 posting 2/40 of 23 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v8 posting 1/4 | 0 of 23 patches | 0 replies | Superseded |
Patches in v8 posting 4/4 No applies recorded yet
None of the 23 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v8 yet.
Cover letter [PATCHv8 00/23]I2C big cleanup
Quoted 25 lines · Felipe Balbi
Hi,
Quoted 22 lines · Kevin Hilman
Quoted 2 lines · Kevin Hilman
Kevin Hilman <[email protected]> writes:
[...]
Quoted 15 lines
Quoted 6 lines
Sorry to be late to the party (again), but still catching up after some time off.
Unfortunately, this series causes PM regressions on several OMAP platforms. I hope we can hold off on this until those issues are addressed.
I tracked the regression down to [PATCHv8 21/22] (see reply there.)
Since this series is already merged, I suggest that the problem patch be reverted, at least for v3.7 and until the problem is better understood and tested.
With that patch reverted, all my PM tests are passing. Feel free to add:
Quoted 8 lines
Quoted 5 lines
OK, the i2c series is off the hook.
Felipe and I spent a little time tracking this down. Felipe suggested that there might be a driver with periodic i2c activity keeping I2C awake, and thus preventing CORE retention. He was right.
FYI, the original idea came from Shubhro. We agreed that would be the only way i2c would be prevented from idling.
Great, thanks Shubhro!
Also, FYI, I just submitted a patch to the TWL RTC driver which was the source of all the I2C activity since it's on the I2C-connected PMIC.
Thanks for the help and suggestions,
Kevin
[1] https://groups.google.com/forum/#!topic/rtc-linux/sFbYmAzCRLQ