On Fri, Aug 02, 2019 at 03:51:09PM +0100, Thomas Preston wrote:
On 02/08/2019 12:10, Mark Brown wrote:
You can use a read only control for the readback, or just have it be triggered by overwriting the readback value. You can cache the result.
Keeping the trigger and result together like that would be better I think, although the routine isn't supposed to run mid way through playback. If we're mid playback the debugfs routine has to turn off AMP_ON, take the device back to a known state, run diagnostics, then restore. Which causes a gap in the audible sound.
Whatever method is used to do the triggering can always return -EBUSY when you someone tries to do so during playback.
Kirill Marinushkin mentioned this in the first review [0], it just didn't really sink in until now!
You could do that too, yeah. Depends on what this is diagnosing and if that'd be useful.
The diagnostic status bits describe situations such as:
- open load (no speaker connected)
- short to GND
- short to VCC
- etc
The intention is to test if all the speakers are connected. So, one might have a self test which runs the diagnostic and verifies it outputs:
...
I think the module parameter method is more appropriate for a "Turn-on diagnostic", even though I don't really like grepping dmesg for the result. I'll go ahead and implement that unless anyone has a particular preference for the kcontrol-trigger.
Right. It's not ideal for use in production systems for example but perhaps fine for support techs or whoever. Up to you anyway.