On Wed, Jan 15, 2014 at 01:27:21PM +0200, Jyri Sarha wrote:

On 12/31/2013 03:25 PM, Mark Brown wrote:

quoted

quoted

support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.

quoted

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.

quoted

quoted

+	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+				     2, 2);

quoted

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140121/b1d094fe/attachment.sig>