Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp3202237img; Mon, 25 Mar 2019 05:57:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqxpFOAolTyP5qwDvnM8s/A1u8I2IF2pIylTioii8OeA73hT6N6iEmb5EGaN6VOHh0ILQHjK X-Received: by 2002:a63:3dc8:: with SMTP id k191mr6574106pga.286.1553518655616; Mon, 25 Mar 2019 05:57:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553518655; cv=none; d=google.com; s=arc-20160816; b=kQZ2Fj6guIdMlay08AUeQoZjQeVcbaKMmUjyVH8f8LrCcnwrjBcHL3T7kVNYg+wjl4 ZbxJyjFAfqalCRLRso0L+wCTEf9g6A6D3NithBPzK62/Z3SZd0PR4On7FvijvkGuL2ma X11QeYoC1LTuPkG7GAfx5AVMu6IXe7rr4d5SV6c/v2JRXeXO70avmZYLvC2q8CaO0l06 ScZVgXvz62fU9FfcWHN4haEB0rM4872854INTcTcuNSnMEf4WIYPh0l2/yr1Tz5rnyIj R54+sIC9hbd0X8eh4w2dK+0l2/cQTJvQXkRnvV0uGSraN0ni9bAp7RAN9ZF0H0PFhZdd PWBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TYzr5buvYg8A39gMPuKUSTTVfE4d8QM2AKqAE4mmoNA=; b=sqRJ8jx86DspbtenPU0iE9u5J2cykDRWz4QXzkSJjJeuK5C6uPO1I+4B6lSYrccKii nEcTaPjv1VK+MAJ2UcFUbKvCzTzGxs/fiCrk4pY3SMUmyxKHq2NGtlHxVegLYR2SHxcu 4/9V1LpEU+kxaLA727J7LGMzabYhMIA480FZBxwPl32Lg+gGuSvKOeIN9X/tLLvzV06c JW9oc/ODRfOuC+s9BQ9Dpe2swX2EXR4DdrmTVSLH8X16m0gjI/flxro7A6O0+xE5l+Zx /PLFlhyjIsff3qRVMj7EK+OSlSo88mbdzykxw0PttCd2UljrDky2vjwr5/azUuyNt/FX djWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=p6oQgsJ9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u20si13359522pga.71.2019.03.25.05.57.20; Mon, 25 Mar 2019 05:57:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=p6oQgsJ9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731279AbfCYM4p (ORCPT + 99 others); Mon, 25 Mar 2019 08:56:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:41270 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730889AbfCYM4p (ORCPT ); Mon, 25 Mar 2019 08:56:45 -0400 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB25620989; Mon, 25 Mar 2019 12:56:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553518603; bh=BKKTT753ARlZk/4IjdlC0bQRP/dJMnxRJWEhf3CQTSs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=p6oQgsJ9GZcEfxaVhPN7DWP6gsZFfDmT9x/5Ftl1E+aN8sAd/9uEfEgs/n2H/xK/a kWsKfgmrfW8XvTGqCaSkQQVQgzQtBqlplCeLSJ6EZskt1cP4lr7WHvpVp7XmjTRhXc X1/nRIrKiF2QOgisCPnCZeTur4q6Ml3OJPuGq5Aw= Received: by mail-lj1-f182.google.com with SMTP id f18so7699479lja.10; Mon, 25 Mar 2019 05:56:42 -0700 (PDT) X-Gm-Message-State: APjAAAWcfgSNgky4MDsk/3R4bQCQp8QABZcBCEkUsec+70xZQF3QN+O9 N1VCxXVK/Z+xSL3cEazJ6PtNiBhTLmEvZXWtJ9U= X-Received: by 2002:a2e:7206:: with SMTP id n6mr13225979ljc.112.1553518601013; Mon, 25 Mar 2019 05:56:41 -0700 (PDT) MIME-Version: 1.0 References: <20190324083256.1047-1-linux.amoon@gmail.com> In-Reply-To: From: Krzysztof Kozlowski Date: Mon, 25 Mar 2019 13:56:29 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] ARM: dts: exynos: Add proper regulator states for suspend-to-mem for odroid-u3 To: Anand Moon Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "linux-samsung-soc@vger.kernel.org" , linux-kernel@vger.kernel.org, Rob Herring , Kukjin Kim , Marek Szyprowski , Chanwoo Choi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 Mar 2019 at 13:46, Krzysztof Kozlowski wrote: > > On Sun, 24 Mar 2019 at 09:33, Anand Moon wrote: > > > > Add suspend-to-mem node to regulator core to be enabled or disabled > > during system suspend and also support changing the regulator operating > > mode during runtime and when the system enter sleep mode (stand by mode). > > > > Cc: Marek Szyprowski > > Cc: Krzysztof Kozlowski > > Cc: Chanwoo Choi > > Signed-off-by: Anand Moon > > --- > > Current patch: > > > > Note: Both microSD and eMMC suspend resume works this changes at my end. > > > > regulator-off-in-suspend: > > set the regulator node into suspend state i.e. standby mode during suspend > > operation. > > > > Current changes are based on > > [0] https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/max77686.txt > > > > Regulators which can be turned off during system suspend: > > -LDOn : 2, 6-8, 10-12, 14-16, > > -BUCKn : 1-4. > > Use standard regulator bindings for it ('regulator-off-in-suspend'). > > > > drop the suspend off binding which are not supported by the driver. > > > > RFC version > > [1] https://patchwork.kernel.org/patch/10810909/ > > These changes had some problem with eMMC not entering into suspend mode. > > with some miss configuration in regulator-off-in-suspend mode. > > > > Changes from previos patch. > > [2] https://patchwork.kernel.org/patch/10712549/ > > > > Set all the non used regulator in suspend-odd state > > LD02, LD03, LD05, LD06, LD07, LD011, LD013, LDO14, LD016 > > > > BUCK5, BUCK6, BUCK7 and not confirable as per driver max77686-regulator > > --- > > .../boot/dts/exynos4412-odroid-common.dtsi | 39 +++++++++++++++++++ > > 1 file changed, 39 insertions(+) > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > > index 08d3a0a7b4eb..375156ad5454 100644 > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi > > @@ -288,6 +288,9 @@ > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > regulator-always-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > Please maintain proper versioning of patches. > First patch sent to lists should be either RFC or v1. Second > release/submission is then always v2. Third v3. > > This is third or fourth submission but you marked it as v1. This makes > it very difficult to discuss and reference previous versions. > > The commit message did not change since beginning (first version). I > asked twice that you need to explain exactly why you put the the > regulator to off or on state in suspend. Why? > Because: > 1. This change looks without justification - once you put on, then you > put off, now again on, > 2. Anyone reading the code later must know the rationale why this was done, > 3. I am not quite sure whether this is good setting so I would be > happy to be convinced. > > How to provide such explanation? The best in commit message. Sometimes > in the comment in the code, depends. > How such explanation could look like? For example like this: > f8f3b7fc21b1 ("ARM: dts: exynos: Fix regulators configuration on Peach > Pi/Pit Chromebooks") > Marek clearly explained why he put the regulators "always-on", even > tough we do not know everything about this. More over, he mentions > that this fixes specific issue. > > Summarizing, please answer: > 1. Why this is made off-in-suspend? > 2. Why this can be made off-in-suspend? > > > + }; > > }; > > > > ldo3_reg: LDO3 { > > @@ -317,6 +320,9 @@ > > regulator-min-microvolt = <1000000>; > > regulator-max-microvolt = <1000000>; > > regulator-always-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo7_reg: LDO7 { > > @@ -324,18 +330,27 @@ > > regulator-min-microvolt = <1000000>; > > regulator-max-microvolt = <1000000>; > > regulator-always-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo8_reg: LDO8 { > > regulator-name = "VDD10_HDMI_1.0V"; > > regulator-min-microvolt = <1000000>; > > regulator-max-microvolt = <1000000>; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo10_reg: LDO10 { > > regulator-name = "VDDQ_MIPIHSI_1.8V"; > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo11_reg: LDO11 { > > @@ -343,6 +358,9 @@ > > regulator-min-microvolt = <1800000>; > > regulator-max-microvolt = <1800000>; > > regulator-always-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo12_reg: LDO12 { > > @@ -351,6 +369,9 @@ > > regulator-max-microvolt = <3300000>; > > regulator-always-on; > > regulator-boot-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo13_reg: LDO13 { > > @@ -367,6 +388,9 @@ > > regulator-max-microvolt = <1800000>; > > regulator-always-on; > > regulator-boot-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo15_reg: LDO15 { > > @@ -375,6 +399,9 @@ > > regulator-max-microvolt = <1000000>; > > regulator-always-on; > > regulator-boot-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo16_reg: LDO16 { > > @@ -383,6 +410,9 @@ > > regulator-max-microvolt = <1800000>; > > regulator-always-on; > > regulator-boot-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > > > ldo20_reg: LDO20 { > > @@ -421,6 +451,9 @@ > > regulator-max-microvolt = <1100000>; > > regulator-always-on; > > regulator-boot-on; > > + regulator-state-mem { > > + regulator-off-in-suspend; > > + }; > > }; > > I questioned this change two times. You did not answer to my > question... If you turn memory bus regulator off, how the memory will > work in Suspend-to-Memory mode? I might be missing here something but > it just looks suspicious. Maybe the regulator does not supply the > memory itself (so refresh works even when it is down), just the > interface? I don't know, it just looks suspicious. I need to see > proper explanation. > > I am sorry but I will not check other hunks in this patch. Please > provide the answers for all my questions here first. I started digging around this and datasheet describes the regulator values in sleep mode. The MIF can be off if C2C is not used. It seems that the memory refresh is provided by CKEM regulators (which you wanted to turn off in first version of the patch). I am not happy that I ask about such information and cannot get it. It is the job of submitter to provide rationale. Best regards, Krzysztof