Received: by 10.192.165.148 with SMTP id m20csp276015imm; Thu, 3 May 2018 20:05:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqGOyw54B9cRGtlLFAX46sbNRG3BCQolHY9N+fEsmddKypFE+65O1LRWaytAShiDkuJilHB X-Received: by 2002:a17:902:c24:: with SMTP id 33-v6mr25511128pls.88.1525403156887; Thu, 03 May 2018 20:05:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525403156; cv=none; d=google.com; s=arc-20160816; b=Sc80XORZTEBKXQjX7ZU8T/nO9Xc2JL3QZjc2VB1nYlAK7UU0U0egPcmcLfFDpteJiT /igti5tMdZWFoGzxbPXrM5AbJdo4hRlKnulnk8t7/Sd9ds9L8wAODRlfxamBIbCw3vOJ 1AlcJsGpVOv2VhnKmN80vqOPbppjYI0DONhYZFppkB0xeFyUHluBrEFXXoS5FzRTKbsW May2NVSwNouIV77k65TYGYUBVZq/KRSdLRYIqjEC9tzxXuNmxugZPwS7FDMjagmCslJG Ogzro5L1AKZkYiu8F7Xa5qHv0cNv04qJinYJAN7t9sywf6wHjP5LKJQ09HbeavO+wtI4 hD3A== 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=RKuk+FCAJFymckQ63Vcyk0ymiF7gtwR8Sk9USwO9rzo=; b=tx/Gey+L1CtoxX2nhxnwJltOog6baWzY+QMAiifMgybw1wYIZquNYBKp0LeyGrg4SE QPZGETW1rM7oxHzzK2xQb3WzbEWdF5ZRnRV2CT0r/cIxF+D/LO2EvsIE696y1YWMu7MN gQsRZDmL7/Ql6AeVsabWaX+iX9XX0IUEy/irFxbvmVAOEGeNVPpT9LzwfuHoSoqZuPZQ IpggtAKMguwH7+0pj7EGaHBQIbhqqvtsU0rUFCOTOXVvyKK+j7A4/BKM0C9IG3mKjugu V6ImlflN4vNJlOe3679SyVDFMQf1KHWEbeSEQwO+kfrnWJUe15AGGp8XzAC7yjaHutgG 2l9Q== 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 h193-v6si12262445pgc.57.2018.05.03.20.05.41; Thu, 03 May 2018 20:05:56 -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 S1751287AbeEDDES (ORCPT + 99 others); Thu, 3 May 2018 23:04:18 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:44858 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751236AbeEDDEQ (ORCPT ); Thu, 3 May 2018 23:04:16 -0400 X-UUID: f68bc0debf1a401dba9b012370727092-20180504 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 293934180; Fri, 04 May 2018 11:04:14 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs03n1.mediatek.inc (172.21.101.181) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 May 2018 11:04:12 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Fri, 4 May 2018 11:04:12 +0800 Message-ID: <1525403052.14792.131.camel@mtkswgap22> Subject: Re: [PATCH V4 5/8] soc: mediatek: pwrap: add pwrap for mt6797 SoCs From: Sean Wang To: Argus Lin CC: Rob Herring , Mark Rutland , Matthias Brugger , Catalin Marinas , Will Deacon , Chenglin Xu , , , , Chen Zhong , Christophe Jaillet , , , , Date: Fri, 4 May 2018 11:04:12 +0800 In-Reply-To: <1525328436.6214.10.camel@mtkswgap22> References: <20180502092112.3991-1-argus.lin@mediatek.com> <20180502092112.3991-6-argus.lin@mediatek.com> <1525320067.14792.95.camel@mtkswgap22> <1525328436.6214.10.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 Thu, 2018-05-03 at 14:20 +0800, Argus Lin wrote: > On Thu, 2018-05-03 at 12:01 +0800, Sean Wang wrote: > > }; [...] > > > @@ -1503,11 +1581,13 @@ static int pwrap_probe(struct platform_device *pdev) > > > if (IS_ERR(wrp->base)) > > > return PTR_ERR(wrp->base); > > > > > > - wrp->rstc = devm_reset_control_get(wrp->dev, "pwrap"); > > > - if (IS_ERR(wrp->rstc)) { > > > - ret = PTR_ERR(wrp->rstc); > > > - dev_dbg(wrp->dev, "cannot get pwrap reset: %d\n", ret); > > > - return ret; > > > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_RESET)) { > > > + wrp->rstc = devm_reset_control_get(wrp->dev, "pwrap"); > > > > there should be a reset bit present for pwrap on infrasys. > > > > the specific condition can be dropped when the reset cell is exported from infrasys and then the device has a reference to it. > hmm, I think it need to keep here. > because after pwrap initialized, it can't be reset alone. > It needs to reset PMIC simultaneously, too. Reset a pair, either a master or its slave, all had been a part of pwrap_init. The reset controller provided here is just to reset pwrap device. And for its slave reset, it should be done by pwrap_reset_spislave. So for MT6397, it should be able to fall into the same procedure. > > > > > + if (IS_ERR(wrp->rstc)) { > > > + ret = PTR_ERR(wrp->rstc); > > > + dev_dbg(wrp->dev, "cannot get pwrap reset: %d\n", ret); > > > + return ret; > > > + } > > > } > > > > > > if (HAS_CAP(wrp->master->caps, PWRAP_CAP_BRIDGE)) { > > > @@ -1549,9 +1629,17 @@ static int pwrap_probe(struct platform_device *pdev) > > > if (ret) > > > goto err_out1; > > > > > > - /* Enable internal dynamic clock */ > > > - pwrap_writel(wrp, 1, PWRAP_DCM_EN); > > > - pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD); > > > + /* > > > + * add dcm capability check > > > + */ > > > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_DCM)) { > > > > the specific condition can be dropped since so far all devices the driver can support are owning PWRAP_CAP_DCM > We did not support DCM for future chips. > MT6797 is the last one. > This why I want to add judgement here. The series is only for MT6797 pwrap, so it's fine with only adding these things the SoC actually relies on. PWRAP_CAP_DCM should not be added until a new SoC without dcm is really introduced. > > > > > + if (wrp->master->type == PWRAP_MT6797) > > > + pwrap_writel(wrp, 3, PWRAP_DCM_EN); > > > > the setup for MT6797 can be moved into .init_soc_specific callback ? > > I think put it here is more generally. > > > > > + else > > > + pwrap_writel(wrp, 1, PWRAP_DCM_EN); > > > + > > > + pwrap_writel(wrp, 0, PWRAP_DCM_DBC_PRD); > > > + } > > > > > > /* > > > * The PMIC could already be initialized by the bootloader. > > > @@ -1580,6 +1668,12 @@ static int pwrap_probe(struct platform_device *pdev) > > > pwrap_writel(wrp, wrp->master->wdt_src, PWRAP_WDT_SRC_EN); > > > pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN); > > > pwrap_writel(wrp, wrp->master->int_en_all, PWRAP_INT_EN); > > > + /* > > > + * We add INT1 interrupt to handle starvation and request exception > > > + * If we support it, we should enable them here. > > > + */ > > > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_INT1_EN)) > > > + pwrap_writel(wrp, wrp->master->int1_en_all, PWRAP_INT1_EN); > > > > > > > if there is no explicitly enabling on INT1, then ISR handling for INT1 is also unnecessary > > It's ok for me. > > > > > irq = platform_get_irq(pdev, 0); > > > ret = devm_request_irq(wrp->dev, irq, pwrap_interrupt, > > > > > > > >