Hi Morimoto-san,
On 8/24/2020 5:55 AM, Kuninori Morimoto wrote:
External email: Use caution opening links or attachments
Hi Mark Cc Sameer
Having an audio-graph-card2 isn't ideal but may be required at least during development :/ Ideally we'd be able to have the new driver parse both binding formats (or rather, have the new binding format be new use cases for the same binding format) and only use -card2 while it's in development.
If you want to update current audio-graph-card without creating new audio-graph-card2, I'm OK about it. But need adjusting / agreement.
Current audio-graph-card "DSP" user is only me, and I'm using it only locally. Thus upstream doesn't get damage if I removed "audio-graph-scu-card" (= DSP use case) support.
OTOH, Sameer is posting patch for "-cc-" support. If it was accepted and he used it on upstream (= on tegra), keeping compatibility will be very difficult and/or code will be very confusable.
If Sameer can OK and wait new audio-graph-card, maybe we have no compatibility issue. But in such case, 1st version of new audio-graph-card might be not enough for him. Sameer need to waiting / testing / adjusting / etc, etc...
The series [0] introduces small deltas to resolve issues I am facing. As you see, most of the implementation is unchanged for the graph-card driver. Hence I am not sure if we need a new driver now. If at all it gets complicated in future, the "-cc-" compatible can be moved to new driver? Please note that the new "-cc-" compatibility is added to address following and some of these are discussed in [1]. - DPCM usage with component model (where there can be N number of components available and M (<= N) of them can be connected together to form an audio path). For example the path would be like, FE -> BE_1 -> BE_2 -> ... -> BE_M. - I am extending dpcm_path_get() for this reason and DAI ops get called for all connected components.
[0] https://lkml.org/lkml/2020/8/5/42 [1] https://lkml.org/lkml/2020/4/30/519
Thank you for your help !!
Best regards
Kuninori Morimoto