Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp822506imm; Wed, 4 Jul 2018 06:37:59 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcdJBtG5Yxx7EJOzubkmXpj9XHzARrwPIUskkWAqeMF2jfZF91lYsbZhdffkn8HtUYswIzC X-Received: by 2002:a62:c410:: with SMTP id y16-v6mr2236503pff.161.1530711479342; Wed, 04 Jul 2018 06:37:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530711479; cv=none; d=google.com; s=arc-20160816; b=o9Tk+DdkE4efv4vEnI0UwLH5mnIAdM8kDKbMlNekxYDB5CUWQs7wlAzutbScLc50i+ Fe4MztP/7DIlaKpMu7l8n1nPWSvofssoNa0KG0M6RVFIMDldtum0FefQg8J7dY0iPk// M5C0maJn2Frngo08id7UvIwQewowaYXHD4iuRgGjBJSMrlkHH16oSBzv6XnkT2pJm5Wm HIw6b5bYudkkGcygDN0DoQBjZmObS2qDG1Ju451BfuSWWibAvxmtWd/DsFNPq7wbm9V3 L7rgZwLNoYDNB3lJW1Zz8AVFM0oo4DiajBvrSqYIasiYT8g0ys0xFfRCN9YL1icj0Jsr 73Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=vOqGlFIfeFrkecY8dVz8ipXA8DjxpFQ8rlA8D33r4GE=; b=yVMAyAOW6patvJgJAmvSpODKyX8+berJVnck86vpCQBGPsG25NqC9rEbN6P5CE/mrG E/No5nBSkPslSE5qTgeeK07B+4VLq6SiP0bHi2SZYMpH4uASjN5o5bXrPtENuaMpS+KJ /F7lGMs/QYXTkCD7TGZhN5QeZEdgO6+MjOzVl4nVfccJs5HtFbwCP14SyEZ5iYCGcPmp 2M6FOggsTfxO5sVvm538+YcqxXMbLDF93lu5WsAakZFHsJGgLQ3knh903X5V266s3nNI W/nZBBspGvZawRXoJ5BxFdzb/rhnpLaI32NHfnJFfUutGFDm/lnmeWiD4jeOqXvPtYEi j3yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=HBQS13a9; dkim=pass header.i=@codeaurora.org header.s=default header.b=pKmpx+kx; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v28-v6si428554pfi.22.2018.07.04.06.37.44; Wed, 04 Jul 2018 06:37:59 -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=@codeaurora.org header.s=default header.b=HBQS13a9; dkim=pass header.i=@codeaurora.org header.s=default header.b=pKmpx+kx; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753029AbeGDNg1 (ORCPT + 99 others); Wed, 4 Jul 2018 09:36:27 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:47554 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752277AbeGDNgY (ORCPT ); Wed, 4 Jul 2018 09:36:24 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id BF15F60B25; Wed, 4 Jul 2018 13:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1530711383; bh=PJvSZIKBke47jDRus7Sqnpf/tOkSr8kOWGNOafTlk4I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HBQS13a9EDIJDmuGJeBVjQ4ab0XVnWjP7iLgQrwYc3sC9bUdeTAPv84zx3IaYCUXU EPKLKPDbkSmzMSmgIkNSg60P08NC1ScUXtSJiJGcxxG+ad7nu3dIXs6gP064yXGCfB /vsU5nflAH1JIZLBOtQNQ7/wdCoioW6o4UgZEO1c= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.206.24.162] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sayalil@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 94BF86031A; Wed, 4 Jul 2018 13:36:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1530711382; bh=PJvSZIKBke47jDRus7Sqnpf/tOkSr8kOWGNOafTlk4I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pKmpx+kxwCDgXeivJxqnyAQNrnMd8vOxPLMJeqnTXO6G62TE898ipfd/YjiR6wleu 9SNTQqpOG8jkK+EmhQtzaV8P01Q0/sNzR6ol+cJsi/W5A7/wumbKTdlqykiuVyWmGh nZ5rkhyi1y85FDCsIHfiXDP1CR9hRLIPOqDiErPw= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 94BF86031A Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sayalil@codeaurora.org Subject: Re: [PATCH V2 1/3] scsi: ufs: set the device reference clock setting To: Rob Herring Cc: Subhash Jadavani , Can Guo , Vivek Gautam , Rajendra Nayak , Vinayak Holikatti , "James E.J. Bottomley" , "Martin K. Petersen" , asutoshd@codeaurora.org, Evan Green , linux-scsi@vger.kernel.org, Mark Rutland , Mathieu Malaterre , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" References: <1528455990-24572-1-git-send-email-sayalil@codeaurora.org> <1528455990-24572-2-git-send-email-sayalil@codeaurora.org> <20180612192636.GA31725@rob-hp-laptop> <000101d403d3$87210d20$95632760$@codeaurora.org> <002401d4093d$256fdc90$704f95b0$@codeaurora.org> From: Sayali Lokhande Message-ID: <4d8c8171-2ead-8953-afce-a30f260cf9c9@codeaurora.org> Date: Wed, 4 Jul 2018 19:06:15 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/3/2018 11:34 PM, Rob Herring wrote: > On Thu, Jun 21, 2018 at 2:52 AM sayali wrote: >> Hi Rob, >> >> Please check my comment inline. > As mentioned in the back and forth comments previously in this thread, > please fix your email client (hint: you can't use Outlook) and > properly quote your replies (i.e. the leading ">") I have started using Thunderbird now. Hope you can see my replies correctly this time. > >> Thanks, >> Sayali >> -----Original Message----- >> From: Rob Herring [mailto:robh@kernel.org] >> Sent: Thursday, June 14, 2018 7:59 PM >> To: sayali >> Cc: Subhash Jadavani ; Can Guo ; Vivek Gautam ; Rajendra Nayak ; Vinayak Holikatti ; James E.J. Bottomley ; Martin K. Petersen ; asutoshd@codeaurora.org; Evan Green ; linux-scsi@vger.kernel.org; Mark Rutland ; Mathieu Malaterre ; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; open list >> Subject: Re: [PATCH V2 1/3] scsi: ufs: set the device reference clock setting >> >> On Thu, Jun 14, 2018 at 5:33 AM, sayali wrote: >>> Comment inline. >>> >>> Thanks, >>> Sayali >>> -----Original Message----- >>> From: Rob Herring [mailto:robh@kernel.org] >>> Sent: Wednesday, June 13, 2018 12:57 AM >>> To: Sayali Lokhande >>> Cc: subhashj@codeaurora.org; cang@codeaurora.org; >>> vivek.gautam@codeaurora.org; rnayak@codeaurora.org; >>> vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; >>> martin.petersen@oracle.com; asutoshd@codeaurora.org; >>> evgreen@chromium.org; linux-scsi@vger.kernel.org; Mark Rutland >>> ; Mathieu Malaterre ; open >>> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS >>> ; open list >>> Subject: Re: [PATCH V2 1/3] scsi: ufs: set the device reference clock >>> setting >>> >>> On Fri, Jun 08, 2018 at 04:36:28PM +0530, Sayali Lokhande wrote: >>>> From: Subhash Jadavani >>>> >>>> UFS host supplies the reference clock to UFS device and UFS device >>>> specification allows host to provide one of the 4 frequencies (19.2 >>>> MHz, >>>> 26 MHz, 38.4 MHz, 52 MHz) for reference clock. Host should set the >>>> device reference clock frequency setting in the device based on what >>>> frequency it is supplying to UFS device. >>>> >>>> Signed-off-by: Subhash Jadavani >>>> Signed-off-by: Can Guo >>>> Signed-off-by: Sayali Lokhande >>>> --- >>>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 7 +++ >>>> drivers/scsi/ufs/ufs.h | 9 ++++ >>>> drivers/scsi/ufs/ufshcd-pltfrm.c | 24 ++++++++++ >>>> drivers/scsi/ufs/ufshcd.c | 52 >>> ++++++++++++++++++++++ >>>> drivers/scsi/ufs/ufshcd.h | 1 + >>>> 5 files changed, 93 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >>>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >>>> index c39dfef..4522434 100644 >>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt >>>> @@ -41,6 +41,12 @@ Optional properties: >>>> -lanes-per-direction : number of lanes available per direction - >>>> either 1 >>> or 2. >>>> Note that it is assume same number of lanes >>>> is >>> used both >>>> directions at once. If not specified, default >>>> is 2 >>> lanes per direction. >>>> +- dev-ref-clk-freq : Specify the device reference clock frequency, must >>> be one of the following: >>>> + 0: 19.2 MHz >>>> + 1: 26 MHz >>>> + 2: 38.4 MHz >>>> + 3: 52 MHz >>>> + Defaults to 26 MHz if not specified. >>> I must have misunderstood your last response. I thought you could >>> handle things without DT. If not, my question remains. >>> [Sayali]: Ref clk frequency setting could vary from >>> platfrom-to-platform(vendor specific). Hence we need to pass it via DT. >>> Currently in DT we do not set/mention any ref clk frequency >>> parameter. Hence I have added one new DT entry to configure >>> required ref clk freq. >> The clocks property contains "ref_clk". Is that not the same clock? >> Why can't you read what that frequency is? Or you need to be able to change it to a specific frequency? These all look like typical oscillator frequencies, so I wouldn't expect you could change them (other than divide by 2 maybe). >> [Sayali] : It is the same "ref_clk", but we need to be able to change it to a specific frequency as per requirement. Thus, we need new DT entry to specify/override reference clock frequency as per need. > That is not what your patch does. It just tells the device what the > frequency is. If you need to get the rate, use "clk_get_rate" on > "ref_clk". If you need to actually set it to a specific frequency, > then we have properties for that already (assigned-clock-rates). Yes, we need to set it to a specific frequency. I will use "assigned-clock-rates" for passing ref_clk frequency in next patch set. > > Seems to me that by the time you get to Linux, the bootloader would > have already set this. Otherwise, how do you boot? Seems like you > would want to read the attr and ensure "ref_clk" freq matches. Yes, ref_clk freq will be already set in device via bootloader. In Kernel, before updating ref_clk freq (if required and passed via DT), we are reading the current ref_clk set in device and only if it is different than what has been passed via DT, we will be updating ref_clk freq, otherwise we just return. > Rob Thanks, Sayali