On Friday 21 February 2014 16:18:54 Jonas Gorski wrote:
> On Fri, Feb 21, 2014 at 3:59 PM, Arnd Bergmann <[email protected]> wrote:
> > On Friday 21 February 2014 15:48:04 Jonas Gorski wrote:
> >>
> >> There already is a (non-OF) user for this driver that exports a
> >> "periph" clock, which is where the name comes from. It currently does
> >> all clock lookups purely based on the clock name, not the device name
> >> itself. Of course we can just make it get a different named clock when
> >> of_node is present; that should satisfy both.
> >
> > I think you are referring to arch/mips/bcm63xx/clk.c, but that doesn't
> > actually use clkdev at all and instead expects device drivers to know
> > the name of *output* of the clock controllers. You can't use that
> > name in the binding for a device, which needs to know the name of
> > the *input* from the clock consumer point of view.
>
> That's why I was suggesting making the driver do a lookup on the input
> name in case of probing through OF (having an of_node), and using
> the "legacy" output name else. That way the binding is not limited to
> the output name of bcm63xx/mips anymore.
Ok, fair enough.
> > An easy solution would be to register a clkdev lookup table in
> > the above clock driver.
>
> Requiring bcm63xx/mips to implement clkdev would be IMHO an
> unnecessary burden just so bcm63xx/arm using OF can reuse this driver.
> Letting bcm63xx use a clkdev lookup table (or rather tables, as each
> chip is different) is good mid or long term goal, but it should not
> block other users.
Ah, that's probably right. I was assuming you'd only need to
add a single function call to register a table, but I see now
that using clkdev would impact the entire clk implementation
on bcm63xx.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
