From: Mark Brown <broonie@kernel.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>,
kernel@collabora.com, "Jaroslav Kysela" <perex@perex.cz>,
"Shuah Khan" <shuah@kernel.org>, "Takashi Iwai" <tiwai@suse.com>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2] kselftest/alsa: Increase kselftest timeout
Date: Wed, 14 Dec 2022 18:15:22 +0000 [thread overview]
Message-ID: <Y5oSui0udT/6cvSI@sirena.org.uk> (raw)
In-Reply-To: <808f35bf-2800-c34b-cae9-4d8eaa11294d@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]
On Wed, Dec 14, 2022 at 09:40:02AM -0700, Shuah Khan wrote:
> On 12/14/22 06:03, Nícolas F. R. A. Prado wrote:
> > The default timeout for kselftests is 45 seconds, but that isn't enough
> > time to run pcm-test when there are many PCMs on the device, nor for
> > mixer-test when slower control buses and fancier CODECs are present.
> >
> > As data points, running pcm-test on mt8192-asurada-spherion takes about
> > 1m15s, and mixer-test on rk3399-gru-kevin takes about 2m.
> >
> > Set the timeout to 4 minutes to allow both pcm-test and mixer-test to
> > run to completion with some slack.
> What I have in mind is that the default run can be limited scope.
> Run it on a few controllers and in the report mention that a full
> test can be run as needed.
> There are a couple of examples of default vs. full test runs - cpu
> and memory hot-lug tests.
For pcm-test it's probably more sensible to refactor things to run
multiple PCMs (or at least cards, though that's less relevant in an
embedded context) in parallel rather than cut down the test coverage,
it's already very limited coverage as things stand. There is some risk
there could be false positives from cross talk between the PCMs but it's
probably worth it.
With mixer-test if it's actually taking a long time to run generally
this is just identifying that the driver could use some work,
implementing runtime power management and a register cache will probably
resolve most issues.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-12-14 18:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 13:03 Nícolas F. R. A. Prado
2022-12-14 16:40 ` Shuah Khan
2022-12-14 18:15 ` Mark Brown [this message]
2023-04-03 21:30 ` Nícolas F. R. A. Prado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y5oSui0udT/6cvSI@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nfraprado@collabora.com \
--cc=perex@perex.cz \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®