All of lore.kernel.org
 help / color / mirror / Atom feed
From: mfuzzey@parkeon.com (Martin Fuzzey)
To: linux-arm-kernel@lists.infradead.org
Subject: Order of clock multiplexer registrations
Date: Thu, 22 Nov 2012 09:56:30 +0100	[thread overview]
Message-ID: <50ADE8BE.1000707@parkeon.com> (raw)

Hello,

I notice that currently (3.7-rc6) the behaviour of clock multiplexers 
depends on their registration order.

Suppose the hardware has a 2 bit clock select field with
00 => srcA
01 => srcB
10 => unused
11 => srcC

If the multiplexer is registered after the sources:

     static const char *sel[] = { "srcA", "srcB", "dummy", "srcC" };

     clk_register_fixed(NULL, "dummy", ...);
     clk_register_fixed(NULL, "srcA", ...);
     clk_register_fixed(NULL, "srcB", ...);
     clk_register_fixed(NULL, "srcC", ...);
     child = clk_register_mux(NULL, "child",  sel, ARRAY_SIZE(sel), ...);

Then all works as expected and child's parent will depend on the value 
in the hardware clock select register.

However, if the multiplexer is registered before the sources:

     child = clk_register_mux(NULL, "child",  sel, ARRAY_SIZE(sel), ...);
     clk_register_fixed(NULL, "dummy", ...);
     clk_register_fixed(NULL, "srcA", ...);
     clk_register_fixed(NULL, "srcB", ...);
     clk_register_fixed(NULL, "srcC", ...);

Then child's parent will always be the first registered parent clock 
("dummy" in this case) regardless of the
value in the hardware clock select register.

This occurs because of the reparenting code in drivers/clk/clk.c 
__clk_init():

     /*
      * walk the list of orphan clocks and reparent any that are children of
      * this clock
      */
     hlist_for_each_entry_safe(orphan, tmp, tmp2, &clk_orphan_list, 
child_node)
         for (i = 0; i < orphan->num_parents; i++)
             if (!strcmp(clk->name, orphan->parent_names[i])) {
                 __clk_reparent(orphan, clk);
                 break;
             }


Is this a bug or are multiplexers supposed to always be registered after 
their parents?

Currently this occurs for some i.MX53 clocks:
|-- dummy
|   |-- emi_fast_gate
|   |-- gpc_dvfs
|   `-- ipu_di0_sel


Regards,

Martin

                 reply	other threads:[~2012-11-22  8:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=50ADE8BE.1000707@parkeon.com \
    --to=mfuzzey@parkeon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.