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/3e4ff84242dbb7774bb...
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.