[PATCH v2] ASoC: amd: put off registering mach platform_dev to avoid -517 err

[Hui Wang]

On 2020/5/23 上午8:11, Mukunda, Vijendar wrote:
>
>> -----Original Message-----
>> From: Mark Brown <broonie at kernel.org>
>> Sent: Friday, May 22, 2020 9:02 PM
>> To: Mukunda, Vijendar <Vijendar.Mukunda at amd.com>
>> Cc: Hui Wang <hui.wang at canonical.com>; alsa-devel at alsa-project.org
>> Subject: Re: [PATCH v2] ASoC: amd: put off registering mach platform_dev to
>> avoid -517 err
>>
>> On Fri, May 22, 2020 at 03:14:21PM +0000, Mukunda, Vijendar wrote:
>>
>>> I have seen sample implementation of deferred probe in one of the machine
>>> driver code using late_initcall() API.
>>> Not sure how this api really works which will resolve the modules loading
>> sequence
>>> issue.
>> What deferred probe does is keep a list of devices that failed to bind
>> with a deferred probe error code then every time a device does manage to
>> bind it retries all those failed devices in case the new device provides
>> whatever was missing from one of the others.  It's a bit brute force and
>> ignorance but it does sort things out in the end if all the drivers are
>> actually there and just loaded in the wrong order.
> We see one more problem with this patch.
> We are going to add support for I2S endpoint on another
> platform based on Renoir.
>
> Platform device creation logic going to be expanded in ACP PCI
> driver probe call.
> Because ACP Is Parent device , Ideally platform devices creation logic
> should be handled in ACP PCI driver.
>
> Based on Audio configuration, During ACP PCI driver probe call,
> platform devices will be created.
>
> In case of I2S endpoint support,  machine driver gets probed via acpi dev id match.
> If we go ahead with this patch, We have to expand the work around logic
> by adding extra check in PDM DMA driver  which doesn't seems to be good.
>
> Currently I observed only two times sound card registration failure in dmesg
> during boot time.
> For the sake of avoiding  few card registration failure logs observed in dmesg,
> I don't think at this stage, we really need to go ahead with this patch.

OK, got it, thanks.


>
>
>
>
>
>
>