On Thu, Mar 31, 2022 at 05:04:32PM +0200, Martin Povišer wrote: > > On 31. 3. 2022, at 16:18, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Yes, having two devices driving the bus at the same time wouldn't be > > great. How is the TDM slot selection for the signals done in the > > hardware, I'm not seeing anything immediately obvious in the driver? > > I'd have thought that things would be implemented such that you could > > implement speaker protection on all speakers simultaneously but perhaps > > not. > I don’t know. I would have to go study the details of this. Should I see > if I can find a combination of ‘ASI1 Sel’ ‘VSENSE’ ‘ISENSE’ settings > that would lead to driver conflict on one of the models, or is there > a chance we could hide those controls just on the basis of ‘it doesn’t > do anything usable and is possibly dangerous’? If ISENSE and VSENSE output are controlled by the same mux as routing then we should lock one of the controls out for at least stereo devices (it might be a good idea to check if the output is actually high Z when ISENSE and VSENSE are off rather than just driving zeros, if not it definitely has to be the routing control). My instinct is that it's better to preserve the ability to implement speaker protection in future since that is something that'd be broadly useful, especially if someone comes up with a generic speaker protection implementation in which case there should be an awful lot of systems out there which could benefit. > >> That’s the reasoning anyway. To reiterate, seems to me the controls > >> are useless/confusing at best and dangerous at worst. > > I'm just not seeing an issue for the slot selection. > Yeah, agreed there’s no (damage) issue as we should to proper volume > caps anyway. Though see above about how ISENSE/VSENSE output slot is controlled I guess :/
Attachment:
signature.asc
Description: PGP signature
