From: James Liao <jamesjj.liao@mediatek.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: Daniel Kurtz <djkurtz@chromium.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sascha Hauer <kernel@pengutronix.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"open list:OPEN FIRMWARE AND..." <devicetree@vger.kernel.org>,
srv_heupstream <srv_heupstream@mediatek.com>,
Kevin Hilman <khilman@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date: Thu, 1 Oct 2015 15:15:50 +0800 [thread overview]
Message-ID: <1443683750.1714.25.camel@mtksdaap41> (raw)
In-Reply-To: <1443604022.3185.17.camel@pengutronix.de>
Hi Lucas,
On Wed, 2015-09-30 at 11:07 +0200, Lucas Stach wrote:
> > If the VENC power domain is disabled, then accesses to the vencsys
> > registers just silently fail (i.e., reads probably
> > return all 0s).
>
> If this ever happens it is really unfortunate and needs fixing, too. If
> you need the power domain to be powered ON to properly read or even
> change the clock registers, the clock driver needs to be a consumer of
> the power domain, so any clock operations powers the domain up.
A subsystem should be powered on before its clock operations. But I
think this flow should be guaranteed by VENC driver. This patch is
focused on the race between disabling unused clocks and power domains by
frameworks.
> > In theory, we could add "clocks=<&topckgen CLK_TOP_VENC_SEL>;" to the
> > vencsys clock-controller node. On initialization, mtk_vencsys_init()
> > could then pass venc_sel to the generic MT8173 gate clock driver, and
> > it would then clk_enable(venc_sel)/_disable(venc_sel) around any
> > access to the clock-controller registers. James, however, thinks
> > this is a lot of extra overhead, and instead has proposed the fix in this patch,
> > where venc_sel is forced on whenever the VENC power domain is enabled.
> >
> I would still say this is the correct solution. If the vencsys clock
> registers are itself clocked by VENC_SEL this driver needs to make sure
> this clock is running at the appropriate times. I understand that this
> may be a bit of an overhead, but clock enable/disable paths are not
> really performance critical.
>
> > So, this patch is a bit of a hack, but the mtk scpsys driver already
> > does something similar for the MM & MFG clocks - these clocks are
> > always enabled whenever certain power domains are enabled, and they
> > are only disabled when all such power domains are disabled. I'm not
> > 100% why these clocks must always be kept on whenever these power
> > domains are enabled, but probably to solve a similar problem where
> > these clocks are needed to access some registers at a time when these
> > clocks would not otherwise be explicitly enabled.
> >
> I can't really argue with this being the wrong solution if we already
> have precedent of the same solution being used for other domains. But I
> would still ask you to re-evaluate with the above in mind.
One cause of the hang up issue is frameworks' behavior. Power domain
framework and clock framework work independently during kernel init. So
their control flow can't be guaranteed by a suitable driver, such as
VENC driver.
I preferred to keep venc_sel on during VENC power on because I'm not
sure there is any other framework may control VENC's registers during
kernel init.
Best regards,
James
next prev parent reply other threads:[~2015-10-01 7:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 6:31 [PATCH] soc: mediatek: Fix random hang up issue while kernel init James Liao
[not found] ` <1443162717-64831-1-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-09-25 8:26 ` Lucas Stach
[not found] ` <1443169573.3135.9.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2015-09-27 11:25 ` Matthias Brugger
2015-09-29 10:25 ` Daniel Kurtz
[not found] ` <CAGS+omCXMRf4bxWancSJSq2a1pc38TYYY46Os9ASWWCRp95_ig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-30 9:07 ` Lucas Stach
2015-10-01 7:15 ` James Liao [this message]
2015-10-01 8:07 ` Daniel Kurtz
2015-10-01 9:26 ` James Liao
2015-10-01 10:08 ` Daniel Kurtz
2015-10-02 3:00 ` James Liao
2015-10-02 9:25 ` Daniel Kurtz
[not found] ` <CAGS+omBQLVGeWrNoD+8L_J0C9DjzkXO_cfph2tQgMGiPBJq2vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-02 10:37 ` James Liao
2015-10-01 6:58 ` James Liao
2015-10-06 1:57 ` Daniel Kurtz
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=1443683750.1714.25.camel@mtksdaap41 \
--to=jamesjj.liao@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=djkurtz@chromium.org \
--cc=kernel@pengutronix.de \
--cc=khilman@kernel.org \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=srv_heupstream@mediatek.com \
/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).