Practical questions about mainlining a downstream codec driver
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
participants (1)
-
Vincent Knecht