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

[Arnd Bergmann]

On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote:
> 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.)

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.

	Arnd