Mark Brown <broonie@xxxxxxxxxx> writes: >> > It will eumerate the AC'97 bus by itself and does not need the CODEC to >> > be described. > >> I think I still don't get it. > >> So let's rephrase it another way : how will the function wm9713_probe() be >> called, ie. what is the possible function backtrace leading to that call ? > > It will not be called, the generic AC'97 code will be used. Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right ? In that case wm9713_set_dai_clkdiv() will never be used, nor will the wm9713_audio_map or wm9713_dapm_widgets be created, which will break all userspace programs relying on these mixers and DAPM routes. Or am I missing something ? >> Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I >> can have a look at to understand ? > > Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but > same effect). I suppose you mean sound/arm/aaci.c, which is more a platform_data like driver (if I understood the integrator code correctly). I suppose we can achieve comparable result with sound/arm/pxa2xx-ac97.c, but as to know if the functionality will be comparable to sound/soc/pxa/pxa2xx-ac97.c, it's hard to say. If I count the DMA requestors, I see 5 in the sound/soc version, and 2 in sound/arm. That makes me believe the sound/arm version is inferior. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
