> >> On GitHub we talked about using the SDCA Initialization table coming > >> from ACPI, is this still something you're interested in? > > > > If the SDCA function is ready, the codec driver could call the API to do the > blind writes. > > The code I have is about ready, it just needs to be cleaned-up and submitted. > > But just to be clear, the codec driver would use the API to retrieve an array of > (address, value) pair. It would be up to the codec driver to do the writes and/or > patch their regmap. Understood. However, the customer requested Realtek to send the primary version to upstream first. We could modify the codec driver after the patches of the SDCA function are submitted. > > OK, will add a comment for the version_id. > > Currently, the blind writes enables the basic function, not the advanced > mode (speaker protection). > > However, VER_B has the capability to enable the speaker protection. > > The codec driver could use the version_id if the customer wants to enable > the speaker protection. > > Regarding DSP firmware, the ROM code stores the DSP FW inside the chip. > > The speaker protection needs other parameters to set. > > If there is a speaker protection running on the codec DSP, shouldn't there be a > source port to pass an echo reference back to the host? I could create the capture DAI for AEC feedback.
