Re: [RFC 0/4] ASoC DSP topology

[Peter Ujfalusi <peter.ujfalusi@ti.com>]

On 04/21/2015 12:28 PM, Mark Brown wrote:
> On Tue, Apr 21, 2015 at 09:58:27AM +0300, Peter Ujfalusi wrote:
> 
>> It is not entirely clear for me based on the first look, but who is
>> responsible to initiate the topology load? Is it the component or machine
>> driver? We have had issues with deferred probing when the component driver was
>> in charge of loading the firmware. I got around this by initiating the FW load
>> from the machine driver and via callbacks I notified the component driver to
>> take over from that point. This fixed the probe order and I can also handle
>> cases when the filesystem does not have the firmware so I can fall back to
>> 'legacy' mode.
> 
> Could you expand on those issues please?  I'd *really* not expect the
> machine driver to be involved in loading firmware for a component driver
> (think how this is going to affect generic drivers) and it's not obvious
> to me what impact this might have on deferred probe either.

The two issue were interconnected. We had cases when all components have been
loaded, but the machine driver was still in the deferred list, if we loaded
any non related module the card will suddenly got created.
It is due to the firmware loading. The firmware load will not kick the
deferred module list (we had a hack in place to kick the queue from the ABE
driver):
Components are loaded and registered in ASoC with the exception of the parts
needing the FW, since the dynamic FW contained widgets, routes, etc. So the
ABE driver loaded and requested the FW, probe exited with success. Machine
driver is still not able to form the card since the ABE widgets, PCMs are
missing, it goes to deferred probe. The ABE driver loads the dynamic FW,
parses it, DAPM widgets, PCMs, routes are created and registered. But the
machine driver is in deferred list and there is nothing to kick that queue,
which means that we have everything, but the card is not created.

But if we initiate the FW load from the machine driver and we pass the FW down
to the component driver(s) interested in handling the FW we are going to be
fine since we only register the card when the component drivers already parsed
and processed the FW image.

In this way we can have fall back for cases when the FW is not available on
the filesystem (some distro might want to go w/o binary blob).

We have discussed this with Liam in the past: in my view the DSP topology (or
Dynamic FW) should be represented in the machine level and it would be the
best if the same image could carry card level widgets routes and links. If you
have big enough change in the FW and it's provided widgets/PCMs you would need
separate machine driver or at least a way to have different set of machine
level routes, widgets, links, etc for different DSP topology file.

One of the issue with this: When we need to call the component driver's
firmware load function (to process the FW and create the widgets and then
register the component) the component is not registered (we need the firmware
to set up things) so generic snd_soc_* callback is not possible to use

-- 
Péter