Hi Arnd,
On Wed, Jul 15, 2015 at 12:17 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote:
>> On Wed, Jul 15, 2015 at 11:38 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>
>> > The CHRP ISA binding defines that a 8250 compatible UART must have this
>> > property:
>> >
>> > "clock-frequency" S
>> >
>> > Standard property, encoded as with encode-int, that shall be the baud-rate
>> > generator's clock input frequency (in hertz).
>> > Typically, the clock frequency is nominally 1,843,200 Hz. Some devices
>> > generate the baud rate input clock by dividing a higher-frequency clock
>> > source that is not an exact multiple of 1,843,200 Hz, resulting in a
>> > small but acceptable error in the nominal clock frequency. In such cases,
>> > the "clock-frequency" shall report the actual nominal frequency. For
>> > example, if the baud rate input clock is generated by dividing a 24
>> > MHz clock by 13, the value of the "clock-frequency" property shall be 1846153.
>>
>> Isn't that for the case where the clock frequency will never change at runtime?
>>
>> The problem (I think) with many systems using PL011 is that they can
>> actually change the serial port clock at runtime (software controlled clock),
>> so providing a "clock-frequency" would imply that they cannot, and the clock
>> frequency is fixed to that value.
>>
>> I think it's better to use boot-clock-frequency or so to indicate that a richer
>> OS will provide more refined clocks. For example that frequency can
>> typically change if the SoC changes operating point or so, though it would
>> be awkward to handle in the driver, admittedly and I haven't seen a
>> piece of code that actually go and change the UART input frequency.
>>
>> Still for completion it is better for the UART to tie into the clk framework
>> as the OS gets up, and just providing clock-frequency seems to imply
>> that it need not do that or something. The semantical effect of providing both
>> clock-frequency = and clocks =< &..> must be clarified in any case.
>> Like the latter overrides the former if clock phandles can be handled by
>> the environment. (And this should be stated in the binding.)
>
> Ah right. I don't think that naming is super critical though, as a lot
> of properties in the DT just describe how things are at boot time.
Hence those don't describe the hardware...
Shouldn't they be in /chosen instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
