[alsa-devel] ASoC: new ac97 bus and codec clock

Rob Herring robh+dt at kernel.org
Tue Jun 19 19:56:41 CEST 2018


On Tue, Jun 19, 2018 at 9:02 AM, Mark Brown <broonie at kernel.org> wrote:
> On Sun, Jun 17, 2018 at 10:03:54PM +0200, Robert Jarzmik wrote:
>
>> The new ac97 is working well in a platform data build. But in the device tree
>> case, there is an issue, triggered by our review in [1].
>
>> The main issue is the lack of one clock.
>
>> The device hierarchy is :
>>  - platform device sound at 40500000 (the AC97 controller)
>>    \-> ac97 device sound at 40500000:0 (the discovered ac97 IP for a wm9713)
>
>> Now the issue is here :
>>  - sound/ac97/bus.c:419, function ac97_get_enable_clk()
>>  - the clk_get() fails
>
>> The sound at 40500000:0 device was automatically created by the AC97 bus code, but
>> I don't see any way to provide this device the "ac97_clk" ... How do you think
>> this is supposed to work, and how can my devicetree description provide this
>> clock ?

So the clock is a sideband signal outside the scope of AC97? If so...

> This sounds like a DT question - how do you hook things up using DT to a
> device that will be enumerated from the hardware?  I'm not sure what
> best practice is here, adding Rob and Frank.

Like PCI, USB, SDIO, etc., you need to define an AC97 bus binding
which defines child node structure, compatible formatting (if you can
base compatibles on something like VID/PID), and addressing (reg and
unit-address formats). Then once you define child nodes, you can add
whatever sideband connections you need. The AC97 core should be able
to populate struct device_node if there are any matching child
devices. It gets a bit more complicated if you need to do things like
enable power or de-assert resets to discover the devices. Sounds like
that might be the next person's problem in this case. :)

Rob


More information about the Alsa-devel mailing list