Codec driver gets probed prior to the machine driver

Codec driver gets probed prior to the machine driver

[Fabio Estevam]

Hi,

When running linux-next 20130607 on a mx6qsabrelite I see that the
audio drivers fail to probe.
Added some printk's to better illustrate the problem:

mmcblk0: mmc0:b5a1 SD04G 3.69 GiB
**** reading the chip ID
sgtl5000: probe of 0-000a failed with error -5
****** enabling the codec clock
imx-sgtl5000 sound.13: ASoC: CODEC (null) not registered
imx-sgtl5000 sound.13: snd_soc_register_card failed (-517)
platform sound.13: Driver imx-sgtl5000 requests probe defer

The problem here is that the codec driver (sgtl5000) is being probed
prior to the machine driver (imx-sgtl5000).

The reading of the chip ID fails because at this point in time there
is no codec clock, which is turned on by imx-sgtl5000.

Running 3.10-rc4, the order of the events is as expected: imx-sgtl5000
is called first and sgtl5000 is called later.
In this case the probe works as usual.

Tried doing a bisect, but this was not succesful due to several bisect
breakages (build issues and non-booting kernels) on  its way.

Would anyone have some suggestion as to why the codec driver is
getting probed first?

Thanks,

Fabio Estevam

Re: Codec driver gets probed prior to the machine driver

[Lars-Peter Clausen]

On 06/09/2013 04:50 PM, Fabio Estevam wrote:
> Hi,
> 
> When running linux-next 20130607 on a mx6qsabrelite I see that the audio
> drivers fail to probe. Added some printk's to better illustrate the
> problem:
> 
> mmcblk0: mmc0:b5a1 SD04G 3.69 GiB **** reading the chip ID sgtl5000: probe
> of 0-000a failed with error -5 ****** enabling the codec clock 
> imx-sgtl5000 sound.13: ASoC: CODEC (null) not registered imx-sgtl5000
> sound.13: snd_soc_register_card failed (-517) platform sound.13: Driver
> imx-sgtl5000 requests probe defer
> 
> The problem here is that the codec driver (sgtl5000) is being probed prior
> to the machine driver (imx-sgtl5000).
> 
> The reading of the chip ID fails because at this point in time there is no
> codec clock, which is turned on by imx-sgtl5000.

This sounds as if the CODEC driver should enable the CODEC clock and not the
machine driver.

> 
> Running 3.10-rc4, the order of the events is as expected: imx-sgtl5000 is
> called first and sgtl5000 is called later. In this case the probe works as
> usual.

There are two probe functions one for the i2c driver, one for the codec. The
I2C driver probe will be called as soon as the I2C device gets registered.
The codec probe will be called once all components for the ASoC sound card
(CPU DAI, codec, platform) are ready. Since you are checking the ID in the
I2C probe callback there is no guarantee that it will be called before or
after the machine driver will be probed.

> 
> Tried doing a bisect, but this was not succesful due to several bisect 
> breakages (build issues and non-booting kernels) on  its way.
> 

Well, your commit b871f1ad ("ASoC: sgtl5000: Read SGTL5000_CHIP_ID in
i2c_probe") moved things around. From one probe callback to the other.

- Lars

Re: Codec driver gets probed prior to the machine driver

[Fabio Estevam]

Hi Lars-Peter,

On Sun, Jun 9, 2013 at 12:12 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:

> This sounds as if the CODEC driver should enable the CODEC clock and not the
> machine driver.

Thanks, this works fine. Will send the patches soon.

Thanks for your help.

Fabio Estevam

Re: Codec driver gets probed prior to the machine driver

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 692 bytes --]

On Sun, Jun 09, 2013 at 05:12:57PM +0200, Lars-Peter Clausen wrote:
> On 06/09/2013 04:50 PM, Fabio Estevam wrote:

> > The reading of the chip ID fails because at this point in time there is no
> > codec clock, which is turned on by imx-sgtl5000.

> This sounds as if the CODEC driver should enable the CODEC clock and not the
> machine driver.

Well, probably both.  Remember that we don't actually have a standard
clock API, even the generic clock API is not available on most
platforms.  Though frankly I'm getting fed up enough with this to just
start using the API and getting platforms that haven't provided one to
deal with the issue since otherwise I'm getting very little traction.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]