From: t-kristo@ti•com (Tero Kristo)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
Date: Thu, 1 Aug 2013 18:08:16 +0300 [thread overview]
Message-ID: <51FA79E0.2070605@ti.com> (raw)
In-Reply-To: <51FA69E8.8000000@ti.com>
On 08/01/2013 05:00 PM, Nishanth Menon wrote:
> On 07/31/2013 04:46 AM, Tero Kristo wrote:
>> On 07/30/2013 07:23 PM, Nishanth Menon wrote:
>>> This patch probably was submitted in the wrong sequence - fails build
>>> and few other issues below.
>>
>> Yeah, I'll double check the build sequence for these.
>>
>>>
>>> On 07/23/2013 02:19 AM, Tero Kristo wrote:
>>>> The OMAP clock driver now supports DPLL clock type. This patch also
>>>> adds support for DT DPLL nodes.
>>>
>>> Then why is $subject specific to OMAP4? is that because of
>>> of_omap4_dpll_setup?
>>
>> The driver only supports omap4 dpll type at this point, omap3 dplls
>> require some modifications on top of this, and are provided later in the
>> series.
>
> ok.
>
>>
>>>
>>>>
>>>> Signed-off-by: Tero Kristo <t-kristo@ti•com>
>>>> ---
>>>> drivers/clk/omap/Makefile | 2 +-
>>>> drivers/clk/omap/clk.c | 1 +
>>>> drivers/clk/omap/dpll.c | 295
>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> Device Tree Binding documentation?
>>
>> Didn't bother writing those yet as I haven't received too much feedback
>> whether this approach is acceptable or not.
>
> Documentation helps simplify the understanding of expected usage - this
> is useful to review approach as well :)
True, I'll try adding docs for next rev.
>
>>>> diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
>>>> index 4bf1929..1dafdaa 100644
>>>> --- a/drivers/clk/omap/clk.c
>>>> +++ b/drivers/clk/omap/clk.c
>>>> @@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
>>>> .data = of_fixed_factor_clk_setup, },
>>>> {.compatible = "divider-clock", .data = of_divider_clk_setup, },
>>>> {.compatible = "gate-clock", .data = of_gate_clk_setup, },
>>>> + {.compatible = "ti,omap4-dpll-clock", .data =
>>>> of_omap4_dpll_setup, },
>>>> {},
>>>> };
>>> you would not need this if you did just of_clk_init(NULL); ?
>>
>> Why not? And I think we still need to do this.
>
> CLK_OF_DECLARE will take care of having all required clks registered
> of_clk_init(NULL); will pick up from that list.
>
> that will remove all extra exports, and make clk.c redundant.
> [...]
Yep, as agreed on previous patch.
>
>>
>>>
>>>> +#include <linux/clk/omap.h>
>>>
>>> why?
>>
>> Need dpll_data definition for example.
> OK - without the ordering of patches, it was not obvious. structures aside,
>
> We should move the functions to this file instead and empty out
> mach-omap2 gradually, omap_dpll.h should be exported and used by
> mach-omap2, rather than the other way around.
Yeah, the clock stuff should evolve and move here. I just need to start
from somewhere.
>
>>>> +
>>>> +struct clk *omap_clk_register_dpll(struct device *dev, const char
>>>> *name,
>>>> + const char **parent_names, int num_parents, unsigned long
>>>> flags,
>>>> + struct dpll_data *dpll_data, const char *clkdm_name,
>>>> + const struct clk_ops *ops)
>>>
>>> why should this be public?
>>
>> Currently does not need to be, but someone could in theory build up
>> cclockXxxx_data.c file and use these calls from there. Kind of legacy
>> support, see some of the basic clk types. I guess I can add static to
>> this, and remove some of the params along.
>>
>
> thanks. we should keep unneeded stuff in static unless a specific
> provable need really arises.
>
>>>
>>> I am assuming you do not do parameter check as you expect clk_register
>>> to do the same?
>>
>> True, so I'll change the above function to static.
>>
>>>
>>>> +
>>>> + /* allocate the divider */
>>>> + clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
>>> checkpatch complained:
>>> CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct
>>> clk_hw_omap)...)
>>
>> Hmm, I didn't get this with checkpatch. Some special option/version you
>> use? I still see both types of sizeof used in the kernel.
> use checkpatch with --strict option
Okay.
>
>>
>>>
>>> or given we have dev, devm_kzalloc?
>>
>> Actually we don't have dev, check how this is called from below.
>
> ok.
>
>>
>>>> + if (!clk_hw) {
>>>> + pr_err("%s: could not allocate clk_hw_omap\n", __func__);
>>>> + return ERR_PTR(-ENOMEM);
>>>> + }
>>>> +
>>>> + clk_hw->dpll_data = dpll_data;
>>>> + clk_hw->ops = &clkhwops_omap3_dpll;
>>>> + clk_hw->clkdm_name = clkdm_name;
>>>> + clk_hw->hw.init = &init;
>>>> +
>>>> + init.name = name;
>>>> + init.ops = ops;
>>>> + init.flags = flags;
>>>> + init.parent_names = parent_names;
>>>> + init.num_parents = num_parents;
>>>> +
>>>> + /* register the clock */
>>>> + clk = clk_register(dev, &clk_hw->hw);
>>>> +
>>>> + if (IS_ERR(clk))
>>>> + kfree(clk_hw);
>>>> + else
>>>> + omap2_init_clk_hw_omap_clocks(clk);
>>> what if init fails? and it is in mach-omap2 at this point in time?
>>
>> Yea, this just calls the autoidle init part under mach-omap2.
>
> we should make this independent of mach-omap2. calls should be made to
> here if needed from mach-omap2 instead of the other way around. OR the
> required code should be moved over here.
Same comment as above, I did not want to move the allow / deny idle
portion of every possible clock under drivers/clk/omap yet. This is on
the evolution path for this driver.
>
>>
>>>
>>>> +
>>>> + return clk;
>>>> +}
>>>
> <snip>
>>>
>>>> +
>>>> + if (of_property_read_bool(node, "ti,dpll-j-type")) {
>>>> + dd->sddiv_mask = 0xff000000;
>>>> + mult_mask = 0xfff << 8;
>>>> + div1_mask = 0xff;
>>>> + max_multiplier = 4095;
>>>> + max_divider = 256;
>>>> + }
>>>> +
>>>> + if (of_property_read_bool(node, "ti,dpll-regm4xen")) {
>>> I think we need bindings to understand this better.
>>
>> Or documentation you mean?
>
> yes. Documentation/devicetree/bindings/....
>
>>
>>>
>>>> + dd->m4xen_mask = 0x800;
>>>> + dd->lpmode_mask = 1 << 10;
>>>> + }
>>>> +
>>>> + dd->mult_mask = mult_mask;
>>>> + dd->div1_mask = div1_mask;
>>>> + dd->max_multiplier = max_multiplier;
>>>> + dd->max_divider = max_divider;
>>>> + dd->min_divider = min_divider;
>>>> +
>>>> + clk = omap_clk_register_dpll(NULL, clk_name, parent_names,
>>>> + num_parents, dpll_flags, dd,
>>>> + clkdm_name, ops);
>>>> +
>>>> + if (!IS_ERR(clk))
>>>> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
>>> error check?
>>
>> This is not done with other drivers either. Would require clk_unregister
>> use to cleanup the above register call which is currently unavailable. I
>> could add an error trace for this though.
>
> you can definitely ensure this driver is clean :)
Not really, as the clk_unregister does not work, so the implementation
for this can't be exactly clean yet. I don't know if we want to
unregister any clocks anyway if this would fail...
>
>>>
>>>> + kfree(dd);
>>>> + return;
>>>> +}
>>>> +
>>>> +static void __init of_omap_dpll_x2_setup(struct device_node *node)
>>>> +{
>>>> + struct clk *clk;
>>>> + const char *clk_name = node->name;
>>>> + void __iomem *reg;
>>>> + const char *parent_name;
>>>> +
>>>> + of_property_read_string(node, "clock-output-names", &clk_name);
>>>> +
>>>> + parent_name = of_clk_get_parent_name(node, 0);
>>>> +
>>>> + reg = of_iomap(node, 0);
>>>
>>> if dts has errors, should we not verify mandatory parameters?
>>
>> You mean checking the validity of this pointer? It seems of_iomap does
>> something strange when it fails, e.g. when passed a 0x0 from DT. You can
>> see what I do in a later patch for adding am335x support for DPLLs.
>
> in general, helping dts writers know of invalid/out of range parameters
> with a log message helps ensure those are fixed either on development or
> at some point - it aids debug instead of others having to scratch heads
> wondering what happened.
>
> if mandatory parameters are verifable at setup and decided as bad,
> refusing to register is good idea especially with logs, they tend to get
> fixed rather faster - than an error that pops up when a specific DPLL is
> used at a later point in time.
>
> just my 2 cents.
> [..]
I'll add verification for the of_iomap calls.
>
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
>>>
>>> you can drop the export if you use of_clk_init(NULL);
>>
>> Hmm no?
>>
>> Actually dug this further, I think the init setup is slightly wrong at
>> the moment, we should not do CLK_OF_DECLARE at all within the omap
>> specific clock drivers, but instead just use the match table from clk.c.
>> I'll change it like so.
>>
>>>
>>>> +CLK_OF_DECLARE(omap4_dpll_clock, "ti,omap4-dpll-clock",
>>>> of_omap4_dpll_setup);
>>
>> So, for example this should be removed. We don't want to support this
>> clock type on non-omap platforms just to avoid problems.
>
> As discussed offline, doing the other way around and doing what all
> other platforms do (which is CLK_OF_DECLARE) is a better idea to ensure
> standard APIs are carried forward and not spin off OMAP as a "special
> platform" - at least I dont seem to see any good reasoning for it yet.
Yea.
next prev parent reply other threads:[~2013-08-01 15:08 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 7:19 [PATCHv4 00/33] ARM: OMAP: clock conversion to DT Tero Kristo
2013-07-23 7:19 ` [PATCHv4 01/33] CLK: clkdev: add support for looking up clocks from DT Tero Kristo
2013-07-30 15:04 ` Nishanth Menon
2013-07-31 8:43 ` Tero Kristo
2013-07-23 7:19 ` [PATCHv4 02/33] clk: omap: introduce clock driver Tero Kristo
2013-07-30 15:21 ` Nishanth Menon
2013-07-31 8:59 ` Tero Kristo
2013-08-01 13:44 ` Nishanth Menon
2013-08-01 14:59 ` Tero Kristo
2013-07-23 7:19 ` [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support Tero Kristo
2013-07-30 16:23 ` Nishanth Menon
2013-07-31 9:46 ` Tero Kristo
2013-08-01 14:00 ` Nishanth Menon
2013-08-01 15:08 ` Tero Kristo [this message]
2013-08-01 15:13 ` Nishanth Menon
2013-08-01 8:29 ` Rajendra Nayak
2013-08-01 15:10 ` Nishanth Menon
2013-08-01 15:41 ` Tero Kristo
2013-07-23 7:19 ` [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver Tero Kristo
2013-07-30 18:22 ` Nishanth Menon
2013-07-31 9:59 ` Tero Kristo
2013-08-01 14:04 ` Nishanth Menon
2013-08-01 15:12 ` Tero Kristo
2013-08-01 15:21 ` Nishanth Menon
2013-07-23 7:20 ` [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration mechanism Tero Kristo
2013-07-30 18:40 ` Nishanth Menon
2013-07-31 10:07 ` Tero Kristo
2013-08-01 14:25 ` Nishanth Menon
2013-08-01 15:18 ` Tero Kristo
2013-08-01 15:24 ` Nishanth Menon
2013-08-01 15:30 ` Tero Kristo
2013-08-02 7:22 ` Tony Lindgren
2013-07-23 7:20 ` [PATCHv4 06/33] CLK: omap: add autoidle support Tero Kristo
2013-07-30 18:56 ` Nishanth Menon
2013-07-31 10:13 ` Tero Kristo
2013-08-01 14:11 ` Nishanth Menon
2013-08-01 15:22 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 07/33] CLK: omap: add support for OMAP gate clock Tero Kristo
2013-07-30 19:17 ` Nishanth Menon
2013-07-31 14:45 ` Tero Kristo
2013-08-01 14:33 ` Nishanth Menon
2013-08-01 15:29 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 08/33] ARM: dts: omap4 clock data Tero Kristo
2013-07-30 19:27 ` Nishanth Menon
2013-07-31 14:49 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 09/33] CLK: omap: add omap4 clock init file Tero Kristo
2013-07-30 19:33 ` Nishanth Menon
2013-07-31 14:52 ` Tero Kristo
2013-08-01 14:40 ` Nishanth Menon
2013-08-01 15:34 ` Tero Kristo
2013-08-01 16:10 ` Nishanth Menon
2013-07-23 7:20 ` [PATCHv4 10/33] ARM: OMAP4: remove old clock data and link in new clock init code Tero Kristo
2013-07-30 19:42 ` Nishanth Menon
2013-07-31 14:55 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 11/33] ARM: dts: omap5 clock data Tero Kristo
2013-07-23 7:20 ` [PATCHv4 12/33] CLK: omap: add omap5 clock init file Tero Kristo
2013-07-23 7:20 ` [PATCHv4 13/33] ARM: dts: dra7 clock data Tero Kristo
2013-07-23 7:20 ` [PATCHv4 14/33] CLK: omap: add dra7 clock init file Tero Kristo
2013-07-23 7:20 ` [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property ti, dpll-no-gate Tero Kristo
2013-07-30 19:18 ` [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property ti,dpll-no-gate Nishanth Menon
2013-07-31 14:56 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle register Tero Kristo
2013-07-30 19:49 ` Nishanth Menon
2013-07-31 14:57 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 17/33] CLK: DT: add support for set-rate-parent flag Tero Kristo
2013-07-30 19:58 ` Nishanth Menon
2013-07-23 7:20 ` [PATCHv4 18/33] ARM: dts: am33xx clock data Tero Kristo
2013-07-23 7:20 ` [PATCHv4 19/33] CLK: omap: add am33xx clock init file Tero Kristo
2013-07-30 20:00 ` Nishanth Menon
2013-07-31 14:59 ` Tero Kristo
2013-08-01 14:43 ` Nishanth Menon
2013-08-01 15:35 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 20/33] ARM: AM33xx: remove old clock data and link in new clock init code Tero Kristo
2013-07-23 7:20 ` [PATCHv4 21/33] CLK: OMAP: DPLL: add omap3 dpll support Tero Kristo
2013-07-30 20:08 ` Nishanth Menon
2013-07-31 15:03 ` Tero Kristo
2013-08-01 14:46 ` Nishanth Menon
2013-07-23 7:20 ` [PATCHv4 22/33] CLK: OMAP: update gate clock setup for OMAP3 Tero Kristo
2013-07-30 20:13 ` Nishanth Menon
2013-07-31 15:05 ` Tero Kristo
2013-07-23 7:20 ` [PATCHv4 23/33] CLK: OMAP: add interface clock support " Tero Kristo
2013-07-30 20:23 ` Nishanth Menon
2013-07-31 15:09 ` Tero Kristo
2013-08-01 14:50 ` Nishanth Menon
2013-07-23 7:20 ` [PATCHv4 24/33] CLK: OMAP: move some defines from machine to driver header Tero Kristo
2013-07-23 7:20 ` [PATCHv4 25/33] ARM: OMAP: hwmod: fix an incorrect clk type cast with _get_clkdm Tero Kristo
2013-07-23 7:20 ` [PATCHv4 26/33] CLK: omap: gate: add support for OMAP36xx dpllx_mx_ck:s Tero Kristo
2013-07-23 7:20 ` [PATCHv4 27/33] ARM: OMAP3: hwmod: initialize clkdm from clkdm_name Tero Kristo
2013-07-23 7:20 ` [PATCHv4 28/33] ARM: dts: omap3 clock data Tero Kristo
2013-07-23 7:20 ` [PATCHv4 30/33] clk: OMAP: DRA7: Add APLL support Tero Kristo
2013-07-23 7:20 ` [PATCHv4 31/33] ARM: dts: clk: Add apll related clocks Tero Kristo
2013-07-23 7:20 ` [PATCHv4 32/33] clk: OMAP: DRA7: Change apll_pcie_m2_ck to fixed factor clock Tero Kristo
2013-07-23 7:20 ` [PATCHv4 33/33] clk: DTS: DRA7: Add PCIe related clock nodes Tero Kristo
2013-07-23 8:24 ` [PATCHv4 00/33] ARM: OMAP: clock conversion to DT Tero Kristo
2013-07-24 14:16 ` Roger Quadros
2013-07-24 14:29 ` Tero Kristo
2013-07-24 14:34 ` Roger Quadros
2013-07-24 14:43 ` Tero Kristo
[not found] ` <1374564028-11352-30-git-send-email-t-kristo@ti.com>
2013-07-30 20:19 ` [PATCHv4 29/33] CLK: omap: add omap3 clock init file Nishanth Menon
2013-07-31 6:35 ` Tony Lindgren
2013-07-31 15:10 ` Tero Kristo
2013-08-02 7:24 ` Tony Lindgren
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=51FA79E0.2070605@ti.com \
--to=t-kristo@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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