Re: [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 01/21/2014 09:15 PM, Mark Brown wrote:
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.


I do not disagree. I just do no not have a clear understanding how something like that should be done. Either the tda998x_drv it self should provide the ASoC codec driver or there should be some kind of API that could be accessed by some driver under sound/soc/codecs. Anyway it sound like Jean-Francois Moine is already doing that. I'll take his driver into use as soon as his code is merged.

However, for now a simple implementation that I have does not really need any interaction with the HDMI encoder and thus no codec driver either.

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


Sure, but it would not save form making runtime constraints. The usage of i2s mode, which limits the number of channels, is selected by dai_fmt call after dai registering.

Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux