Practical questions about mainlining a downstream codec driver

[Vincent Knecht]

Hi !

I'm looking at submitting a patch to add support for (i2c) ak4375 codec
(a headphones amplifier). It works in close-to-mainline kernel forks
used in postmarketOS for msm8916-alcatel-idol347 and msm8939-alcatel-idol3
phones (the latter is not in mainline yet).

Currently the driver is mostly a cleanup and update of the downstream one
to use modern framework (eg. regmap, snd_soc_component_* functions, etc.)

The question is : how much should it be trimmed down ?

For example :
IC supports PLL and MCLK modes, and both testing devices use PLL mode.
- should the driver only support the mode that I could test ?
- should the UCM control(s) related to untested mode/features also be trimmed down ?
or can they be kept, with an error/warning that selected value is unsupported ?

Another question :
While both devices are quite close, downstream drivers have little differences.
For example, the idol347 one has an additional initialization register sequence.
What are the options ?
- allow setting this optional sequence from devicetree ?
  with register/values in driver and a boolean devicetree property to enable it ?
  or with an optional devicetree array property
- put it in driver, and associate it with a specific additional compatible ?
- ... ?

Bonus question :
Sadly, there's no detailed datasheet for ak4375 at
https://www.akm.com/eu/en/products/audio/audio-dac/
and only a brief one is floating on the Internets, eg.
https://datasheetspdf.com/pdf-file/1400317/AKM/AK4375A/1
I sent multiple inquiries through akm.com, even mailed directly
to persons with akm.com addresses I could find in alsa mailing list
so as to obtain a complete datasheet, with no success.
Can anyone help with this ?


Work on this driver is there :
https://github.com/msm8916-mainline/linux/pull/203

Thank you