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

From: Nicolas Saenz Julienne
Date: Mon Feb 03 2020 - 14:10:28 EST


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:
> > 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?

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

Attachment: signature.asc
Description: This is a digitally signed message part