From patchwork Mon Apr 23 08:36:22 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Wang X-Patchwork-Id: 10356409 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id DD65C6019D for ; Mon, 23 Apr 2018 08:36:57 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C942428883 for ; Mon, 23 Apr 2018 08:36:57 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BDFBE289BF; Mon, 23 Apr 2018 08:36:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5F77E28883 for ; Mon, 23 Apr 2018 08:36:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754370AbeDWIg4 (ORCPT ); Mon, 23 Apr 2018 04:36:56 -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 X-MTK: N Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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, }, };