On Mon, Mar 28, 2011 at 06:06, Mark Brown wrote:
On Sun, Mar 27, 2011 at 10:48:52PM -0400, Mike Frysinger wrote:
is there an obvious way that i'm missing to get at the bus state from the funcs in the global soc_ac97_ops structure ? the ac97 bus drivers that i see in the tree simply have a global variable for state and that sort of defeats the purpose of having multi-instance support in the first place ...
I'm not sure what you mean by "bus state" but the AC'97 support in ASoC is really intended for the sort of single CODEC systems you typically see on embedded boards. It's mostly there because some of the later AC'97 CODECs started to grow a lot of non-standard power management and routing.
looking at the cpu dai drivers which declare soc_ac97_ops: au1x/psc-ac97.c:au1xpsc_ac97_workdata ep93xx/ep93xx-ac97.c:ep93xx_ac97_info fsl/mpc5200_psc_ac97.c:psc_dma ... and so on ...
this is state specific to the ac97 bus connection (snd_ac97_bus_ops), not the specific machine driver which links the codec to the transport, and currently all of these guys do it globally. which means only 1 AC97 codec can be in play in the system.
the Blackfin has multiple SPORTs and could do one AC97 codec per SPORT. but atm, there is only one global soc_ac97_ops structure, and i cant see how the functions in that structure could get at the link-specific state so that the bus driver would work with multiple AC97 codecs.
granted, no customer that i know of has asked for this (more than AC97 codec), it's just a limitation i noticed when working on an AC97 driver, and i figured i might as well do it right while i'm cleaning crap out already.
so atm i have: ... static struct sport_device *ac97_sport_handle; ... static unsigned short bf5xx_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct sport_device *sport_handle = ac97_sport_handle; ...
when really i'd expect ac97_sport_handle to not exist and to be able to get that via the struct snd_ac97 that gets passed in. -mike