> > > So really this is setting up a loopback for testing? > > > We would not like to change ADCDAT pin to input mode in normal case. > > That's why the driver enables ADCDAT pin to the output mode in default. > > The rt1011 supports the feedback signal which could be playback data or I/V > data, etc. > > If the system wants the AEC reference data, rt1011 could feedback the > playback data. > > > The product could connect 2/4/6/8 rt1011 chips on the same I2S bus. > > In a test or debug mode, we could toggle ADCDAT pin to input mode that > > also helps HW engineer check the slot of feedback signal for each rt1011. > > I think this needs more than just a straight userspace control on one device, > these use cases make sense but they'll need to be configured over multiple > chips simultaneously otherwise there's some possibility of hardware damage > (eg, if two chips try to drive the signal at the same time). If this really can be > usefully varied at runtime then the driver bit of this should probably be an API > that the machine driver can call, the machine driver can then expose a control > that sets all the chips involved up together. I understand your concerns and comments. In a design-in project, we will provide the proper control settings to arrange the slot location of ADCDAT signal for each rt1011. HW engineer will confirm the ADCDAT signal, too. So, the customer should not make two chips drive the signal at the same slot and at the same time. But, there is a chance to happen if the customer sets the wrong control settings. We will take your suggestion to make it as API call. The machine driver knows how many rt1011 chips connect and make pin config change together. Thanks. > ------Please consider the environment before printing this e-mail. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
