From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753202AbdBGJ0s (ORCPT ); Tue, 7 Feb 2017 04:26:48 -0500 Received: from regular1.263xmail.com ([211.150.99.140]:48415 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753285AbdBGJ0L (ORCPT ); Tue, 7 Feb 2017 04:26:11 -0500 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: zhangqing@rock-chips.com X-FST-TO: linux-kernel@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: zhangqing@rock-chips.com X-UNIQUE-TAG: <5f124f5d9dcdfacb4fce8fcd05ef3e47> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <589991EB.9090501@rock-chips.com> Date: Tue, 07 Feb 2017 17:22:51 +0800 From: Elaine Zhang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ulf Hansson CC: Feng Xiao , Heiko Stuebner , "Rafael J. Wysocki" , Kevin Hilman , Pavel Machek , Len Brown , Greg Kroah-Hartman , "linux-pm@vger.kernel.org" , Tao Huang , xxx@rock-chips.com, Caesar Wang , "open list:ARM/Rockchip SoC..." , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases References: <1484878893-25270-1-git-send-email-zhangqing@rock-chips.com> <58842848.5090806@rock-chips.com> <5896F1A5.9080405@rock-chips.com> <589925B7.4020009@rock-chips.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/07/2017 04:19 PM, Ulf Hansson wrote: > [...] > >>> >>> >>> Unfortunate, I am still not fully understanding the scenarios. As you >>> indicate, the problem seems related to wakeup settings. >>> >>> Could you please try to answer the below questions, hopefully it helps >>> me to better understand. >>> >>> 1) >>> While starting the system suspend sequence, under what circumstances >>> are you expecting the vdd_gpu and pd_gpu to be powered on? >>> >> >> I don't want to power on the vdd_gpu and pd_gpu during the system suspend >> sequence. >> I hope the pd_gpu and vdd_gpu power on/off just by gpu device. > > Let me rephrase my question. > > Can the vdd_gpu/pd_gpu ever remain in a powered on state while the > system is suspended? > NO, the vdd_gpu/pd_gpu ever remain in a powered off state while the system is suspended. > If yes, when is that the case? > >> >>> 2) >>> While starting the system suspend sequence, under what circumstances >>> are you expecting the vdd_gpu and the pd_gpu to be powered off? >>> >> >> I don't want to power off the vdd_gpu and pd_gpu during the system suspend >> sequence. >> Because before the system suspend,the vdd_gpu and pd_gpu has been power off >> by gpu device(pm_ruantime_put). > > *Exactly*, how do you guarantee that a pm_runtime_put() for the gpu > device triggers a runtime suspend - before a system suspend sequence > starts? > > For example, userspace may via sysfs prevent runtime suspend for any > device with runtime PM enabled. > Yes, you are right.I did't consider this. Whether on or off pd_gpu, the vdd_gpu is must be enabled.How to deal with the enable/disable the vdd_gpu? our process in devices/platform/ff9a0000.gpu: device init pm_runtime_enable() gpu_power_on regulator_enable(vdd_gpu) pm_runtime_get_sync(pd_gpu) gpu_power_off pm_runtime_put_sync(pd_gpu) regulator_disable(vdd_gpu) device remove pm_runtime_disable() >> >>> 3) >>> What devices are attached to vdd_gpu? >>> >> just pd_gpu >>> >>> 4) >>> What devices are attached to pd_gpu? >>> >> just gpu device(mali driver) >> >> vdd_gpu >> ------- pd_gpu >> ----------------devices/platform/ff9a0000.gpu >>> >>> > > Thanks for these details, very useful! > > [...] > > Kind regards > Uffe > > >