On Sun, Aug 9, 2009 at 6:48 AM, Mark Brownbroonie@sirena.org.uk wrote:
On Sat, Aug 08, 2009 at 02:44:48PM -0400, Jon Smirl wrote:
I think I have this backwards, the ac97 driver can take 8/16/24/32 it's the Bestcomm program that doesn't know about anything except 32b.
Remember, you need to consider the I2S driver as well.
#define SND_SOC_STD_AC97_FMTS (SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S32_LE |\ SNDRV_PCM_FMTBIT_S32_BE) shouldn't this be
#define SND_SOC_STD_AC97_FMTS (SNDRV_PCM_FMTBIT_S16 |\ SNDRV_PCM_FMTBIT_S32)
The first form says the AC97 hardware can take both endians, but it doesn't take both endians it takes the endian matching the machine it is attached to.
No, it can take any endianess - the wire format is fixed. The layout of the data in memory is of little interest to the CODEC. The formats used will be restricted by the CPU driver, the values there are essentially functioning as a wildcard match.
I agree with you, but I think the second form better indicates the wildcard than the first form. It makes it look like endianess is not a factor.
If you had used the second form I wouldn't have had a problem bringing up a powerpc driver.
Don't the standard AC97 formats also include 8 and 24b?
They'll include whatever the controller is happy to render down onto the bus. That's just the ones that people have needed so far.
We could add 8/24b now so to make thing easier on the next driver developer.