Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Andy Shevchenko
Date: Thu Mar 01 2018 - 15:02:33 EST
On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote:
> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@xxxxxxxxx>
> 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!
I would look to this later. It's late here. I need to do a bit of
research for the answer.
> I see that support was also added recently to earlycon to let it use ACPI
> SPCR to choose a console and configure its parameters... but AFAICT, this
> path also doesn't allow specifying the uart clock.
Fix your firmware then. It should set console to 115200 like (almost)
everyone does.
Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
--
With Best Regards,
Andy Shevchenko