>>> That tells us it has 3 functions (jack, mic, amp), so what's different to RT722? >>> could we have a single driver for both parts? A lot of this driver seems >>> copy-pasted-renamed. > >> RT721 has 3 functions just like RT722, but it's still a different codec and from internal discussion, >> we think it's better to separate the driver for future code management. > > As I mentioned with the events it's possible there's some room for > factoring out some of the code for the common bits that are shared > between multiple devices. Look at how Cirrus' Arizona drivers for > example, each chip has specific support in a separate driver but there's > a lot of shared code. > >>>> + /* Set RC calibration */ >>>> + rt721_sdca_index_write(rt721, RT721_RC_CALIB_CTRL, >>>> + RT721_RC_CALIB_CTRL0, 0x0b00); >>>> + rt721_sdca_index_write(rt721, RT721_RC_CALIB_CTRL, >>>> + RT721_RC_CALIB_CTRL0, 0x0b40); >>>> + /* Fine tune PDE2A latency */ >>>> + regmap_write(rt721->regmap, 0x2f5c, 0x25); } > >>> Humm, isn't all this supposed to be handled with blind writes? It seems odd to >>> hard-code all this, no? > >> It seems there is no api or function to support blind write from ACPI from latest upstream code, >> and we think it's easier for us to manage the different function's blind write. The problem is that those blind writes are supposed to be sku-specific, so it's not great to encode a behavior in a generic codec driver. It's my understanding that the Windows driver will rely on blind writes, it'd seem natural to use the same initialization parameters, no? > It's always possible for you to add shared code for things like parsing > ACPI tables (any references to the spec for blind writes here?). Yes, the code is already available in a prototype, see the initial code here: https://github.com/thesofproject/linux/pull/5010/commits/3e4ff84242dbb7774bbed785371d27c3afc10a96 The goal was to add a sound/soc/sdca library to parse ACPI function information, extract initialization tables, deal with interrupts, create controls, etc. That said, it's probably best if Bard and/or Charles take over since I won't be able to work on this short-term. One of the big opens is how we deal with regmap. In theory each SDCA function is independent from others, but in practice they all share a common control channel and interrupt mechanism. I initially thought we could have one regmap for each function, but Charles had a different idea that we should handle regmap at the device level. Both options have merits and issues, we didn't really reach a conclusion on this. One of the other opens is also related to regmap, we now have two types of regmap for SoundWire (sdw- and sdw-mbq), but there are parts of ASoC where components are assumed to have a single regmap.
