Dear Mika, On Wed, 20 May 2015 19:34:22 +0800 Jisheng Zhang <jszhang@xxxxxxxxxxx> wrote: > Dear Mika, > > On Tue, 19 May 2015 16:15:16 +0300 > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > On Tue, May 19, 2015 at 08:32:42PM +0800, Jisheng Zhang wrote: > > > > I can see that this fixes the issue with the platform driver (as the > > > > platform bus core doesn't power on the device automatically as opposed > > > > to other buses, like PCI). However, I'm thinking that can we do better > > > > here. > > > > > > > > Instead of powering the device on again, can't we leave it in low power > > > > state? Recently added 'dev->power.direct_complete' may be used to > > > > achieve that, I think. > > > > > > how to handle runtime suspended via just being clock gated? > > > > As far as I can tell driver's suspend hook does the clock gating so why > > would you need to handle it differently? Once the device is runtime > > suspended, it is both clock and power gated depending on the platform. > > Sorry for confusion. Considering one platform which doesn't support power off > the i2c host but it can disable the host's clock. So in such platform, when > the host is runtime suspended, its clock is disabled, then i2c_dw_disable() will > hang when s2ram. Except using the runtime pm API to ensure the host is in > a correct state, is there any other solution? AFAIK, 'dev->power.direct_complete' > doesn't help such case. I misunderstood the direct_complete flag usage. I think it can help such case will investigate and provide new patch if necessary. Thanks a lot -- 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
