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.) Yours, Linus Walleij -- 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
