On Tue, Oct 08, 2019 at 07:22:17PM +0800, Cheng-yi Chiang wrote: > The VPD is not part of the codec. > It is a binary blob in system firmware where we can store important > information per-device. > The calibration data is written to RO section of VPD in the factory > during calibration step. Ugh, this is not idiomatic for a DT system :( > The codec driver is not suitable of reading this information directly > because the string format written into VPD is customized per board. > For example on cml_rt1011_rt5682.c there are four R0 values for four The expected model for a DT system is that this stuff should just come in through DT properties, if for system design/manufacturing reasons it needs to be stored separately then you'd expect it to be merged into the main DT by the bootloader or something else earlier on in boot. > speakers, and one temperature values . So in this case, there are > totally 5 values in a VPD dsm_calib key. In VPD, the format is like > "dsm_calib"="0x00278F09 0x00251E1B 0x0021AFE6 0x0022720A 0x0000012E" > We put all the information into one string to allow arbitrary > calibration data needed for smart amp calibration in the future. > On other system using smart amp, there might be two speakers, with two > temperature values..etc. The format will be changed accordingly. > Number of temperature values depends on number of temperature sensor > available near the speakers. > Since machine driver knows the combination of speakers and the > available temperature sensor, we think that machine driver is the > better place to put this per-board logic. I'm not sure why they all need to be in one property? That's a secondary problem though.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
