From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752542AbcGAHPa (ORCPT ); Fri, 1 Jul 2016 03:15:30 -0400 Received: from mga03.intel.com ([134.134.136.65]:30123 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752498AbcGAHP3 (ORCPT ); Fri, 1 Jul 2016 03:15:29 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,555,1459839600"; d="scan'208";a="727785436" From: Alexander Shishkin To: Mathieu Poirier Cc: Greg KH , Chunyan Zhang , laurent.fert@intel.com, yann.fouassier@intel.com, "linux-kernel\@vger.kernel.org" Subject: Re: [QUEUED v20160630 1/4] stm class: Add runtime power management handling In-Reply-To: References: <1467291374-16587-1-git-send-email-alexander.shishkin@linux.intel.com> <1467291374-16587-2-git-send-email-alexander.shishkin@linux.intel.com> <877fd6snhb.fsf@ashishki-desk.ger.corp.intel.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 01 Jul 2016 10:10:02 +0300 Message-ID: <87ziq1rfzp.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mathieu Poirier writes: > On 30 June 2016 at 09:30, Alexander Shishkin > wrote: >> Mathieu Poirier writes: >> >>> On 30 June 2016 at 06:56, Alexander Shishkin >>> wrote: >>>> Currently, there's no runtime pm in stm class devices, which makes it >>>> harder for the underlying hardware drivers to handle their power >>>> management. >>>> >>>> This patch applies the following runtime pm policy to stm class devices, >>>> which their parents can rely on for their power management tracking: >>>> >>>> * device is in use during character device writes, >>>> * delayed autosuspend is used to keep it active between adjacent >>>> writes, >>>> * device is in use while mmio regions are mapped, >>>> * device is is use while any stm_source devices are linked to it. >>>> >>>> Signed-off-by: Alexander Shishkin >>>> Cc: Mathieu Poirier >>>> Cc: Chunyan Zhang >>> >>> Coresight power management on my Juno board (the only device with an >>> STM I have access to) is broken and as such, can't test if this code >>> does what is intended. But theoretically it looks good. >> >> Thanks for taking a look. >> >>> Throughout the driver, wouldn't it be better to use >>> pm_runtime_put_sync() rather than autosuspending with a hard coded >>> value? >> >> Yeah, the autosuspend is for the char write()ers that are likely to send >> multiple consequent write()s, so that we don't have to go in and out of >> suspend every time that happens. >> > > Yes, it's a trade off. Please add a comment in stm_register_device() > that explains the usage of the autosuspend functions and the choice of > '2000' value. Will do. The 2000 is arbitrary, but it has to be configurable from a sysfs attribute and I thought that's a start as good as any. > Thanks, > > Reviewed-by: Mathieu Poirier Thanks, -- Alex