Re: [PATCH] serial: 8250_early: Add earlycon for BCM2835 aux uart

From: Lukas Wunner <lukas@wunner.de>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	matthias.bgg@kernel.org, linux-arm-kernel@lists.infradead.org,
	Matthias Brugger <mbrugger@suse.com>,
	Scott Branden <sbranden@broadcom.com>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	Ray Jui <rjui@broadcom.com>, Stephen Boyd <swboyd@chromium.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org,
	linux-serial@vger.kernel.org, jslaby@suse.com
Subject: Re: [PATCH] serial: 8250_early: Add earlycon for BCM2835 aux uart
Date: Tue, 28 Jan 2020 15:19:58 +0100	[thread overview]
Message-ID: <20200128141958.vwbxoqglt5gw4xj5@wunner.de> (raw)
In-Reply-To: <C07FL64L9QNN.357K7JAUOSNA2@linux-9qgx>

On Tue, Jan 28, 2020 at 01:42:21PM +0100, Nicolas Saenz Julienne wrote:
> I'm testing this by booting directly from RPi4's bootloader. And it
> works as long as I add this to config.txt:
> 
> enable_uart=1
> gpu_freq=500
> 
> Which AFAIK blocks frequency scalin on the GPU and fixes the clock to a
> point where the serial is set at 115200 bauds.
> 
> Ideally it'd be nice to be able to query the clock frequency, and
> recalculate the divisors based on that. But I don't know if it's
> feasible at that point in the boot process.

Well, we don't even support adjusting the baudrate *after* the kernel
has booted.

The problem is that in mainline, bcm2835_defconfig contains:
CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y

Likewise in the Foundation's downstream tree, bcmrpi_defconfig as well
as bcm2711_defconfig and bcm2709_defconfig contain:
CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE=y

In contrast to this, we set the following on Revolution Pi devices:
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

Downclocking influences not only the uart1 baud rate but also the
spi0 clock.  We attach Ethernet chips to spi0, throughput was
significantly worse with the ondemand governor (which is what we
used previously).  We felt that maximum Ethernet performance
outweighs the relatively small powersaving gains.

Thanks,

Lukas