All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David E. Box" <david.e.box@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
	lee.jones@linaro.org, dvhart@infradead.org, andy@infradead.org,
	bhelgaas@google.com, alexey.budankov@linux.intel.com
Cc: linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH V8 0/5] Intel Platform Monitoring Technology
Date: Wed, 28 Oct 2020 18:50:16 -0700	[thread overview]
Message-ID: <bc5f059c5bae957daebde699945c80808286bf45.camel@linux.intel.com> (raw)
In-Reply-To: <2f17db4b-2988-7f0d-fd0e-9e5b621d24ec@redhat.com>

On Tue, 2020-10-27 at 12:28 +0100, Hans de Goede wrote:
> Hi,
> 
> On 10/3/20 3:31 AM, David E. Box wrote:
> > Intel Platform Monitoring Technology (PMT) is an architecture for
> > enumerating and accessing hardware monitoring capabilities on a
> > device.
> > With customers increasingly asking for hardware telemetry,
> > engineers not
> > only have to figure out how to measure and collect data, but also
> > how to
> > deliver it and make it discoverable. The latter may be through some
> > device
> > specific method requiring device specific tools to collect the
> > data. This
> > in turn requires customers to manage a suite of different tools in
> > order to
> > collect the differing assortment of monitoring data on their
> > systems.  Even
> > when such information can be provided in kernel drivers, they may
> > require
> > constant maintenance to update register mappings as they change
> > with
> > firmware updates and new versions of hardware. PMT provides a
> > solution for
> > discovering and reading telemetry from a device through a hardware
> > agnostic
> > framework that allows for updates to systems without requiring
> > patches to
> > the kernel or software tools.
> > 
> > PMT defines several capabilities to support collecting monitoring
> > data from
> > hardware. All are discoverable as separate instances of the PCIE
> > Designated
> > Vendor extended capability (DVSEC) with the Intel vendor code. The
> > DVSEC ID
> > field uniquely identifies the capability. Each DVSEC also provides
> > a BAR
> > offset to a header that defines capability-specific attributes,
> > including
> > GUID, feature type, offset and length, as well as configuration
> > settings
> > where applicable. The GUID uniquely identifies the register space
> > of any
> > monitor data exposed by the capability. The GUID is associated with
> > an XML
> > file from the vendor that describes the mapping of the register
> > space along
> > with properties of the monitor data. This allows vendors to perform
> > firmware updates that can change the mapping (e.g. add new metrics)
> > without
> > requiring any changes to drivers or software tools. The new mapping
> > is
> > confirmed by an updated GUID, read from the hardware, which
> > software uses
> > with a new XML.
> > 
> > The current capabilities defined by PMT are Telemetry, Watcher, and
> > Crashlog.  The Telemetry capability provides access to a continuous
> > block
> > of read only data. The Watcher capability provides access to
> > hardware
> > sampling and tracing features. Crashlog provides access to device
> > crash
> > dumps.  While there is some relationship between capabilities
> > (Watcher can
> > be configured to sample from the Telemetry data set) each exists as
> > stand
> > alone features with no dependency on any other. The design
> > therefore splits
> > them into individual, capability specific drivers. MFD is used to
> > create
> > platform devices for each capability so that they may be managed by
> > their
> > own driver. The PMT architecture is (for the most part) agnostic to
> > the
> > type of device it can collect from. Software can determine which
> > devices
> > support a PMT feature by searching through each device node entry
> > in the
> > sysfs class folder. It can additionally determine if a particular
> > device
> > supports a PMT feature by checking for a PMT class folder in the
> > device
> > folder.
> > 
> > This patch set provides support for the PMT framework, along with
> > support
> > for Telemetry on Tiger Lake.
> 
> The entire series looks good to me, so you may add my:
> 
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Thanks. I did send out a V9 after rebasing and noticing that I
accidentally dropped a change in the MFD driver between V7 and V8. This
was added back. I also took the opportunity to get rid of a nuisance
dev_warn.

David


      reply	other threads:[~2020-10-29  1:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03  1:31 [PATCH V8 0/5] Intel Platform Monitoring Technology David E. Box
2020-10-03  1:31 ` [PATCH V8 1/5] PCI: Add defines for Designated Vendor-Specific Extended Capability David E. Box
2020-10-06 22:45   ` David E. Box
2020-10-07  0:51     ` Bjorn Helgaas
2020-10-07  1:47       ` David E. Box
2020-10-07  6:54         ` Lee Jones
2020-10-07 21:36           ` Hans de Goede
2020-10-08  7:29             ` Lee Jones
2020-10-08 11:13               ` Hans de Goede
2020-10-03  1:31 ` [PATCH V8 2/5] mfd: Intel Platform Monitoring Technology support David E. Box
2020-10-07  6:57   ` Lee Jones
2020-10-07 16:10     ` David E. Box
2020-10-08  7:32       ` Lee Jones
2020-11-10 10:39   ` Geert Uytterhoeven
2020-11-10 18:06     ` David E. Box
2020-10-03  1:31 ` [PATCH V8 3/5] platform/x86: Intel PMT class driver David E. Box
2020-10-03  1:31 ` [PATCH V8 4/5] platform/x86: Intel PMT Telemetry capability driver David E. Box
2020-10-03  1:31 ` [PATCH V8 5/5] platform/x86: Intel PMT Crashlog " David E. Box
2020-10-27 11:28 ` [PATCH V8 0/5] Intel Platform Monitoring Technology Hans de Goede
2020-10-29  1:50   ` David E. Box [this message]

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=bc5f059c5bae957daebde699945c80808286bf45.camel@linux.intel.com \
    --to=david.e.box@linux.intel.com \
    --cc=alexey.budankov@linux.intel.com \
    --cc=andy@infradead.org \
    --cc=bhelgaas@google.com \
    --cc=dvhart@infradead.org \
    --cc=hdegoede@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /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.