Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1237887

Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init

From James Liao <jamesjj.liao@mediatek.com>
Newsgroups linux.kernel
Subject Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Date 2015-10-02 05:10 +0200
Message-ID <qeYTo-7EU-3@gated-at.bofh.it> (permalink)
References (4 earlier) <qelyG-rL-35@gated-at.bofh.it> <qeGjM-58Q-25@gated-at.bofh.it> <qeH69-6r6-1@gated-at.bofh.it> <qeIlB-8lU-43@gated-at.bofh.it> <qeIYi-SO-27@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Daniel,

On Thu, 2015-10-01 at 18:08 +0800, Daniel Kurtz wrote:
> I see two cases where "a power domain is a consumer of a clock":
>   (a) the clock is needed to access the power domain control
> registers.  The clock must actually be in another power domain, since
> otherwise you could never turn *on* the power domain in question.
>   (b) the clock is needed to talk to the power domain that is about to
> turn off, or that was just turned on - these clocks are usually used
> to control some kind of bus arbitration, etc.  In this case, the
> clocks are only accessed when the power domain is on.
> 
> I would argue that in both cases, the clock should in theory should
> only be enabled/disabled by the power on/off routine for the duration
> of time that is needed, and that it should not be "left enabled" by
> the power domain on/off function...  I can see how this might be a
> useful optimization - but it also seems like a way to burn extra power
> by leaving on a clock that is not necessarily being used.
> 
> But - perhaps I am over thinking this, and it is standard practice to
> bundle power domains with the clocks that service components in the
> power domain.

Yes, you are right. Power domain on/off operations need clocks to get
status of the subsystem. Keeping clocks on during power domain on is an
optimization.

But to model a clock controller as a power domain consumer, or say we
need to control power domain before clock on/off, is not a good practice
because we always consider clock operations should be light weight.
Power domains should be controlled explicitly by subsystem drivers,
instead of hiding behind clock controls.

> Or, alternatively, just prepare venc_sel once during init, for each
> clock controller that needs it, when configuring the clock controller
> node (for example, in mtk_vencsys_init()). This is similar to how we
> set up 'critical clocks'.
> By just preparing the clock, you tell the common clock core:
>  "my clock controller will need this clock later; please make sure
> that it can be enabled/disabled later during atomic context."

In current implementation, PLLs will be turned on in clk_prepare(). So
if a clock is always prepared, its parent PLL will be kept on even if
the clock is not enabled. It consumes extra power, so we don't prefer
this kind of solution.


Best regards,

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] soc: mediatek: Fix random hang up issue while kernel init James Liao <jamesjj.liao@mediatek.com> - 2015-09-25 08:40 +0200
  Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init Lucas Stach <l.stach@pengutronix.de> - 2015-09-25 10:30 +0200
    Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init Matthias Brugger <matthias.bgg@gmail.com> - 2015-09-27 13:30 +0200
      Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init Daniel Kurtz <djkurtz@chromium.org> - 2015-09-29 12:30 +0200
        Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init Lucas Stach <l.stach@pengutronix.de> - 2015-09-30 11:10 +0200
          Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init James Liao <jamesjj.liao@mediatek.com> - 2015-10-01 09:20 +0200
            Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init Daniel Kurtz <djkurtz@chromium.org> - 2015-10-01 10:10 +0200
              Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init James Liao <jamesjj.liao@mediatek.com> - 2015-10-01 11:30 +0200
                Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init Daniel Kurtz <djkurtz@chromium.org> - 2015-10-01 12:10 +0200
                Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init James Liao <jamesjj.liao@mediatek.com> - 2015-10-02 05:10 +0200
                Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init Daniel Kurtz <djkurtz@chromium.org> - 2015-10-02 11:30 +0200
                Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init James Liao <jamesjj.liao@mediatek.com> - 2015-10-02 12:40 +0200
        Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel  init James Liao <jamesjj.liao@mediatek.com> - 2015-10-01 09:00 +0200

csiph-web