Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3651827pxb; Mon, 1 Feb 2021 00:35:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkV1+vPZbESe+srf//7/+v062pm8wPHpNnGsNP1HtVbE11G912eFOJ+heawP8zQ5oa4494 X-Received: by 2002:a17:906:c793:: with SMTP id cw19mr16165954ejb.246.1612168510189; Mon, 01 Feb 2021 00:35:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612168510; cv=none; d=google.com; s=arc-20160816; b=SgVlwsqIKJI2AR4GywRa6Wf5CkhHeCVNSKxF+LQ5NU3267PBZTI1GlbxlfdSJE7gjO ts7LzeuTWEu32/MxvmXkWIirvz4kwR5Vr+Ubl0xPE7caLjSm0fpKXkTMP6V0nCkalbv0 n3QH0OHbZfFYD+WJS13zqkhcBptfsqZ4lSrm8sJuigksubip5oacpm7iy+n46txEaVgy tC+oFQrtxozeqbPkQ0HrNxDSTFa0L/BojooqRdRtSxXWBPTpqkjbuyrW2NXlfebF0Wys xu8q0iPgjpfBFB8AzhBEbOsNxj5tRfi+IUF9GbnRNKFzLxPdd1RoqRjyFLTpZblIJu2e qFJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :sender:dkim-signature; bh=6EzIkNA3acQs1j+OyBpJRN8xkjdhbxTtElMpjG4WLrs=; b=jKbs3Vfy/OOCHrfPQOFI84wIdjcPwaF0w55wJceR3Mq8R55EtIDTv8KqabafjtKfMc +nY+QNviuRKwpMJprglfC1nuCvNa8ciRXtUzyu5GoCGk2O64fbuDc8r/cu/MbBAuzg6d XZ5YhVuOPSCd/NnstGGuGjZAfEUs6+RMhcTM4Us8piOx9afZj9mDOITqO+5nZMFWAZCJ wRiimAMt1KbHrpQN71iMnxY63xD2jrlgh8lCZlbfN/D24zoc+FMbjaUTSJOoHvgb6YyY NGlbDCfl56+NhG9LtvJVtrEP7J7adMs+crpK2EM4OU8U3hKdf07FtTq+hQCEaf5MH0cP hpaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b=TtBHEASv; 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 a1si10864215edq.48.2021.02.01.00.34.45; Mon, 01 Feb 2021 00:35:10 -0800 (PST) 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=@mg.codeaurora.org header.s=smtp header.b=TtBHEASv; 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 S229736AbhBAIcm (ORCPT + 99 others); Mon, 1 Feb 2021 03:32:42 -0500 Received: from so15.mailgun.net ([198.61.254.15]:30716 "EHLO so15.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230080AbhBAIck (ORCPT ); Mon, 1 Feb 2021 03:32:40 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1612168339; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=6EzIkNA3acQs1j+OyBpJRN8xkjdhbxTtElMpjG4WLrs=; b=TtBHEASvUvKiqPYmWsMmKO7oNGUpfaBu329Hds2hAd2hNPfDD3UBa/CS5MPXuD2ERWjS707a Kaw1kk9R6FZvC2r6OtvV/w4JUqU927k6BZUvTaBtljSBbz3/lVlFrj0sXCM8MMhofLegdZJZ PqIoevhAazcnwsTkrr2XOYLHvMc= X-Mailgun-Sending-Ip: 198.61.254.15 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n04.prod.us-west-2.postgun.com with SMTP id 6017bc72f71e8b99346c0ff1 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 01 Feb 2021 08:31:46 GMT Sender: nitirawa=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 9CDEFC43463; Mon, 1 Feb 2021 08:31:46 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nitirawa) by smtp.codeaurora.org (Postfix) with ESMTPSA id 84644C433ED; Mon, 1 Feb 2021 08:31:45 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Feb 2021 14:01:45 +0530 From: nitirawa@codeaurora.org To: Avri Altman Cc: asutoshd@codeaurora.org, cang@codeaurora.org, stummala@codeaurora.org, vbadigan@codeaurora.org, alim.akhtar@samsung.com, jejb@linux.ibm.com, martin.petersen@oracle.com, stanley.chu@mediatek.com, beanhuo@micron.com, bvanassche@acm.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, nitirawa@codeaurora.org Subject: Re: [PATCH V1 0/3] scsi: ufs: Add a vops to configure VCC voltage level In-Reply-To: References: <1611852899-2171-1-git-send-email-nitirawa@codeaurora.org> Message-ID: <48fbd86b319697fced61317bd15c4779@codeaurora.org> X-Sender: nitirawa@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-01-31 19:32, Avri Altman wrote: >> >> UFS specification allows different VCC configurations for UFS devices, >> for example, >> (1)2.70V - 3.60V (For UFS 2.x devices) >> (2)2.40V - 2.70V (For UFS 3.x devices) >> For platforms supporting both ufs 2.x (2.7v-3.6v) and >> ufs 3.x (2.4v-2.7v), the voltage requirements (VCC) is 2.4v-3.6v. >> So to support this, we need to start the ufs device initialization >> with >> the common VCC voltage(2.7v) and after reading the device descriptor >> we >> need to switch to the correct range(vcc min and vcc max) of VCC >> voltage >> as per UFS device type since 2.7v is the marginal voltage as per specs >> for both type of devices. >> >> Once VCC regulator supply has been intialised to 2.7v and UFS device >> type is read from device descriptor, we follows below steps to >> change the VCC voltage values. >> >> 1. Set the device to SLEEP state. >> 2. Disable the Vcc Regulator. >> 3. Set the vcc voltage according to the device type and reenable >> the regulator. >> 4. Set the device mode back to ACTIVE. >> >> The above changes are done in vendor specific file by >> adding a vops which will be needed for platform >> supporting both ufs 2.x and ufs 3.x devices. > The flow should be generic - isn't it? > Why do you need the entire flow to be vendor-specific? > Why not just the parameters vendor-specific? > > Thanks, > Avri Hi Avri, This vops change was done as per the below mail thread discussion where it was decided to go with vops and let vendors handle it, until specs provides more clarity. https://www.spinics.net/lists/kernel/msg3754995.html Regards, Nitin