On 5/15/24 22:22, Shuming [范書銘] wrote:
>>> +static const struct reg_sequence rt1320_blind_write[] = {
>> ...
>>> +};
>>> +
>>> +static const struct reg_sequence rt1320_patch_code_write[] = {
>> ...
>>> +};
>>
>> 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.
>> Maybe I missed it but I didn't see anything that tests the version_id and does
>> something different between VER_A and VER_B. Can you add a comment on
>> why it's important to track the version?
>>
>> Also if there's a DSP, is there a need for the FDL capability to download
>> firmware, or is the speaker protection configured only via tables?
>
> 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?
