Received: by 10.192.165.148 with SMTP id m20csp3169332imm; Mon, 23 Apr 2018 01:38:48 -0700 (PDT) X-Google-Smtp-Source: AIpwx48jd7QasfIJHmzSrEuggN72WmAJjl/GP0TxB86eAlPPdOu8DZjd6iWV2Ipj62qnkMSomFeR X-Received: by 10.99.52.76 with SMTP id b73mr16565011pga.258.1524472728653; Mon, 23 Apr 2018 01:38:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524472728; cv=none; d=google.com; s=arc-20160816; b=SdqSOXrAC0nj+pbhr1TzRnXXiYKUBNgQyLRV+AvVuhG+IcqNn4yy5XnWWm6zBaPNDU Jh7STeDKQa9wRji4omPsm2MpVhS6GTo0+CCq+zleozBXMq04YWcCPV9UfxvhK3DlkcQE lcGAz2AZaozcJ8CkWWMEaxVxbWWtsz13DsqiX3+cndpA5RV1/z+gNZ7KMTSqG6JZk6jv 5hbvx0tbSVUYTQs1MIHFzt+cZJjwkbTco16P9YPrh0ZZwSu/pB8JdwXlVfxN1ArX1qI/ SQagqgKLbyHx6wHfE/YjA6VON/41jZ7xIjp2DoPXeHuV5PjmJO3KVV4h5IyExjE0xhso J08Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:arc-authentication-results; bh=ZMaiStsXCsOyafJJ2z0hmQJdg5h4dvXNtXGUciAqFIM=; b=OYAemq5Nls7QUVPKeiDNsOZSTeR0mjmicnhPbwOkWQh295KJxeHHKSZHMoy3z1f3wn POjG0C7nEkhZc4AdsXzyTEX+JJBsTg0tJEXZNyhns2kNRR+mqquktuJcEopTbPtrdyfz +VEubbzSeoEbpq/7sAIemFVNSL5tScY+cD5+KlEbM5pv5PBVxDtEwkLZ4NyxI2Whmfiu X6z68rCZp/Z0MOLPntrM11jDgojpr81lQmD1g1h20/M/g8bFKvjhPCxDEzm9v4YclGJW e+i5d1buY3sY02HAD0S+91obVEwXCObQPclKuSTdKdp4XITOWUZDqgW5gcXqSfmNkaiq W1xw== ARC-Authentication-Results: i=1; mx.google.com; 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 k5si7399441pgo.673.2018.04.23.01.38.34; Mon, 23 Apr 2018 01:38:48 -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; 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 S1754568AbeDWIg6 (ORCPT + 99 others); Mon, 23 Apr 2018 04:36:58 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:54839 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754460AbeDWIgf (ORCPT ); Mon, 23 Apr 2018 04:36:35 -0400 X-UUID: ea6e97b907a74487a11894dbaee5705f-20180423 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 972982453; Mon, 23 Apr 2018 16:36:31 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs08n1.mediatek.inc (172.21.101.55) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Apr 2018 16:36:24 +0800 Received: from mtkswgap22.mediatek.inc (172.21.77.33) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Mon, 23 Apr 2018 16:36:24 +0800 From: To: , , CC: , , , , , Sean Wang , Weiyi Lu Subject: [PATCH v2 2/2] soc: mediatek: add a fixed wait for SRAM stable Date: Mon, 23 Apr 2018 16:36:22 +0800 Message-ID: <0ef8e87ba7156e626d1a1a48388f222ce917099b.1524472331.git.sean.wang@mediatek.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <2e16481e1477dfae0cfb24568d8111da81d92628.1524472331.git.sean.wang@mediatek.com> References: <2e16481e1477dfae0cfb24568d8111da81d92628.1524472331.git.sean.wang@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Wang MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes stable, which is not like the behavior the other power domains should have. Therefore, it's necessary for such a power domain to have a fixed and well-predefined duration to wait until its managed SRAM can be allowed to access by all functions running on the top. v1 -> v2: - use MTK_SCPD_FWAIT_SRAM flag as an indication requiring force waiting. Signed-off-by: Sean Wang Cc: Matthias Brugger Cc: Ulf Hansson Cc: Weiyi Lu --- drivers/soc/mediatek/mtk-scpsys.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index b1b45e4..d4f1a63 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -32,6 +32,7 @@ #define MTK_POLL_TIMEOUT (jiffies_to_usecs(HZ)) #define MTK_SCPD_ACTIVE_WAKEUP BIT(0) +#define MTK_SCPD_FWAIT_SRAM BIT(1) #define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x)) #define SPM_VDE_PWR_CON 0x0210 @@ -237,11 +238,22 @@ static int scpsys_power_on(struct generic_pm_domain *genpd) val &= ~scpd->data->sram_pdn_bits; writel(val, ctl_addr); - /* wait until SRAM_PDN_ACK all 0 */ - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0, - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT); - if (ret < 0) - goto err_pwr_ack; + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */ + if (!MTK_SCPD_CAPS(scpd, MTK_SCPD_FWAIT_SRAM)) { + ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0, + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT); + if (ret < 0) + goto err_pwr_ack; + } else { + /* + * Currently, MTK_SCPD_FWAIT_SRAM is necessary only for + * MT7622_POWER_DOMAIN_WB and thus just a trivial setup is + * applied here. If there're more domains which need to force + * waiting for its own pre-defined value, the duration should + * be coded in the caps field. + */ + usleep_range(12000, 12100); + }; if (scpd->data->bus_prot_mask) { ret = mtk_infracfg_clear_bus_protection(scp->infracfg, @@ -785,7 +797,7 @@ static const struct scp_domain_data scp_domain_data_mt7622[] = { .sram_pdn_ack_bits = 0, .clk_id = {CLK_NONE}, .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB, - .caps = MTK_SCPD_ACTIVE_WAKEUP, + .caps = MTK_SCPD_ACTIVE_WAKEUP | MTK_SCPD_FWAIT_SRAM, }, }; -- 2.7.4