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.
