On 1/6/16 11:42 AM, Mark Brown wrote:
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...?
exposing devices and dependencies, setting the _HID, codec I2C address,
Gpio lines, DSD properties if needed. Nothing new compared to a normal
DSDT table except that you only add the audio-related information yourself.
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.
that's fine, i will provide more documentation to explain the steps
later this month. The 'infrastructure' isn't that bad really - and since
the SSDT update application is open-source for once you can't blame the
BIOS if your audio doesn't work :-)
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
