public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: jamesjj.liao@mediatek.com (James Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date: Fri, 2 Oct 2015 18:37:00 +0800	[thread overview]
Message-ID: <1443782220.1714.102.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omBQLVGeWrNoD+8L_J0C9DjzkXO_cfph2tQgMGiPBJq2vw@mail.gmail.com>

HI Daniel,

On Fri, 2015-10-02 at 17:25 +0800, Daniel Kurtz wrote:
> Actually, I should have proposed adding prepare / unprepare callbacks
> to mtk_clk_gate_ops in which we prepare_enable/disable_unprepare
> venc_sel (& mm_sel).
> This should correctly track all of the clk reference counting needed
> to access the venc clock control registers.
> 
> 
> However, this would not actually solve the issue that this patch is
> trying to fix, since nobody would have called the
> prepare_clk(venc_cke0) before clk_disable_unused_subtree(venc_cke0).
> Bummer.

Hmm... it's true.

> I think the crux of the original issue is that the mediatek/clk-gate.c
> is_enabled() callbacks may be called at a point in time when venc_sel
> is disabled but VENC PD is enabled.
> So, perhaps an easier, but still a little hacky way out is to keep the
> clk & PD problems separate, and just check __clk_is_enabled(venc_sel)
> before reading the venc clk status register.
> 
> WDYT?

This may be a way to resolve this issue, but model the prerequisite
clock of subsystem clocks is not straightforward. And once we model the
prerequisite clocks, someone may suggest us to enable prerequisite
clocks before operate subsystem clocks, which may have concerns on
overhead and complexity.

> By the way, I'm not really opposed to your current implementation
> either, I was just helping Matthias & Lucas understand in enough
> detail that they can help review.

I know and many thanks for your suggestion on this patch.


Best regards,

James

  reply	other threads:[~2015-10-02 10:37 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
2015-09-25  8:26 ` Lucas Stach
2015-09-27 11:25   ` Matthias Brugger
2015-09-29 10:25     ` Daniel Kurtz
2015-09-30  9:07       ` Lucas Stach
2015-10-01  7:15         ` James Liao
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
2015-10-02 10:37                     ` James Liao [this message]
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=1443782220.1714.102.camel@mtksdaap41 \
    --to=jamesjj.liao@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.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