> -----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.
