Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox  wrote:
>> But we don't have the full ACPI interpreter up in the early part of
>> the kernel. All these 'early' devices have their own setup/config
>> which is the source of the issue. Or maybe I am wrong about the full
>> interpreter and the early drivers are just not taking advantage of the
>> ACPI device binding?
>
> In very early boot with serial console you just have to pray. No change
> there. Once ACPI comes up you however have the information to populate
> everything and configure correctly.
>
> So it should work fine except for kernel hackers trying to do early boot
> debug, which is a small (but important) cornercase ?

Yes, I think we're on the same page. This patch series is trying to
get the early console working correctly given the current code
assumptions.

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Fri, Apr 6, 2018 at 7:47 AM, Alan Cox  wrote:
>> But we don't have the full ACPI interpreter up in the early part of
>> the kernel. All these 'early' devices have their own setup/config
>> which is the source of the issue. Or maybe I am wrong about the full
>> interpreter and the early drivers are just not taking advantage of the
>> ACPI device binding?
>
> In very early boot with serial console you just have to pray. No change
> there. Once ACPI comes up you however have the information to populate
> everything and configure correctly.
>
> So it should work fine except for kernel hackers trying to do early boot
> debug, which is a small (but important) cornercase ?

Yes, I think we're on the same page. This patch series is trying to
get the early console working correctly given the current code
assumptions.

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device binding?

In very early boot with serial console you just have to pray. No change
there. Once ACPI comes up you however have the information to populate
everything and configure correctly.

So it should work fine except for kernel hackers trying to do early boot
debug, which is a small (but important) cornercase ?

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device binding?

In very early boot with serial console you just have to pray. No change
there. Once ACPI comes up you however have the information to populate
everything and configure correctly.

So it should work fine except for kernel hackers trying to do early boot
debug, which is a small (but important) cornercase ?

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox  wrote:
> On Mon, 26 Mar 2018 20:56:45 -0600
> Aaron Durbin  wrote:
>
>> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  
>> wrote:
>> >> 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.
>> >
>> > Is there any fundamental reason you can't just embed dt entries in the
>> > ACPI table to describe the other features you need. I appreciate it
>> > doesn't solve the generic PC case but it ought to help for anything where
>> > the firmware cares about Linux ?
>>
>> What's the method for doing that? Using _DSD methods? Or have a
>> pointer to examples? Sorry, I haven't spelunked into the current state
>> of bridging ACPI and devicetree in a while.
>
> ACPI 5.1 adds an _DSD method UUID for device properties.
>
> The kernel device_property_* interface will pick them up just as if they
> came from DT tables etc.

But we don't have the full ACPI interpreter up in the early part of
the kernel. All these 'early' devices have their own setup/config
which is the source of the issue. Or maybe I am wrong about the full
interpreter and the early drivers are just not taking advantage of the
ACPI device binding?

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Thu, Mar 29, 2018 at 6:34 AM, Alan Cox  wrote:
> On Mon, 26 Mar 2018 20:56:45 -0600
> Aaron Durbin  wrote:
>
>> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  
>> wrote:
>> >> 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.
>> >
>> > Is there any fundamental reason you can't just embed dt entries in the
>> > ACPI table to describe the other features you need. I appreciate it
>> > doesn't solve the generic PC case but it ought to help for anything where
>> > the firmware cares about Linux ?
>>
>> What's the method for doing that? Using _DSD methods? Or have a
>> pointer to examples? Sorry, I haven't spelunked into the current state
>> of bridging ACPI and devicetree in a while.
>
> ACPI 5.1 adds an _DSD method UUID for device properties.
>
> The kernel device_property_* interface will pick them up just as if they
> came from DT tables etc.

But we don't have the full ACPI interpreter up in the early part of
the kernel. All these 'early' devices have their own setup/config
which is the source of the issue. Or maybe I am wrong about the full
interpreter and the early drivers are just not taking advantage of the
ACPI device binding?

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin  wrote:

> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  wrote:
> >> 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.  
> >
> > Is there any fundamental reason you can't just embed dt entries in the
> > ACPI table to describe the other features you need. I appreciate it
> > doesn't solve the generic PC case but it ought to help for anything where
> > the firmware cares about Linux ?  
> 
> What's the method for doing that? Using _DSD methods? Or have a
> pointer to examples? Sorry, I haven't spelunked into the current state
> of bridging ACPI and devicetree in a while.

ACPI 5.1 adds an _DSD method UUID for device properties.

The kernel device_property_* interface will pick them up just as if they
came from DT tables etc.

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin  wrote:

> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  wrote:
> >> 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.  
> >
> > Is there any fundamental reason you can't just embed dt entries in the
> > ACPI table to describe the other features you need. I appreciate it
> > doesn't solve the generic PC case but it ought to help for anything where
> > the firmware cares about Linux ?  
> 
> What's the method for doing that? Using _DSD methods? Or have a
> pointer to examples? Sorry, I haven't spelunked into the current state
> of bridging ACPI and devicetree in a while.

ACPI 5.1 adds an _DSD method UUID for device properties.

The kernel device_property_* interface will pick them up just as if they
came from DT tables etc.

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  wrote:
>> 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.
>
> Is there any fundamental reason you can't just embed dt entries in the
> ACPI table to describe the other features you need. I appreciate it
> doesn't solve the generic PC case but it ought to help for anything where
> the firmware cares about Linux ?

What's the method for doing that? Using _DSD methods? Or have a
pointer to examples? Sorry, I haven't spelunked into the current state
of bridging ACPI and devicetree in a while.

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox  wrote:
>> 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.
>
> Is there any fundamental reason you can't just embed dt entries in the
> ACPI table to describe the other features you need. I appreciate it
> doesn't solve the generic PC case but it ought to help for anything where
> the firmware cares about Linux ?

What's the method for doing that? Using _DSD methods? Or have a
pointer to examples? Sorry, I haven't spelunked into the current state
of bridging ACPI and devicetree in a while.

-Aaron

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

> 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.

Is there any fundamental reason you can't just embed dt entries in the
ACPI table to describe the other features you need. I appreciate it
doesn't solve the generic PC case but it ought to help for anything where
the firmware cares about Linux ?

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Alan Cox]

> 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.

Is there any fundamental reason you can't just embed dt entries in the
ACPI table to describe the other features you need. I appreciate it
doesn't solve the generic PC case but it ought to help for anything where
the firmware cares about Linux ?

Alan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 7:12 PM, Aaron Durbin  wrote:
> On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
>  wrote:
>> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
>>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>>> ricardo.riba...@gmail.com> wrote:
 On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
>>> 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

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 7:12 PM, Aaron Durbin  wrote:
> On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
>  wrote:
>> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
>>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>>> ricardo.riba...@gmail.com> wrote:
 On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
>>> 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

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
 wrote:
> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>> ricardo.riba...@gmail.com> wrote:
>>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
>> 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.

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Aaron Durbin]

On Wed, Mar 14, 2018 at 10:38 AM, Andy Shevchenko
 wrote:
> On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
>> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
>> ricardo.riba...@gmail.com> wrote:
>>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
>> 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.

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
> ricardo.riba...@gmail.com> wrote:
>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
> 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).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 6:29 PM, Daniel Kurtz  wrote:
> On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
> ricardo.riba...@gmail.com> wrote:
>> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
> 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).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Daniel Kurtz]

Hi Ricardo,

On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Hi Daniel


> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
wrote:
> >
> > AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> > input clock.
> >
> > Allow these platforms to set up this clock by specifying a kernel
command
> > line like:
> > earlycon=amdcz,mmio32,0xfedc6000,115200


> If the port and the mode (mmio32) is always fixed, couldn't we just
> add those two into
> early_amdcz_setup?

There are multiple memory mapped UARTs on at least the one chip I am aware
of, specifying the address here chooses which port to use as the early
console.

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.  With an SPCR table in place,  the
kernel command line just becomes "earlycon", with no parameters.

-Dan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Daniel Kurtz]

Hi Ricardo,

On Wed, Mar 14, 2018 at 4:54 AM Ricardo Ribalda Delgado <
ricardo.riba...@gmail.com> wrote:

> Hi Daniel


> On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz 
wrote:
> >
> > AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> > input clock.
> >
> > Allow these platforms to set up this clock by specifying a kernel
command
> > line like:
> > earlycon=amdcz,mmio32,0xfedc6000,115200


> If the port and the mode (mmio32) is always fixed, couldn't we just
> add those two into
> early_amdcz_setup?

There are multiple memory mapped UARTs on at least the one chip I am aware
of, specifying the address here chooses which port to use as the early
console.

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.  With an SPCR table in place,  the
kernel command line just becomes "earlycon", with no parameters.

-Dan

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Ricardo Ribalda Delgado]

Hi Daniel


On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz  wrote:
>
> AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> input clock.
>
> Allow these platforms to set up this clock by specifying a kernel command
> line like:
> earlycon=amdcz,mmio32,0xfedc6000,115200


If the port and the mode (mmio32) is always fixed, couldn't we just
add those two into
early_amdcz_setup?


Thanks!

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Ricardo Ribalda Delgado]

Hi Daniel


On Wed, Mar 14, 2018 at 1:36 AM, Daniel Kurtz  wrote:
>
> AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> input clock.
>
> Allow these platforms to set up this clock by specifying a kernel command
> line like:
> earlycon=amdcz,mmio32,0xfedc6000,115200


If the port and the mode (mmio32) is always fixed, couldn't we just
add those two into
early_amdcz_setup?


Thanks!

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 2:36 AM, Daniel Kurtz  wrote:
> AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> input clock.
>
> Allow these platforms to set up this clock by specifying a kernel command
> line like:
> earlycon=amdcz,mmio32,0xfedc6000,115200
>

Thanks, this is what I meant.
Reviewed-by: Andy Shevchenko 

Suggested-by: ?

> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/tty/serial/8250/8250_early.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_early.c 
> b/drivers/tty/serial/8250/8250_early.c
> index ae6a256524d8..c6bf971a6038 100644
> --- a/drivers/tty/serial/8250/8250_early.c
> +++ b/drivers/tty/serial/8250/8250_early.c
> @@ -195,3 +195,18 @@ static int __init early_au_setup(struct earlycon_device 
> *dev, const char *opt)
>  OF_EARLYCON_DECLARE(palmchip, "ralink,rt2880-uart", early_au_setup);
>
>  #endif
> +
> +#ifdef CONFIG_SERIAL_8250_DW
> +static int __init early_amdcz_setup(struct earlycon_device *dev,
> +   const char *opt)
> +{
> +   struct uart_port *port = >port;
> +
> +   port->uartclk = 4800;
> +
> +   return early_serial8250_setup(dev, opt);
> +}
> +
> +EARLYCON_DECLARE(amdcz, early_amdcz_setup);
> +
> +#endif
> --
> 2.16.2.804.g6dcf76e118-goog
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

[Andy Shevchenko]

On Wed, Mar 14, 2018 at 2:36 AM, Daniel Kurtz  wrote:
> AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz
> input clock.
>
> Allow these platforms to set up this clock by specifying a kernel command
> line like:
> earlycon=amdcz,mmio32,0xfedc6000,115200
>

Thanks, this is what I meant.
Reviewed-by: Andy Shevchenko 

Suggested-by: ?

> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/tty/serial/8250/8250_early.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_early.c 
> b/drivers/tty/serial/8250/8250_early.c
> index ae6a256524d8..c6bf971a6038 100644
> --- a/drivers/tty/serial/8250/8250_early.c
> +++ b/drivers/tty/serial/8250/8250_early.c
> @@ -195,3 +195,18 @@ static int __init early_au_setup(struct earlycon_device 
> *dev, const char *opt)
>  OF_EARLYCON_DECLARE(palmchip, "ralink,rt2880-uart", early_au_setup);
>
>  #endif
> +
> +#ifdef CONFIG_SERIAL_8250_DW
> +static int __init early_amdcz_setup(struct earlycon_device *dev,
> +   const char *opt)
> +{
> +   struct uart_port *port = >port;
> +
> +   port->uartclk = 4800;
> +
> +   return early_serial8250_setup(dev, opt);
> +}
> +
> +EARLYCON_DECLARE(amdcz, early_amdcz_setup);
> +
> +#endif
> --
> 2.16.2.804.g6dcf76e118-goog
>



-- 
With Best Regards,
Andy Shevchenko