Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdF0H7R (ORCPT ); Tue, 27 Jun 2017 03:59:17 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:34632 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbdF0H7J (ORCPT ); Tue, 27 Jun 2017 03:59:09 -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: Tue, 27 Jun 2017 15:59:02 +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: 3080 Lines: 64 On 26 June 2017 at 06:19, Linus Walleij wrote: > On Wed, Jun 21, 2017 at 10:10 AM, Baolin Wang wrote: >> 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. > > I don't really mean you should select the "sleep" state. > > I meant, as part of setting the "default" state or even the "init" > state, we would inspect the "sleep" state, use those settings, and > program them into the registers at this early point. I understood your points. But we can not program all into the registers at one early point, sometimes these sleep-related configs need depend on some conditions in users' drivers, like on condition 1: driver need to set one pin as input-enable when specified system goes into deep sleep, on condition 2: driver need set this pin as output-enable when specified system goes into deep sleep. So I still think it is better if we introduce some standard sleep related configs. > > Then never touch the registers again, and never really go to the > sleep state by software, just by hardware. > > Yours, > Linus Walleij -- Baolin.wang Best Regards