Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752077AbdC0Gev (ORCPT ); Mon, 27 Mar 2017 02:34:51 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34130 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751457AbdC0Gem (ORCPT ); Mon, 27 Mar 2017 02:34:42 -0400 Subject: Re: [PATCH v6 07/11] drivers: perf: hisi: Add support for Hisilicon SoC event counters To: Mark Rutland References: <1489127311-112778-1-git-send-email-anurup.m@huawei.com> <20170321165252.GA29116@leverpostej> <58D4F277.7080006@gmail.com> <20170324115707.GD22771@leverpostej> Cc: will.deacon@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, anurup.m@huawei.com, zhangshaokun@hisilicon.com, tanxiaojun@huawei.com, xuwei5@hisilicon.com, sanil.kumar@hisilicon.com, john.garry@huawei.com, gabriele.paoloni@huawei.com, shiju.jose@huawei.com, huangdaode@hisilicon.com, linuxarm@huawei.com, dikshit.n@huawei.com, shyju.pv@huawei.com From: Anurup M Message-ID: <58D8B25E.90308@gmail.com> Date: Mon, 27 Mar 2017 12:04:06 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20170324115707.GD22771@leverpostej> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1833 Lines: 57 On Friday 24 March 2017 05:27 PM, Mark Rutland wrote: >> +/* hip05/06 chips L3C bank identifier */ >> >+static u32 l3c_bankid_map_v1[MAX_BANKS] = { >> >+ 0x02, 0x04, 0x01, 0x08, >> >+}; >> >+ >> >+/* hip07 chip L3C bank identifier */ >> >+static u32 l3c_bankid_map_v2[MAX_BANKS] = { >> >+ 0x01, 0x02, 0x03, 0x04, >> >+}; >> > >> >Is my approach OK? or can be improved? > I think it would make more sense for this to be described in the DT. Ok. Shall describe it in DT. > [...] > >> I shall handle the error internally and propagate it until a void >> >function (pmu->start, pmu->stop, pmu->del etc. are void). >> >e.g. in the scenario pmu->add ---> pmu->start. If start fail, >> >pmu->add cannot catch it and continues. >> >the counter index could be cleared when pmu->del is called later. >> > >> >Is this fine? Any suggestion to handle it? > Propagating it up to a void function, only to silently fail is not good. > > Given it seems this should only happen if there is a major HW problem, > I'd be happier with a BUG_ON() in the djtag accessors. Yes, it occur only when major HQ problem. I would add BUG_ON in djtag and simplify callers. > [...] > >>> > >In the absence of pmu::{enable,disable}, you must disallow groups, since >>> > >their events will be enabled for different periods of time. >> > >> >For L3 cache and MN PMU, pmu::{enable,disable}is present. But in >> >case of Hisilicon DDRC PMU, >> >it is not available. It only support continuous counting. I shall >> >disallow groups when adding support >> >for DDRC PMU. > Given this code does not currently support the DDRC, please simplify > the coder to assume these callbacks always exist. We can alter it when > DDRC support arrives. Ok. Sure. Shall remove all similar checks added for DDRC in this file to simplify. Thanks, Anurup > Thanks, > Mark.