Re: [PATCH v2 2/5] arm64: dts: r8a7795: Add cpuidle support for CA53 cores

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 29, 2019 at 09:44:52AM +0200, Geert Uytterhoeven wrote:
> Hi Eugniu,
> 
> CC cpuidle people
> 
> On Fri, Jul 26, 2019 at 11:47 AM Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote:
> > On Fri, Jul 26, 2019 at 11:13:29AM +0200, Rosca, Eugeniu (ADITG/ESM1) wrote:
> > [..]
> > > The culprit BSP commits are:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=3c3b44c752c4ee
> > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/commit/?id=902ff7caa32dc71c
> > >
> > > Further narrowing it down, it turns out the CA57 cpuidle support is
> > > not responsible for generating the issue. It's all about the CA53 idle
> > > enablement. The reference target is H3-ES2.0-Salvator-X (the problem
> > > originally emerged on M3-based customer HW).
> > [..]
> >
> > Small amendment to the above (based on vanilla testing):
> >
> >  Version                              Issue reproduced?
> >                                       (H3-ES2.0-Salvator-X)
> >  v5.3-rc1-96-g6789f873ed37              No
> >  v5.3-rc1-96-g6789f873ed37 + [1]        No
> >  v5.3-rc1-96-g6789f873ed37 + [2]        No
> >  v5.3-rc1-96-g6789f873ed37 + [1] + [2]  Yes
> >
> > [1] https://patchwork.kernel.org/patch/10769701/
> > ("[v2,1/5] arm64: dts: r8a7795: Add cpuidle support for CA57 cores")
> >
> > [2] https://patchwork.kernel.org/patch/10769689/
> > ("[v2,2/5] arm64: dts: r8a7795: Add cpuidle support for CA53 cores")
> 
> Thanks for your report and investigation!
> 
> Unfortunately your original report didn't make it to lore.kernel.org, and
> probably also not to the list, due to the large audio attachment.
> 
> For the newly CCed people, the issue is about consistent dropouts
> during audio playback using an in-house application, introduced by
> adding cpuidle support to _both_ the big and LITTLE cores.

CPUidle entry/exit latencies are certainly bringing the issue
about, I am not an audio expert but I suspect buffering should
be tuned to cope with those _increased_ latencies or possibly
idle states disabled for certain specific use cases - there
is no silver bullet, entering deep idle states will increase
latencies, there is no way around it.

I am happy to help you debug the issue further.

Lorenzo



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux