From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0D7BC433E0 for ; Thu, 30 Jul 2020 08:56:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ACF98206E6 for ; Thu, 30 Jul 2020 08:56:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="gCLfPftv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACF98206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nxp.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=K+dj7hHFjPNUYCdU67EphKH1TJMaae8WFRU1Sa+Psgo=; b=gCLfPftvg/uvtcBQiratlgocN ATfBFXdQl1xtNC55Dt9ugmxu0xK37sOwFhW2Xym6MFBeLFdxf+4VaBOBQAn63wIl3yamBYPZdf46o hHE8kd9Tnl4qFNy34sPCika+UujkBO4zXZD0rDvah9HgwJ/31GZMf8Je6jOEWlbWs6ZyNg+Az5udD iFCUOdgJOU/3Nza6zZdS2QZxRCpn7G204wSo0HryLjcbfHfbPF5SUWFV5wKob69tmHajdyxmdKCht bNaI23cUNahzJr6mMvRPy/zlX3BL8d93tyC1/L2bcPTiUNkUGpjXBuFWsLhO9JBY8oMqlYoQpFVCT fIEshJWNQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k14LJ-0000N8-KW; Thu, 30 Jul 2020 08:55:13 +0000 Received: from inva021.nxp.com ([92.121.34.21]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k14LG-0000Lp-8n for linux-arm-kernel@lists.infradead.org; Thu, 30 Jul 2020 08:55:11 +0000 Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 9F5ED2011FB; Thu, 30 Jul 2020 10:55:08 +0200 (CEST) Received: from inva024.eu-rdc02.nxp.com (inva024.eu-rdc02.nxp.com [134.27.226.22]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 91B3B200263; Thu, 30 Jul 2020 10:55:08 +0200 (CEST) Received: from localhost (fsr-ub1664-175.ea.freescale.net [10.171.82.40]) by inva024.eu-rdc02.nxp.com (Postfix) with ESMTP id 7932920340; Thu, 30 Jul 2020 10:55:08 +0200 (CEST) Date: Thu, 30 Jul 2020 11:55:08 +0300 From: Abel Vesa To: Philipp Zabel Subject: Re: [PATCH 11/17] clk: imx: Add blk_ctrl combo driver Message-ID: <20200730085508.ddxhb4rjnzwooh2z@fsr-ub1664-175> References: <1596024483-21482-1-git-send-email-abel.vesa@nxp.com> <1596024483-21482-12-git-send-email-abel.vesa@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180622 X-Virus-Scanned: ClamAV using ClamSMTP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200730_045510_547318_E9A3D165 X-CRM114-Status: GOOD ( 25.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dong Aisheng , Rob Herring , Peng Fan , Fugang Duan , Anson Huang , devicetree@vger.kernel.org, Stephen Boyd , Mike Turquette , Linux Kernel Mailing List , NXP Linux Team , Sascha Hauer , Fabio Estevam , Shawn Guo , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 20-07-29 14:46:28, Philipp Zabel wrote: > Hi Abel, > > On Wed, 2020-07-29 at 15:07 +0300, Abel Vesa wrote: > > On i.MX8MP, there is a new type of IP which is called BLK_CTRL in [...] > > + > > +static int imx_blk_ctrl_reset_set(struct reset_controller_dev *rcdev, > > + unsigned long id, bool assert) > > +{ > > + struct imx_blk_ctrl_drvdata *drvdata = container_of(rcdev, > > + struct imx_blk_ctrl_drvdata, rcdev); > > + unsigned int offset = drvdata->rst_hws[id].offset; > > + unsigned int shift = drvdata->rst_hws[id].shift; > > + unsigned int mask = drvdata->rst_hws[id].mask; > > + void __iomem *reg_addr = drvdata->base + offset; > > + unsigned long flags; > > + u32 reg; > > + > > + if (assert) { > > + pm_runtime_get_sync(rcdev->dev); > > + spin_lock_irqsave(&drvdata->lock, flags); > > + reg = readl(reg_addr); > > + writel(reg & ~(mask << shift), reg_addr); > > + spin_unlock_irqrestore(&drvdata->lock, flags); > > + } else { > > + spin_lock_irqsave(&drvdata->lock, flags); > > + reg = readl(reg_addr); > > + writel(reg | (mask << shift), reg_addr); > > + spin_unlock_irqrestore(&drvdata->lock, flags); > > + pm_runtime_put(rcdev->dev); > > This still has the issue of potentially letting exclusive reset control > users break the device usage counter. > > Also shared reset control users start with deassert(), and you end probe > with pm_runtime_put(), so the first shared reset control user that > deasserts its reset will decrement the dev->power.usage_count to -1 ? > For multiple resets being initially deasserted this would decrement > multiple times. > > I think you'll have to track the (number of) asserted reset bits in this > reset controller and limit when to call pm_runtime_get/put_sync(). > Yes, you're right. I'll add a mask, and for each assert, the according bit will get set, and for each deasssert the same bit will get cleared. And when the mask has at least one bit set, the pm_runtime_get gets called and when the mask is 0, the pm_runtime_put_sync will be called. Does that sound OK ? > > + } > > + > > + return 0; > > +} > > + > > +static int imx_blk_ctrl_reset_reset(struct reset_controller_dev *rcdev, > > + unsigned long id) > > +{ > > + imx_blk_ctrl_reset_set(rcdev, id, true); > > + return imx_blk_ctrl_reset_set(rcdev, id, false); > > Does this work for all peripherals? Are there none that require the > reset line to be asserted for a certain number of bus clocks or similar? As of now, there is no user that calls reset. All the users call the assert and then deassert. As for the number of clocks for reset, I'll try to have a chat to the HW design team and then come back with the information. > > > +} > > + _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel