Received: by 10.192.165.148 with SMTP id m20csp247642imm; Thu, 19 Apr 2018 20:51:26 -0700 (PDT) X-Google-Smtp-Source: AIpwx491UFYA/DVjAlMZnA02XhCsjie/zHupgFH6axU8F3SQS5N3XcDE16i9UXj9zx+BEtJryT6H X-Received: by 10.101.82.133 with SMTP id y5mr7136300pgp.27.1524196285914; Thu, 19 Apr 2018 20:51:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524196285; cv=none; d=google.com; s=arc-20160816; b=ECrxA+yXTGd02M7zSNEwF05t2SK9qV++9cYzv8tShCgFcejT2npW0ltKKL0S8Jr63a 4EllDvqtkX1RjPEZ51Oo53MBy782MD9G+PwoRqcBdqdGp6FDFtLy7qjkOCzMDZEHQ2gA hWvLY0GomhvSagGVFR3T8lVw2eENrKoZFKQkaJpGl3+m3p5pAa2WNZBTB6K4UynAsH7y wuCssMxfptvkrh4K6Ug2AQmk6Xf1Q4B4anH86z2S0X41eKHSpcEcf4iJ7sHwON8VYRZA J3XntO6sR5JlV6V2rGpkJz58W2Ci+srGvvGdw2sZOrRwOw/aYU5VPLAxrBogrQZDhmFi 8/+A== 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=PXAafOhW6tj/mLF9QuAg24KrXEBbwULZWB5DEjOydNA=; b=P/P2W9kzbQ3z1E40/sjAO/5BTR2kTljbn8/yJV4mGMTPuKEp1/fTHLktRE6AHKecoK U8zgGMTetVNeBx54WNdiCsivVZKly3hXv1K/ZpQrGhL/8x9NAcmmRXrj5tS7HWb76aNz XJsRl3dU5Y67154RSpxwsSXZg/MhDgDrnFTqqku3ULIPLEWEBAynDnE9C5lBtbDqZsAd gUTgo4MootQan7JVXjPwzMklmYG5knFuQwFUsPekTFpktEdJH76lzaKHHF++Pxz11Bzx mIC2RhCCk0rp0llO5kVtecS1aiS32+bsjsdhcWMJpCYnQFZkuQDL/NnBReLg8527y8hF jQBw== 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 n11-v6si4499299plp.221.2018.04.19.20.51.09; Thu, 19 Apr 2018 20:51:25 -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 S1754269AbeDTDt7 (ORCPT + 99 others); Thu, 19 Apr 2018 23:49:59 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:15958 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754155AbeDTDt5 (ORCPT ); Thu, 19 Apr 2018 23:49:57 -0400 X-UUID: ccbf26155af945d7b24ce3fef72de5e8-20180420 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1397603040; Fri, 20 Apr 2018 11:49:51 +0800 Received: from mtkcas09.mediatek.inc (172.21.101.178) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Apr 2018 11:49:50 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas09.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Fri, 20 Apr 2018 11:49:50 +0800 Message-ID: <1524196190.26454.3.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: Fri, 20 Apr 2018 11:49:50 +0800 In-Reply-To: <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com> References: <0fc10b2498c6dbe20141831c722c32cc74330d3d.1522736996.git.sean.wang@mediatek.com> <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com> 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 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! > 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, > > }, > > }; > > > >