ASoC: soc_sdw_utils: skip the endpoint that doesn't present

[bardliao]

A codec endpoint may not be used. We could check the present SDCA
functions to know if the endpoint is used or not. Skip the endpoint
which is not used.

The first 12 commits are from #5128. Please review the last commit. That is a proposal to skip the unused endpoints.

[plbossart]

can this happen?

I am wondering if the deferred-probe mechanism doesn't already guarantee that if this function is reached than all resources were registered.

Probably a question for @charleskeepax and @shumingfan as well.

[charleskeepax]

I think these can indeed be missing here. Until snd_soc_register_card (which we are before since we are building the DAI links) is called there is no connection between the drivers, but once that is called ASoC will check if all the components are probed.

[bardliao]

We don't need the connection. What we need is devm_snd_soc_register_component() being called by codec drivers. The thing is machine driver could probe before codec driver. And machine driver will probe again after codec driver is probed. Not sure what should I do here in this scenario. Maybe just create the dai link as usual and let ASoC do machine probe again?

[charleskeepax]

Hmm... yes one needs to be careful here, because the codec probe could be totally asynchronous to us here. So it would be possible that this code here runs, then the codec probes, then we call devm_snd_soc_register_component. So I don't think we could rely on register component to probe defer.

I suspect we need to handle probe defers here, should we not be returning -EPROBE_DEFER rather than -EAGAIN?

[bardliao]

Hmm... yes one needs to be careful here, because the codec probe could be totally asynchronous to us here. So it would be possible that this code here runs, then the codec probes, then we call devm_snd_soc_register_component. So I don't think we could rely on register component to probe defer.

I suspect we need to handle probe defers here, should we not be returning -EPROBE_DEFER rather than -EAGAIN?

Yes, it is for this purpose. Thanks.

[charleskeepax]

Would it be better to use the type here? It gets patched up I think in the case of the older versions of the standard, so it seems a bit nicer than string matching.

[bardliao]

Yes, my first version is to use type. However, we have different SDCA function types map to the same DAI type.

enum sdca_function_type {
	SDCA_FUNCTION_TYPE_SMART_AMP	= 0x01,	/* Amplifier with protection features */
	SDCA_FUNCTION_TYPE_SIMPLE_AMP	= 0x02,	/* subset of SmartAmp */
	SDCA_FUNCTION_TYPE_SMART_MIC	= 0x03,	/* Smart microphone with acoustic triggers */
	SDCA_FUNCTION_TYPE_SIMPLE_MIC	= 0x04,	/* subset of SmartMic */
	SDCA_FUNCTION_TYPE_SPEAKER_MIC	= 0x05,	/* Combination of SmartMic and SmartAmp */
	SDCA_FUNCTION_TYPE_UAJ		= 0x06,	/* 3.5mm Universal Audio jack */
	SDCA_FUNCTION_TYPE_RJ		= 0x07,	/* Retaskable jack */
	SDCA_FUNCTION_TYPE_SIMPLE_JACK	= 0x08,	/* Subset of UAJ */
	SDCA_FUNCTION_TYPE_HID		= 0x0A,	/* Human Interface Device, for e.g. buttons */
	SDCA_FUNCTION_TYPE_IMP_DEF	= 0x1F,	/* Implementation-defined function */
};

For example, SOC_SDW_DAI_TYPE_AMP could be SDCA_FUNCTION_TYPE_SMART_AMP or SDCA_FUNCTION_TYPE_SIMPLE_AMP. And so do SOC_SDW_DAI_TYPE_JACK and SOC_SDW_DAI_TYPE_MIC

[charleskeepax]

You could do something like add a function:

int asoc_sdw_get_dai_type(u32 type) {
        switch (type) {
                case SDCA_FUNCTION_TYPE_SMART_AMP:
                case SDCA_FUNCTION_TYPE_SIMPLE_AMP:
                        return SOC_SDW_DAI_TYPE_JACK;
                case SDCA_FUNCTION_TYPE_SMART_MIC:
                case SDCA_FUNCTION_TYPE_SIMPLE_MIC:
                case SDCA_FUNCTION_TYPE_SPEAKER_MIC:
                        return SOC_SDW_DAI_TYPE_MIC;
                case SDCA_FUNCTION_TYPE_UAJ:
                case SDCA_FUNCTION_TYPE_RJ:
                case SDCA_FUNCTION_TYPE_SIMPLE_JACK:
                        return SOC_SDW_DAI_TYPE_JACK;
                default:
                        return -EINVAL;
        }
}

Then update your loop to something like:

for (k = 0; k < slave->sdca_data.num_functions; k++) {
        int dai_type = asoc_sdw_get_dai_type(slave->sdca_data.sdca_func[k].type);

        if (dai_type == dai_info->dai_type) {
                dev_dbg(&slave->dev, "Function %s found\n",
                                slave->sdca_data.sdca_func[k].name);
                break;
        }
}

[bardliao]

Yes, it looks better. Thanks @charleskeepax

[bardliao]

I tested it by blacklist the codec driver first and then modprobe it after the machine driver probed. And it works.