lkml.org 
[lkml]   [2014]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
    On Thu, May 1, 2014 at 2:41 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    > Hi Grant,
    >
    > On Thu, May 1, 2014 at 10:03 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
    >> On Wed, 30 Apr 2014 23:54:37 +0200, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
    >>> On Tue, Apr 29, 2014 at 3:16 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
    >>> > I also don't like that it tries to set up every clock, but there is no
    >>> > guarantee that the driver will even use it. I would rather see this
    >>> > behaviour linked into the function that obtains the clock at driver
    >>> > .probe() time. That way it can handle deferred probe correctly and it
    >>> > only sets up clocks that are actually used by the driver.
    >>>
    >>> Not every clock. Only the clocks that are advertised by the clock driver as
    >>> being suitable for runtime_pm management. These are typically module
    >>> clocks, that must be enabled for the module to work. The driver doesn't
    >>> always want to handle these explicitly.
    >>
    >> Help me out here becasue I don't understand how that works with this
    >> patch set. From my, admittedly naive, reading it looks like the setup is
    >> being done at device creation time, but if the driver (or module) gets
    >> to declare which clocks need to be enabled in order to work, then that
    >> information is not available at device creation time.
    >
    > Setup is indeed done at registration time. Note the check calling
    > clk_may_runtime_pm(), which is introduced in "[PATCH/RFC 1/4] clk: Add
    > CLK_RUNTIME_PM and clk_may_runtime_pm()".
    >
    > Clock drivers are initialized much earlier, so they can set the CLK_RUNTIME_PM
    > flag for suitable clocks before platform devices are created from DT, cfr. the
    > example for shmobile MSTP clocks in "[PATCH/RFC 4/4] clk: shmobile: mstp:
    > Set CLK_RUNTIME_PM flag".

    This is where I have issue. You're *assuming* clock drivers are
    initialized much earlier. That is not guaranteed. It is perfectly
    valid for clocks to be set up by a normal device driver, just like for
    interrupt controllers or gpio controllers.

    g.


    \
     
     \ /
      Last update: 2014-05-01 16:41    [W:4.824 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site