From patchwork Mon Nov 30 09:16:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stanley Chu X-Patchwork-Id: 11939999 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90FBAC5519F for ; Mon, 30 Nov 2020 09:27:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D2BA42076E for ; Mon, 30 Nov 2020 09:27:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pg72pzcf"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="ZLZKy5wI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D2BA42076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=JIFu9o0ztIsDxwFjUXCvtdxjF8Psn1u38zhrq+Cyqgw=; b=pg72pzcf0AbV84r9Gh++mnWijQ EhrX0VBen8U1i2G/oPayPym1mLNw+7wmrcAJuWBDd2+fY+3IS3jZkbVssOkLc0kg+Oy+BvNcrH8AD J5YGP0sX/LJn3tZ5qT7Lh9Bbt/Jxj43Edjvo7Wh7GzkD3//k8mnt452nO5i2Hol+wAMAl5zIKlIX2 P9az/Kg8Pu0abir3Ons0socsrBY9h4yysBoeFYpSxTQoFy/6nfXQH3FoHV4oLmSH7zhQFooMS2TqN cmv/z9cxrnAQgFXL3ZI4+QLcoD/7WbM1h8Hay+P05S0wEniOk9XzXNn8PywI+ZPD+8BteTkQELzM/ 5GHnsjyQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjfRZ-0007zB-U9; Mon, 30 Nov 2020 09:26:01 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjfRW-0007xJ-6g; Mon, 30 Nov 2020 09:25:59 +0000 X-UUID: 0490401f65ce4450a534ce5d9662a5c8-20201130 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From; bh=i4h3PflF5Bkc2y9daW5QYyLjsw/RtBQt0T1mhBWyqNE=; b=ZLZKy5wIVctzGX+oQaRdItSDZPdEb2y8WsV7fr9/RVi6aUyZCEV26oPBZ47BC8Kgv3ZY9iG69cxuu5zvYjnjAqSRMyd2wLtVQzywSZ5suBicHBBCZwZfFyXvV6LsYI64JY2+ltGoXzxngv81Re8N4TgIVoJDPV9+yur/bj8t1TA=; X-UUID: 0490401f65ce4450a534ce5d9662a5c8-20201130 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1600418236; Mon, 30 Nov 2020 01:25:46 -0800 Received: from mtkmbs08n1.mediatek.inc (172.21.101.55) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 01:16:10 -0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 17:16:10 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 17:16:10 +0800 From: Stanley Chu To: , , , , Subject: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values Date: Mon, 30 Nov 2020 17:16:10 +0800 Message-ID: <20201130091610.2752-1-stanley.chu@mediatek.com> X-Mailer: git-send-email 2.18.0 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201130_042558_641925_4E975A99 X-CRM114-Status: GOOD ( 17.18 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bjorn.andersson@linaro.org, Stanley Chu , alice.chao@mediatek.com, bvanassche@acm.org, andy.teng@mediatek.com, cc.chou@mediatek.com, chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org, nguyenb@codeaurora.org, jiajie.hao@mediatek.com, cang@codeaurora.org, linux-mediatek@lists.infradead.org, peter.wang@mediatek.com, matthias.bgg@gmail.com, beanhuo@micron.com, chaotian.jing@mediatek.com, linux-arm-kernel@lists.infradead.org, asutoshd@codeaurora.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org UFS specficication allows different VCC configurations for UFS devices, for example, (1). 2.70V - 3.60V (By default) (2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in device tree) (3). 2.40V - 2.70V (Supported since UFS 3.x) With the introduction of UFS 3.x products, an issue is happening that UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC regulator on UFU 3.x products with VCC configuration (3) used. To solve this issue, we simply remove pre-defined initial VCC voltage values in UFS driver with below reasons, 1. UFS specifications do not define how to detect the VCC configuration supported by attached device. 2. Device tree already supports standard regulator properties. Therefore VCC voltage shall be defined correctly in device tree, and shall not be changed by UFS driver. What UFS driver needs to do is simply enabling or disabling the VCC regulator only. This is a RFC conceptional patch. Please help review this and feel free to feedback any ideas. Once this concept is accepted, and then I would post a more completed patch series to fix this issue. Signed-off-by: Stanley Chu Reviewed-by: Bjorn Andersson --- drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c index a6f76399b3ae..3965be03c136 100644 --- a/drivers/scsi/ufs/ufshcd-pltfrm.c +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c @@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const char *name, vreg->max_uA = 0; } - if (!strcmp(name, "vcc")) { - if (of_property_read_bool(np, "vcc-supply-1p8")) { - vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV; - vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV; - } else { - vreg->min_uV = UFS_VREG_VCC_MIN_UV; - vreg->max_uV = UFS_VREG_VCC_MAX_UV; - } - } else if (!strcmp(name, "vccq")) { + if (!strcmp(name, "vccq")) { vreg->min_uV = UFS_VREG_VCCQ_MIN_UV; vreg->max_uV = UFS_VREG_VCCQ_MAX_UV; } else if (!strcmp(name, "vccq2")) {