getting dynamic state from ac97 bus ops

getting dynamic state from ac97 bus ops

[Mike Frysinger]

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 ...
-mike

Re: getting dynamic state from ac97 bus ops

[Mark Brown]

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 ...

Please remember to CC maintainers on mails if you want to see them.

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.

Re: getting dynamic state from ac97 bus ops

[Mike Frysinger]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: getting dynamic state from ac97 bus ops

[Mark Brown]

On Mon, Mar 28, 2011 at 06:20:23AM -0400, Mike Frysinger wrote:

> 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.

These drivers all predate multi-component and in many cases they only
physically support a single device.

> 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
> so atm i have:

I wouldn't worry about it unless someone actually comes up with a
multi-CODEC embedded AC'97 system.  New designs tend to be I2S based
rather than AC'97 based as the PC market moved away from AC'97 so
there's less benefit to designing with it - it's likely that any effort
spent here wouldn't actually benefit anyone.