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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dfbe2c94dd52a31826be751f8dd9afc4ed08ec6d.camel@suse.de>
Date:   Mon, 03 Feb 2020 20:10:21 +0100
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Matthias Brugger <matthias.bgg@...il.com>, matthias.bgg@...nel.org,
        linux-arm-kernel@...ts.infradead.org,
        Matthias Brugger <mbrugger@...e.com>,
        Scott Branden <sbranden@...adcom.com>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        Ray Jui <rjui@...adcom.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        bcm-kernel-feedback-list@...adcom.com,
        linux-rpi-kernel@...ts.infradead.org, linux-serial@...r.kernel.org,
        jslaby@...e.com
Subject: Re: [PATCH] serial: 8250_early: Add earlycon for BCM2835 aux uart

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


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)