On Tue, Jun 19, 2018 at 9:02 AM, Mark Brown <broonie@xxxxxxxxxx> 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@40500000 (the AC97 controller) >> \-> ac97 device sound@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@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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
