From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932424AbcIBOXm (ORCPT ); Fri, 2 Sep 2016 10:23:42 -0400 Received: from regular1.263xmail.com ([211.150.99.141]:56840 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932261AbcIBOXh (ORCPT ); Fri, 2 Sep 2016 10:23:37 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: xzy.xu@rock-chips.com X-FST-TO: zhengsq@rock-chips.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: xzy.xu@rock-chips.com X-UNIQUE-TAG: <30ed43b8ae5b6dedc8087c6fa797982e> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 2/2] arm64: dts: rockchip: add eMMC's power domain support for rk3399 To: Ulf Hansson , Doug Anderson References: <20160827134103.28160-1-xzy.xu@rock-chips.com> <20160827134103.28160-3-xzy.xu@rock-chips.com> <2ab8ab94-fa4d-2cd6-5805-a92ac5f9697e@rock-chips.com> <57C3A30B.5080707@rock-chips.com> <77f5cff1-80a2-76b3-40e9-f77caced2257@rock-chips.com> <12451b81-321e-b661-8f1c-25c91bffba54@rock-chips.com> Cc: Shawn Lin , =?UTF-8?Q?Heiko_St=c3=bcbner?= , Mark Rutland , "devicetree@vger.kernel.org" , Xing Zheng , "open list:ARM/Rockchip SoC..." , Frank Wang , Catalin Marinas , Elaine Zhang , Will Deacon , "linux-kernel@vger.kernel.org" , Brian Norris , Masahiro Yamada , Rob Herring , David Wu , Caesar Wang , Jianqun Xu , "linux-arm-kernel@lists.infradead.org" , Shunqian Zheng From: Ziyuan Xu Message-ID: <10dfff58-88b2-a397-ef2e-9cd451253c40@rock-chips.com> Date: Fri, 2 Sep 2016 22:23:15 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ulf, On 2016年09月02日 18:24, Ulf Hansson wrote: > On 1 September 2016 at 23:50, Doug Anderson wrote: >> >Hi, >> > >> >On Thu, Sep 1, 2016 at 6:45 AM, Ulf Hansson wrote: >>> >>I was reading the discussion regarding this change and browsing the DT >>> >>documentation around this... Can you guys explain what really goes on >>> >>here, please. >>> >> >>> >>To me, it seems like you are managing one device's resources in one >>> >>separate genpd. One genpd per device. Is that correct? >>> >> >>> >>Perhaps each device actually has its own PM domain and thus it makes >>> >>sense to assign one genpd per device? >> > >> >I'm not as familiar with genpd as I should be, so hopefully this makes sense. >> > >> >...in hardware there is a "pd_emmc" that is the power domain for just >> >eMMC. That will be referenced hooked up via device tree, like: >> > >> >power-domains = <&power RK3399_PD_EMMC>; > Yes, I noticed that and this is what puzzles me a bit. > >> > >> >I believe that means that power will automatically be removed whenever >> >the device is runtime suspended or suspended. > Well, it depends if the genpd has a subdomain or other devices in it > being runtime resumed. > The genpd will not power off unless all devices within it are runtime > enabled+suspended and that its subdomains are also powered off. > > So, in case you only have one device and no subdomains, then your > statement is correct. Yup, pd_emmc is a individual power domain which is only deployed to eMMC on rk3399. It has no subdomains. > >> > >> >If w're not supporting "autosuspend" and nobody is tweaking anything > I guess you mean runtime PM autosuspend? Then why don't you support this? > > Wouldn't that allow you to avoid wasting power in runtime when the > device is idle? pd_emmc manages the sdhci controller, phy and corecfg_* stuff, if we support autosuspend in driver, we have to re-init context. I didn't test the latency, if it's acceptable, we will apply it.:-) But it's not a blocker, right? > >> >manually, then it's possible (I think) that runtime suspend happens at >> >exactly the same time as suspend. ...but my point was that it was > I am not sure I follow you here. You must not rely on that the device > always becomes runtime suspended during system suspend, as there are > no guarantees for this. > > Instead that is something you need to take care of in the > subsystem/driver for the device, of course. > >> >cleaner to actually do it any restoring in the "runtime resume" hooks >> >to match what genpd does. This matches what you say: use runtime PM. > Yes! > > Using genpd without deploying runtime PM for the devices doesn't make > much sense, at least to me. > >> > >> >...but it also sounds like it might not be terribly important to >> >restore these values since they're a bit silly to begin with. If >> >that's true then I guess we don't need to do anything special here. >> > >> > >> >Did that all make sense (it's entirely possible it didn't since >> >somehow my brain still hasn't absorbed all runtime PM and genpd >> >concepts) > No worries. I understand this might be a bit tricky, that's why I also > tries to help review related changes. > > Kind regards > Uffe > > >