Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 27 Jan 2020 13:32:49 +0100
From:   Petr Mladek <pmladek@suse.com>
To:     Eugeniu Rosca <erosca@de.adit-jv.com>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        John Ogness <john.ogness@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Geert Uytterhoeven <geert+renesas@glider.be>,
        Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
        Andrew Gabbasov <andrew_gabbasov@mentor.com>,
        Sanjeev Chugh <sanjeev_chugh@mentor.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Daniel Wang <wonderfly@google.com>,
        Dean Jenkins <dean_jenkins@mentor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Dirk Behme <dirk.behme@de.bosch.com>,
        Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
        Jiri Slaby <jslaby@suse.com>,
        Peter Feiner <pfeiner@google.com>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Eugeniu Rosca <roscaeugeniu@gmail.com>
Subject: Re: [RFC PATCH v1 00/25] printk: new implementation
Message-ID: <20200127123249.t7agkht3ddgetfhf@pathway.suse.cz>
References: <20190212143003.48446-1-john.ogness@linutronix.de>
 <20200120230522.GA23636@lxhi-065.adit-jv.com>
 <87v9p4mkhr.fsf@linutronix.de>
 <20200122023422.GA926@lxhi-065.adit-jv.com>
 <CAMuHMdXT9USuHw15nA1mLXsh7RKK68eN0phevC_Jauaa7FnW0Q@mail.gmail.com>
 <20200122165855.GA3485@lxhi-065.adit-jv.com>
 <CAMuHMdWzapJ+5Jtf5fPQGP5edzCUfMeQA7v3GVWbKKvR=aXSsg@mail.gmail.com>
 <20200124160929.GA10863@lxhi-065.adit-jv.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200124160929.GA10863@lxhi-065.adit-jv.com>
User-Agent: NeoMutt/20170912 (1.9.0)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri 2020-01-24 17:09:29, Eugeniu Rosca wrote:
> Hi Geert,
> 
> On Wed, Jan 22, 2020 at 08:48:12PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Jan 22, 2020 at 5:59 PM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> > > On Wed, Jan 22, 2020 at 08:31:44AM +0100, Geert Uytterhoeven wrote:
> > > > On Wed, Jan 22, 2020 at 3:34 AM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> > > > > So, what's specific to R-Car3, based on my testing, is that the issue
> > > > > can only be reproduced if the printk storm originates on CPU0
> 
> Slight amendment the above statement. Below results are got on R-Car
> H3ULCB running renesas-drivers-2020-01-14-v5.5-rc6 (cX stands for CPUx,
> whitespace stands for clean audio, '!' stands for distorted audio):
> 
>                   printk @:
>                   c0 c1 c2 c3 c4 c5 c6 c7
> speaker-test @ c0 !
>                c1 !  !
>                c2 !     !
>                c3 !        !
>                c4 !           !
>                c5 !              !
>                c6 !                 !
>                c7 !                    !
> 
> One can see two patterns in the chart. The audio has glitches whenever:
>  - printk and the audio application run on the same CPU, or:
>  - printk runs on CPU0

The proper longterm solution seems to be offloading printk console
handling to a kthread so that it can be bound to a particular CPU
and does not block audio.

Anyway, there is a question whether you really need to send all messages
via the serial console. It might make sense to filter less important
messages using "loglevel=" or "quiet" kernel parameters. The full
log can be read later from userspace (dmesg, syslog, /dev/kmsg).
Filtering can get disabled when debugging non-booting kernel.
In this case, a distorted audio is the least problem.

Best Regards,
Petr