[RFC PATCH 0/6] ALSA: mixer_audient: Cache rework and simplifications

[Will Porter <mrwillporter@gmail.com>]

Hi Christian,

On Tue, Nov 10, 2026 at 09:57:40PM +0100, Christian Ruppert wrote:
> I realized that usb_mixer_elem_info already contains an integer array for
> caching we could use instead of our manually allocated cache. I suspect we
> should rework patch 10 accordingly.

I like the idea. When I read the code for it, I saw a few more places
where the driver could be simpler. It seemed easier to show them as
patches than to describe them, so here they are for you to try on the
EVO4. Please take what you like and drop the rest.

> I'll prepare a new patch 10 but won't be able to test before the week-end.

Patches 3 to 6 need the cache change as a base, so patch 2 is my
version of it, only so that the rest can be tested. Please replace it
with yours. Two questions came up when I wrote it:

- The notify paths clear info->cached unless get_cur_broken is set. A
  write-only control could not read its value back after that. Patch 2
  sets get_cur_broken for the write-only controls. Is that a correct
  use of the field?
- The interrupt path clears the bit of the channel number in the
  message, and channel 0 clears all bits. Patch 2 uses the channel
  index in the element as the bit. Would the channel number of the
  request fit your EVO4 events better?

> Do you think it makes sense to refactor FU12 caching as well?

Yes, I think so: the driver then has one cache. Patch 6 does it.

The patches:

1. Not for merging. It has the changes from your review as one diff,
   so that patches 2 to 6 apply to the RFC with the enum fix.
2. Use cached and cache_val[] of usb_mixer_elem_info.
3. Replace INIT_HW, FORCE_SET and CACHE with an access mode:
   read-back, cached or write-only. The tables use only these three
   combinations of the flags. Do you plan to use another combination
   on the EVO4, for example INIT_HW on a control that can be read? If
   so, I will drop this patch.
4. Fill the cache on the first get or put, not at probe. The probe
   then sends 12 fewer GET requests on the EVO4 and 56 fewer on the
   iD14. Is there a reason for the EVO4 to read at probe?
5. Use one get and one put for booleans, integers and enums. This
   changes the code path of the EVO4 controls, which I cannot test.
6. Use the same cache for the FU 12 control.

Patches 2 to 6 make mixer_audient.c about 100 lines shorter (227
insertions, 324 deletions). Only patch 4 is meant to change behaviour.

Each patch builds with W=1 without warnings, and checkpatch --strict
shows no errors or warnings. On the iD14 MkI (stable 7.2.15) the read
and write checks of the controls pass with all six patches, change
events included. In 7.2.15 cached is still an int, so that build used
bit masks in place of the bitmap calls.

If some of these look useful, please take them into your new RFC in
any form you like. I can also fold them into the earlier patches, if
that saves you time.

Thanks,
Will

Will Porter (6):
  ALSA: mixer_audient: Fold in the review changes to patches 12-16
  ALSA: mixer_audient: Use the cache of usb_mixer_elem_info
  ALSA: mixer_audient: Replace three flags with an access mode
  ALSA: mixer_audient: Fill the cache on first use
  ALSA: mixer_audient: Use one get and one put for all control types
  ALSA: mixer_audient: Use the same cache for the iD14 MkI FU 12 control

 sound/usb/mixer_audient.c | 589 ++++++++++++++++----------------------
 sound/usb/mixer_quirks.c  |   2 -
 2 files changed, 251 insertions(+), 340 deletions(-)

-- 
2.47.3