[Sound-open-firmware] [PATCH 2/3] ASoC: add function parameters to enable forced path pruning

[Guennadi Liakhovetski]

Hi Mark,

On Wed, Mar 11, 2020 at 12:25:31PM +0000, Mark Brown wrote:
> On Wed, Mar 11, 2020 at 08:41:27AM +0100, Guennadi Liakhovetski wrote:
> > On Tue, Mar 10, 2020 at 12:45:44PM +0000, Mark Brown wrote:
> 
> > > So why doesn't DPCM recognize that the path is inactive and why is it
> > > better to do this than fix whatever the issue is there?
> 
> > Of course that would be better abd I'd much prefer that. Unfortunately I 
> > haven't been able to find a single scenario in which those paths would be 
> > exercised. As far as I understand path pruning should take place e.g. 
> > when a mixer modifies audio routing and as a result disables a certain 
> > pipeline, which is then pruned. If I could reproduce such a scenario I 
> > would be able to first check whether it's working, then see exactly how 
> > it is working and then see how best to add my use case to it. Since I 
> > wasn't able to find such a scenario, my only option was to preserve 
> > the current state and add my own path "on top." I'd be happy to try the 
> > other path too, I just need a use case, that I can reproduce.
> 
> It's still not clear to me what the issue is here.  If something is
> making a modification to the graph which needs a recheck or update I'd
> expect that these things happen along with that modification.  I don't
> understand what you're saying about not being able to reproduce
> scenarios or adding things "on top".

I mean, that I don't have a test-case to test dpcm_prune_paths() without my 
VirtIO support. That function currently exists in the kernel, but I don't 
have a test-case to verify its work, to see it called and actually perform 
the pruning. So I don't know how it is supposed to work. And because of 
that I cannot fix my VirtIO use case to use that function properly, without 
forcing it with an additional parameter.

Thanks
Guennadi