devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Turquette <mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
Cc: Joachim Eastwood
	<manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org
Subject: Re: [PATCH v3 4/6] clk: add lpc18xx ccu clk driver
Date: Wed, 27 May 2015 20:44:24 -0700	[thread overview]
Message-ID: <20150528034424.22384.83956@quantum> (raw)
In-Reply-To: <1431988559-23338-5-git-send-email-manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hi Joachim,

Quoting Joachim Eastwood (2015-05-18 15:35:57)
<snip>
> +static void lpc18xx_ccu_register_branch_clks(void __iomem *reg_base,
> +                                            int base_clk_id,
> +                                            const char *parent)
> +{
> +       int i;
> +
> +       for (i = 0; i < ARRAY_SIZE(clk_branches); i++) {
> +               if (clk_branches[i].base_id != base_clk_id)
> +                       continue;
> +
> +               lpc18xx_ccu_register_branch_gate_div(&clk_branches[i], reg_base,
> +                                                    parent);
> +
> +               if (clk_branches[i].flags & CCU_BRANCH_IS_BUS)
> +                       parent = clk_branches[i].name;
> +       }
> +}
> +
> +static void __init lpc18xx_ccu_init(struct device_node *np)
> +{
> +       struct lpc18xx_branch_clk_data *clk_data;
> +       int num_base_ids, *base_ids;
> +       void __iomem *reg_base;
> +       const char *parent;
> +       int base_clk_id;
> +       int i;
> +
> +       reg_base = of_iomap(np, 0);
> +       if (!reg_base) {
> +               pr_warn("%s: failed to map address range\n", __func__);
> +               return;
> +       }
> +
> +       clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> +       if (!clk_data)
> +               return;
> +
> +       num_base_ids = of_clk_get_parent_count(np);
> +
> +       base_ids = kcalloc(num_base_ids, sizeof(int), GFP_KERNEL);
> +       if (!base_ids) {
> +               kfree(clk_data);
> +               return;
> +       }
> +
> +       clk_data->base_ids = base_ids;
> +       clk_data->num_base_ids = num_base_ids;
> +
> +       for (i = 0; i < num_base_ids; i++) {
> +               struct clk *clk = of_clk_get(np, i);
> +               if (IS_ERR(clk)) {
> +                       pr_warn("%s: failed to get clock at idx %d\n",
> +                               __func__, i);
> +                       continue;
> +               }
> +
> +               parent = __clk_get_name(clk);
> +               base_clk_id = of_clk_get_index(np, i);
> +
> +               clk_data->base_ids[i] = base_clk_id;
> +               lpc18xx_ccu_register_branch_clks(reg_base, base_clk_id,
> +                                                parent);

Thanks for sending V3. This driver is getting close!

So the main thing I don't understand is why you do not encode the CGU
clock parent string names into this CCU driver. If I understand your
approach correctly, you do the following in lpc18xx_ccu_init:

1) count the number of parent clocks (ostensibly CGU clocks)
2) iterate through all of those CGU clocks, extracting a base_id value
(loop #1)
3) using this base_id as a key you walk through an array in the CCU
driver trying to find a matching base_id value
(loop #2)
4) after finding the corresponding CCU clocks you get the parent clock
with of_clk_get
5) using of_clk_get you fetch its name with __clk_get_name
6) you pass this parent name into a fairly typical looking registration
function

Assuming I got all of that right, I hope we can simplify it
considerably.

You already have an array of CCU clock information in this driver,
clk_branches[]. Why not encode the parent string name here? This would
involve adding a "parent_name" member to struct lpc18xx_clk_branch.

Doing the above, your O(n^2)-ish registration function becomes O(n):

1) iterate through the array of the CCU clocks (clk_branchs[])
2) register them
3) profit

I'm starting to think any reference to base_id is sign that things are
wrong in your driver. I am unconvinced that you need to "share" this
base_id across CGU and CCU drivers in the way you do. If I'm wrong
please help me to understand.

As a wild thought, if you do not want to encode parent string names into
this driver, have you tried to use the clock-names property in the CCU
blob? You do not need clock-output-names in the CGU blob either. But
this is just an idea. It is far for straightforward for you t encode the
parent names in your clk_branches[] array.

Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-05-28  3:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-18 22:35 [PATCH v3 0/6] Clk drivers for NXP LPC18xx family Joachim Eastwood
     [not found] ` <1431988559-23338-1-git-send-email-manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-18 22:35   ` [PATCH v3 1/6] clk: add lpc18xx cgu clk driver Joachim Eastwood
2015-05-18 22:35   ` [PATCH v3 2/6] doc: dt: add documentation for lpc1850-cgu " Joachim Eastwood
2015-05-18 22:35   ` [PATCH v3 3/6] clk: add function to retrieve clk id from dt Joachim Eastwood
2015-05-18 22:35   ` [PATCH v3 4/6] clk: add lpc18xx ccu clk driver Joachim Eastwood
     [not found]     ` <1431988559-23338-5-git-send-email-manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-28  3:44       ` Michael Turquette [this message]
2015-05-28  3:51         ` Michael Turquette
2015-05-28 17:13         ` Joachim Eastwood
2015-05-18 22:35   ` [PATCH v3 5/6] doc: dt: add documentation for lpc1850-ccu " Joachim Eastwood
     [not found]     ` <1431988559-23338-6-git-send-email-manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-28  3:45       ` Michael Turquette
2015-05-28  7:02         ` Joachim Eastwood
2015-05-18 22:35   ` [PATCH v3 6/6] ARM: dts: lpc18xx: add clock nodes for cgu and ccu Joachim Eastwood

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=20150528034424.22384.83956@quantum \
    --to=mturquette-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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;
as well as URLs for NNTP newsgroup(s).