Thread (48 messages) 48 messages, 6 authors, 2014-01-24

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

From: Anssi Hannula <hidden>
Date: 2014-01-15 13:48:29
Also in: alsa-devel, dri-devel, linux-devicetree, linux-omap

15.01.2014 13:27, Jyri Sarha kirjoitti:
On 12/31/2013 03:25 PM, Mark Brown wrote:
quoted
On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
quoted
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.
That sounds strange, CTS/N values only depend on audio sample rate and
TMDS/video clock, not on the audio format or the size of samples (HDMI
spec sec 7.2 - Audio Sample Clock Capture and Regeneration).

Sure there isn't anything more going on (like the used HDMI sink being
more tolerant to wrong CTS/N with 4-byte samples, or more likely
something else I can't immediately think of)?


BTW, radeon driver has some code that calculates static CTS/N values
since the hw autogeneration is not reliable there:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600_hdmi.c
Not that it directly helps now, but just for the record...

-- 
Anssi Hannula
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help