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,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 CB67FC433DF for ; Wed, 12 Aug 2020 07:32:06 +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 99EA4204EC for ; Wed, 12 Aug 2020 07:32:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BEnKGiXe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99EA4204EC 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=dPUnfH7+nTG75QkDoR4/HVmuNN/FcF6M80fH/7JGIVA=; b=BEnKGiXe/EHTYV+avEpWbI5X+ 2yUhjEjcn49UDKm2xx7WyFrc+VhO3WJha8/AUBNVITNw6iyxmKRmG3rfX/KExr2nTh//FZar6sAkC 4NRsnfRuq6iNsdwSvxxZN8dHnwpAQI5gxPpSSNgXS9vr/fr/5wx3IQ3QDkYgFdmDU5D8o0/Cb+nFi +uz8VFGz7CkjmvSpxaG2jh5++jmy6AaM/UdYBKRpDYhNLrxDFZThwg/+WdZYZeLZnAm0AT7vYReCx G4pad/NiB2Z9Z8cMrD+aX7Nz5MQWL7KBTW9Hu8eyxuHOjt/J2bqlMpM69KB/IRiDuxvrprQTu+4I5 j5QDpgnPw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k5lBz-0000XR-5w; Wed, 12 Aug 2020 07:28:59 +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 1k5lBw-0000WV-QP for linux-arm-kernel@lists.infradead.org; Wed, 12 Aug 2020 07:28:58 +0000 Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 5564120003C; Wed, 12 Aug 2020 09:28:54 +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 45412200002; Wed, 12 Aug 2020 09:28:54 +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 3092B2030A; Wed, 12 Aug 2020 09:28:54 +0200 (CEST) Date: Wed, 12 Aug 2020 10:28:54 +0300 From: Abel Vesa To: Philipp Zabel Subject: Re: [PATCH 11/17] clk: imx: Add blk_ctrl combo driver Message-ID: <20200812072854.4r4d6cz5cprezlof@fsr-ub1664-175> References: <1596024483-21482-1-git-send-email-abel.vesa@nxp.com> <1596024483-21482-12-git-send-email-abel.vesa@nxp.com> <20200730085508.ddxhb4rjnzwooh2z@fsr-ub1664-175> <3f4fd963bdf58e61715524fdb246481fb2b2d137.camel@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3f4fd963bdf58e61715524fdb246481fb2b2d137.camel@pengutronix.de> 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-20200812_032857_059425_8B202F6F X-CRM114-Status: GOOD ( 34.96 ) 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-30 11:39:22, Philipp Zabel wrote: > On Thu, 2020-07-30 at 11:55 +0300, Abel Vesa wrote: > > 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 > > ^ When the mask was 0 before but now has a bit set. > > > and when the mask is 0, the pm_runtime_put_sync will be called. > > ^ When the mask had a bit set but now is 0. > > > Does that sound OK ? > > And the mask starts out as 0, as after the pm_runtime_put() in probe all > reset lines are deasserted? > Yes, that is correct. > > > > + } > > > > + > > > > + 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. > > Ok. If this is not required or can't be guaranteed to work, it may be > better to just leave it out. > > regards > Philipp _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel