[alsa-devel] [PATCH] ASoC: Intel: bytcr_rt5640: fallback mechanism if MCLK is not enabled
Takashi Iwai
tiwai at suse.de
Thu Dec 15 08:42:22 CET 2016
On Wed, 14 Dec 2016 23:08:45 +0100,
Pierre-Louis Bossart wrote:
>
> On 12/14/16 7:19 AM, Mark Brown wrote:
> > On Tue, Dec 13, 2016 at 12:41:30PM -0600, Pierre-Louis Bossart wrote:
> >> Commit df1a2776a795 ("ASoC: Intel: bytcr_rt5640: add MCLK support")
> >> was merged but the corresponding clock framework patches have not,
> >> after being bumped from audio to clock to x86 domains. The missing
> >> clock-related patches result in a regression starting with 4.9 with
> >> the audio card not being created.
> >
> > When I asked about this previously you said that this only affected new
> > boards?
>
> see
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/111865.html
> all boards will be affected but newer boards never worked before. Only
> older BYT-T are affected by a regression. And given the hair-splitting
> debates on what constitutes pdata or what the locations of the PMC
> files should be I am no longer expecting a quick resolution. At this
> rate it'll take 9 months to program 2 registers.
>
> >
> >> dev_err(&pdev->dev,
> >> "Failed to get MCLK from pmc_plt_clk_3: %ld\n",
> >> PTR_ERR(priv->mclk));
> >> - return PTR_ERR(priv->mclk);
> >> +
> >> + /* Fall back to bitclock only */
> >> + byt_rt5640_quirk &= ~BYT_RT5640_MCLK_EN;
> >
> > This is broken for probe deferral, I'd expect this to be explicitly
> > checking for a no clock mapped error code (probably -ENOENT) rather than
> > just ignoring all errors.
>
> I don't understand the probe deferral concept here. Are you saying
> fall back to the bit clock mode if the status is -ENOENT and fail
> otherwise?
The clk driver may return -EPROBE_DEFER, and in that case, the intel
driver should also defer the probe as well. Or, like -ENOMEM, it
indicates a serious error, and then better bail out.
So, we need to figure out which error code should fall back to the
legacy mode. (Or vice versa, which error code shouldn't be ignored.)
Takashi
More information about the Alsa-devel
mailing list