On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:
On 12/31/2013 03:25 PM, Mark Brown wrote:
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least significant bits are ignored.
Where does this constraint come from?
From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N register statically to a value that works only with 4 byte samples. According to my tests it is possible to support 3 and 2 byte samples too by changing the CTS_N register value, but I am not sure if the configuration can be changed on the fly. My data sheet of the nxp chip is very vague about the register definitions, but I suppose the register configures some clock divider on the chip. HDMI supports only upto 24bit audio and the data sheet states that any extraneous least significant bits are ignored.
Hrm. This sounds like it ought to be presenting as an ASoC CODEC driver.
- snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
2, 2);
Why not just set all this statically when registering the DAI?
Because there is no relevant DAI to where to put these limitations. I did not want to add yet another dummy codec driver, but decided to use the already existing ASoC HDMI codec. By default the driver support all audio params supported by HDMI. The limitations are coming from NXP chip, the NXP driver, and because the chip is used in i2s mode. In other words the limitation is coming from machine setup, not from the DAIs.
OK, but it sounds like it's got register configuration as well? That really does sound like a device that ought to have a driver...
No excuse for i initialization, I'll fix that. The casting is just to survive with just one kmalloc call instead of separate memory blobs for struct snd_pcm_hw_constraint_list and referred list of supported sample rates. I'll allocate a second blob, if that is easier to read.
Yes, please. Unless it's something where memory is getting tight (eg, due to be allocated a lot) it's more important that we can read the code than that we save a few bytes.