Hi Morimoto-san,
But, I guess new driver 1st version is focus to detecting normal-link and DPCM-link only.
Do you plan to propose something like enum for card2 and has scope for extension, where link type can be normal/DPCM/codec-to-codec/etc., ? Since there are so many board variants and may have some specific requirements, I am wondering being able to detect link type from DT should be the only motivation for a new driver.
I'm now thinking that new one can detect normal-link, DPCM-link, multi-CPU / multi-Codec, Codec-to-Codec as normal audio-graph feature. And has .hook callback for Eeach board specific feature. see my previous mail which was To:Pierre-Louis But, it is still under idea, not yet fixed.
If we plan to go this way, I think we need to consider board specific configuration at init time and one at runtime. In that case there could be multiple compatibles that would get added to the driver and various other requirements can be managed with behavioral flags instead from DT?
Thanks, Sameer.