Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp329198imw; Fri, 15 Jul 2022 04:13:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tjRr0InuF4Z1WSzlNKeYushgJ9c6G0p9HQz2oEZ+Ky1jBqDHNaSv9SIQPuOWGCjPCsLljM X-Received: by 2002:a17:907:7394:b0:72b:44ff:5cec with SMTP id er20-20020a170907739400b0072b44ff5cecmr13803764ejc.670.1657883604380; Fri, 15 Jul 2022 04:13:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657883604; cv=none; d=google.com; s=arc-20160816; b=S/kXPJkrynm3FvmFAjFERfc3LopPYFCM14wYJ5woO55qlteNYNEfDiF6CdP4NrXTTj QtTEi3ny96pMBYzSYCUEbUlzj3njGLQbkIS+K4Wo1UiMFlWS2x8QGeEZdUKa6d7b54Us O5DzciJKIFkEPnfdqvJaAZoUbpJXKe1eAewpzl8mVn4cfKf+fR1S4wm6PZsvzjrzBkoC eDC23geqS6vAiuRHM01R1uiCu7vWhCIODE77SM7o2zzaf+rlynMP943y/VoslApcsfU+ YMen4icLwKbZK3USqMyD4fSzP7hDOb7nppzj7SmHVvhB4jiwkLHnPMToTD49WEFsoI4+ sBVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Valzg4MdQM0s6Xay0/0OhLA2dJ21OLQUFF2eZQYgXgA=; b=JgsoRPnZOux7km6a/mJtGtt3S7mlfkaeUcxdD4CfZTnt7DDnIOT9LYNBjWvjwKp24o 1yZpB4Aj82xQ1G5BU0VyTaaW3l1/lUTqZtnCxfjBccyKwkiVHrwW1q5GP+m8tCL3gHTX a45+0Eb7YMdzvak43ifh8cyR7N74wiP6xOIE/C+THdv80T+ktWcKndDZLV9IEAo8bxTM oZneDVLRgk1hHC/fqizoogQhkLutUQWsxrUiKTaZQ+G45oyS+L2GKn0A3T76NY0RRGj+ IMlpXmSGzaynBdqx5BXkuoe9tdAZMA492BXJAENzT4WDDccq9mQTewJgxFsKvPhOeUdu YpJQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=m3pDjO4M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i41-20020a0564020f2900b0043a86c4afabsi5017765eda.152.2022.07.15.04.12.59; Fri, 15 Jul 2022 04:13:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=m3pDjO4M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232344AbiGOLEH (ORCPT + 99 others); Fri, 15 Jul 2022 07:04:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232296AbiGOLEF (ORCPT ); Fri, 15 Jul 2022 07:04:05 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABA5314D23 for ; Fri, 15 Jul 2022 04:04:03 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id g16-20020a17090a7d1000b001ea9f820449so11207946pjl.5 for ; Fri, 15 Jul 2022 04:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Valzg4MdQM0s6Xay0/0OhLA2dJ21OLQUFF2eZQYgXgA=; b=m3pDjO4Mg+N5AN7bxsMHxeVwbcfVtID/FmTJdKEfO1F/VozkzhJH2LCAT/bvz69gxY Fk91SyHAClxBFvpCg6KkirrHFB1ErGIXoCJ1Jb9SLim/Sl2nHSv+U5Z37bsfM9I0s2DE YiWRmLLPO/pI/PaQaYPv/lDWLnukIFkFFq6PE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Valzg4MdQM0s6Xay0/0OhLA2dJ21OLQUFF2eZQYgXgA=; b=xAwJOwEma7wrmoJMX6Fvfmnr94gnGI7RhdcYCrKCS7eWSIffd12L13pBb5cWkSynPD bvGCabcj7fwWuUCgNuLJQzmyB5YieJ215EQGhm70DhG6eCsGGDYjbpT2+PYzTwy6Xzkt lHu5jnN0eNkKemr7myCsxcwwu4j6xX/4ZP26MMJOQTcVABcOXVJfTe/LCrtgjJGk8S4+ Bddj5jc0nRoJqmE4d3NEdwgrFSIxnPuUO/3xU7xa1mWGxL/2qUVoXCk1gKCw+eMFe5uI wP4bWjO/VZmN9wHX/rwU+oa3KdzRpDTObNrXH+1G7O/Z1CMpHZQfdSqeLeBZ3Ox1Efo1 4H0g== X-Gm-Message-State: AJIora8uUmp5me9AUOMlfGNY0KriTn7N9P7t+9/n0Y+5XBO3zNcKyol9 sTObsMLf+5YPOQX6oQTT0XHagw== X-Received: by 2002:a17:902:e749:b0:16c:3d6f:aba3 with SMTP id p9-20020a170902e74900b0016c3d6faba3mr12764452plf.135.1657883043108; Fri, 15 Jul 2022 04:04:03 -0700 (PDT) Received: from dlunevwfh.roam.corp.google.com (n122-107-196-14.sbr2.nsw.optusnet.com.au. [122.107.196.14]) by smtp.gmail.com with ESMTPSA id d64-20020a623643000000b0052b2e8d0894sm2126836pfa.16.2022.07.15.04.03.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Jul 2022 04:04:02 -0700 (PDT) From: Daniil Lunev To: Adrian Hunter , Bart Van Assche Cc: Daniil Lunev , Alim Akhtar , Avri Altman , Bean Huo , "James E.J. Bottomley" , Jonathan Corbet , "Martin K. Petersen" , Randy Dunlap , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: [PATCH] scsi: ufs: ufshcd: Read device property for ref clock Date: Fri, 15 Jul 2022 21:03:53 +1000 Message-Id: <20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeid> X-Mailer: git-send-email 2.31.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org UFS storage devices require bRefClkFreq attribute to be set to operate correctly at high speed mode. The necessary value is determined by what the SoC / board supports. The standard doesn't specify a method to query the value, so the information needs to be fed in separately. DT information feeds into setting up the clock framework, so platforms using DT can get the UFS reference clock frequency from the clock framework. A special node "ref_clk" from the clock array for the UFS controller node is used as the source for the information. On the platforms that do not use DT (e.g. Intel), the alternative mechanism to feed the intended reference clock frequency is necessary. Specifying the necessary information in DSD of the UFS controller ACPI node is an alternative mechanism proposed in this patch. Those can be accessed via firmware property facility in the kernel and in many ways simillar to querying properties defined in DT. This patch introduces a small helper function to query a predetermined ACPI supplied property of the UFS controller, and uses it to attempt retrieving reference clock value, unless that was already done by the clock infrastructure. Signed-off-by: Daniil Lunev --- Documentation/scsi/ufs.rst | 15 +++++++++++++++ drivers/ufs/core/ufshcd.c | 16 ++++++++++++++++ 2 files changed, 31 insertions(+) diff --git a/Documentation/scsi/ufs.rst b/Documentation/scsi/ufs.rst index fbac745b783ce..885b1a736e3f3 100644 --- a/Documentation/scsi/ufs.rst +++ b/Documentation/scsi/ufs.rst @@ -17,6 +17,8 @@ Universal Flash Storage 3.2 UTP Transfer requests 3.3 UFS error handling 3.4 SCSI Error handling + 4. BSG Support + 5. UFS Reference Clock Frequency configuration 1. Overview @@ -193,3 +195,16 @@ UFS specifications can be found at: - UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf - UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf + +5. UFS Reference Clock Frequency configuration +============================================== + +Devicetree can define a clock named "ref_clk" under the UFS controller node +to specify the intended reference clock frequency for the UFS storage +parts. ACPI-based system can specify the frequency using ACPI +Device-Specific Data property named "ref-clk-freq". In both ways the value +is interpreted as frequency in Hz and must match one of the values given in +the UFS specification. UFS subsystem will attempt to read the value when +executing common controller initialization. If the value is available, UFS +subsytem will ensure the bRefClkFreq attribute of the UFS storage device is +set accordingly and will modify it if there is a mismatch. diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index ce86d1b790c05..78242f189f636 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -8536,6 +8536,19 @@ static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on) return ret; } +static enum ufs_ref_clk_freq ufshcd_parse_ref_clk_property(struct ufs_hba *hba) +{ + u32 freq; + int ret = device_property_read_u32(hba->dev, "ref-clk-freq", &freq); + + if (ret) { + dev_dbg(hba->dev, "Cannnot query 'ref-clk-freq' property = %d", ret); + return REF_CLK_FREQ_INVAL; + } + + return ufs_get_bref_clk_from_hz(freq); +} + static int ufshcd_init_clocks(struct ufs_hba *hba) { int ret = 0; @@ -8629,6 +8642,9 @@ static int ufshcd_hba_init(struct ufs_hba *hba) if (err) goto out_disable_hba_vreg; + if (hba->dev_ref_clk_freq == REF_CLK_FREQ_INVAL) + hba->dev_ref_clk_freq = ufshcd_parse_ref_clk_property(hba); + err = ufshcd_setup_clocks(hba, true); if (err) goto out_disable_hba_vreg; -- 2.31.0