Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752711AbdFUIKr (ORCPT ); Wed, 21 Jun 2017 04:10:47 -0400 Received: from mail-ot0-f176.google.com ([74.125.82.176]:33220 "EHLO mail-ot0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbdFUIKn (ORCPT ); Wed, 21 Jun 2017 04:10:43 -0400 MIME-Version: 1.0 In-Reply-To: References: <359d62c1f2f7ef61c6160df9b60c1af4bfcea89a.1496664241.git.baolin.wang@spreadtrum.com> <20170612060718.GA8566@spreadtrum.com> <20170613031547.GA29679@spreadtrum.com> From: Baolin Wang Date: Wed, 21 Jun 2017 16:10:41 +0800 Message-ID: Subject: Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for Spreadtrum pin controller To: Linus Walleij Cc: Mark Rutland , Rob Herring , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Mark Brown Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1976 Lines: 38 On 20 June 2017 at 17:31, Linus Walleij wrote: > On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang wrote: > >> I forgot one most important reason why we can not use the "sleep" state. As I explained >> above, the sleep related configuration will bind with the pin's sleep mode. If we set the >> pin's sleep mode as AP_SLEEP, then we can select "sleep" state when AP system goes into >> deep sleep mode by issuing "pinctrl_force_sleep()" in pinctrl suspend function. >> >> But if we set the pin's sleep mode as PUBCP_SLEEP and pubcp system doesn't run linux kernel >> (it run another thread OS), then we can not select "sleep" state since the AP system does >> not go into deep sleep mode (AP system run linux kernel OS). > > Allright yes it makes sense, and also there are systems that just go into > "hardware sleep" and just put the pin into some pre-programmed mode. > > I'm a bit back-and-forth. I didn't mean that some code would actually > switch the state to "sleep" when we go to sleep, I meant that when > the system configures "default" mode it should also look up and > program the "sleep" mode, but this approach with a special property > is just another way of achieveing the same thing. > > But then we should add a whole slew of sleep states. > > I was thinking whether we could avoid having a special DT property > by parsing ahead to states we do not currently use and programming > that into the sleep mode registers. Yes, for most scenarios, it can work with the "sleep" state to set sleep-related config. But for our Spreadtrum platform scenario (I do not know if there are other platforms need this feature), we can not select the "sleep" state when pubcp system goes into deep sleep mode but ap system does not go into deep sleep mode. So I think we still need these "sleep-bias-pull-up", "sleep-bias-pull-down", "sleep-input-enable" and "sleep-output-enable" properties. -- Baolin.wang Best Regards