On Tue, Jan 05, 2016 at 08:50:11AM -0600, Pierre-Louis Bossart wrote: > On 1/5/16 7:15 AM, Mark Brown wrote: > >I'm wondering how this is going to get loaded (I don't see what creates > >the platform device) and how we handle systems with a CODEC connected on > >the expansion headers? > Good question. > To solve this audio is disabled by default, and we have an EFI application > loaded by the startup.nsh file that sets the relevant codec information in > the SSDT table so that you can swap codec cards at will. The EFI application > will be open-sourced so that additional codecs can be added as needed with > changes in the ASL code. The whole thing was tested with experimental > releases in three different setups for now but will be formally released > next month. Sets the relevant codec information by...? > On probe the sst_acpi part checks for the presence of known codecs and > registers the platform driver. For the case where no codec is present I just > added an entry at the end of the table that always works (checks for an > SOC-side HID) and is selected if no other codec was found. I need to add > this patch and submit it, forgot to add it in this batch. Can we punt on this until we've got the rest of the infrastructure to look at? I'd feel safer and it sounds like it's going to need some manual hacking to get working anyway until the other bits are lined up.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
