On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> wrote: >> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado < >> ricardo.ribalda@xxxxxxxxx> wrote: >>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz <djkurtz@xxxxxxxxxxxx> >> wrote: > >> In fact, the recommended way is to have firmware specify an ACPI SPCR table >> with OEMID="AMDCZ " (see https://patchwork.kernel.org/patch/10281307/) to >> configure proper access and address. > > Hmm... I was thinking it's already there. And thus, this is just a > quirk for *existing* firmware that doesn't correctly configured > hardware. > (Yes, I'm aware about one nuance in SPCR specification I'm trying to > address via official ways) > >> With an SPCR table in place, the >> kernel command line just becomes "earlycon", with no parameters. > > SPCR *provides* an address of UART (required by specification). What is "it's" in your first sentence? The access method? Baud rate can't be configured ever in the kernel w/o knowing the input clock to the uart block. That's already been brought up, and it is inherently a requirement to know that to recalculate the divisor. These patches are doing early OOB binding to set the proper input clock because: 1. SPCR doesn't have that information 2. you nak'd the generic way of specifying the input clock on the command line. Sadly, this situation is not unique to this hardware. There is hardware all over that does not meet the current assumptions being made in the early uart drivers within the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
