TLV320AIC31xx recovery after a SPKVDD power glitch

[Dexter Travis]

I have a production agriculture display system using a TLV320AIC3120
for sound output to a speaker built into the monitor. The primary
processor is an NXP IMX6 Dual Plus. The system has an internal battery
backup but not all voltage rails are backed by the battery.  In
particular SPKVDD the 5V rail to the TLV320AIC3120 is not backed up.
The rest of the voltage rails to this device are backed by battery.
After a power glitch we do not emit sound.  Using dynamic debug and
adding some additional messages to the log It appears the driver is
working the same both before and after the power glitch.
We developed this a few years ago using the Freescale/NXP (fsl)
eureka-tlv320 (with slight modifications for the tlv320aic31xx) and
tlv320aic31xx.c drivers.

As an experiment i compiled both the eukrea-tlv320 and the
tlv320aic31xx drivers as modules.  This worked as expected before the
glitch.  After a glitch if I manually remove the modules and re-insert
them sound can be restored.

We have a user space application that can detect the power loss and if
the loss is persistent will gracefully shutdown the system.  When
power is restored we would like to use this to tell the driver to
perform some kind of restorative action.  I have tried triggering
through sysfs various resets to the tlv320aic3120 without success.  So
far only a full module remove of both eukrea and tlv320 will restore
sound.  remove and re-insert of either driver by itself does not work.

I have a few questions and areas where I would like advice.

0) What am i missing or doing wrong?  Should I be taking a different
approach altogether to this problem?

1) Should I migrate to simple-audio-card instead of eukrea-tlv320?

2) Suggestions on what needs to be reset/restored after the power rail
comes back?

3) Suggestions on how best to trigger the reset/restore from either
user space or the kernel?

Below is the relevant sections of our devicetree.


        sound {
                compatible = "eukrea,asoc-tlv320";
                eukrea,model = "pp-gen3display-tlv320aic3120";
                ssi-controller = <&ssi2>;
                fsl,mux-int-port = <2>;
                fsl,mux-ext-port = <3>;

                clocks = <&clks IMX6QDL_CLK_CKO>;
        };

&i2c1 {
        clock-frequency = <100000>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_i2c1>;
        status = "okay";

        tlv320aic3120: tlv320aic3120 at 18 {
            reg = <0x18>;
        };
...

&ssi2 {
        codec-handle = <&tlv320aic3120>;
        status = "okay";
};
&audmux {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_audmux>;
        status = "okay";
};
                pinctrl_audmux: audmuxgrp {
                        fsl,pins = <
                                MX6QDL_PAD_CSI0_DAT7__AUD3_RXD          0x130b0
                                MX6QDL_PAD_CSI0_DAT4__AUD3_TXC          0x130b0
                                MX6QDL_PAD_CSI0_DAT5__AUD3_TXD          0x110b0
                                MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS         0x130b0
                                MX6QDL_PAD_GPIO_2__GPIO1_IO02           0x17059
                                MX6QDL_PAD_CSI0_MCLK__CCM_CLKO1         0x130b0
                        >;
                };


Attached is our changes to the eukrea driver to support the
TLV320AIC31xx in our system.


Thank you,


Dexter Travis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2020-04-24_12-35-46.png
Type: image/png
Size: 84725 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200427/aec1aca3/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eukrea-tlv320-support-tlv320aic31xx.patch
Type: text/x-patch
Size: 3570 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20200427/aec1aca3/attachment-0001.bin>