[U-Boot] [PATCH 11/20] dm: serial: Update binding for PL01x serial UART

[Linus Walleij]

On Wed, Jul 15, 2015 at 11:38 AM, Arnd Bergmann <arnd at arndb.de> 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