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;
Date:   Wed, 18 Mar 2020 13:08:08 +0200
From:   Abel Vesa <abel.vesa@nxp.com>
To:     Philipp Zabel <p.zabel@pengutronix.de>
Cc:     Rob Herring <robh@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <kernel@pengutronix.de>,
        Fabio Estevam <fabio.estevam@nxp.com>,
        Mike Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        Anson Huang <anson.huang@nxp.com>,
        Leonard Crestez <leonard.crestez@nxp.com>,
        Peng Fan <peng.fan@nxp.com>, Jacky Bai <ping.bai@nxp.com>,
        devicetree@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        NXP Linux Team <linux-imx@nxp.com>,
        linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 10/11] reset: imx: Add audiomix reset controller support
Message-ID: <20200318110808.hzwr7m2hc2nfftvm@fsr-ub1664-175>
References: <1583226206-19758-1-git-send-email-abel.vesa@nxp.com>
 <1583226206-19758-11-git-send-email-abel.vesa@nxp.com>
 <ac6eb54c01cce4ec52560ac622e024ab47f2136c.camel@pengutronix.de>
 <20200313141606.euumtuizm562zghv@fsr-ub1664-175>
 <3aedf6357f321efaf1d59a0b654300803ad51cef.camel@pengutronix.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3aedf6357f321efaf1d59a0b654300803ad51cef.camel@pengutronix.de>
User-Agent: NeoMutt/20180622
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 20-03-13 16:55:47, Philipp Zabel wrote:
> On Fri, 2020-03-13 at 16:16 +0200, Abel Vesa wrote:
> [...]
> > > > +	if (assert) {
> > > > +		pm_runtime_get_sync(rcdev->dev);
> > > 
> > > This seems wrong. Why is the runtime PM reference count incremented when
> > > a reset is asserted ...
> > 
> > The audiomix IP has its own power domain. 
> 
> The reset controller does not control the power domain for its
> consumers. The consumer of this reset should implement runtime PM.
> 

No, the reset controller itself is part of a more complex IP called audiomix
that has its own power domain.

> > The way I see it, when the last deassert is done, there is no point
> > in keeping the audiomix on. So, unless the clock controller part of it does it,
> > the audiomix will be powered down.
> 
> You mean when the last assert is done? Presumably the driver wants to
> use the hardware after deasserting the reset and asserts the reset when
> it is done.

No, I mean deassert. If there is no reset asserted anymore, then the audiomix
can power down, if nothing else (I'm talking about the other stuff that's
in the audiomix, like clock controller) keeping it on.

The reset controller needs to be on only when there is an assertion of at least
one reset bit going on.

> 
> regards
> Philipp