On Wed, Mar 14, 2018 at 7:12 PM, Aaron Durbin <adurbin@xxxxxxxxxxxx> wrote: > 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? *SPCR table* itself on the platforms in question. > There is hardware all over that does > not meet the current assumptions being made in the early uart drivers > within the kernel. I know, that's why I'm working now on a proposal to SPCR specification to make our life slightly easier in that sense. P.S. In case you are interested, I have crafted SPCR in U-Boot for Intel Edison (ACPI case) where UART clock is also non-standard and did some tests. It works quite nicely when firmware, **iff written properly**, configures UART beforehand. In this case no clock information is needed, no code needs to be added into the kernel. -- With Best Regards, Andy Shevchenko -- 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
