Wolfram Sang wrote:
> On Wed, Nov 11, 2009 at 12:55:13PM +0100, Wolfgang Grandegger wrote:
>> Wolfram Sang wrote:
>>> On Mon, Nov 02, 2009 at 10:44:13PM +0100, Wolfgang Grandegger wrote:
>>>> Wolfram Sang wrote:
>>>>>>> This is not possible yet. For that, I wanted to wait until the
>>>>>>> clock-representation in the device-tree (the patches you mentioned, I
>>>>>>> suppose)
>>>>>>> stabilizes. If this matures, we can add the proper way to do it. For
>>>>>>> now,
>>>>>>> "clock-ipb" is supported, the rest has to be done by the bootloader or
>>>>>>> additional patches. I wouldn't like to introduce "intermediate"
>>>>>>> properties to
>>>>>>> the device tree.
>>>>>> Why "intermediate"? I think the clock should be selectable via device
>>>>>> tree.
>>>>> Sure. With "intermediate" I just meant we would define some properties
>>>>> now and
>>>>> we already know they will then be obsoleted by the
>>>>> OF-clock-implementation.
>>>>> Hmmmm...
>>>> You mean the new one from Benjamin Herrenschmidt? I think it's the
>>>> drivers responsibility to set the clock source and frequency. Most
>>>> useful is the sys_clk, as it allows to select "good" CAN clock
>>>> frequencies (being a multiple of 8 MB).
>>> Yes, sure it is the drivers responsibility. But should we define some
>>> properties now, if it is favourable to use something like
>>>
>>> c...@xxxx {
>>> compatible = "...";
>>> clock = <&clock ... >;
>>> ...
>>> }
>>>
>>> in the future? (Old properties are always annoying, I think, so I just
>>> wonder
>>> if it is sensible to define some we know will be obsoleted?)
>> I think you mean that Herrenschmidt's clock patches will make a setting
>> like:
>>
>> fsl,mscan-clock-source = "ref_clk";
>> fsl,mscan-clock-divider = <8>;
>>
>> obsolete. Well, we need to provide a solution based on the new clock
>> interface. From Grant's comments I understood that the MSCAN clock
>> settings should be part of the driver.
>
> I have the feeling we are missing each other here :)
>
> Sure, the setting should be part of the driver. But the driver could do this
> also via something like of_get_clock() instead of custom properties, no?
But then the clock interface must take care of the clock settings, e.g.
the divider values for the MSCAN clock should be configurable via DTS
entries for the relevant clock node. Have I missed something? The
question is how to specify the divider value to be used for the MSCAN
clocks. How would you implement that?
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
