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
