Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp791097imm; Wed, 26 Sep 2018 06:55:01 -0700 (PDT) X-Google-Smtp-Source: ACcGV62ancowAzlW1ScpOxDxNg5nZxb/aEgd3jxLEu4+q9JA/A8PzJOL+r4LVXG0+rLe0FDzp/be X-Received: by 2002:a17:902:f085:: with SMTP id go5mr6349444plb.241.1537970101233; Wed, 26 Sep 2018 06:55:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537970101; cv=none; d=google.com; s=arc-20160816; b=hWC50qplbrvGTcNnSUFqNgY7LEa05vgmSeCwdDg7SN8a0T9Me6XHWvF2Bzm9fa49ZB 5w8emEqYkewWNGY2lgI3Tbd+7HGveK+O2+APtzBNc0bPER1Oq7Ki2HaTHjVYT9JEbjnX b8IkNp0Bnwz68T3QauI530Z698Tkw07uhx643smbj+KPu+DNhBskyBKHPC0T+RYCkn5F Pa/GJJ3nGON1C26F/mRKz7kPAnxahMKGODxc4aODexROP1buJQqDThdPpV/fWjxbt5d7 o/rq2F267A7jnOHutZXglX79d9u32rtdQ7eGcv8jInpSeHnMcbQM4gdlZGLtwMvrj5kG 2Hgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=88/2cfvdBss3O2vrPN3ChGUN6VdhuZnNWDN6bZX27s8=; b=maFbtYfCvIJ6J5KfdXZER1A/1WOHaC0GHrBsOIh0GTogevOX4KH1yfrTxpz6aOFvrk 14sc7sQ/c9qv1rqCEUdm0f7fkrs1oTUmyyAv9voWAsuXdpK27QWWBhNt9hkye0ykN/0v /mp0hmdZ9A5YdoR8M+hB4MvTjLBS/Gk9hZ8LdnusVxg3dkg2KL8we6vaPw9SflrUtpol qh/ESwgRZzRTexbA5VWL2d4mxee+t4Uq9SvZYbzFhzBLlXsjGnMs/MpPcN5KtmpXHfdE DgG9X/FejvDc4dHGaTAojdcbdtLGdPN0OYvp29Zey03wNBYy7JTOQVa/9lfhVdVGj6p/ LMrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qyXai9QG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j15-v6si3197822pgi.552.2018.09.26.06.54.45; Wed, 26 Sep 2018 06:55:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qyXai9QG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727432AbeIZUHM (ORCPT + 99 others); Wed, 26 Sep 2018 16:07:12 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:45279 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726602AbeIZUHM (ORCPT ); Wed, 26 Sep 2018 16:07:12 -0400 Received: by mail-qt1-f193.google.com with SMTP id l2-v6so17267348qtr.12; Wed, 26 Sep 2018 06:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=88/2cfvdBss3O2vrPN3ChGUN6VdhuZnNWDN6bZX27s8=; b=qyXai9QGBtomAl9+Bu+Frf25vXePFeWtyNTmyUcFOEYZ2WjUuhM5V4WepUOvvct2Qd BHLlQnA82XS/qGo2bEssthKLu/eMCIxiojfRr/1R9qJr0GqXhpRI8I8I0qS06mx2nIEQ uuzSEFT2os+sLbV6nE5vkMVv8KZ4DSJfJUaWJtJtGN6hHGq7WqTOKYxqsKbRZ2ad03zO NMYoFSz2e3KdnTt4QpebNBj9EXfapFyHdFFmzRbLsk9xYwioGUXetb7fXE1JuY/TRptD nGBz0Sz3ATFfYDNWNYBaDSk6EZ4TB0h26ZYZbtHq7ClpslNO3YZPanysR/yqEtsa6C/I GAtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=88/2cfvdBss3O2vrPN3ChGUN6VdhuZnNWDN6bZX27s8=; b=NAzMqeB+OdHPXHnW8SWkBI3uqybBW/ns1K6m+QLlTYeJ+xco3O47Cd0Wd93flNdJ6m 3yHJWklZOUlB7A05Ed7VkjvMNveBpmziJ1WCeCrqPp32mBbxJ4NfcZ/mRgt4kYc45Jgl Wo0aLS6H8edHaLbwoAkbzOytFfbWWAt7hL+QKXqf55VL04xRsqmKaKIheXUbzE8nnPHI ygbMmkMRhDyeA0whSgXnq/nvr8gUhx4InA2Mw/p/RqsG8qjUu6sBsK1SnojYjKTnzv5B YGcJjwjBgdcPxzO0SJq9ij4lh201Vkh1fo7w0s1J+w1XIiogdn6lyZGwdEDN0PMCeYax gqug== X-Gm-Message-State: ABuFfoi6uJmpYwYJzX+XiG3Jgh/R2YAlP7M/3K+in1lU84pzqePZYHYG juzzCcQtZbeiYrWr/OT4Z6yPKr20RtXxyQi0JPE= X-Received: by 2002:ac8:16c5:: with SMTP id y5-v6mr4645360qtk.187.1537970046966; Wed, 26 Sep 2018 06:54:06 -0700 (PDT) MIME-Version: 1.0 References: <20180903180415.31575-1-rajneesh.bhardwaj@linux.intel.com> <20180903180415.31575-3-rajneesh.bhardwaj@linux.intel.com> In-Reply-To: <20180903180415.31575-3-rajneesh.bhardwaj@linux.intel.com> From: Andy Shevchenko Date: Wed, 26 Sep 2018 16:53:55 +0300 Message-ID: Subject: Re: [PATCH 3/4] platform/x86: intel_pmc_core: Decode Snoop / Non Snoop LTR To: rajneesh.bhardwaj@linux.intel.com Cc: Platform Driver , Darren Hart , Andy Shevchenko , Linux Kernel Mailing List , Rajneesh Bhardwaj , Souvik Kumar Chakravarty Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 3, 2018 at 9:05 PM Rajneesh Bhardwaj wrote: > > The LTR values follow PCIE LTR encoding format and can be decoded as per > https://pcisig.com/sites/default/files/specification_documents/ECN_LatencyTolnReporting_14Aug08.pdf > > This adds support to translate the raw LTR values as read from the PMC > to meaningful values in nanosecond units of time. > +static void get_ltr_scale(u32 *val) What's wrong to return converted value? Actually the name should reflect what it does, ie *convert* value. > +{ > + /* > + * As per PCIE specification supprting document supporting > + * ECN_LatencyTolnReporting_14Aug08.pdf the Latency > + * Tolerance Reporting data payload is encoded in a > + * 3 bit scale and 10 bit value fields. Values are > + * multiplied by the indicated scale to yield an absolute time > + * value, expressible in a range from 1 nanosecond to > + * 2^25*(2^10-1) = 34,326,183,936 nanoseconds. > + * > + * scale encoding is as follows: > + * > + * ---------------------------------------------- > + * |scale factor | Multiplier (ns) | > + * ---------------------------------------------- > + * | 0 | 1 | > + * | 1 | 32 | > + * | 2 | 1024 | > + * | 3 | 32768 | > + * | 4 | 1048576 | > + * | 5 | 33554432 | > + * | 6 | Invalid | > + * | 7 | Invalid | > + * ---------------------------------------------- > + */ > + if (*val > 5) { > + *val = 0; > + pr_warn("Invalid LTR scale factor.\n"); > + } else { > + *val = 1U << (5 * (*val)); > + } > +} > + > static int pmc_core_ltr_show(struct seq_file *s, void *unused) > { > struct pmc_dev *pmcdev = s->private; > const struct pmc_bit_map *map = pmcdev->map->ltr_show_sts; > + u64 decoded_snoop_ltr = 0, decoded_non_snoop_ltr = 0; > + union ltr_payload ltr_data; > + u32 scale = 0; Redundant assignment. > int index; > > for (index = 0; map[index].name ; index++) { > - seq_printf(s, "%-32s\tRAW LTR: 0x%x\n", > + ltr_data.raw_data = pmc_core_reg_read(pmcdev, > + map[index].bit_mask); > + > + if (ltr_data.bits.non_snoop_req) { > + scale = ltr_data.bits.non_snoop_scale; > + get_ltr_scale(&scale); > + decoded_non_snoop_ltr = > + ltr_data.bits.non_snoop_val * scale; > + } > + > + if (ltr_data.bits.snoop_req) { > + scale = ltr_data.bits.snoop_scale; > + get_ltr_scale(&scale); > + decoded_snoop_ltr = > + ltr_data.bits.snoop_val * scale; > + } > + > + seq_printf(s, "%-24s\tRaw LTR: 0x%-16x\t Non-Snoop LTR (ns): %-16llu\t Snoop LTR (ns): %-16llu\n", > map[index].name, > - pmc_core_reg_read(pmcdev, map[index].bit_mask)); > + ltr_data.raw_data, > + decoded_non_snoop_ltr, > + decoded_snoop_ltr); > + > + decoded_snoop_ltr = decoded_non_snoop_ltr = 0; You may do this at the beginning of the loop and get rid of assignment in the definition block. > } > return 0; > } > +union ltr_payload { > + u32 raw_data; > + struct { > + u32 snoop_val : 10; > + u32 snoop_scale : 3; > + u32 snoop_res : 2; > + u32 snoop_req : 1; > + u32 non_snoop_val : 10; > + u32 non_snoop_scale : 3; > + u32 non_snoop_res : 2; > + u32 non_snoop_req : 1; > + } bits; > +}; Just use normal masks and shifts. -- With Best Regards, Andy Shevchenko