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
Date: Wed, 18 Mar 2020 13:08:08 +0200 [thread overview]
Message-ID: <20200318110808.hzwr7m2hc2nfftvm@fsr-ub1664-175> (raw)
In-Reply-To: <3aedf6357f321efaf1d59a0b654300803ad51cef.camel@pengutronix.de>
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
next prev parent reply other threads:[~2020-03-18 11:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 9:03 [RFC 00/11] Add generic MFD i.MX mix and audiomix support Abel Vesa
2020-03-03 9:03 ` [RFC 01/11] mfd: Add i.MX generic mix support Abel Vesa
2020-03-26 11:03 ` Lee Jones
2020-03-26 12:30 ` Abel Vesa
2020-03-03 9:03 ` [RFC 02/11] arm64: dts: imx8mp: Add AIPS 4 and 5 Abel Vesa
2020-03-13 7:44 ` Peng Fan
2020-03-23 10:48 ` Abel Vesa
2020-03-03 9:03 ` [RFC 03/11] arm64: dts: imx8mp: Add audiomix node Abel Vesa
2020-03-03 9:03 ` [RFC 04/11] clk: imx: Add gate shared for i.MX8MP audiomix Abel Vesa
2020-03-13 7:47 ` Peng Fan
2020-03-03 9:03 ` [RFC 05/11] clk: imx: pll14xx: Add the device as argument when registering Abel Vesa
2020-03-13 7:50 ` Peng Fan
2020-03-21 0:46 ` Stephen Boyd
2020-03-03 9:03 ` [RFC 06/11] clk: imx: Add helpers for passing the device as argument Abel Vesa
2020-03-13 7:58 ` Peng Fan
2020-03-21 0:46 ` Stephen Boyd
2020-03-03 9:03 ` [RFC 07/11] dt-bindings: clocks: imx8mp: Add ids for audiomix clocks Abel Vesa
2020-03-10 20:17 ` Rob Herring
2020-03-21 0:51 ` Stephen Boyd
2020-03-03 9:03 ` [RFC 08/11] clk: imx: Add audiomix clock controller support Abel Vesa
2020-03-21 0:51 ` Stephen Boyd
2020-03-03 9:03 ` [RFC 09/11] arm64: dts: imx8mp: Add audiomix clock controller node Abel Vesa
2020-03-03 9:03 ` [RFC 10/11] reset: imx: Add audiomix reset controller support Abel Vesa
2020-03-04 11:41 ` Philipp Zabel
2020-03-13 14:16 ` Abel Vesa
2020-03-13 15:55 ` Philipp Zabel
2020-03-18 11:08 ` Abel Vesa [this message]
2020-03-10 20:19 ` Rob Herring
2020-03-03 9:03 ` [RFC 11/11] arm64: dts: imx8mp: Add audiomix reset controller node Abel Vesa
2020-04-16 11:06 ` [RFC 00/11] Add generic MFD i.MX mix and audiomix support Arnd Bergmann
2020-04-16 11:06 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200318110808.hzwr7m2hc2nfftvm@fsr-ub1664-175 \
--to=abel.vesa@nxp.com \
--cc=anson.huang@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=kernel@pengutronix.de \
--cc=lee.jones@linaro.org \
--cc=leonard.crestez@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=peng.fan@nxp.com \
--cc=ping.bai@nxp.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).