Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752100AbeABGDq (ORCPT + 1 other); Tue, 2 Jan 2018 01:03:46 -0500 Received: from mga05.intel.com ([192.55.52.43]:34465 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751419AbeABGDp (ORCPT ); Tue, 2 Jan 2018 01:03:45 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,495,1508828400"; d="scan'208";a="18285967" Subject: Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface To: Richard Cochran Cc: Takashi Iwai , linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Vinod Koul , Thomas Gleixner References: <1513323522-15021-1-git-send-email-sagar.a.kamble@intel.com> <1513323522-15021-16-git-send-email-sagar.a.kamble@intel.com> <20171215165125.avkz25eek56i5md4@localhost> <20171228164944.crphv46zegvwautk@localhost> From: Sagar Arun Kamble Message-ID: <1a9a1507-7ca3-459b-c2ce-02fc2afad2ff@intel.com> Date: Tue, 2 Jan 2018 11:33:41 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171228164944.crphv46zegvwautk@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 12/28/2017 10:19 PM, Richard Cochran wrote: > On Tue, Dec 26, 2017 at 01:07:35PM +0530, Sagar Arun Kamble wrote: >>> Or can we provide simpler versions for covering some defaults? At >>> least reducing the number of arguments would make things easier. >> Thought about specifying 1. cyclecounter read func 2. frequency 3. width of >> counter as parameters here >> which can get rid of mult, shift params. But this is not easy as most of the >> drivers do not specify >> cyclecounter frequency and instead hard-code the mult/shift factors. > You are talking about using clocks_calc_mult_shift() here, right? (See > the usage example in drivers/net/ethernet/ti/cpts.c). Yes > This is a good idea, and it is worth getting the driver authors' input > to figure out the correct parameters. > > I bet we can use that almost everywhere. If there are any drivers > that cannot be converted, then we can leave some sort of low level > legacy initialization method. Agree > Thanks, > Richard >