[lkml]   [2012]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Common clock framework for external clock generators
    On 05/13/2012 06:43 PM, Mark Brown wrote:
    > One of the patches I've been sending adds a dummy clk_unregister() for
    > the sake of making the drivers look nicer - practically speaking it's
    > not likely to be terribly important as these things don't get unloaded
    > terribly often. It looks like that patch didn't get applied either.

    Well, of course I don't plan to unload the driver ever but basically it
    is possible..

    One more thing I thought about: The platform I currently use needs to
    pass the external clocks to the platform devices that can use them
    later. IMHO the correct way of creating clocks would be:

    - register i2c clock driver and let it register its clocks with names
    like e.g. si5351, clkout0. The clock driver itself cannot and should
    not know who uses it later on.
    - let drivers look for e.g. kirkwood-i2s.1, extclk because the i2s
    driver cannot know where the external clock comes from.
    - have a board-specific function that configures clock hierarchy and
    create suitable clk_aliases e.g.
    si5351,clkout0 = kirkwood-i2s.1,extclk.

    Currently I added a callback function pointer to the platform data
    passed to the i2c clock driver that is called at the end of clock
    driver probe. I doubt it will be accepted that way but can't think
    of any other way..


     \ /
      Last update: 2012-05-13 19:41    [W:0.026 / U:10.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site