Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932346AbdHWQFc (ORCPT ); Wed, 23 Aug 2017 12:05:32 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:58536 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932103AbdHWQFa (ORCPT ); Wed, 23 Aug 2017 12:05:30 -0400 Date: Wed, 23 Aug 2017 11:05:28 -0500 From: Kim Phillips To: Leo Yan Cc: Mathieu Poirier , Jonathan Corbet , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] doc: coresight: correct usage for '/dev/cpu_dma_latency' Message-Id: <20170823110528.ba272128cde46f40c71241cc@arm.com> In-Reply-To: <1503472998-9009-1-git-send-email-leo.yan@linaro.org> References: <1503472998-9009-1-git-send-email-leo.yan@linaro.org> Organization: Arm X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1361 Lines: 34 On Wed, 23 Aug 2017 15:23:18 +0800 Leo Yan wrote: > Cc: Kim Phillips > Reported-by: Kim Phillips Thanks; typically only the latter is needed. > Set latency request to /dev/cpu_dma_latency to disable all CPUs specific idle > -states (if latency = 0uS then disable all idle states): > -# echo "what_ever_latency_you_need_in_uS" > /dev/cpu_dma_latency > +states (if latency = 0uS then CPU Idle governor selects idle state0, so this > +means 'WFI' is still enabled but other deeper states have be disabled, this > +can avoid power off CPUs): > +# exec 3<> /dev/cpu_dma_latency; echo "what_ever_latency_you_need_in_uS" >&3 not a fan of the "what_ever_latency_you_need_in_uS" (including and especially the quotes which can create ambiguity in the user's mind): just put a cut-n-pasteable example, clarifying the typically-default value you chose, and its unit, in the text. More to the point, how did you test this? Are you sure that that the value being echoed isn't being interpreted as a binary number? kernel/power/qos.c:pm_qos_power_read() looks to be looking for a 32-bit binary integer, but I'm not sure if that's where it gets read. Certainly, this 2013 article uses a C example to write a binary integer: https://access.redhat.com/articles/65410 Please double-check, thanks, Kim