Re: [PATCH] drivers: char: omap-uart: add "clock-hz" option

[Julien Grall <julien@xxxxxxx>]

On 06/08/2024 10:50, Amneesh Singh wrote:
> On 10:16-20240806, Julien Grall wrote:
> > Hi,
> >
> > On 19/07/2024 12:33, Amneesh Singh wrote:
> > > Quite a few TI K3 devices do not have clock-frequency specified in their
> > > respective UART nodes.
> > Can you outline why fixing the device-tree is not solution?
> Because other frequencies, say 96MHz or 192 MHz are also valid inputs.
Are you saying this is configurable by the user? Or do you mean the 
firmware can configure it?
> > > However hard-coding the frequency is not a
> >   > solution as the function clock input can differ between SoCs.
> >
> > Can you provide some details how Linux is handling those SoCs?
> Yes, like omap-uart under xen, the 8250_omap driver also parses the DT,
> but unlike omap-uart, falls back to clk_get_rate() and if the value is
> still zero, it defaults to 48MHz.
Thanks for the information. Then my next question is why Linux can get 
away with a default value and not Xen?
To give more context, I don't feel it is right to ask the user to 
specify the clock speed. Xen should have a sane default like Linux.
> > > So,
> > > similar to com1/com2, let the user pass the frequency as a dtuart option
> > > via the bootargs. If not specified it will fallback to the same DT
> > > parsing as before. For example, dtuart=serial2:clock-hz=48000000 can be
> > > a valid bootarg.
> > Regardless my questions, any change to the command line needs to be
> > documented in docs/misc/xen-command-line.pandoc.
> I am not sure if that will be necessary as the dtuart option already
> says: "The options are device specific."
Let me ask differently, if you don't document in 
xen-command-line.pandoc, then how do you expect the user to know that 
the option clockspeed exists and what is the expected value?
To me the right place is in xen-command-line.pandoc because it should 
describe all the options (including device specific ones).
Cheers,

--
Julien Grall