[PATCH 4/7] dt/clock: Add handling for fixed clocks and a clock node setup iterator

Shawn Guo shawn.guo at linaro.org
Sun Apr 15 17:01:35 EST 2012


On Sat, Apr 14, 2012 at 10:04:26PM -0500, Rob Herring wrote:
...
> So you want to have generic bindings for every clock which implies a
> bunch of nodes if not a node per clock anyway, but then object to 3
> nodes for fixed clocks.
> 
I do not really care about that now, as long as you clearly document
in fixed clock binding that there is no multiple outputs support for
fixed-clock, and #clock-cells has to be 0.

...
> I'm talking about the bindings and you are pointing me to an
> implementation with no bindings. It's 2 different things. The
> implementation can fully be the generic clk implementations, but the
> clock bindings can still be either a node per clock or a monolithic
> clock module node. There is no fixed rule here and there should not be.
> We can each chose what works best for us.
> 
It will be a pity if we can not have a generic binding for a generic
implementation.

> I see a couple of examples that your clocks are still SoC specific
> despite your claims.
> 
> Your clock gates may reuse clk_gate struct, but they still have custom
> ops to handle the 2-bit field. Obviously, you decided not to merge 2-bit
> field support into the existing clk gate code (the correct decision
> IMHO). I made a similar decision.
> 
Actually, Sascha decided.

> For practically every clock, you need to set the spinlock to
> imx_ccm_lock. How are you going to know which clocks to set this lock
> for with a "generic" binding? You have to distinguish those from IPU
> clocks for example.
> 
Something like this:

void __init of_clk_divider_setup(struct device_node *node, spinlock_t *lock)
{
        [ parse clock-divider properties from node ]

        clk = clk_register_divider(NULL, name, parent, CLK_SET_RATE_PARENT,
                        reg, shift, width, 0, &lock);
        if (clk)
                of_clk_add_provider(node, NULL, clk);
}

void __init imx_clk_divider_init(struct device_node *node)
{
        return of_clk_divider_setup(node, &imx_ccm_lock);
}

static const struct of_device_id imx_clk_match[] __initconst = {
        { .compatible = "fsl,clock-divider", .data = imx_clk_divider_init, },
        {}
};

void __init imx_clocks_init(void)
{
        of_clk_init(imx_clk_match);
}

When I say generic binding, it does not necessarily mean the generic
compatible string, but the property definition and generic DT setup
code for them, something similar as generic regulator binding
Documentation/devicetree/bindings/regulator/regulator.txt and the
setup/parse function of_get_regulator_init_data.

Honestly, I'm losing my interest on clock binding.  I will stay with
clk_lookup before I see a solution to how we represent part of the
clock tree in DT while their input/parent clocks in the clock code.

-- 
Regards,
Shawn


More information about the devicetree-discuss mailing list