On Fri, 2020-01-31 at 16:24 +0100, Lukas Wunner wrote:

On Thu, Jan 30, 2020 at 05:11:55PM +0100, Nicolas Saenz Julienne wrote:

quoted

BTW did you had the oportunity to have a go at the patch?

I've just performed a quick test and it doesn't work for me.
If I add stdout-path = "serial1:115200n8"; to the chosen node,
I only get a regular console with this patch, not an earlycon.

That's surprising, you're using u-boot isn't it? and the upstream device tree?

quoted

quoted

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.

In that regard I suggest you use the upstream cpufreq driver which
behaves properly in that regard. It disables GPU freq scaling, so as to
change CPU frequencies without SPI/I2C/UART issues.

Okay, I'll take a look.  But the uart1 baudrate will still be wrong
if the firmware downclocks because of overheating, right?

You're right, it might happen. The way I understand it you're bound to leave
the GPU at it's lower frequency if you want to use those peripherals and for
them to be reliable. You could technically try to empirically fine tune the CPU
thermal trip point so as to make sure the upstream kernel cpufreq downclock
always kicks in before videocore's one. I'd actually like to see someone try
that. However short of using an RT kernel It think you'll never be 100% sure it
can never happen.

Regards,
Nicolas