On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin <adur...@chromium.org> wrote: > On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko > <andy.shevche...@gmail.com> wrote: >> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djku...@chromium.org> wrote: >>> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevche...@gmail.com> >>> wrote: >> >>> "earlycon simply does not utilize the information". >>> >>> earlycon parses iotype, mapbase and baud (from options). However, it is >>> hard-coded to assume that the clock used to generate the UART bitclock is >>> always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs, >>> it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz >>> clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and >>> uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is >>> actually a set up in acpi_apd.c when there is an acpi match for "AMD0020", >>> with a rate read from the .fixed_clk_rate param of the corresponding >>> apd_device_desc. >>> >>> This patch attempts to add a way to inform earlycon about this clock. As >>> noted above, the information is actually already in the kernel and used by >>> 8250_dw - I would happy be to hear recommendations for wiring this data >>> into earlycon that doesn't require adding another command line arg. >> >> And it should not require that for sure! > > But it does require that. There's an input clock to the uart ip block. > That is a design constraint by the hardware and is required to make > baud calculation work.
I mean it should not be user's headache to provide this information to the system. > It's not a firmware problem. If it's ACPI, then it's definitely firmware issue, since SPCR provides a baudrate. > Its the driver's problem in that it > assumes an input clock to the uart block that does not reflect > reality. So, driver can't get this info from device tree or what? >> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock. > > That's only possible if there is a clock divider on the front end of > the uart block. For this hardware that's not the case. I actually did > this very thing on intel chromebook devices, but it was only possible > because there was a hardware divider that could be tuned to reach the > assumed clock that the code currently assumes. OK. -- With Best Regards, Andy Shevchenko
