On any panic, we dump out the last ~30 seconds of IVSENSE data along
with the starting state and panic reason.
Also add a feature to panic if the gain reduces too much. This can be
used to try to catch badness.
Signed-off-by: Hector Martin <marcan@marcan.st>
We're not doing explicit error handling, since the kernel is in charge
of safety if we crash. Just panic on anything.
Signed-off-by: Hector Martin <marcan@marcan.st>
ALSA needs special handling to correctly resume after the system is
suspended with a PCM active. Do the required dance.
Signed-off-by: Hector Martin <marcan@marcan.st>
Doesn't really matter for us since all machines we plan to use so far
have the same chip, but might matter in the future.
Signed-off-by: Hector Martin <marcan@marcan.st>
Take the vendor from the DT compatible, since in principle other
manufacturers could use this code too.
Signed-off-by: Hector Martin <marcan@marcan.st>
Just reporting the first nonzero change isn't really useful. Be spammy,
we can always reduce this later.
Signed-off-by: Hector Martin <marcan@marcan.st>
If this is the first time the daemon runs, we assume 99C (just under the
limit, which means no reduction). Otherwise, we assume the max
temperature, and therefore max limit.
Signed-off-by: Hector Martin <marcan@marcan.st>
This is mostly to avoid a sudden jump up in volume on the common case where the
first sound happens after enough catchup has occurred (once we implement
catchup...)
Signed-off-by: Hector Martin <marcan@marcan.st>
the bindings we rely on were merged in v0.7.1, so we
no longer need to carry the crate downstream.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
This allows the sense PCM to be opened at the correct current rate if
playback is active, or otherwise arbitrarily picks the lowest rate.
Signed-off-by: Hector Martin <marcan@marcan.st>
