From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753119AbbETLiI (ORCPT ); Wed, 20 May 2015 07:38:08 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:26368 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751849AbbETLiE (ORCPT ); Wed, 20 May 2015 07:38:04 -0400 Date: Wed, 20 May 2015 19:34:22 +0800 From: Jisheng Zhang To: Mika Westerberg , CC: , , Subject: Re: [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm Message-ID: <20150520193422.73de7d90@xhacker> In-Reply-To: <20150519131516.GO1490@lahna.fi.intel.com> 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> 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-1505200151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > Currently the only solution is using the runtime pm apis to ensure the > > device is in a working state during s2ram. What's your opinion? > > Well, it sounds a bit silly to resume the device just because you want > to call i2c_dw_disable() for it before suspending again ;-) > Agree. But it's the only solution I know so far. > At least, it would be nice to check if we can keep it runtime suspended > with the help of 'dev->power.direct_complete'. If not possible, then I > suppose your patch is sufficient. Thanks, Jisheng