Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4162015pxk; Tue, 8 Sep 2020 12:15:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw8mPO56D3c+llxkAAj/FjUHtHZn3bqXQCIACVqQylDHOkV94LTu99/UApyrOR4zwc6UXMV X-Received: by 2002:a17:907:2456:: with SMTP id yw22mr26721430ejb.337.1599592551586; Tue, 08 Sep 2020 12:15:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599592551; cv=none; d=google.com; s=arc-20160816; b=jHMzxGUj1gPv2tFe5qOlYLdvtFVRFn4PFFFtSpODh4Wngk83Ea6uc5+Lz4rB3QXrgc WIFX6gdD43Uh7vR1SxZxvfYRNVhDaZlJKnaBMVJKtwflYvmdBD1rNIHrZIii6qpH0/Bs pP637JIt25fL1IZFDGOWBX0NPUJTExpDVweWffIJuK27Lg2XMHzCnoUanvg62Z/AvzXh zHra8eEhLcoyUPqdC+b8Wm0sWKh2y/hXAW43m+caNs97Q+J1xOCbunsGy1iMHB96FPOq +IgePtCTVqCL1Lm6Z8qUaZn5HkKL1dF6g57x0WUtqDUPfmeypKs2/QOOe9qVOfV02Cl6 CV+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cmTe2RoshXbwFtEcOLFc34l0hu0e34DB3+UpxEE31j8=; b=PCo8bhGYJZ85H5lFS+mDsSgfnMg0HBHceKLoCffQIK/04ftE/kIBYj3Ls0BudRG30n EY+hqwOTXblK8MCdk7K/07Lpl9Cm3+xpl3Qfno/jUoDqBFIz7Uh1/9ZBnzZxYbcLOTuZ vWCOvg1mcDptPKcGxUCvEsN1cZPIo6zkPqhzPxRJ5LC7v33ftBgTdjUHMzo7tvlmdtnB 8H8dzQq/fcgfN9zMzg0Lh0T4kuil6/FweMqNolfvgpKNBYwDLu43V+77zf+aPI5j1hZf 6J8YvhOWeJBmi7DQeQUF5JAXgz0mfbvawFkQUJ7SkjdJoACSDJPcVqQx085SxP5mjE3i WLpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r17si12396361ejz.238.2020.09.08.12.15.28; Tue, 08 Sep 2020 12:15:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731756AbgIHTNe (ORCPT + 99 others); Tue, 8 Sep 2020 15:13:34 -0400 Received: from foss.arm.com ([217.140.110.172]:56774 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731161AbgIHQFH (ORCPT ); Tue, 8 Sep 2020 12:05:07 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4CA921682; Tue, 8 Sep 2020 07:09:03 -0700 (PDT) Received: from bogus (unknown [10.57.10.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4059F3F73C; Tue, 8 Sep 2020 07:09:01 -0700 (PDT) Date: Tue, 8 Sep 2020 15:08:51 +0100 From: Sudeep Holla To: Amit Kucheria Cc: Viresh Kumar , Manivannan Sadhasivam , "Rafael J. Wysocki" , Rob Herring , Andy Gross , Bjorn Andersson , Linux PM list , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , linux-arm-msm , Dmitry Baryshkov , Sudeep Holla , Taniya Das Subject: Re: [PATCH 5/7] cpufreq: qcom-hw: Use regmap for accessing hardware registers Message-ID: <20200908140842.GA17621@bogus> References: <20200908075716.30357-1-manivannan.sadhasivam@linaro.org> <20200908075716.30357-6-manivannan.sadhasivam@linaro.org> <20200908103444.5e526uawa45om6lt@vireshk-i7> <20200908111141.GB23095@mani> <20200908111813.bbgfxo5v7qt6ujpc@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 08, 2020 at 05:18:35PM +0530, Amit Kucheria wrote: > On Tue, Sep 8, 2020 at 4:48 PM Viresh Kumar wrote: > > > > On 08-09-20, 16:41, Manivannan Sadhasivam wrote: > > > On 0908, Viresh Kumar wrote: > > > > On 08-09-20, 13:27, Manivannan Sadhasivam wrote: > > > > > Use regmap for accessing cpufreq registers in hardware. > > > > > > > > Why ? Please mention why a change is required in the log. > > > > > > > > > > Only because it is recommended to use regmap for abstracting the hw access. > > > > Yes it can be very useful in abstracting the hw access in case of > > busses like SPI/I2C, others, but in this case there is only one way of > > doing it with the exact same registers. I am not sure it is worth it > > here. FWIW, I have never played with regmaps personally, and so every > > chance I can be wrong here. > > One could handle the reg offsets through a struct initialisation, but > then you end up with lots of #defines for bitmasks and bits for each > version of the IP. And the core code becomes a bit convoluted IMO, > trying to handle the differences. > > regmap hides the differences of the bit positions and register offsets > between several IP versions. > > > > Moreover it handles the proper locking for us in the core (spinlock vs mutex). > > > > What locking do you need here ? > > Right, locking isn't the main reason here. If that is the case, IMO it is better to set disable_lock or something in config especially as this regmap_write is used in qcom_cpufreq_hw_fast_switch -- Regards, Sudeep