From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH 11/20] dm: serial: Update binding for PL01x serial UART Date: Thu, 16 Jul 2015 09:41:11 +0200 Message-ID: References: <1436324032-17931-1-git-send-email-sjg@chromium.org> <1510062.S45KkZCs96@wuerfel> <4255169.hST9sycFU2@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <4255169.hST9sycFU2@wuerfel> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Arnd Bergmann Cc: Linus Walleij , Simon Glass , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , U-Boot Mailing List , Stephen Warren , Stephen Warren , Joe Hershberger , Masahiro Yamada , Masahiro Yamada , Marek Vasut , Tom Rini , Albert Aribaud , Vikas Manocha , Pavel Herrmann List-Id: devicetree@vger.kernel.org Hi Arnd, On Wed, Jul 15, 2015 at 12:17 PM, Arnd Bergmann wrote: > On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote: >> On Wed, Jul 15, 2015 at 11:38 AM, Arnd Bergmann 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-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Thu, 16 Jul 2015 09:41:11 +0200 Subject: [U-Boot] [PATCH 11/20] dm: serial: Update binding for PL01x serial UART In-Reply-To: <4255169.hST9sycFU2@wuerfel> References: <1436324032-17931-1-git-send-email-sjg@chromium.org> <1510062.S45KkZCs96@wuerfel> <4255169.hST9sycFU2@wuerfel> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Arnd, On Wed, Jul 15, 2015 at 12:17 PM, Arnd Bergmann wrote: > On Wednesday 15 July 2015 12:08:05 Linus Walleij wrote: >> On Wed, Jul 15, 2015 at 11:38 AM, Arnd Bergmann 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 at linux-m68k.org 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