Received: by 10.192.165.148 with SMTP id m20csp3183775imm; Mon, 23 Apr 2018 01:59:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+ePpOwJGXo9MAR+q8/LxhyKgwceZwRMn3Lcy8H5x9BUwfmWX1brkZi5hJTsZB0cS5WTYiZ X-Received: by 2002:a17:902:aa94:: with SMTP id d20-v6mr20682101plr.323.1524473981653; Mon, 23 Apr 2018 01:59:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524473981; cv=none; d=google.com; s=arc-20160816; b=Grf2/U2LxvzFuqSZM5W+48WDRB32TLqnuG9VC3VEv8KwP3HhNdEVDsaDEtGYZT7mXl UV2tYH0I2iUKOKEjER6iWBTjG53gUzhBRv8/j77ep4g0AdsLbtUxUlRZTYfyt6NegP5b /gyLcXpxOI53uBBcqAWSbVgIhdVChGiLQZll9B9Uu9vV76XNfaMkF0UNzUmIsrOpcCXa lMr1v7Hn8WcwkmxOzcCmIv29NX1zdMpaL9oz1sOZOFAAAaGu6tQ61h9ECMDcMxQLlNHN e9pfsEi78fseSLZSgwVxGtBNBR3Aov7AIR+rLBE/P3OGqqDDDUs42nDXtbQUAC9zzwyS HA9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=R/j3HaLarIJHBl9btzSt0ukvsR51WPJTuUxZqyEEjJ8=; b=LoBgWJu/RTFyrKJoCX1LR4t4lx2x607St0nrOxjwttIrTXTXyz9BrEHbous3cfcm1D oWln0kuZRnyV63fMCUvOGahkm3DXa17OZPd+gJ4uYMubfgGzrTybwNWVR7x7NmYaxI8C g3Motch02SpEZwC0y3BwIqd6m6TV7vTG02pl+tCFt9Uze7AyMX0yGw6B6bNaAjPjoy4V r7h/LhRA7LrvofvNZ9d5G23UtT7NjS4iSQO8thyZ4KevmKprp37dsGfEQCGg6BKZgFEW RWRq9lIFoxw+/6jqKlFhSzmbntIrnEexr5WKJ0Xg7RA+u192g742iEGUKMjvBwOVWIXq 8+lQ== 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 v12-v6si11513135plk.62.2018.04.23.01.59.27; Mon, 23 Apr 2018 01:59:41 -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 S1754308AbeDWI6W (ORCPT + 99 others); Mon, 23 Apr 2018 04:58:22 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:9730 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754130AbeDWI6T (ORCPT ); Mon, 23 Apr 2018 04:58:19 -0400 X-UUID: 739699560b674f3ea5343009516011a6-20180423 Received: from mtkexhb01.mediatek.inc [(172.21.101.102)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 148685141; Mon, 23 Apr 2018 16:58:16 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Apr 2018 16:58:14 +0800 Received: from [172.21.77.33] (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:58:14 +0800 Message-ID: <1524473894.12322.13.camel@mtkswgap22> Subject: Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable From: Sean Wang To: Matthias Brugger CC: , , , , , , , , , "Ulf Hansson" , Weiyi Lu Date: Mon, 23 Apr 2018 16:58:14 +0800 In-Reply-To: <1524196190.26454.3.camel@mtkswgap22> References: <0fc10b2498c6dbe20141831c722c32cc74330d3d.1522736996.git.sean.wang@mediatek.com> <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com> <1524196190.26454.3.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-04-20 at 11:49 +0800, Sean Wang wrote: > On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote: > > > > On 04/03/2018 09:15 AM, sean.wang@mediatek.com wrote: > > > 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. > > > > > > Signed-off-by: Sean Wang > > > Cc: Matthias Brugger > > > Cc: Ulf Hansson > > > Cc: Weiyi Lu > > > --- > > > drivers/soc/mediatek/mtk-scpsys.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c > > > index f9b7248..19aceb8 100644 > > > --- a/drivers/soc/mediatek/mtk-scpsys.c > > > +++ b/drivers/soc/mediatek/mtk-scpsys.c > > > @@ -121,6 +121,7 @@ struct scp_domain_data { > > > u32 bus_prot_mask; > > > enum clk_id clk_id[MAX_CLKS]; > > > bool active_wakeup; > > > + u32 us_sram_fwait; > > > > Before adding more and more fields to scp_domain_data which get checked in if's, > > I'd prefer to add a caps field used for bus_prot_mask, active_wakeup in a first > > patch and add the cap FORCE_WAIT in a second patch. > > > > Can you help to implement this Sean, or shall I give it a try? > > > > Sure, I have a willing to do and then see if you're also fond of it. > > thanks! > Hi, Matthias I have done it in [1], but in the version, I doesn't merge bus_prot_mask into caps fields because bus_prot_mask is actually mapped into realistic hardware bitmap like sram_pdn_bits, sram_pdn_ack_bits, sta_mask is doing. It should be more straightforward to port a new SoC to scpsys when there are standalone fields to hold these hardware configuring bitmaps. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-April/012884.html Sean > > Regards, > > Matthias > > > > > }; > > > > > > struct scp; > > > @@ -234,11 +235,16 @@ 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 (!scpd->data->us_sram_fwait) { > > > + 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 { > > > + usleep_range(scpd->data->us_sram_fwait, > > > + scpd->data->us_sram_fwait + 100); > > > + }; > > > > > > if (scpd->data->bus_prot_mask) { > > > ret = mtk_infracfg_clear_bus_protection(scp->infracfg, > > > @@ -783,6 +789,7 @@ static const struct scp_domain_data scp_domain_data_mt7622[] = { > > > .clk_id = {CLK_NONE}, > > > .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB, > > > .active_wakeup = true, > > > + .us_sram_fwait = 12000, > > > }, > > > }; > > > > > > >