The quirks to get sound working with bytcr-rt5640 on that device are:
BYT_RT5640_SSP0_AIF1 | BYT_RT5640_IN1_MAP | BYT_RT5640_MCLK_EN
I guess this means that SSP0 is being used?
Yes indeed, and that makes me think we should force this device to look like
Baytrail-CR.
You can do this with a DMI-based quirk (preferably in is_byt_cr directly so
that I can reuse the code when I move it to a helper at some point).
Okay - thanks! One last question:
I was looking at the ACPI DSDT tables of some similar devices and have
found two others that look the same (only one IRQ listed). In this case,
the BYT-T acpi_ipc_irq_index = 5 will never work, and we will definitely
have a better chances with trying Baytrail-CR.
One of them actually had a similar patch proposed at [1] (although they
did it in a weird way and also need an extra machine driver).
We could also detect this situation in a generic way with something like
if (platform_irq_count(pdev) == 1) {
*bytcr = true;
return 0;
}
... instead of a DMI quirk. What do you think?
To avoid confusion: The existing PMIC-type based is_byt_cr() detection
would be used in all other cases (i.e. if irq_count != 1), so it won't
make any difference for the devices that are already working fine.
(Most BYT-CR devices seem to have 5 IRQs listed)
So it's more like
if (platform_irq_count(pdev) == 1) {
*bytcr = true;
} else {
// pmic-type based detection...
}
with platform_irq_count == 1 as condition for the "quirk".
The solution seems appealing but
1) does it really work? I am not sure an index=5 means there are 5
interrupts.
2) the test would affect all existing devices, and there's so much
hardware proliferation that proving this change in harmless might be
difficult. I personally only have one BYT-T (ASus T100) device left and
it's not very reliable. Hans seems to have a ton of devices but they are
mostly Byt-Cr?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
