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