Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4171285pxk; Tue, 8 Sep 2020 12:30:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlNV34NxTKY7l7f/ZnGtKxFew90usQtZ/PZHovISa/TDPkia0PR26uAHHMObxoF4miHPSd X-Received: by 2002:aa7:d1ce:: with SMTP id g14mr574309edp.153.1599593455763; Tue, 08 Sep 2020 12:30:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599593455; cv=none; d=google.com; s=arc-20160816; b=OlLogUA88QO5E0NiWjR+1FAJvJblMee4pLWq85wfo5xbEpnOqsGjWeVkdPZ+c/8gMI 9q+wSk1ofNCvDA3EVTLDOKO740x1BHqxEGG+UaSrfsU0ctkCwZTtFS8LPhVG2atcPp/0 2FMEWIeQYgrSfG9kOjly5N/SVq588erjS6TwqlDfPx4etTav6231vdoPx+I3twwGdLM2 jW+1sGqDhnspdwqd5ib0MkM2MOrQTsAMJbRD54xCgOB/ng4FTb5BMuYleCcPFlmOAGsw b8W0pryEVSGc9OuGiIOHUnO6bNUuP3CKV7rl6UXFHrwSm3jLUptabs2qgzXUCNAR4G20 iSlA== 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:dkim-signature; bh=YnSMm4ogisR5W8OzFSgC2w8o0qTW3G5f4K1/tGLIEYA=; b=X/lE5gFp4gjjh3KJKnwSKEY64VjyZm6rUHz++Ngt6MPmIOlHsKJdaBmwTJo3ulkQbh 1HC38QQsG9/EHR2v7pNWlKn4MUCPkgsolKl1pgW/mlZQ2ZPEWr88TJ9Qwqb3672FQJhp J4j+mrJiPnmoDyXBkx6oivlG3tpvezaNo17w9vCVpRljD8hIrwDMQMm9NA2/d9hDR1kN O5BSqlua4izcNhx9pjPYN7cs036oIRY9LyDEJ0ACfSMx7ibN0V80elxUjtGK0/oWn/sX eFq9sDBRREbWSdf7aQnGKUaap8CvqpnrJiQkN3dzC2OZcw6zS1bS0nhfMGMA6krpOees AfYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=VB4HA7ZY; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jo8si12451431ejb.524.2020.09.08.12.30.28; Tue, 08 Sep 2020 12:30:55 -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; dkim=pass header.i=@linaro.org header.s=google header.b=VB4HA7ZY; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732210AbgIHT2C (ORCPT + 99 others); Tue, 8 Sep 2020 15:28:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731042AbgIHQAE (ORCPT ); Tue, 8 Sep 2020 12:00:04 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A4CBC004592 for ; Tue, 8 Sep 2020 08:03:40 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id jw11so2270356pjb.0 for ; Tue, 08 Sep 2020 08:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YnSMm4ogisR5W8OzFSgC2w8o0qTW3G5f4K1/tGLIEYA=; b=VB4HA7ZYUddQ/czN0QR6hFOtLPOVBlc7yLlibZ8LGNe7lrh/c+qET5DMkAXLxTmt7c 2My3M29VqYQtJyC2HUJaeqWuSn+14HZLUiuedh3TdzD9kopJC9AfijVLH4nCSa4SzDr7 CyzRiOKsGvrjC/qzkt0HKNyrW6VRexUTgx+p1tuEC0nso2zv0fhCkNFmuqGKI6ZYrPG1 R4PSFPcQyjzmbmpJNvZBSXlLgo6rkjfVad941h7r8FI3PqAb3aU7MvPrNtHPe/fULAlV AzbextZqwrYLgzq9E47RsEi0rt0YEJvllqQkaID87k25MLGjR0sydF6xl/dg04qRjQ8n zaKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YnSMm4ogisR5W8OzFSgC2w8o0qTW3G5f4K1/tGLIEYA=; b=U9Ws8OI9RYuQ1TfCOIMOUoEIyVCTo98jJ9vXd06eKqfi6zsF+cbwxWdEYb0X3ITEsU CqqnDEB9M+em2EJsld11MASSVzj3Zb+SaSNEkDUAbhrKxm8Z2fvAzxKY+tNq6S4FI0af f6wHp9rYI7E/EdtA1CtVXpzKDy8i/FrJ5EhKu3bpdFIi/3KsHLSJoEn+2m+beuf5zTlq nT22Cs1ZNlmE9YKvxzS9D07KynP4M++0tPDBpI2AmIM/mToIk92prHq9JUyycWfIYbq0 /7wGXGFTrieyIj015EsuqT74sFkqBsZcnKqAayeGN4N9IUiB68TYl/WX6QnRVUJW8jfZ PV/A== X-Gm-Message-State: AOAM5333Yr6PZYx/992qzoGyXiJOHhIRpAIzaE/IRDllOFQ31X5YqZQV NvxGmKwm8GVFZ2A6J/V3OtKW X-Received: by 2002:a17:90b:4b82:: with SMTP id lr2mr4319741pjb.184.1599577419882; Tue, 08 Sep 2020 08:03:39 -0700 (PDT) Received: from mani-NUC7i5DNKE ([2409:4072:6213:6149:94b7:eeb3:82a5:2b53]) by smtp.gmail.com with ESMTPSA id a18sm4160368pgw.50.2020.09.08.08.03.34 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 Sep 2020 08:03:39 -0700 (PDT) Date: Tue, 8 Sep 2020 20:33:30 +0530 From: Manivannan Sadhasivam To: Amit Kucheria Cc: Viresh Kumar , "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 , Taniya Das Subject: Re: [PATCH 5/7] cpufreq: qcom-hw: Use regmap for accessing hardware registers Message-ID: <20200908150321.GA2352@mani-NUC7i5DNKE> 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 0908, Amit Kucheria wrote: > On Tue, Sep 8, 2020 at 5:18 PM 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. > > Having said this, perhaps this patch can be held back for now, since > we're not yet using some of the features of regmap to abstract away > bit fields and such. > Okay. Dropping this patch for now (in v2)! Thanks, Mani > We don't strictly need it for just different register offsets. > > Regards, > Amit