On Fri, Mar 27, 2009 at 05:09:08PM +0100, Daniel Glöckner wrote:
On 03/26/2009 03:15 PM, Mark Brown wrote:
I'm not seeing any hits on XTENSA_VARIANT_S6000 in next? While that shouldn't hurt immediately since it'll just never appear it'd be good to make sure that the APIs this depends on are going into mainline in the form they're in. Do you know what the status is there?
The patch introducing XTENSA_VARIANT_S6000 has already been reviewed by the architecture maintainer and there is hope that it will make it into 2.6.30. The dma api, which we posted four days ago to LKML, has not received any comments so far.
OK, might be worth nagging the architecture maintainer to get their tree included in -next if it isn't already.
+#define S6000_I2S_RATES (SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_KNOT | \
SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000)SND_PCM_RATE_KNOT doesn't work with ASoC (though it shouldn't do any harm since it'll just get removed).
Except for the maximum bit clock (50 MHz) the interface doesn't care about the sampling rate, so I put in all SNDRV_PCM_RATE_* constants. Shall I remove it?
Yes, please - this applies to almost all CPU side drivers, it's kind of unfortunate but in practice it generally makes very little practical difference since applications tend to use one of the standard audio rates.
Any reason to expose these to users?
This was an attempt to avoid symbol exports.. I'll move everything to s6000-i2s.c and export the three necessary functions.
Which functions are you exporting? None of this looked like anything that I'd expect to see used outside of the driver.