All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Hao <hao.wu@intel.com>
To: Moritz Fischer <mdf@kernel.org>
Cc: atull@kernel.org, linux-fpga@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	Luwei Kang <luwei.kang@intel.com>,
	Russ Weight <russell.h.weight@intel.com>,
	Xu Yilun <yilun.xu@intel.com>
Subject: Re: [PATCH 14/17] fpga: dfl: fme: add thermal management support
Date: Thu, 4 Apr 2019 07:43:56 +0800	[thread overview]
Message-ID: <20190403234356.GA11098@hao-dev> (raw)
In-Reply-To: <20190403180909.GD5752@archbook>

On Wed, Apr 03, 2019 at 11:09:09AM -0700, Moritz Fischer wrote:
> Hi Hao,
> 
> On Thu, Apr 04, 2019 at 12:31:47AM +0800, Wu Hao wrote:
> > On Tue, Apr 02, 2019 at 07:59:25AM -0700, Moritz Fischer wrote:
> > > Hi Wu,
> > > 
> > > On Mon, Mar 25, 2019 at 11:07:41AM +0800, Wu Hao wrote:
> > > > This patch adds support to thermal management private feature for DFL
> > > > FPGA Management Engine (FME). As thermal throttling is handled by
> > > > hardware automatically per pre-defined thresholds, this private
> > > > feature driver only provides read-only sysfs interfaces for user
> > > > to read temperature, thresholds, threshold policy and other info.
> > > > 
> > > > Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> > > > Signed-off-by: Russ Weight <russell.h.weight@intel.com>
> > > > Signed-off-by: Xu Yilun <yilun.xu@intel.com>
> > > > Signed-off-by: Wu Hao <hao.wu@intel.com>
> > > > ---
> > > >  Documentation/ABI/testing/sysfs-platform-dfl-fme |  56 +++++++
> > > >  drivers/fpga/dfl-fme-main.c                      | 202 +++++++++++++++++++++++
> > > >  2 files changed, 258 insertions(+)
> > > > 
> > > > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > > > index b8327e9..d3aeb88 100644
> > > > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > > > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > > > @@ -44,3 +44,59 @@ Description:	Read-only. It returns socket_id to indicate which socket
> > > >  		this FPGA belongs to, only valid for integrated solution.
> > > >  		User only needs this information, in case standard numa node
> > > >  		can't provide correct information.
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/temperature
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. It returns temperature (in Celsius) of this FPGA
> > > > +		device.
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/threshold1
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. Read this file to get the temperature threshold1
> > > > +		(in Celsius).
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/threshold2
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. Read this file to get the temperature threshold2
> > > > +		(in Celsius).
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/trip_threshold
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. It returns trip threshold (in Celsius), once FPGA
> > > > +		temperature reaches trip threshold, it triggers a fatal event
> > > > +		to board management controller (BMC) to shutdown FPGA.
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/threshold1_status
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. It returns 1 if temperature reaches threshold1,
> > > > +		otherwise 0. Once temperature reaches threshold1, hardware
> > > > +		will automatically enter throttling state (AP1 - 50%
> > > > +		or AP2 - 90% throttling, see 'threshold1_policy').
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/threshold2_status
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. It returns 1 if temperature reaches threshold2,
> > > > +		otherwise 0. Once temperature reaches threshold2, hardware
> > > > +		will automatically enter the deepest throttling state (AP6
> > > > +		- 100% throttling).
> > > > +
> > > > +What:		/sys/bus/platform/devices/dfl-fme.0/thermal_mgmt/threshold1_policy
> > > > +Date:		March 2019
> > > > +KernelVersion:  5.2
> > > > +Contact:	Wu Hao <hao.wu@intel.com>
> > > > +Description:	Read-only. Read this file to get the policy of temperature
> > > > +		threshold1. It only supports two value (policy):
> > > > +		    0 - AP2 state (90% throttling)
> > > > +		    1 - AP1 state (50% throttling)
> > > 
> > > These look like they could directly map to the linux thermal framework,
> > > any reason you can't use the thermal framework?
> > > 
> > > The trip stuff literally maps 1:1 to what a thermal driver does, I think
> > > that's something you'd wanna consider.
> > > 
> > 
> > Hi Moritz,
> > 
> > Thanks a lot for the suggestion, actually I feel that the trip points in thermal
> > zone are used to indicate cooling actions required for thermal software either
> > in kernel or userspace. But in this case, such FPGA hardware handles cooling
> > automatically (yes, driver only expose Read-only sysfs for information), so
> > software doesn't need to take care of this at all. For this purpose, it seems
> > that we don't have to put these thresholds as trip points. And per my
> > understanding, if people use such FPGA device, then they may need to know
> > what's the current hardware throttling behavior, e.g. 50% vs 90%. These
> > information can't be provided by standard thermal zone sysfs, so anyway user
> > needs these sysfs interfaces to know it. But it seems that we still could
> > create a thermal zone without trip points, it could help if user wants to
> > connect some external cooling devices via userspace thermal daemon, they can
> > define whatever trip points they like to activate the external cooling 
> > device. I will consider this further more and come up with a new patch in
> > v2 patchset.
> 
> Generally speaking extending an existing framework with the
> functionality you want is preferable over rolling 100% your own.
> 
> So please look into this.

Yes, agree, will look into this and try to fix this in next version.

Thanks for the comments.

Hao

> 
> Thanks,
> Moritz

  reply	other threads:[~2019-04-03 23:59 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25  3:07 [PATCH 00/17] add new features for FPGA DFL drivers Wu Hao
2019-03-25  3:07 ` [PATCH 01/17] fpga: dfl-fme-mgr: fix FME_PR_INTFC_ID register address Wu Hao
2019-03-25 17:28   ` Alan Tull
2019-04-01 19:54   ` Moritz Fischer
2019-04-02  4:38     ` Wu Hao
2019-04-02 13:33       ` Moritz Fischer
2019-03-25  3:07 ` [PATCH 02/17] fpga: dfl: fme: align PR buffer size per PR datawidth Wu Hao
2019-03-25 17:50   ` Alan Tull
2019-03-26  0:28     ` Wu Hao
2019-03-28 18:50       ` Alan Tull
2019-03-25  3:07 ` [PATCH 03/17] fpga: dfl: fme: support 512bit data width PR Wu Hao
2019-03-25 18:48   ` Alan Tull
2019-03-25 22:53   ` Scott Wood
2019-03-25 22:58     ` Scott Wood
2019-03-26 19:33       ` Alan Tull
2019-03-26 21:22         ` Scott Wood
2019-03-27  4:37           ` Wu Hao
2019-03-27  6:10             ` Scott Wood
2019-03-27  6:10               ` Scott Wood
2019-03-27  6:03               ` Wu Hao
2019-03-27  5:10       ` Wu Hao
2019-03-27  6:19         ` Scott Wood
2019-03-27  7:10           ` Wu Hao
2019-03-27  5:46     ` Wu Hao
2019-03-25  3:07 ` [PATCH 04/17] Documentation: fpga: dfl: add descriptions for virtualization and new interfaces Wu Hao
2019-03-25  3:07 ` [PATCH 05/17] fpga: dfl: fme: add DFL_FPGA_FME_PORT_RELEASE/ASSIGN ioctl support Wu Hao
2019-03-28 22:03   ` Alan Tull
2019-03-25  3:07 ` [PATCH 06/17] fpga: dfl: pci: enable SRIOV support Wu Hao
2019-03-28 22:03   ` Alan Tull
2019-03-25  3:07 ` [PATCH 07/17] fpga: dfl: afu: add AFU state related sysfs interfaces Wu Hao
2019-03-28 17:13   ` Alan Tull
2019-03-25  3:07 ` [PATCH 08/17] fpga: dfl: afu: add userclock " Wu Hao
2019-04-01 21:41   ` Alan Tull
2019-03-25  3:07 ` [PATCH 09/17] fpga: dfl: add id_table for dfl private feature driver Wu Hao
2019-04-02 15:09   ` Moritz Fischer
2019-04-11 20:55     ` Alan Tull
2019-03-25  3:07 ` [PATCH 10/17] fpga: dfl: afu: export __port_enable/disable function Wu Hao
2019-04-02 15:42   ` Moritz Fischer
2019-04-02 15:50   ` Moritz Fischer
2019-04-11 20:45     ` Alan Tull
2019-03-25  3:07 ` [PATCH 11/17] fpga: dfl: afu: add error reporting support Wu Hao
2019-04-09 20:57   ` Alan Tull
2019-04-10  1:43     ` Wu Hao
2019-03-25  3:07 ` [PATCH 12/17] fpga: dfl: afu: add STP (SignalTap) support Wu Hao
2019-04-02 15:07   ` Moritz Fischer
2019-04-11 20:41     ` Alan Tull
2019-03-25  3:07 ` [PATCH 13/17] fpga: dfl: fme: add capability sysfs interfaces Wu Hao
2019-04-09 21:05   ` Alan Tull
2019-03-25  3:07 ` [PATCH 14/17] fpga: dfl: fme: add thermal management support Wu Hao
2019-04-02 14:59   ` Moritz Fischer
2019-04-03 16:31     ` Wu Hao
2019-04-03 18:09       ` Moritz Fischer
2019-04-03 23:43         ` Wu Hao [this message]
2019-03-25  3:07 ` [PATCH 15/17] fpga: dfl: fme: add power " Wu Hao
2019-04-11 20:07   ` Alan Tull
2019-04-12  2:50     ` Wu Hao
2019-04-15 21:17       ` Alan Tull
2019-04-17  7:36         ` Wu Hao
2019-04-12 21:05     ` Moritz Fischer
2019-04-17  7:31       ` Wu Hao
2019-03-25  3:07 ` [PATCH 16/17] fpga: dfl: fme: add global error reporting support Wu Hao
2019-04-09 21:35   ` Alan Tull
2019-04-10  1:34     ` Wu Hao
2019-03-25  3:07 ` [PATCH 17/17] fpga: dfl: fme: add performance " Wu Hao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190403234356.GA11098@hao-dev \
    --to=hao.wu@intel.com \
    --cc=atull@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luwei.kang@intel.com \
    --cc=mdf@kernel.org \
    --cc=russell.h.weight@intel.com \
    --cc=yilun.xu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.