Re: kernelci/kernelci.org bisection: baseline-nfs.bootrr.deferred-probe-empty on at91sam9g20ek
On Tue, Jan 16, 2024 at 10:25:28AM -0800, KernelCI bot wrote:
The KernelCI bisection bot has identified bc7d0133181e5f33aca ("ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek") from the v5.15 stable tree as causing something to fail to probe on at91sam9g20ek, most likely the audio driver though I didn't pull the logs to verify. The commit isn't a particularly obvious one for backporting.
Full bisection report below.
- This automated bisection report was sent to you on the basis *
- that you may be involved with the breaking commit it has *
- found. No manual investigation has been done to verify it, *
- and the root cause of the problem may be somewhere else. *
*
- If you do send a fix, please include this trailer: *
- Reported-by: "kernelci.org bot" bot@kernelci.org *
*
- Hope this helps! *
kernelci/kernelci.org bisection: baseline-nfs.bootrr.deferred-probe-empty on at91sam9g20ek
Summary: Start: bd7e92d593935 kernelci-20240116.0 Plain log: https://storage.kernelci.org/kernelci/kernelci.org/kernelci-20240116.0/arm/m... HTML log: https://storage.kernelci.org/kernelci/kernelci.org/kernelci-20240116.0/arm/m... Result: bc7d0133181e5 ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek
Checks: revert: PASS verify: PASS
Parameters: Tree: kernelci URL: https://github.com/kernelci/linux.git Branch: kernelci.org Target: at91sam9g20ek CPU arch: arm Lab: lab-broonie Compiler: gcc-10 Config: multi_v5_defconfig Test case: baseline-nfs.bootrr.deferred-probe-empty
Breaking commit found:
commit bc7d0133181e5f33ac33ca4f6bb2bce876c8ad88 Author: Mark Brown broonie@kernel.org Date: Fri Mar 25 15:42:39 2022 +0000
ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek [ Upstream commit c775cbf62ed4911e4f0f23880f01815753123690 ] The MCLK of the WM8731 on the AT91SAM9G20-EK board is connected to the PCK0 output of the SoC, intended in the reference software to be supplied using PLLB and programmed to 12MHz. As originally written for use with a board file the audio driver was responsible for configuring the entire tree but in the conversion to the common clock framework the registration of the named pck0 and pllb clocks was removed so the driver has failed to instantiate ever since. Since the WM8731 driver has had support for managing a MCLK provided via the common clock framework for some time we can simply drop all the clock management code from the machine driver other than configuration of the sysclk rate, the CODEC driver still respects that configuration from the machine driver. Fixes: ff78a189b0ae55f ("ARM: at91: remove old at91-specific clock driver") Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lore.kernel.org/r/20220325154241.1600757-2-broonie@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c index 8a55d59a6c2aa..d243de5f23dc1 100644 --- a/sound/soc/atmel/sam9g20_wm8731.c +++ b/sound/soc/atmel/sam9g20_wm8731.c @@ -46,35 +46,6 @@ */ #undef ENABLE_MIC_INPUT
-static struct clk *mclk;
-static int at91sam9g20ek_set_bias_level(struct snd_soc_card *card,
struct snd_soc_dapm_context *dapm,
enum snd_soc_bias_level level)
-{
- static int mclk_on;
- int ret = 0;
- switch (level) {
- case SND_SOC_BIAS_ON:
- case SND_SOC_BIAS_PREPARE:
if (!mclk_on)
ret = clk_enable(mclk);
if (ret == 0)
mclk_on = 1;
break;
- case SND_SOC_BIAS_OFF:
- case SND_SOC_BIAS_STANDBY:
if (mclk_on)
clk_disable(mclk);
mclk_on = 0;
break;
- }
- return ret;
-}
static const struct snd_soc_dapm_widget at91sam9g20ek_dapm_widgets[] = { SND_SOC_DAPM_MIC("Int Mic", NULL), SND_SOC_DAPM_SPK("Ext Spk", NULL), @@ -135,7 +106,6 @@ static struct snd_soc_card snd_soc_at91sam9g20ek = { .owner = THIS_MODULE, .dai_link = &at91sam9g20ek_dai, .num_links = 1,
.set_bias_level = at91sam9g20ek_set_bias_level,
.dapm_widgets = at91sam9g20ek_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(at91sam9g20ek_dapm_widgets),
@@ -148,7 +118,6 @@ static int at91sam9g20ek_audio_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; struct device_node *codec_np, *cpu_np;
- struct clk *pllb; struct snd_soc_card *card = &snd_soc_at91sam9g20ek; int ret;
@@ -162,31 +131,6 @@ static int at91sam9g20ek_audio_probe(struct platform_device *pdev) return -EINVAL; }
/*
* Codec MCLK is supplied by PCK0 - set it up.
*/
mclk = clk_get(NULL, "pck0");
if (IS_ERR(mclk)) {
dev_err(&pdev->dev, "Failed to get MCLK\n");
ret = PTR_ERR(mclk);
goto err;
}
pllb = clk_get(NULL, "pllb");
if (IS_ERR(pllb)) {
dev_err(&pdev->dev, "Failed to get PLLB\n");
ret = PTR_ERR(pllb);
goto err_mclk;
}
ret = clk_set_parent(mclk, pllb);
clk_put(pllb);
if (ret != 0) {
dev_err(&pdev->dev, "Failed to set MCLK parent\n");
goto err_mclk;
}
clk_set_rate(mclk, MCLK_RATE);
card->dev = &pdev->dev;
/* Parse device node info */
@@ -230,9 +174,6 @@ static int at91sam9g20ek_audio_probe(struct platform_device *pdev)
return ret;
-err_mclk:
- clk_put(mclk);
- mclk = NULL;
err: atmel_ssc_put_audio(0); return ret; @@ -242,8 +183,6 @@ static int at91sam9g20ek_audio_remove(struct platform_device *pdev) { struct snd_soc_card *card = platform_get_drvdata(pdev);
- clk_disable(mclk);
- mclk = NULL; snd_soc_unregister_card(card); atmel_ssc_put_audio(0);
Git bisection log:
git bisect start # good: [8bb7eca972ad531c9b149c0a51ab43a417385813] Linux 5.15 git bisect good 8bb7eca972ad531c9b149c0a51ab43a417385813 # bad: [bd7e92d593935dd5324b1a129a4753ab866fa8fc] kernelci-20240116.0 git bisect bad bd7e92d593935dd5324b1a129a4753ab866fa8fc # bad: [5a7a5b2edac4b05abd744eeaebda46d9dacd952d] drm/radeon: add a force flush to delay work when radeon git bisect bad 5a7a5b2edac4b05abd744eeaebda46d9dacd952d # good: [157a22ca80c50f64c495767331045d501c9ff013] staging:iio:adc:ad7280a: Fix handing of device address bit reversing. git bisect good 157a22ca80c50f64c495767331045d501c9ff013 # bad: [e0199ce728fb98a96a20136a5edb11c160d3151f] drm/amd/pm: Fix missing thermal throttler status git bisect bad e0199ce728fb98a96a20136a5edb11c160d3151f # bad: [fa189827f00c67b8ac2c396ee79d767c6a9ad6b9] netlink: do not reset transport header in netlink_recvmsg() git bisect bad fa189827f00c67b8ac2c396ee79d767c6a9ad6b9 # good: [56e44ff13d841cbb8638e7ec7759240a556752cd] ALSA: sonicvibes: Fix the missing snd_card_free() call at probe error git bisect good 56e44ff13d841cbb8638e7ec7759240a556752cd # bad: [858d93280e83561997cc06f5318ac22464d2bae0] serial: imx: fix overrun interrupts in DMA mode git bisect bad 858d93280e83561997cc06f5318ac22464d2bae0 # bad: [84e77e72367f6f2d293b80b18da84d587e86382f] dmaengine: dw-edma: Fix unaligned 64bit access git bisect bad 84e77e72367f6f2d293b80b18da84d587e86382f # good: [eab8e585840f84c6a352eaab70e5495eda7ebb6f] drm/amd/display: Enable power gating before init_pipes git bisect good eab8e585840f84c6a352eaab70e5495eda7ebb6f # good: [cbdd7a33c533e03404d51071af1e056ce3716caf] dt-bindings: net: snps: remove duplicate name git bisect good cbdd7a33c533e03404d51071af1e056ce3716caf # good: [935745abcf4c695a18b9af3fbe295e322547a114] vfs: make sync_filesystem return errors from ->sync_fs git bisect good 935745abcf4c695a18b9af3fbe295e322547a114 # good: [ba9e9a794fd1689bf7e8a7452c55f3d3cbda7728] net/sched: cls_u32: fix netns refcount changes in u32_change() git bisect good ba9e9a794fd1689bf7e8a7452c55f3d3cbda7728 # bad: [9a4c63e7332c8303265e559a0b52acf9e3ab2148] ASoC: rk817: Use devm_clk_get() in rk817_platform_probe git bisect bad 9a4c63e7332c8303265e559a0b52acf9e3ab2148 # good: [236785649ad2e027ccdaa6ee888c4a5571473eb9] ALSA: hda/realtek: Add quirk for Clevo NP70PNP git bisect good 236785649ad2e027ccdaa6ee888c4a5571473eb9 # bad: [bc15442cc99f054f7b2703db147099b7fe6bba69] ASoC: topology: Correct error handling in soc_tplg_dapm_widget_create() git bisect bad bc15442cc99f054f7b2703db147099b7fe6bba69 # bad: [bc7d0133181e5f33ac33ca4f6bb2bce876c8ad88] ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek git bisect bad bc7d0133181e5f33ac33ca4f6bb2bce876c8ad88
# first bad commit: [bc7d0133181e5f33ac33ca4f6bb2bce876c8ad88] ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek
-=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#50028): https://groups.io/g/kernelci-results/message/50028 Mute This Topic: https://groups.io/mt/103768621/1131744 Group Owner: kernelci-results+owner@groups.io Unsubscribe: https://groups.io/g/kernelci-results/unsub [broonie@kernel.org] -=-=-=-=-=-=-=-=-=-=-=-
On Tue, Jan 16, 2024 at 07:02:19PM +0000, Mark Brown wrote:
On Tue, Jan 16, 2024 at 10:25:28AM -0800, KernelCI bot wrote:
The KernelCI bisection bot has identified bc7d0133181e5f33aca ("ASoC:
Nit, typo in your sha1 here :(
atmel: Remove system clock tree configuration for at91sam9g20ek") from the v5.15 stable tree as causing something to fail to probe on at91sam9g20ek, most likely the audio driver though I didn't pull the logs to verify. The commit isn't a particularly obvious one for backporting.
Full bisection report below.
This is also in the following kernel releases: 4.19.240 5.4.191 5.10.113 do they also have issues? Does 6.1 and newer work properly?
And wow, this is old, nice to see it reported, but for a commit that landed in April, 2022? Does that mean that no one uses this hardware?
I'll be glad to revert, but should I also revert for 4.19.y and 5.4.y and 5.10.y?
thanks,
greg k-h
On Wed, Jan 17, 2024 at 06:55:09AM +0100, Greg Kroah-Hartman wrote:
This is also in the following kernel releases: 4.19.240 5.4.191 5.10.113 do they also have issues? Does 6.1 and newer work properly?
Current kernels work well, I've not had reports generated for the older kernels but it's possible they may be forthcoming (the bisection does tend to send issues slowly sometimes).
And wow, this is old, nice to see it reported, but for a commit that landed in April, 2022? Does that mean that no one uses this hardware?
I suspect it's just me, it's in my test lab. I don't routinely test stable (just let KernelCI use it to test stable).
I'll be glad to revert, but should I also revert for 4.19.y and 5.4.y and 5.10.y?
I'd be tempted to, though it's possible it's some other related issue so it might be safest to hold off until there's an explicit report. Up to you.
On Wed, Jan 17, 2024 at 01:52:59PM +0000, Mark Brown wrote:
On Wed, Jan 17, 2024 at 06:55:09AM +0100, Greg Kroah-Hartman wrote:
This is also in the following kernel releases: 4.19.240 5.4.191 5.10.113 do they also have issues? Does 6.1 and newer work properly?
Current kernels work well, I've not had reports generated for the older kernels but it's possible they may be forthcoming (the bisection does tend to send issues slowly sometimes).
And wow, this is old, nice to see it reported, but for a commit that landed in April, 2022? Does that mean that no one uses this hardware?
I suspect it's just me, it's in my test lab. I don't routinely test stable (just let KernelCI use it to test stable).
I'll be glad to revert, but should I also revert for 4.19.y and 5.4.y and 5.10.y?
I'd be tempted to, though it's possible it's some other related issue so it might be safest to hold off until there's an explicit report. Up to you.
I'll just drop it from 5.15.y for now, thanks!
greg k-h
On Thu, Jan 18, 2024 at 11:16:29AM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 17, 2024 at 01:52:59PM +0000, Mark Brown wrote:
I'll be glad to revert, but should I also revert for 4.19.y and 5.4.y and 5.10.y?
I'd be tempted to, though it's possible it's some other related issue so it might be safest to hold off until there's an explicit report. Up to you.
I'll just drop it from 5.15.y for now, thanks!
Thanks. I've actually just seen that it's also failing on v4.19, and went looking and found that v5.4 and v5.10 look like they never passed which means it didn't trigger as a report there.
On Thu, Jan 18, 2024 at 02:33:17PM +0000, Mark Brown wrote:
On Thu, Jan 18, 2024 at 11:16:29AM +0100, Greg Kroah-Hartman wrote:
On Wed, Jan 17, 2024 at 01:52:59PM +0000, Mark Brown wrote:
I'll be glad to revert, but should I also revert for 4.19.y and 5.4.y and 5.10.y?
I'd be tempted to, though it's possible it's some other related issue so it might be safest to hold off until there's an explicit report. Up to you.
I'll just drop it from 5.15.y for now, thanks!
Thanks. I've actually just seen that it's also failing on v4.19, and went looking and found that v5.4 and v5.10 look like they never passed which means it didn't trigger as a report there.
Now queued up the revert for the other branches as well, thanks.
greg k-h
participants (2)
-
Greg Kroah-Hartman
-
Mark Brown