On 2020/5/23 上午8:11, Mukunda, Vijendar wrote:
-----Original Message-----
From: Mark Brown <broonie@xxxxxxxxxx>
Sent: Friday, May 22, 2020 9:02 PM
To: Mukunda, Vijendar <Vijendar.Mukunda@xxxxxxx>
Cc: Hui Wang <hui.wang@xxxxxxxxxxxxx>; alsa-devel@xxxxxxxxxxxxxxxx
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.
