From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752851AbbETMJS (ORCPT ); Wed, 20 May 2015 08:09:18 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:6061 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbbETMJQ (ORCPT ); Wed, 20 May 2015 08:09:16 -0400 Date: Wed, 20 May 2015 20:05:40 +0800 From: Jisheng Zhang To: Mika Westerberg , CC: , , Subject: Re: [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm Message-ID: <20150520200540.58b1230b@xhacker> In-Reply-To: <20150520193422.73de7d90@xhacker> References: <1431693099-2292-1-git-send-email-jszhang@marvell.com> <20150518082823.GH1490@lahna.fi.intel.com> <20150519203242.74617ad6@xhacker> <20150519131516.GO1490@lahna.fi.intel.com> <20150520193422.73de7d90@xhacker> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-20_03:2015-05-19,2015-05-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505200158 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Mika, On Wed, 20 May 2015 19:34:22 +0800 Jisheng Zhang wrote: > Dear Mika, > > On Tue, 19 May 2015 16:15:16 +0300 > Mika Westerberg 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