Kevin, On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >> So I guess in this case the truly correct way to handle it is: >> >> 1. i2c controller should have Runtime PM even though (as per the code >> now) there's nothing you can do to it to save power under normal >> circumstances. So the runtime "suspend" code would be a no-op. >> >> 2. When the i2c controller is told to runtime resume, it should >> double-check if a full SoC poweroff has happened since the last time >> it checked. In this case it should reinit its hardware. >> >> 3. If the i2c controller gets a full "resume" callback then it should >> also reinit the hardware just so it's not sitting in a half-configured >> state until the first peripheral uses it. >> >> If later someone finds a way to power gate the i2c controller when no >> active transfers are going (and we actually save non-trivial power >> doing this) then we've got a nice place to put that code. >> >> NOTE: Unless we can actually save power by power gating the i2c >> peripheral when there are no active transfers, we would also just have >> the i2c_xfer() init the hardware if needed. Maybe that's kinda gross, >> though. > > Yes, this is how we manage the i2c controller on OMAP. > > Essentially, between every xfer, the hw is disabled and can potentially > lose context, so eveery xfer requires a hw init. We use the runtime PM > "autosuspend" feature so that it stays alive for X milliseconds so > bursty i2c xfers are not punished. > > Have a look at drivers/i2c/busses/i2c-omap.c. > > You'll notice there are not callbacks for system suspend/resume, it's > only doing runtime PM. OK, cool! That might be a bit too aggressive of a change for what I can take on right now. I've filed http://crbug.com/388007 to see if Samsung can take a look at this. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
